I’ve uploaded the source to the jMonkeyEngine port.
Got frustum culling working but it is still much slower than Xith3D and Java3D.
Got this running in jME… Wow. Considering we haven’t even begun optimizing for such a scene (by coincidence, BSP/Portals is next on our list - see our v.10 feature list) I’m surprised it runs as smoothly as it does… I get 70-150FPS inside and 17FPS from the top.
I’ll have to setup all of the source and libs to see the xith version next to get an idea of how much slower we run, but I’m thrilled you ported the demo to jME because now we have a nice demo to test with while we optimize. Thanks!
What do i need to get the jME version compiling correctly? I managed to run the xith as well as the Java3D version, but i couldn’t get jME to run without commenting keyboard and mouse related stuff out…so i couldn’t move. I tried the official 0.9 and the “latest” release but to no avail.
So i benchmarked the starting position only (P4HT@3.2 Ghz, Ati X800XT-PE, latest drivers, WinXP, Java 1.5):
jme: 85 fps
xith: 132 fps
java3d: 210 fps
I’ve also loaded the level into jPCT but without BSP stuff (used jPCT’s build in octree support instead) and with full collision detection enabled and i got around 300fps for this particular view. And that’s with jPCT “special” T&L pipeline, which is not 100% hardware based due to support for software rendering… 
Edit: 25fps for software rendering using that view (without multi texturing in that case).
I used the nightly build with JME.
Thanks. I’ve downloaded it again and now it works. Only god knows, where i’ve unzipped it to yesterday… :-[
This was a great exercise, and really let us find out a couple weaknesses in our (jME) rendering pipeline. Specifically, we found two issues, that we can now fix.
- Static geometry should not update (transform/merge) boundings up the tree, as it’s not changing.
- Sending small trimesh data to the card without batching is very wasteful (sending 3700 individual data objects to the card one at a time).
After playing with the demo some, and doing some hacks to force these improvements into the renderer for this case, I went from ~85 FPS to ~250 FPS (for initial starting position). And ~15 FPS to ~60 FPS on full level view.
So, this was a fantastic demo to point out a couple areas that we can gain the most improvement. Thanks for the effort, Tom.
Does anybody have the chance to run these tests on a dual core cpu (or dual cpu)? Because Java3D seems to use multiple threads for rendering, which you can notice when running it on a hyperthreading cpu. Xith and jME are using 50% of the two virtual cpus while Java3D uses around 85%. It would be interesting to see, if Java3D scales better when run on two (or more) real cpus/cores.
I have compared the 3 scene graphs with my custom level renderer and will post some numbers.
Test 1 - Spawn position looking at windows. 2206 out of 3704 nodes are enabled by PVS but most are outside frustum.
JME: 55
Xith3D: 117
Java3D: 135
Custom: 375
Test 2 - Spawn position but rotated 180 degrees, looking down hall. 2206 out of 3704 nodes are enabled by PVS and most are inside frustum.
JME: 20
Xith3D: 24
Java3D: 44
Custom: 185
Test 3 - Looking at level from above. Everything is enabled and visible.
JME: 9
Xith3D: 9
Java3D: 34
Custom: 103
Test 4 - Camera is in one of the corners looking at the spawn position. 1230 out of 3704 nodes are enabled by PVS.
JME: 37
Xith3D: 54
Java3D: 74
Custom: 328
Who says Xith3D development was dying ? http://www.java-gaming.org/forums/index.php?topic=11811.0
It would be interesting to re-run the bench with these optimizations (although it may not gain a thousand FPS)
Note : I don’t want to make a war between the different scenegraphs, yet my ego would want to 
I think we should all work to remain humble and recognize that sometimes others make better than us. But that shouldn’t prevent us from working on our projects. (On this point I agree totally with swpalmer).
FYI, We’ve made several upgrades to jME in the last two days or so that affect these tests. I’ve also had the opportunity to benchmark all three libs and have come up with the following results.
Note: Latest xith-cvs tar available from their site. Latest jME-cvs (a few things will be checked in around New Years eve/day). Latest stable Java3D (1.3.2). My only significant to the demo code was to enable scene locking in the jME version so that repeated calculation of bounds for things that do not change does not occur. Other changes include porting to our vecmath objects, reducing object creation when moving between areas and enabling the renderqueue. (all things that probably should have been done when porting to jME)
From Top looking at entire scene:
Xith: 15 FPS
jME: 24 FPS
j3d: 81 FPS
From Initial Position: (after waiting for any JIT, etc.)
Xith: 205 FPS
jME: 260 FPS
j3D: 365 FPS
From Max Load Position: (lowest FPS from real player position seems to be secondfloor, over one of the star blocks, looking through the big room to the other side - where another start block awaits)
Xith: 50 FPS
jME: 75 FPS
j3d: 145 FPS
Memory usage: snapshot after 90 seconds of running at initial position (for heap used, I show the range over the last 10 secs)
HEAP:
jME: 23MB allocated 20-22MB used
Xith: 52.4MB allocated 34-37MB used
J3D: 46MB allocated 31-34MB used
NON-HEAP:
jME: allocated 9MB used 8MB
Xith: allocated 11MB used 11MB
J3D: allocated 11MB used 11MB
Also, as an FYI, I ran a profiler (YourKit) over all three… Interestingly, almost all of the time for the J3D version was spent in javax.media.j3d.J3dThread.run() with less than 1% of time spent in methods called from there. Also, I did notice there are two threads at work there as thought by another poster. Any idea why my profiler does not pick up any java3d methods other than the run on the threads?
(please excuse the cross post to here and the jME official forum… i figure two different audiences.)
Oops, as irrisor of the other forums pointed out, YourKit filters out javax.* by default. Much better now and I might see why we are still slower than J3D… more later should anyone care.
Interesting stuff, please keep posting
Will.
FYI, we enabled display lists similar to what J3D is doing and our frame rates are much closer to J3D (although our top down view is still only 50 compared to 80 with J3D, not sure what that is about…) After some polishing and javadoc, all these changes should be in jme-cvs (perhaps 3-4 days given my current tired state and NY eve… :-\ )
Thats interesting, so you moved to display lists from VBOs or Vertex Arrays or something entirely different? Ties in with some results I’ve been getting recently
Kev
Well the demo was not using our VBO code, and just turning on VBO made things slower! ??? (perhaps because the size of the individual VBO was very small) It was simply using VertexPointer (et al) and DrawElements. Batching that up in a display list made it all much much faster. EDIT: fixed spelling error.
For anyone still watching this space, I’ve uploaded screenshots from all three to my blog (www.renanse.com)
Nice, most of the stuff I’ve been doing recently points towards current consumer cards implementations of VBOs actually being slower than display lists for static geometry.
Kev
VBO’s are slower then display lists for static objects. VBO’s are intended to be the best way to do dynamic geometry with lots of vertices, but display lists can be optimized by the video card once compiled and stored entirely on the video card without parts living in main memory (VBO’s don’t guarantee data resides entirely on the video card).
jME cvs is updated with the changes mentioned plus more. An updated version of the jME q3 demo source is here: http://www.renanse.com/jme/jme_q3_src.zip
Will, arne, should w modify Xith pipeline to use display lists for static geoemetries ?
What other changes would bring performances to a higher level ?
@jME team : any trick to give ? I think rather than to be in competition we should help us mutually.