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.

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.

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.

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:

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:

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.

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?

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:

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.

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.

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.

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.

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