Quake3 level loader - Benchmarks

[Marvin Fröhlich]

I remember when I first came to xith there was a Quake3 level loader (with example) available. I think this would be an excellent test for the current performance of the engine. Unfortunately I cannot find it. Does anyone know where it is or if it even still exists?

Marvin

EDIT: I changed the thread title to better fit the topic, that's talked about here.

[Amos Wenger]

I remember when I first came to xith there was a Quake3 level loader (with example) available. I think this would be an excellent test for the current performance of the engine. Unfortunately I cannot find it. Does anyone know where it is or if it even still exists?

First announce :
http://www.java-gaming.org/forums/index.php?topic=3044.0

Release announce :
http://www.java-gaming.org/forums/index.php?topic=3267.0

Downloadable files :
https://xith3d.dev.java.net/servlets/ProjectDocumentList?folderID=0

[Amos Wenger]

It's really a good idea to renovate this quake3 level loader : it will provide an excellent testcase for the not-refilling-renderbins-each-frame performance improvement.

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

[Marvin Fröhlich]

It's really a good idea to renovate this quake3 level loader : it will provide an excellent testcase for the not-refilling-renderbins-each-frame performance improvement.

Exactly that is the plan . The MultiCubeBenchmark will probably be a too small test (too few Atoms) to see the real effort of this modification (well, whan it is done). That's why I asked for it.

Thanks for the links.

[Marvin Fröhlich]

I've made a first "naive" port of the loader agains the current CVS. Have a look at org.xith3d.test.loaders.BSPLoaderTest .

I'll check the whole code to make it better and more intuively usable. It uses e.g. a RandomAccessFile, which is not the most high performance one when you're just reading a file. Maybe I can switch to a FileInputStream.

And the whole loader is hardcodedly linked with the Xith collision system, which will certainly make it quite slow. Maybe this is the first case, where we need JOODE integration in xith-tk.

Marvin

[kevglass]

First, great work Qudus! Good to see something useful coming out.

Any chance of a re-do of these benchmarks:

http://www.java-gaming.org/forums/index.php?topic=11748.60

with respect to the new display list stuff?

Kev

[Marvin Fröhlich]

First, great work Qudus! Good to see something useful coming out.

hehe

Any chance of a re-do of these benchmarks:

http://www.java-gaming.org/forums/index.php?topic=11748.60

Yes, of course. But first I need to clean-up the loader (and it seems like the textures are not properly loaded. They look rather odd.). And the recently planned RenderBin concerned optimizations should be done before. We wan't to gather as much "points" as possible, don't we .

with respect to the new display list stuff?

Thanks

Marvin

[cylab]

...(and it seems like the textures are not properly loaded. They look rather odd.)...

Could this be the same problem in the MD3 model loader demo by java cool dude?

BTW. there are a lot of broken links/dead ends in the demo and GSG section of the Xith website.

[Marvin Fröhlich]

Could this be the same problem in the MD3 model loader demo by java cool dude?

Yes. Looks like the same problem.

BTW. there are a lot of broken links/dead ends in the demo and GSG section of the Xith website.

The GSG is totally outdated. You should not use it at all.

Marvin

[cylab]

BTW. there are a lot of broken links/dead ends in the demo and GSG section of the Xith website.

The GSG is totally outdated. You should not use it at all.

I know, but neverless the links should not be broken on the website. As well as the library link of the java cool dudes should not point to the outdated forum, since there is only a maintainance site present.

Also the whole xith3d website is unstable (broken images) and slow from time to time. Where is it hosted?

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

[hawkwind]

Drop consideration of FileInputStream...

today/monday I will drop a copy of my fast NIO based file readers.   For me buffer I?O from File handle is substantially faster.

[Marvin Fröhlich]

Drop consideration of FileInputStream...

today/monday I will drop a copy of my fast NIO based file readers.   For me buffer I?O from File handle is substantially faster.

Thanks for the hint. But I've already dropped this consideration, but for some other reason. The bsp file needs RandomAccess! In the first bytes there is some kind of dictionary, where all the byte offsets are listed. When you want to read the vertex data for example, you'll have to seek to the position listed in this dictionary. This is only possible in RandomAccessFile.

[Marvin Fröhlich]

The BSPLoader is quite clean now. The only remaining problem is the one with the Textures. Amos could you have a look at them, please? I think, you're a bit more familiar with the TextureLoader than I am.

But ieven if I detached the scene from the collision system, the whole thing isn't very efficient. Have a look at org.xith3d.test.loaders.BSPLoaderTest (you can now move around with the mouse and keyboard).

Marvin

[c_lilian]

Drop consideration of FileInputStream...

today/monday I will drop a copy of my fast NIO based file readers.   For me buffer I?O from File handle is substantially faster.

Thanks for the hint. But I've already dropped this consideration, but for some other reason. The bsp file needs RandomAccess! In the first bytes there is some kind of dictionary, where all the byte offsets are listed. When you want to read the vertex data for example, you'll have to seek to the position listed in this dictionary. This is only possible in RandomAccessFile.

Just a thought, what about NIO and memory mapped files ?

