I’ve just converted the “old” flight path to the new format and recommited it.
Marvin
Great, that will make future benchmark results a lot easier to do comparisons with.
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:
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[i] == TextureLoader.getInstance().getDefectTexture()):
} else {
textures[i].setMagFilter(Texture.BASE_LEVEL_LINEAR);
textures[i].setMinFilter(Texture.MULTI_LEVEL_LINEAR);
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
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
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:
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 ;D It did the trick.
Marvin
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
It seems renanse is right and all textures are upside down… :-\
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)?
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. 
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
Sure, just so long as it doesn’t drag out forever.
Thank you very, very much.
Yeah I’m impressed, you jME guys often do some nice things.
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 ;D
Marvin
Good job !
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.
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.
Thanks :).
Marvin