To tom. To get GLIntercept to work, just install it, then copy the openGL32.ddl and gliconfig.ini in your application directory.It will work. Note that most of the time, it is configured to log one single frame when you press Ctrl+Shift+f.

1 two different benchmarks produced two different results, one has to suspect the benchmarks. They 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, I can get performance through control.. 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 ask Java3D to do something "pretty please" and hope it happens soon.

3 Any refresh greater than 60 FPS is a waste

to n

1) They do produce the same image now, tom said he fixed his lightmap thingy so they both produce the same. Nothing is wrong with the benchmark

2) Errr....FPS is performance. Your confusing performance with how well the programmer controls the engine.

3) You have it backwards ; because Java3D's performance is now higher, i can add more stuff into Java3D's scene and it will still be >= xith's (to an extent). So you can get more dense scenes and thus, more things to look at. Whats the point of an engine that only draws a very cool box at 100 fps, while another engine can draw an entire level in 100fps ?

Niwak:Thats an awfull lot of calls to be making just for 1 primitive...

To tom. To get GLIntercept to work, just install it, then copy the openGL32.ddl and gliconfig.ini in your application directory.It will work. Note that most of the time, it is configured to log one single frame when you press Ctrl+Shift+f.

Thanks, got it working now. The problem was that application directory is set to the jre/bin directory when running from eclipse.

Also the geometry is batched up so there is usually 10 times as many triangles being drawn for every draw call compared to Java3D and Xith3D.

Quote

maybe we should re run JavaCoolDude's Benchmarks with the newer versions of Xith3D and Java3D?

That might be a good idee to see if there has been a change in the performance of the two libs. But don't compare this benchmark with JavaCoolDude's. They test completely different things. Xith3D may still have a lower overhead and faster than Java3D on "simple" benchmraks as those of JavaCoolDude.

Btw, Java3D uses display lists and this causes some hickups when lists are created and destroyed.

But we cannot deny the facts, so here's a sum-up : - In the old times, when Java3D was abandoned, JCD did some Benchmarks that showed up Xith's superiority : 1980 FPS for Xith vs 920 FPS for Java3D. - David Yazel's left, Xith3D core development has gradually stopped - Java3D core development has been started again by the community (while abandoned by Sun) - Now somebody port the Quake 3 level viewer to Xith3D, and it shows that the situation has been inverted !

But all's not lost ! Why everybody would be moving back to Java3D ? Xith3D's not dead (slowly dying maybe, but not dead yet). William ! Arne ! Yuri ! Where are you ? I'm sure we can correct that.. Studying Java3D pipeline and improve Xith3D's one wouldn't be so difficult, isn't it ?

FWIW, glLockArraysEXT shows up in a web search on a page devoted to optimizing gl drivers for Quake3... Considering only the J3D side is using that, I wonder how much of a difference (if any) this makes in this test.

Not much I think. Xith3D is using static VBOs as far as I can tell and it is something similar. By the way, that is not good when rendering Q3 levels. It has a high overhead and not much are gained when you are only rendering 2-8 triangles. Imidiate mode would be better. But it does make sense in most other cases.

Not much I think. Xith3D is using static VBOs as far as I can tell and it is something similar. By the way, that is not good when rendering Q3 levels. It has a high overhead and not much are gained when you are only rendering 2-8 triangles. Imidiate mode would be better. But it does make sense in most other cases.

I'm also porting the viewer to jMonkeyEngine. First results show that it is slower than Xith3D. About the same speed when looking at whole level from above, but much slower inside. It almost seems like it don't do view frustum culling. Also I'm trying to find a better way to implement the PVS enable and disableing. I will upload the code tomorrow.

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 fpsxith: 132 fpsjava3d: 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).

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.

1. Static geometry should not update (transform/merge) boundings up the tree, as it's not changing. 2. 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.

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 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 FPSjME: 75 FPSj3d: 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)

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

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

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.

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

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.

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