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.
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
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.
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
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
hehe 
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 ;).
Thanks
Marvin
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.
Yes. Looks like the same problem.
The GSG is totally outdated. You should not use it at all.
Marvin
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?
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.
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
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
(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. ;D ;D
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).
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
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).
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
Cool!. After I switched to STATIC Shape3Ds in the BSPConverter it runs about 16% faster and absolutely smooth :).
What sort of hardware are you running on?
Kev