The MD2 post made me attempt to setup a Xith3D build environment to try stuff out. Some problems came up while I was doing this:
Though the source is 1.4 compatible the build thats available has been built using 1.5 source compatibility. Unfortunately this means I can’t use it against a 1.4 VM out of the box (since you get a class version in compatibilty) - just an irritation - have to rebuild everything
I wanted to use the JOGL based renderer - however the JSR 231 jogl libraries arn’t included in the dependencies bundle from the website.
I then tried to use the LWJGL renderer which simply failed on the first render loop with:
java.lang.NullPointerException
at org.lwjgl.opengl.GL11.glGetInteger(GL11.java:1799)
at com.xith3d.render.lwjgl.CanvasPeerImpl.renderStart(CanvasPeerImpl.java:285)
at com.xith3d.render.lwjgl.CanvasPeerImpl.display(CanvasPeerImpl.java:868)
at com.xith3d.render.lwjgl.CanvasPeerImpl.render(CanvasPeerImpl.java:1035)
at com.xith3d.scenegraph.View.renderOnce(View.java:616)
at com.xith3d.scenegraph.View.renderOnce(View.java:549)
at MD2Test.run(MD2Test.java:144)
at java.lang.Thread.run(Thread.java:595)
Which I believe means the display isn’t created when you’re attempting to make GL11 calls.
The userinterface package seems to be broken (or its changed significantly since the MD2Test was written, entirely possible). However, I got no compile errors, everything looked fine. Only failed when calling setComponent(). If its not supported it any more I guess the examples using it should be removed?
Is Xith using an issue tracker that I can log these things in outside of that evil java.net thing?
Incidently, up and running now with fresh downloads of the JOGL libs. Refreshing to find the model loads happily and displayed exactly as I remember it Oh, Marvin the Martian, how I love you
Sorry about that, we decided switching to 1.5 some time ago and even if the core doesn’t use any 1.5 feature the toolkit does (Arne’s picking code use generics)
I thought I fixed that in 0.7.1… are you sure you have it ? 0.7.0 didn’t include them, was my fault. (In 0.7.1 these are in the jogl directory, it’s not called jsr231 or whatever).
I don’t know if the LWJGL renderer is still supported…
The Swing UI package still works, I use it successfully. By “failed” you mean it throw an exception ? Here’s the code I use :
// Window manager
windowMgr = new UIWindowManager(graphic.getCanvas());
UIEventAdapter eventAdapter = new UIEventAdapter(windowMgr);
graphic.getCanvas().get3DPeer().getComponent().addKeyListener(eventAdapter);
graphic.getCanvas().get3DPeer().getComponent().addMouseListener(eventAdapter);
graphic.getCanvas().get3DPeer().getComponent().addMouseMotionListener(
eventAdapter);
graphic.getCanvas().get3DPeer().getComponent().setFocusable(true);
graphic.getLocale().addBranchGraph(windowMgr);
// Creates a new UIPanel
UIPanel uiPanel = new UIPanel();
// create a double buffered JPanel
panel = new JPanel(true);
panel.setLayout(new GridLayout(1, 0));
panel.setSize(new Dimension(width, height));
panel.setOpaque(false);
// title
JLabel titleLabel = new JLabel("Stratagem");
titleLabel.setForeground(Color.WHITE);
panel.add(titleLabel);
// FPS
FPSlabel = new JLabel("FPS = ");
FPSlabel.setForeground(Color.WHITE);
panel.add(FPSlabel);
// include the exit button if it's wanted
if (includeExitButton) {
JButton exitButton = new JButton();
exitButton.setText("Capituler");
exitButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
System.exit(0);
}
});
panel.add(exitButton);
}
// specify the root component of the UI window
uiPanel.setRoot(panel);
// in the main loop
while(true) {
// ...
windowMgr.newFrame(scene.getView().getTransform());
// ...
}
I’m afraid there’s not… However if there is a cool Joomla! module for Issue Tracking I’ll set it up happily.
Hmm… I spent some time fixing path issues in the OBJ/3DS/MD2 loaders… at least it works now (there had some problems with absolute/relative path, “” or “/” separators, loading from jars, classpath and all these tricks…).
If the LWJGLRenderer is no longer supported - remove it. If it is intended to be and it doesn’t work then it needs to be noted somewhere - and possible removed from the formal builds until it does? (leave it in the nightly builds)
Does that mean nothing outside of java.net ? Or nothing at all?
As far as I’m aware the loaders have always simply read from input streams. If someone added a layer wrapping that with an incorrect file handling - meh. The point is the MD2Test.java that I downloaded from the newdawn site needed:
The package names changing
The rendering peer changing
The UI stuff removing
And then … it just worked … which is a lovely state to be in
What sort of an abomination of a source format is that? Never since I worked with C++ military applications have I seen something that makes it so hard to read and maintain code.
The code appears to be just cut and pastes of things within the original MD2Loader but refactored into the loading interface - which of course makes sense. However, my eyes go funny just trying to read it - wheres the javadoc? Whats the point of all these imposed lines of slahes? Wheres in the inline doc? Wheres the param tags, return tags etc? Why is it all tabbed in one space? Why is it formatted to a 80 character width - most people don’t use fix width editors these days? More than anything - why didn’t it just defer to MD2Loader - so we’d only have one place to maintain.
I’d almost got up the enthusiasm to get involved with Xith again but things like this just make me think I’d spend more time fighting whats already there. The only way I am able to navigate this is have eclipse do all the donkey work for me - not particularly pleasent.
I thought at one point (maybe some years ago now) - Xith had aggreed to just use the Sun standards for coding like everyone else in the Java world?
Kev
PS. The source on the website seems to be one version out of date with whats in the build also.
PPS. Still thank god for William’s showsrc tool - thats one handy script
Hmm, actually the standard LoaderBase also doesn’t really make sense at all for MD2s since you’ll always want to specify a skin to go along with your model - hence the need for the addition of the non-standard methods:
public String getTextureFilename ( )
public void setTextureFilename ( String textureFilename )
Why comply to the interface (no, not a java one, just the interface of the class) when it doesn’t fit and ends up making the loading process more convoluted?
I wrote that code. I was trained to write code while I was in the military and that is indeed a derivative of the military style. Funny that you should make that connection.
Supposedly it should make code much easier to read and maintain. At least that’s why the military uses it.
I think (at least from my experience at a 2 large UK defense companies) that this sort of style is easy to read when you’ve been taught it from day one. Its a learned readability. I personally learnt with a completely different style to this one and the java conventions - however, I found the Sun standard Java conventions natural and clear. Obviously its only opinion - but given the breadth of developers that could contribute to Xith its nice to see that an open standard has been adopted for the core.
Ah, forgot this one. And in xith3d-0.7.1.tar.gz, directory third-party/jogl/ should contain JSR-231. But the third-party.tar.gz file doesn’t contain JSR-231, either. I’m sorry this will be fixed soon I still have to get more familiar with Xith build process.
Hmm. It’s intended to be supported it’s just a bit old I may take time to debug it.
About the UI stuff, I’d like to see your old code (when it wasn’t working) cause it works perfectly for me so there’s no reason it shouldn’t work for you.
You’re right, that’d be cool if croft adopted Sun coding standards like “everyone” else. However if he won’t, I’m not willing to refuse to include its contributions just because of the source code conventions. I’d rather refactor the whole source files myself than miss the Collada loader.
Yeah that’s one problem with Scene and LoaderBase and all that stuff. It’s not designed for animated or skinnable thingies… I cannot imagine how it would be doable to port Cal3Dj to Xith3D complying to LoaderBase.
About javadoc… I saw that there has been differences between the old builds (when it was numbered like 20050823) and the CVS. I think some has magically appeared. I complete some when I’ve got no other very important things to do. Now can we copy/adapt/paste the javadoc from Java3D when it’s applicable ? (I didn’t do that, it’s just do know).
[quote="<MagicSpark.org [ BlueSky ]>,post:11,topic:27540"]
Yeah that’s one problem with Scene and LoaderBase and all that stuff. It’s not designed for animated or skinnable thingies… I cannot imagine how it would be doable to port Cal3Dj to Xith3D complying to LoaderBase.
[/quote]
I was able to get COLLADA animations to work with LoaderBase by converting the animations to Java 3D API Behavior classes.
I was able to get COLLADA animations to work with LoaderBase by converting the animations to Java 3D API Behavior classes.
[/quote]
Hmm… what about performances ? And do you have to call an update() method each step yoursefl ?
[quote="<MagicSpark.org [ BlueSky ]>,post:13,topic:27540"]
Hmm… what about performances ? And do you have to call an update() method each step yoursefl ?
[/quote]
I’m hitting my target frame rate.
Well, its in the toolkit - so there isn’t any refusual of code anyway? Either way its was an observation of something that might be making it hard for people to get involved (I’m still struggling to understand why there don’t seem to be many hands to “all” the work round Xith at the moment).
Oh, Marvin the Martian, how I love you 