Can someone cover some of the differences between the two scene graphs?
I like both web sites and they both look like great APIs. When the time comes to use a scene graph, I don’t want to dabble, I’d rather really commit to learning one or the other.
I don’t want to know which is better, as I’m sure they both have the strengths.
Regards,
Dr. A>
They both have strenghts. My advice, look at the starter guide for jME at their web page. Look at how the code is structured. Go through about 2-3 programs. Then look at the Xith3D starter guide at their web page. Look at their code structure. Go through about 2-3 programs. Pick the API who’s code feels more natural for you.
That’s about as unbias as I can be 
Xith3d API is based on java3d, so if you have experience in it, you can start coding almost straight away. Other than that, jME is probably a bit easier to grasp for beginner.
As far as internals are concerned, xith3d state management/sorting is a more sophisticated at the moment, so there is a chance you might get better performance - but this comes at cost of less trivial library code, so changes are rather harder.
Xith3d is a more complete currently, but jME is a lot more active.
jME contains a bit more things inside - while xith3d is mainly visualisation api (game oriented, but focused on graphics/3d world), jME seems to extend in other areas with more game engine functionality outside this area. You have to decide if you want AI routines bundled in same package - there are pros and cons to this.
the AI routines will never be incoorporated into the same package as jME. They will be a seperate jar to download. So if you feel you cant be bothered to write your own AI routines/library, you can use jME’s which integrates nicely into jME.
DP
Hi there,
I tested last release version of Xith using latest JOGL against JME 0.7 using LWJGL 0.9, the test consisted of loading 600000 triangles of geometry with one light source. Xith rendered around 16fps, while jME was giving me 4-5fps.
Tested on GF4600Ti Athlon 1800, Java 1.4.2 and 1.5b
I’ld be interested in seeing the source code.
I’d like to see the source as well!
Screen shots from similar vantage points might also be interesting.
We’ve recently added a few things in CVS that would give jME a nice in scenesgraphs with many objects, if your scene is one mesh of 600,000 tris… well is that normal for games? Even so, we haven’t run into that situation much yet so there’s probably room for good improvements.
Hi,
Xith:
JME
The model has around 30000 polygons, I was experimenting with large models coz I am working on a visualization system that will have high res models.
I can’t provide the source code for the Xith demo coz it is big, but it is pretty much the same concept as the jME test, I loaded all the objects in to the scene graph, added one light source and moved the camera. Xith objects were loaded from 3DS file while on jME side I used MilkShape loader. I have coded my own camera movement in Xith app, while on jME side I used the default stuff.
I just found that I used Spot Light in Xith, and Point Light in jME, could that make such a big difference?
and here is a jME code…
public class TestMilkLoader extends SimpleGame{
public static void main(String[] args) {
TestMilkLoader app=new TestMilkLoader();
app.setDialogBehaviour(ALWAYS_SHOW_PROPS_DIALOG);
app.start();
}
// The new loader
protected void simpleInitGame() {
// Idealy this could be replaced by
// Loader mi=new AutoCadLoader(); ect
LWJGLCullState s = new LWJGLCullState();
Loader mi=new MilkLoader();
//mi.setLoadFlag(Loader.LOAD_CONTROLLERS);
mi.setLoadFlag(Loader.PRECOMPUTE_BOUNDS);
URL MSFile=TestMilkLoader.class.getClassLoader().getResource(
"jmetest/data/model/msascii/body.ms3d");
mi.setBase(TestMilkLoader.class.getClassLoader().getResource(
"jmetest/data/model/msascii/"));
Node mi1=mi.load(MSFile);
//mi1.setLocalScale(.1f);
//mi1.getController(0).setSpeed(10f);
// ((MilkAnimation) mi1.getController(0)).setSkipRate(.01f);
rootNode.attachChild(mi1);
s.setCullMode(CullState.CS_BACK);
s.setEnabled(true);
Node mi2=mi.load(MSFile);
Node mi3=mi.load(MSFile);
Node mi4=mi.load(MSFile);
Node mi5=mi.load(MSFile);
Node mi6=mi.load(MSFile);
Node mi7=mi.load(MSFile);
Node mi8=mi.load(MSFile);
Node mi9=mi.load(MSFile);
Node mi10=mi.load(MSFile);
Node mi11=mi.load(MSFile);
Node mi12=mi.load(MSFile);
Node mi13=mi.load(MSFile);
Node mi14=mi.load(MSFile);
Node mi15=mi.load(MSFile);
Node mi16=mi.load(MSFile);
Node mi17=mi.load(MSFile);
Node mi18=mi.load(MSFile);
Node mi19=mi.load(MSFile);
mi19.setLocalTranslation(new Vector3f(0,0,-360));
mi18.setLocalTranslation(new Vector3f(0,0,-340));
mi17.setLocalTranslation(new Vector3f(0,0,-320));
mi16.setLocalTranslation(new Vector3f(0,0,-300));
mi15.setLocalTranslation(new Vector3f(0,0,-280));
mi14.setLocalTranslation(new Vector3f(0,0,-260));
mi13.setLocalTranslation(new Vector3f(0,0,-240));
mi12.setLocalTranslation(new Vector3f(0,0,-220));
mi11.setLocalTranslation(new Vector3f(0,0,-200));
mi10.setLocalTranslation(new Vector3f(0,0,-180));
mi9.setLocalTranslation(new Vector3f(0,0,-160));
mi8.setLocalTranslation(new Vector3f(0,0,-140));
mi7.setLocalTranslation(new Vector3f(0,0,-120));
mi6.setLocalTranslation(new Vector3f(0,0,-100));
mi5.setLocalTranslation(new Vector3f(0,0,-80));
mi4.setLocalTranslation(new Vector3f(0,0,-60));
mi3.setLocalTranslation(new Vector3f(0,0,-40));
mi2.setLocalTranslation(new Vector3f(0,0,-20));
// ((MilkAnimation) mi2.getController(0)).setSkipRate(.05f);
// mi2.setLocalScale(.5f);
rootNode.attachChild(mi2);
rootNode.attachChild(mi3);
rootNode.attachChild(mi4);
rootNode.attachChild(mi5);
rootNode.attachChild(mi6);
rootNode.attachChild(mi7);
rootNode.attachChild(mi8);
rootNode.attachChild(mi9);
rootNode.attachChild(mi10);
rootNode.attachChild(mi11);
rootNode.attachChild(mi12);
rootNode.attachChild(mi13);
rootNode.attachChild(mi14);
rootNode.attachChild(mi15);
rootNode.attachChild(mi16);
rootNode.attachChild(mi17);
rootNode.attachChild(mi18);
rootNode.attachChild(mi19);
//rootNode.attachChild(new Box("axisX",new Vector3f(5,0,0),5f,.1f,.1f));
//rootNode.attachChild(new Box("axisY",new Vector3f(0,5,0),.1f,5f,.1f));
//rootNode.attachChild(new Box("axisZ",new Vector3f(0,0,5),.1f,.1f,5f));
rootNode.setRenderState(s);
}
and there you go…
Ah, well are the models static or animated? I’m not sure how/if Xith handles this, but I would recommend enabling VBO support in jME. We ran into a similar thing with large terrains running at 40-45 FPS and then developed VBO support and saw that number jump up to 300-400 FPS. I’d be happy to help you fix that up if you like… Also, you might think about converting your .ms3d file to a .jme file prior to execution for quicker loading (won’t likely affect FPS, but the jme loader is easier to use and easier to enable features with.)
One other thing, if your model is something you are willing to share, I’d love to get a copy to use for stress testing and general improvement of jME.
Regards.
Could you please run the jME program in fullscreen and see what FPS you get? Cause on my card, i see a ~100FPS jump when I switch to fullscreen.
Also, in jME, with a poly count that big, you would generally use LOD on the furthurest models to decrease Polycounts and hence increase FPS.
The uses of Xith and jME are different so it is hard to test both. E.g. We use TriMesh, but I know Xith has a CompositeMesh which triangle strips/fans can reduce the number of calculations down.
So you might be using different methods to do the same thing, one being more advantageous over another.
DP
Hi,
Sure, I need 100% static geometry so it would be great if you can give me a hint on how to use VBO, I also suspected that this will improve speed a lot.
yes you can get a copy of it, I am willing to share it for the purposes of testing
Just tested running in fullscreen but got exactly the same results
Well, my point was, jME has all the LOD tools, while Xith has only switch node, which has some problems as I read in Xith forum. I just wanted to compare raw rendering speed. I definetely like LOD stuff in JME but still I will have large polycounts (maxing at 300K with LODs) since I am not building a game.
Email me the model you’re using. I wrote the ms3d loader so I may be able to debug if there’s something that needs it. I’ld only use the model for testing. There’s a newer version of the loader in the current CVS. cep221atgmaildotcom
PS: Is it just me, or do the jME models look way, way better? I guess it’s the lighting direction.
JME contains many ways to improve the fps including impostere and lod (I do not know about Xith3D). If you are considering witch engine to use take this into account.
I’ve not use jME (I intend to at some point soon). I have however used Xith quite a bit. jME appears to be more feature rich although most features are bespoke to certain types of games.
jME does seem to be more targeted towards first person shooters (at least thats my perception looking at the feature list). Xith was originally attempting to be more generic (a la Java3D).
The main point I’ve seen as an issue so far is the superb HUD support in jME and the lack of anything reliable or decent in Xith (the original overlay stuff is unpredictable at best). However, I’ve just seen that work has started on providing a HUD system for Xith.
In short I don’t know, but I thought the viewpoint might be useful.
Kev
PS. I suspect the models are absolutely identical I would say that tho.
[quote]jME does seem to be more targeted towards first person shooters (at least thats my perception looking at the feature list). Xith was originally attempting to be more generic (a la Java3D).
[/quote]
I’d say Java3D is still more generic than Xith3D. Java3D is targeted towards all kinds of 3D simulations, whereas Xith3D concentrates more on games (it’s thread unsafe, uses only floats, doesn’t use capabilities, …), which leads to a better performance.
It would be good to have people using both, Xith3D and jME, so they can provide feedback of the strengths and weaknesses of both APIs. Maybe some kind of official “project goal comparision” would be helpful.
I know a couple of people who have made RTS games with jME. OutRunner, if your outhere (hehe), show em your RTS Game.
Im making a Hitman type game. So really, you can do everything in jME ;D
PS. I agree that we should have some sort of official comparison between the two. ChrisM might do it, he is as unbiased as they come 
DP
I tried, pretty hard, to get some people to write up biased articles on their particular engine about 6 months ago. I was then going to work with a couple of less-biased people to mesh these into a series of unbiased articles. The problem with starting out writing unbiased articles is you end up only covering the highest common factor - which is useless to games programmers. I knew I could trust myself to be impartial IF I had the evidence/facts from biased people in front of me (because I could check everything they said!), and I know a couple of people around here who have shown their ability and willingness to be impartial already - and who have useful real experience with using some or all of these 3D engines.
OK, so it was a miserable failure. All I ever achieved was to get a short article from Cas on LWJGL (too short, sadly - needed more biased details. I was surprised he was so unevangelical - he must have been tired or something ;)).
So. Chalk that one up to experience.
…
Here’s another idea, which I suspect will work MUCH better: having thought about it, I wondered what I’d do if I were an expert in each engine already and able to write the entire review series myself. Ummm…aha! Unit tests! Use cases!
The users, between us, should be able to work out a series of small independent tests - much like the demos that already exist for each API. The API authors / most prolific users then have to code up those tests. It would be best if they could do two versions of each - one which is just the “off the top of my head, not trying to be clever” and then one which “optimizes performance, and perhaps cheats a little here and there” (e.g. in the screenshots in this thread the plain version would have to render all those polys, and the optimized version could use LOD to its heart’s content). This answers two of the most common questions:
I’m too busy to do much on this myself right now, but…I’d suggest the following list for starters (would like to cross-post to Xith forums…):
a Terrain demo, plain multicoloured shaded polygons, fills the view window mostly to the horizon
ditto, but with blended textures (no harsh edges when texture changes from one to another)
a clone of the nVidia ToySoldiers (very large number of identical models loaded at once, all animated in lock-step - i.e. under the hood ought to be using onboard T&L etc, as well as testing the SG’s culling effectiveness)
ditto but with each model in a different state of animation at the same time (c.f. what happens when the robot appears in the NV demo - they scatter and are no longer in lock-step, so their polygons are no longer identical)
a 3D maze, from 3rd person floating perspective, with a model running around it at random, and a simple HUD overlayed on top, showing various things
ditto, with a detailed HUD and lots of models running around it (these simple tests would expose current known problems in Xith’s HUD/Overlay system)
…etc. Of course, each test needs MUCH more detailed descriptions than that, with a checklist of requirements, and precise dimensions, and actual model files and texture files, to make for fair comparisons (and to make implementation easy!).
I have a feeling this might go the same way as the last idea simply because its too much like hard work
Shame JCD isn’t still active round here, he’d love to sit and write the same demo over and over in Xith and JME. After all, didn’t he do just that for the Xith vs Java3D comparison?
Kev