Ok, I’m tackeling multi-texturing right now. I think I have a way to integrate cleanly with everything now. Let me know what you think:
TextureState will now have a combine mode flag, and an array of Texture objects. This array size will be set during construction to the maximum texture units of the video card.
When set on texture state is called, it will go through the array, in a loop from i=0 to N where N is the number of textures.
Setting: glActiveTextureARB(GL_TEXTURE0_ARB + i) and all the texture info that needs to be set.
Geometry will now have multiple texture Vector3f arrays. Again as many as the video card allows. The user sets the arrays for each texture to use in the multi-texture. So, if texture state has 2 textures, the user should set 2 texture coordinate arrays in the geometry. If there are fewer texture coordinate arrays, the remaining textures are ignored, if there are more than texture state has set, an error will occur.
Then in Renderer, it will look at the geometry it’s going to render and bind the appropriate texture for each texture unit set in geometry.
Any problems anyone see with this?
Well, it’s working. And it’s very easy to use. Now, you just set a texture normally, but give it a texture unit to use:
textureState.setTexture(texture, 0);
textureState.setTexture(texture2, 1);
That sets the textures up, then you need to set the texture coordinates for the object.
box.setTextures(tex, 0);
box.setTextures(tex2, 1);
and viola, you’re done. Then you get results like:
I’ll be checking it in soon, but right now I am having a little bit of trouble finding the number of texture units that a particular card has. I’m hardcoding it right now, and that won’t work. 
Ok, multi-texturing is complete and checked in along with a test. I’m curious to make sure that it works with various cards.
BTW I do not check for the availability of the multitexture extension. I figure it’s safe to assume that if the card is supported by LWJGL then it has at least 2 texture units. Is this a safe assumption? LWJGL does not support some of the oldest cards, and support only those that are hardware accelerated, so I think this is safe.
One last note, demo is up on the demo page.
Nice work on multi-texturing Mark.
I think it will be very useful.
Gregg
yup, its kewl. 
Almost as cool as the tinting!
Thanks, I still need to define the combo flags for “mixing” the textures. But that’s the last of it.
Combine modes are set in Texture and working. Multitexturing is finished.
What is the best way to handle texture management? From the C/C++ world it usually means binding different textures as they are needed and giving them priorities.
I’m just not sure with jME and LWJGL. Right now I’m setting up a number of texture states each with a different texture. When I want to change the texture on the mesh I reset the render state with the alternate texture state that I now need and recall updateRenderState. This seems slow. I’m getting pretty low frame-rates like this.
I’m going to try next to create identical meshes, each with their own texture and then just switch out meshes as the look needs to change.
I think I must be missing something fundamental.
What exactly is it you are trying to do? Are you changing the texture of a mesh in game? Showing damage or something?
Anyways, the way it is now, it wasn’t designed for quick switching of a texture on a mesh. However, I think I have an idea. Allowing you to put texture packs in a state and switch the displayed pack. That way you don’t have to handle multiple states.
I have built my own gui set of widgets. The ones in jME don’t allow for good interaction with the Mouse, instead relying on a hardware mouse from LWJGL. I have it working just fine, but I just seems a little slow.
As the mouse moves over and clicks down on the Quad I switch out textures on the quad to show mouse over and mouse down.
And for what it’s worth, the widgets in jME use glDrawPixels which doesn’t store the texture card side either.
I assume that jME or LWJGL convert all these meshes to Display Lists behind the sceens, right? That’s probably why switching out textures makes it slower, because the display list ends up changing.
Again, I probably am way off base.
I take it back, we’re using vertex arrays and indexes… not display lists, I knew that but just wasn’t thinking. :?