Has anyone ported Davids Quake III viewer to Java3D yet. If not, I’m having a shot at it. I want to find out how Java3D compares to Xith3D in the real world. Hopefully people will not shrug it off as yet another microbenchmark.
Good idea !
I’ve ported it to my software renderer, but it was at a lower level (a plug-in renderer for xith), so I touched at xith, but not at the q3 viewer.
I hope you’ll be able to port it, and I’m sure you’ll get better frame rate than mine 
Lilian
Looking forward to that!
Actually I didn’t even knew Java3d was still being developed on :-[
And Lilian: Is that software renderer available to check out online somewhere?
java3d seems very active (at least the community around it) : there are more than 10 posts a day in the mailing list… sometimes much more.
about my software renderer : I’m currently working on something else (more info soon), I’ll get back to it to document it when I have time and release it “as is” (meaning: not finished).
http://www.java-gaming.org/forums/index.php?topic=11311.0
(I don’t think it’s worth finishing it now than JOGL (and probably LWJGL) can be properly included in applets.)
Sorry for the thread hijacking… now back on topic : Java3d and the quake demo…
Lilian
Just got the rendering working on Java3D. I’m not porting the collision detection since it is a bit tied into Xith3D and I’m more interested in comparing the rendering speed. There is some visual differences. Java3D seems to be a bit darker and not as saturated. Might be that the texture combining and blending is not working exactly the same way. Or I messed up the texture loading.
Did the first speed comparison. Looked at the level from outside so that everything is shown. Java3D is around 3.5 (350%) faster than Xith3D. I think this is mostly due to more efficient state sorting and/or better batching of geometry. Inside the difference is less but Java3D is still faster.
Next step is to:
-clean the code up.
-Add a timedemo of some sort.
-Enable/disable PVS to benchamark frustum culling
-Maybe optimize a bit by adding backface culling to planar faces
-Maybe add custom frustum culling in order to further benchmark culling
much interesting !
may be you could add a kind of automated path to follow (advancing at fixed interval) and count how much time (as it will be the same frame count) is needed to follow the entire path ?.
As the rendered images should be the same in both cases, we could have a real comparison or rendering time.
(… well, this will work if you rendering is not limited by Vsync…)
Lilian
p.s. do you mind posting the code when you’re done ?
wow - Java3d 3.5 times faster…
I always thought Xith were faster than Java3D!!
Damn! that was one of the reasons why I switched to Xith3d. Seems to have been a bad move after all 
.
Nah - I like Xith3d more - I simply don’t like Java3D’s Behavior-System.
And when you’re finished - post your code, so we can check your results.
And we should check what xith is doing for state sorting…
Wow you’re quick!
How does it compare in speed to Squareheads? And do you have plans to use Xith3D or Java3D for future developments on Squareheads or have you stopped working on that one?
This was exactly what I was planing to do 
I will of course post the code. I will probably not host webstartable or downloadable applications because I don’t have enough web space. Unless anyone can donate some space…
I have not had time to test both on the same level, but I’m hopeing Squareheads is atleast twice as fast as Java3D. I’ve kind of stopped working on Squareheads. It’s called Undead Arena now btw. If I start working on it again I will defenetly not use Xith3D or Java3D. I’m fairly happy with my current renderer. I did the Java3D port because of the Xith3D vs Java3D speed discussions that come up. I wan’t some fairly complex to use as comparison.
Are you using DirectX or OpenGL for your J3D test? If it’s DX, that might explain why things look a bit different. I doubt it explains the spped boost though
My guess is that J3D is probably creating lists, arrays etc in places that Xith doesn’t - 350% increase is huge.
I’m of course using the OpenGL version of J3D to make the comparison as fair as possible.
Now for some level stats. In the scene there is a total of:
-27311 triangels
-3704 Shape3D objects
-118 unique appearances
wich gives and avarage of:
-7 triangles per shape
-231 triangles per apperance
I think it is better to batch up all triangles with the same appearance and sending that to the card in one go. Instead of compiling every shape into a display list. Might be what it causing the difference.
Also with a minimum of 118 state switches, it is important that the sorting and switching is well implemented.
Note that the 350% difference was mesured with a smal 640x480 window, with the whole level visible. Xith3D got 5-6 fps, Java3D 20-22.
Here is the source:
Java3D version
Xith3D version
jMonkeyEngine version
To run the code you need Java3D/Xith3D and the level found in David’s QuakeIII Demo. Either put the level data folder in current directory or hardcode the full path in the QuakeRenderer class.
Keys are:
arrows - look around
wasd - move
F1 - toggle pvs
F2 - freeze pvs
fps is printed in console
Let me know if anyone bothers to test it.
edit: added jme version. jme version also got mouselook
Hej Tom,
I tested it for you, this is the system I tested it on:
P4 2.8ghz with HT, 512mb ram
Winxp
nvidia geforce 6800 128mb
vsync off
JVM 1.5.0_05
results:
Java3d 1_4_0-pre9-0511270103:
100 - 200+ fps
biggest room 85+ fps
whole level visible (top view): 66fps
Xith3d 2005-08-31 using jogl 1.1 - June 24
40 - 120fps
biggest room ~40fps
whole level visible (top view): 14fps
One thing I noticed where little hickups with Java3d when entering (some) new clusters, this wasn’t the case with Xith3d
Nice job!
Matthijs
Amazing.
I haven’t looked at the sourcecode for j3d, but could it be doing occlusion culling automatically ?
DP
I doubt it. The greatest performance gain is when the whole level is viewed from above. Almost all geometry is visible. It must be state sorting or how the geometry is batched up and rendered.
I also read that J3d doesn’t render the scene if it hasn’t changed from the current frame on screen, maybe your measurment of the FPS is slightly misguided. Meaning that j3d returns saying “rendered” when infact, it isnt oncurring any OGL overhead because it hasn’t rendered anything. The only way to compare this if you define a spline on which the camera moves for both scenegraphs and then measure the FPS.
Just to be a Pain ™, was the pixel bit depth the same on both tests? It could be that J3d falls back to 16bits silently (for some reason, maybe thats why you seeing the less saturated textures).
3.5x faster is a heck of a lot, i dont believe state sorting alone is responsible for that speed up…
The Java3D frame rate is the same when you stand still or move back and forth. So I’m pretty sure it is rendering every frame. If it did not render everyframe the frame rate would go threw the roof. I am planing a time demo that will be a better way of comparing the two.
No idee about what pixel depth are used. I’ll try to find out. But both is rendered in windowed mode if that has anything to impact performance. The saturated textures was caused by a bug that rendered the lightmaps up side down. They look the same now.
I too was surprised by the results. But I know from doing the Squareheads renderer that the implementation is very important when rendering the levels.
I’ll be very interested to see what makes so a huge difference (so we can correct / add functionalities to Xith3D)…
I have tested it too on my low-end system (GeForce 2 GTS). It gives when showing the full level from above ;
Xith3D => 8 FPS
Java3D => 45 FPS
To try to understand this, I have run the test with GLIntercept. The result is that Java3D is far better at feeding the OpenGL pipeline.
Xith3D makes a lot of redundant calls (the GLIntercept log for one frame is 26Mo !) where Java3D groups thing in display lists and makes minimal state change (the GLIntrcept log for one frame is 3Mo).
I was quite surprised since switching my game from Java3D to Xith3D gave a speed boost. Must be something else since while I made the switch to Xith3D, I rewrote a part of my game engine…
This is great news since development on the Xith3D core seemed to be nearly stopped whereas on Java3D it seems to have restarted !
I think it’s time for me to switch back to Java3D.