Quake3 level loader - Benchmarks

[Amos Wenger]

OK ok I'm not gonna run the old path one more time but phew I think "optimizations" had made the FPS go down..

Apparently the vecmath_kh library isn't any better.. I don't get perf boost when I use it.

What about the GC concerning Iterators? Has it become better? I converted several advanced-loops to classic ones. This should at least have effected this kind of GC.

Don't know, will re-bench it soon.

[Marvin Fröhlich]

Perf boost isn't important in that context... what matter is reducing full GC pauses as they are visible (and annoying) for the player...

Profiling and cleaning up vecmaths was my first task when I selected Xith for my game. now I have full gcs only on level loading, which isn't annoying at all

Well, however, I wouldn't mind gaining 50% frame rate : that would give much time for everything else (game logic and music especially)

Are you using HK's vecmath lib? Have you modified it (except adding the TexCoord4f class like I had to do)? If you did, could you please commit it?

Marvin

[c_lilian]

Are you using HK's vecmath lib? Have you modified it (except adding the TexCoord4f class like I had to do)? If you did, could you please commit it?

Marvin

No, I've patched the official vecmaths. But i can't commit it as the updates aren't thread safe and thus, not compatible with java3d.

Lilian

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

[Amos Wenger]

Are you using HK's vecmath lib? Have you modified it (except adding the TexCoord4f class like I had to do)? If you did, could you please commit it?

Marvin

No, I've patched the official vecmaths. But i can't commit it as the updates aren't thread safe and thus, not compatible with java3d.

Lilian

What major changes did you do ? I'm actually trying to have a GC-correct vecmath version from Sun sources. (Kenji Hiranabe's one does not use Sun's sources, right?)

[renanse]

Please also see if you can get the color blending working on the flames.

[Amos Wenger]

Please also see if you can get the color blending working on the flames.

yeah, yeah one thing at a time.

wrong atom sorting, I bet. c_lilian, could your quicksort change have broken something ? not accusing you just trying to gather info about that issue. did you test extensively your patch ?

[c_lilian]

well, it's rather straightforward, so it shouldn't be a problem... the algorithm is direct from sir Gosling...

I'll have a look at it again tomorrow just in case.

Lilian

[Marvin Fröhlich]

well, it's rather straightforward, so it shouldn't be a problem... the algorithm is direct from sir Gosling...

I really hope it has nothing to do with the fact, that I removed the RenderBucket class.But I really believe it hasn't. It should just be more efficient.

Marvin

[Amos Wenger]

well, it's rather straightforward, so it shouldn't be a problem... the algorithm is direct from sir Gosling...

I really hope it has nothing to do with the fact, that I removed the RenderBucket class.But I really believe it hasn't. It should just be more efficient.

Marvin

What was it used to ?

[Marvin Fröhlich]

What was it used to ?

I don't know the initial thought behind it. But what remained is the class RenderBucket, of which any instance held an instance of RenderAtom. And instead of directly using the RenderAtom (with the additional attributes of RenderBucket) a RenderBucket instance was used accessing the RenderAtom instance through it.

So the RenderBucket class was simply useless as far as I understood it.

Marvin

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

[Marvin Fröhlich]

I've just converted the "old" flight path to the new format and recommited it.

Marvin

[renanse]

Great, that will make future benchmark results a lot easier to do comparisons with.

[Marvin Fröhlich]

@renanse: please look into your PMs.

[renanse]

nod, I'll get that flight file changed here shortly.

In the meantime, could you apply these two code changes?  They will bring your visual look up to par with the other versions of the test (aside from the flame transparency issue.)

In com.xith3d.loaders.texture.TextureLoader's constructor, change the last line to:

1   2   3

this.defectTexture.setImage(0, new ImageComponent2D(             ImageComponent.RGB, 2, 2, new byte[] { 127, 127, 127,  127, 127, 127,                         127, 127, 127, 127, 127, 127}));

