Porting Quake III to Java3D

[tom]

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.

[c_lilian]

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

[thijs]

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?

Games published by our own members! Check 'em out!

[c_lilian]

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

[tom]

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

[c_lilian]

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 ?

[arne]

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...

[thijs]

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?

[tom]

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 ?.

This was exactly what I was planing to do

p.s. do you mind posting the code when you're done ?

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...

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?

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.

[Vorax]

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.

Games published by our own members! Check 'em out!

[tom]

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.

[tom]

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

[thijs]

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

[Bombadil]

Amazing.

[darkprophet]

I haven't looked at the sourcecode for j3d, but could it be doing occlusion culling automatically ?

DP

[tom]

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.

[darkprophet]

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 (TM), 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..

[tom]

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.

[Amos Wenger]

I'll be very interested to see what makes so a huge difference (so we can correct / add functionalities to Xith3D)...

[Niwak]

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.

[zparticle]

Just curious, what is the difference in the memory footprint between the two?

[darkprophet]

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).

How do you mean by "redundant". Those calls affect the pipeline of Xith3D, hence they aren't redundant. They are needed, its just that Java3D has a different pipeline...

DP

[Vorax]

There may indeed be redundant calls if for example it's translating multiple things to the same space but pushing and popping for each of them.  The whole thing could be done with one push/translate/pop.  Other redudant things could be setting the same blend functions, texture etc, then unsetting and reseting to the same values for the next set of calls. when you haven't actually changed them - the whole thing could be done as one set.

NOTE: I haven't run the test myself, just giving some possibilities of redundant calls.

[tom]

Just curious, what is the difference in the memory footprint between the two?

Java3D 70MB
Xith3D 140MB

That is the Mem Usage reported in task manager.

[tom]

To try to understand this, I have run the test with GLIntercept.

How do you get GLIntercept to work? I've copied the gliConfig.ini and opengl32.dll into the application directory. But I get no output. I'm guessing it uses the dll in system32 instead. Do I have to rename the one in system32? (I did try that but it came back. If that is what I need to do I'll have to find out how to turn off the outo recovery on windows xp).

[hawkwind]

A copy of another post, please don't let raw FPS be your primary concern........


Surprising numbers, a direct contradiction of the work javacooldude did.  Makes me consider a few things

1   two different benchmarks produced two different results, one has to suspect the benchmarks.  Thet did not test the same thing.

2   lets not confuse FPS with performance.  It is one thing to rip screen updates at full speed it is a different thing to have a high performing game.  By this I mean how well can you allocate the resources, time, memory, etc. to have the optimum frames without sacrificing game play, quality of display, quatitiy of game activities.  With xith, because I have full control over what renders, how it renders. when I want to handles key strokes/mouse actions.  In my game I adjust the various allotments of time different subsystems have based on the FPS, because I control the render loop ...I AM THE GOD OF MY GAME.  Java3D offers substantialy less control because behaviors activate at sometime in the future...that is the level of control you have..you ak Java3D to do something "pretty please" and hope it happens soon.

3 Any refresh greater than 60 FPS is a waste

4 What refresh rate do you really need

[Vorax]

A copy of another post, please don't let raw FPS be your primary concern........


Surprising numbers, a direct contradiction of the work javacooldude did.  Makes me consider a few things

1   two different benchmarks produced two different results, one has to suspect the benchmarks.  Thet did not test the same thing.

Well, when JavaCoolDude did his benchmarks, it was with a much older version of Java3D - there may have been substantial improvements.  Also, JavaCoolDudes benchmarks were very limited, not as close to a real world rendering scenario as rendering a Quake 3 level.  It's easy to batch a simple scene correctly, but much more difficult to batch a complex scene.   Doing the level test forces lots of data to the card, state switches, and opportunities for batching.  Though this to is still limited as a benchmark.   It could be that with simple scenes, Xith is faster, but with more complex scenes, J3D wins.  That is what the FPS numbers and GLIntercept results  suggest.

2   lets not confuse FPS with performance.  It is one thing to rip screen updates at full speed it is a different thing to have a high performing game.  By this I mean how well can you allocate the resources, time, memory, etc. to have the optimum frames without sacrificing game play, quality of display, quatitiy of game activities.  With xith, because I have full control over what renders, how it renders. when I want to handles key strokes/mouse actions.  In my game I adjust the various allotments of time different subsystems have based on the FPS, because I control the render loop ...I AM THE GOD OF MY GAME.  Java3D offers substantialy less control because behaviors activate at sometime in the future...that is the level of control you have..you ak Java3D to do something "pretty please" and hope it happens soon.

You can set J3D behaviours to execute each frame as far as I know, and act upon key strokes, etc when you like, which should give you the level of granularity needed for any game.  You can also implement your own I believe.  My J3D knowledge is out of date though - someone correct me if I am wrong here.  As far as controlling what's rendered, you can't control if it goes as an array or a VBO with J3D, but you can say if it should be rendered or not, which again, should be what you need in most cases as long as J3D is picking the best way to do it (which is decided based on the flags you assigned your nodes), by the numbers it does seem to be.

3 Any refresh greater than 60 FPS is a waste

Not if you want to run your monitor at > 60hz - in which case 60 FPS will show tearing.  Also 60 FPS on a good machine != 60 FPS on a slow one. The more performance you can push from a renderer the better in most cases (I can't think of any where it's not).

4 What refresh rate do you really need

72hz is a good target for monitor refresh.  60hz gives many people headaches with 3D environments.


Just a note: I am not for or against either J3D or Xith - Like Tom who created this benchmark, I use my own game engine developed with LWJGL - I am just commenting on the results posted.

[swpalmer]

3 Any refresh greater than 60 FPS is a waste

4 What refresh rate do you really need

Any refresh rate faster than what you need means you still have breathing room to improve other things - level detail, visual effects.. maybe free up more CPU time for better AI etc.  Or you can lower the specs on the required hardware to increase the size of your target market.

Better performace is better performance, plain and simple.  As long as the control issues you brought up are not a problem with implementing the game, then the RAW numbers do make a difference.

[swpalmer]

The real point of these findings and how they contradict JavaCoolDude's is that you have to profile your own code and what you want to do, and not rely on some unrelated benchmark in the first place

At any rate it shows we should keep an open mind.

[Vorax]

The real point of these findings and how they contradict JavaCoolDude's is that you have to profile your own code and what you want to do, and not rely on some unrelated benchmark in the first place

At any rate it shows we should keep an open mind.

I haven't heard truer words in a long time