A little problem: You need to include JOGL_drihack to the xith jar. And JME is also not working on Linux (class def not found exception: null).
Marvin
I’ll get that jogl hack native in there tonight. Any other info on the jme exception? I wish I had a way to test this myself. 
Try them again when you can.
edit: Borrowed an ubuntu laptop and fixed up some args, xith and jme finally worked. yay.
Thanks.
Marvin
PS: Ubuntu is cool :). I’m using Kubuntu.
I ran the JME and Xith flights and got 160 FPS for JME and 151 for Xith. Yeah ;D. No a too big difference.
Marvin
Cool, yeah some people running it get a slight lead for jME, people with newer graphics cards / cpus seem to get much larger leads (some as much as 2x). Also interesting, most people with modern machines show java3d over xith, older machines seem to put them on par or xith slightly ahead of java3d. Would be fun to have a place where people could upload their stats.
Just glad you can finally run it! 
Hi,
My GeF 440 Go on Toshiba Satellite 5100 at 1600x1200 32bpp gives the result described: Xith3D is ~20% faster than Java3D while jME is 50% faster than Xith3D (I have to admit that it is a good achievement).
Yuri
P.S. You should check against the latest Xith3D, because of one bundled with your test shows up wrong (flashing) textures sometimes.
Java3D doesn’t run with Linux (though it doesn’t seems like a native lib error, it just doesn’t find the main class)
37.94 FPS with jME, experiencing ~8 lags at the beginning of the flight, and irregular memory usage
31.92 FPS with Xith3D, some wrong textures flash as Yuri mentioned, IIRC it should be fixed in current CVS. Memory usage nice and flat, perfect behavior (no lags).
Hi,
[quote]some wrong textures flash as Yuri mentioned
[/quote]
As I mentioned also, it is already fixed in current CVS.
Yuri
Yeah, I just didn’t apply the textures at the beginning before letting the game begin. So it stutters when you see a new texture. Not sure what else you saw that gave you a memory concern.
Here’s my results. This is a pretty high-end system, Intel Dual Core (Conroe) 2.4GHz, 2Gig RAM, Radeon X1800.
Java3D - 348FPS
Xith3D - 306FPS
jME - 530FPS
Just to reiterate something I’ve posted above a few times, I did not pack the java3d test for linux.
It would be interesting if you pulled the latest Xith CVS and re-run the bench from there…
Anyway, it’s interesting to see that we don’t lag as far as before behind Java3D/jME now…
No, please don’t do it now. Some recent changes made the engine slower. We forst need to investigate it.
Marvin
Hi,
I agree with Marvin, especially that there are some things in mind.
Yuri
Been away from the forum for a long time. It’s nice to see someone continued on the q3 benchmarks. And that it’s been used to optimize the engines
Have anyone checked if the changes made in jme and xith have improved the performance of other games/applications?
Enabling display lists in rafa_es game makes it twice as fast. (that’s part of what has been implemented following the q3 benchs).
Yes, actually, most of the changes we’ve done for jME have been to increase the performance of games we are working on. The boosts to the benchmark are gravy. (As a side note, I’m about 60% done with a q3 shader reader for jME, so keep your eyes out for a fun porting project.)
Mostly sorting, and culling I guess ?
Okay…
(Note : is it soo complicated to make a q3 shader reader ?)
Here is a Quake3 shader parser I’ve made for my own engine ;
http://vbousquet.free.fr/tmp/quake3.zip
It uses Antlr for parsing so you will need to download the library.
It also has a lot of other dependencies so it is unlikely that you will be able to use it “as-is” but the grammar for the lexer/parser is fairly complete and it can save you wuite a lot of work.
Vincent