In org.xith3d.loaders.bsp.BSPConverter.convertTextures(String[]) at line 353, add the following else to if ((textures == TextureLoader.getInstance().getDefectTexture()):

1   2   3

} else {                 textures[i].setMagFilter(Texture.BASE_LEVEL_LINEAR);                 textures[i].setMinFilter(Texture.MULTI_LEVEL_LINEAR);

[Marvin Fröhlich]

Thanks for attaching the flight path .

I've changed an committed the BSPConverter as you said. But I didn't change the TextureLoader in that way, since just gray is not a good defect texture. You won't possibly see, that it's a defect one. And it won't do anything to the performance.

Maybe we can find an alternative texture to use for the sky, if you can't get the original Q3 base texture.

Marvin

[renanse]

Grey is what everyone else uses and you see that default all over the place (for example, several lightmaps)  At least try it and do a comparison.

[Marvin Fröhlich]

Grey is what everyone else uses and you see that default all over the place (for example, several lightmaps)  At least try it and do a comparison.

Well, of course I tried it and found it a bit nicer. But I think better seeing that a texture is missing somewhere is better than having a nicer scene and maybe not recognizing that a texture is missing.

Marvin

[renanse]

Latest version of your code seems to have all of the textures upside down.   

The better news though...  Did some detective work on my own and discovered your transparency issue...  as I thought previously, the draw order is wrong.  If you draw your opaque bin before the transparent bin (as it should be) your problems go away.  Simply swap the two lines in CanvasPeerImpl.renderMain(RenderBinProvider) so they look like this:

1   2

drawBin(binProvider.getOpaqueBin());         drawBin(binProvider.getTransparentBin());

Make sure to do it in lwjgl and jsr231.  Now you can't say us jME guys never do anything nice. 

[Marvin Fröhlich]

Latest version of your code seems to have all of the textures upside down.   

The better news though...  Did some detective work on my own and discovered your transparency issue...  as I thought previously, the draw order is wrong.  If you draw your opaque bin before the transparent bin (as it should be) your problems go away.  Simply swap the two lines in CanvasPeerImpl.renderMain(RenderBinProvider) so they look like this:

1   2

drawBin(binProvider.getOpaqueBin());         drawBin(binProvider.getTransparentBin());

Make sure to do it in lwjgl and jsr231.  Now you can't say us jME guys never do anything nice. 

I'm very impressed. Thenk you very, very much It did the trick.

Marvin

[Marvin Fröhlich]

Latest version of your code seems to have all of the textures upside down.   

Hmm... No, just the flames are upside down. Let's wait for Amos. He'll certainly have an answer... I'm too tired now.

Marvin

[cylab]

Latest version of your code seems to have all of the textures upside down.   

Hmm... No, just the flames are upside down. Let's wait for Amos. He'll certainly have an answer... I'm too tired now.

It seems renanse is right and all textures are upside down... 

[renanse]

I'll be putting together the final performance tests and webstarts tonight or maybe tomorrow.  Is there anything further coming from the xith team I should be aware of (aside from bug fixes)?

[renanse]

btw, regarding textures being upside down...   Q3 maps seem to rely on *not* flipping the textures, which is different than most things out there.  I couldn't find a flag in Xith to tell the texture loading process to flip/not flip textures, but maybe you guys know better where to look.  That would be my first guess as to where something might be broken....  That or somebody hardcoded to always flip. 

[Marvin Fröhlich]

I'll be putting together the final performance tests and webstarts tonight or maybe tomorrow.  Is there anything further coming from the xith team I should be aware of (aside from bug fixes)?

It would be very nice if you'd wait until wednesday. There's a huge performance regarding update I'm currently working on. It's more work than I expected and I'll need this day and tomorrow. Is this ok for you?

Marvin

[renanse]

Sure, just so long as it doesn't drag out forever.

[Amos Wenger]

Latest version of your code seems to have all of the textures upside down.   

The better news though...  Did some detective work on my own and discovered your transparency issue...  as I thought previously, the draw order is wrong.  If you draw your opaque bin before the transparent bin (as it should be) your problems go away.  Simply swap the two lines in CanvasPeerImpl.renderMain(RenderBinProvider) so they look like this:

1   2

drawBin(binProvider.getOpaqueBin());         drawBin(binProvider.getTransparentBin());

Make sure to do it in lwjgl and jsr231.  Now you can't say us jME guys never do anything nice. 

Thank you very, very much.

Yeah I'm impressed, you jME guys often do some nice things.

[Marvin Fröhlich]

The Textures are now flipped top-up .

I douplicated all the getTexture() and createTexture() methods of the TextureLoader class and added a parameter to the duplicates telling, if the image is to be flipped. The default is FLIPPED_VERTICALLY, like OpenGL needs it. I had to use an enum instead of a simple boolean, since otherwise we had ambiguous interfaces.

Well... enjoy

Marvin

[Amos Wenger]

The Textures are now flipped top-up .

I douplicated all the getTexture() and createTexture() methods of the TextureLoader class and added a parameter to the duplicates telling, if the image is to be flipped. The default is FLIPPED_VERTICALLY, like OpenGL needs it. I had to use an enum instead of a simple boolean, since otherwise we had ambiguous interfaces.

Well... enjoy

Marvin

Good job !

[renanse]

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.  I'll be writing a .shader interpreter for jME at some point (hopefully this week) which you are welcome to port across to Xith.

[Marvin Fröhlich]

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'll be writing a .shader interpreter for jME at some point (hopefully this week) which you are welcome to port across to Xith.

Thanks .

Marvin