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.

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

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.

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

Quote

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.

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.

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

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 have tested it too on my low-end system (GeForce 2 GTS). It gives when showing the full level from above ;Xith3D => 8 FPSJava3D => 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 !

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.

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

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.

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.

Quote

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.

Quote

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

Quote

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.

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org