Great. I also contacted the author of the quake map we are using and got a better understanding of the missing textures. Basically they are all defined in .shader files.

Hmm... I don't think this is true for all of them. For some it might be. But most of them reside in the base folder of the Quake3 install path (well known by us old Quake3 gamers). They're reused by many Q3 maps just as in this case.

I played plenty Quake3 in my time, but I wouldn't call myself an expert. Still, of the missing textures in your version of the loader, there are only 2-3 that are actually just images... the rest are defined in the .shader files in base Q3 (caulk, hint, noshader, nodraw, missleclip, and lavahell_2000) and in the map we are using's .shader file (orangesky and pdm_blocks17floor2_trans.) In case you are not familiar with the .shader file, it's not a shader in the sense of frag and vert shaders, it's a definition of how to apply, animate and or blend defined texture(s) on a face. Also, there are several things about Q3 textures that have alpha channels (such as making sure they are not back culled and applying a proper alpha blend) that are not handled in the converter.

Ok, I've mostly been waiting as a courtest for you guys to figure out your vertex/index issues on the loader before I put this latest benchmark finally together. Do you have an ETA on that?

Thank you very much for your patience, renanse. I've been very busy.

Well I've just fixed this issue . At least it was really easy. It was due to the latest changes in the BSPVertex class, which I've reverted. They didn't give any performance or GC boost, so they seemed to be useless in this sense.

Now, feel free to take the most recent version for your webstart tests. And please remember: take the org.xith3d.test.benchmark.Q3FlightBenchmark

Marvin

EDIT: If LWJGL is running faster for you (it doesn't for me) then please use it for your tests.

Well I've just fixed this issue . At least it was really easy. It was due to the latest changes in the BSPVertex class, which I've reverted. They didn't give any performance or GC boost, so they seemed to be useless in this sense.

You can grab the source I used there, as well as an open office doc of my raw numbers and some charts.

The lwjgl version of Xith wouldn't run for me due to what appeared to be a opengl-thread issue. (To run in lwjgl mode, I simply changed the JOGL to LWJGL in the test class.) The frame rate of the jogl xith was about 160-165 ish, so about the same, even though the visual look has imroved (proper texture filtering, flame transparent, etc.) You'll notice the FPS for jME went up a good chunk, that is because we improved our ability to lock down unchanging static sections of the scenegraph. I suggest the next benchmark be something involving animation or interactivity. Maybe capturing and playing back the activities of a hand full of actors?

Anyhow, putting down my benchmark hat for awhile... at least until the next test!

Getting the windows java3d libs involved running an installer... Is there a way to get the linux (or mac) libs for java3d without such a process? I was sleepy enough last night that I didn't really care to try to find that out.

Getting the windows java3d libs involved running an installer... Is there a way to get the linux (or mac) libs for java3d without such a process? I was sleepy enough last night that I didn't really care to try to find that out.

No problem.

Well, it should be sufficient to point the the same folder or jar for windows or Linux (never tested it on max, but should be the same). The win libs and linux libs should then be provided at the same place.

Ok, I've repacked xith and jme with linux and mac native libs (sorry java3d.) I could only test mac, which works for jME but has the Tuple3f/Vector3f issue I mentioned before upon starting up in Xith. Upgrading my jvm solved that in windows, but there is not an official upgrade for mac above 1.5.0_06. *shrug*

Anyhow, the point was to get you guys linux native libs, so hopefully that is accomplished now. Same links as before.

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.

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

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