(oh by the way, thanks for adding so many improvements to Xith, I can't wait to test them... if only I had more time)

Lilian

[Amos Wenger]

...(and it seems like the textures are not properly loaded. They look rather odd.)...

Could this be the same problem in the MD3 model loader demo by java cool dude?

BTW. there are a lot of broken links/dead ends in the demo and GSG section of the Xith website.

(Probably same problem as with the MD3 loader)

Wha wha what ? Lots of broken-dead-vampire links on Xith.org ? Tell me where.. and I'll kill them. 

[Amos Wenger]

Wha wha what ? Lots of broken-dead-vampire links on Xith.org ? Tell me where.. and I'll kill them. 

Ahah now I see in the Demos page : these links are a pain in the ass. When 1.0 comes out I'll replace all of them by a single JNLP to the xith3d demo started (thanks Marvin).

[Amos Wenger]

View does not work very well here : i get a
dX = -1
dY = -3
when I don't even move my mouse.. HIAL problem I guess..

But it runs at a smoothe 40FPS

[Marvin Fröhlich]

View does not work very well here : i get a
dX = -1
dY = -3
when I don't even move my mouse.. HIAL problem I guess..

Yes. It is a HIAL problem. I fixed HIAL yesterday, since the exclisive mouse for  AWT mouse wasn't working properly (after the Robot repositioned the mouse the moved event was fired, which caused an infinite loop). Well, I ran on a problem: In non-fullscreen mode the component.getLocationOnScreen() method returns wrong values, which I fixed by constant +1 for x and +3 for y. I guess, this is window manager / theme dependand. And your problem ensure me in this suspection. I'll try to figure out a way to automatically calculate these values.

But there shouldn't be such a problem in fullscreen mode (undecorated frame).

But it runs at a smoothe 40FPS

Well, it runs absolutely smooth an my machine (50 - 250 FPS), when you're movin inside the same room (cluster). But when you're passing the borderline between two clusters, the movement stucks for up to a second or so.

What about the textures. Do you have a clue for them? There're two TODOs in the BSPConverter class. This is where the textures are loaded. I guess, I've just used a wrong parameter. The old (now incompatible) way the textures were loaded is still there (commented) so you can compare them. Please have a look at it, and tell me, if you can do something about it.

Marvin

[Marvin Fröhlich]

Cool!. After I switched to STATIC Shape3Ds in the BSPConverter it runs about 16% faster and absolutely smooth .

[kevglass]

What sort of hardware are you running on?

Kev

[Marvin Fröhlich]

What sort of hardware are you running on?

Athlon64 3000+, 1GB Dual Channel RAM, Radeon 9800 Pro 128MB.

[renanse]

Cool, let us know where to get the latest when it's ready cause I'd love to redo the benchmarks.  Currently, just pulling up the Java3d, Xith and jME versions I have on at 800x600 my work machine (P4 3.2 with a 9800 XT card) gets me 343, 345 and 165 FPS respectively after a 30 sec burn-in at the initial spawn point.

[Marvin Fröhlich]

I found the problem with the textures . It was a problem with the parameters, but with the filename parameter . The textures are expected to be in a certain folder structure, which was not the case. So I searched the filenames in the bsp file and recreated the folder structure. e voila... the level looks just great, even if there're still some textures missing. the biggest missing texture is the sky. Maybe someone has this texture or another matching one, then he could commit it to CVS please.

I proceeded to code the org.xith3d.util.EgoInputAdapter and now I find it could be useful for many people writing FPS shooters. Please have a look at it and tell me, if there's anything missing to have a common tool for this purpose.

Enjoy the demo

Marvin

[Marvin Fröhlich]

Cool, let us know where to get the latest when it's ready cause I'd love to redo the benchmarks.

Checkout your CVS. It's just become ready .

Marvin

[kevglass]

ust pulling up the Java3d, Xith and jME versions I have on at 800x600 my work machine (P4 3.2 with a 9800 XT card) gets me 343, 345 and 165 FPS respectively

Is that right? Xith out performs Java3D? And JME has less than half the framerate?

Kev

[renanse]

Sigh, my brain is on ice in this freezing cold office...  it's jme: 345  java3d: 343 xith: 165...  Java3d does better than jME though if you go to the top of the scene and look down at everything at once.

I'll have a look tomorrow at CVS when I thaw out...   Memory footprint, CPU usage and FPS are what I look at for the testing.

[kevglass]

Just to check, the version of the BSP viewer that Qudus checked in is based from David Yazel's original stuff right? It's not based off the Tom's benchmark code which is almost certainly what Renanse is running?

Probably not a fair comparison if so.

Kev

[Marvin Fröhlich]

Just to check, the version of the BSP viewer that Qudos checked in is based from David Yazel's original stuff right? It's not based off the Tom's benchmark code which is almost certainly what Renanse is running?

Probably not a fair comparison if so.

Yes, it's based on David's code. Is the Tom's benchmark code faster (I mean after the level has loaded)?

Marvin

[Marvin Fröhlich]

About the missing textures. I tried another map and basically there were the same textures missing. It seems like we need some kind of "Quake 3 map kit", where all the base textures are located in. Or if I remember right, they were in the base folder in a Quake 3 installation. Are they freely available somewhere?

Marvin

[kevglass]

Looking at the numbers you were quoting compared to Renanse's I'm not convinced which version would be faster. It would seem Tom's was quicker.

However, I think it'd be a clearer comparison of scenegraph core performance if the code bases were essentially pretty similar. The webstarts and related resources were referenced in this thread:

http://www.java-gaming.org/forums/index.php?topic=11748.60

Kev