I am in the need to use the extension GL_TEXTURE_RECTANGLE_EXT to use NPOT-textures. (For video playback for example) My first problem is, that I am a newbie in regard of JMonkey, so I am poking around a bit …
What is the correct way in extending jMonkey so it can support NPOT-textures with the Extension GL_TEXTURE_RECTANGLE_EXT?
My first idea was to create a new class (called LWJGLTextureRectangleState inherited from TextureState) and use this class like:
Quad q = new Quad("quad", 800, 600);
rootNode.attachChild(q);
TextureState ts = new LWJGLTextureRectangleState();
Texture t = TextureManager.loadTexture("/Users/stephan/Desktop/test.png", Texture.MM_LINEAR, Texture.MM_LINEAR, 1.0f, true);
ts.setTexture(t);
q.setRenderState(ts);
But this does not work, the methods of LWJGLTextureRectangleState (load/apply) don't get called, instead the methods of a LWJGLTextureState-object are called before entering the methods of my class (which results in an OpenGL-Error in the beginning of LWJGLTextureRectangleState.apply).
What's the best way to extend JMonkey? (I want to add support for 1D and 3D-textures also -- same question)
I wouldn't be opposed to just adding properties to the current TextureState for NPOT, 1D and 3D textures. After all I think all these textures would or could share the majority of the code, right? (But I'd wait for the opinion of the other devs too)
As to why your current solution doesn't work… weird. I'd think they'd only be called if you call them yourself with super. (I assume your class extends LWJGLTextureState)
I think i have to dig a little deeper inside the core of jme to understand what is happening. I will provide more feedback when available.
Perhaps it is the best idea to refactor the code of TextureState to support the various kinds of textures as subclasses. For example mipmaps are not supported for GL_TEXTURE_RECTANGLE_EXT.
to my described problem:
My class does not extend LWJGLTextureState, instead it does extend TextureState…
TextureState only holds Textures. Most of the information specific to the Texture is stored in the Texture class. This perhaps could be refactored into Texture1D, Texture and Texture3D, but I don't think we need seperate TextureState classes for each texture. In fact that could complicate things quite a bit, since you have several texture units.
my problem was that the TextureManager creates a TextureState-object and assigns the texture to it. If I load the image and create the texture-object manually, it worked somehow. But I ran into the next problem: jMonkey is very lazy about Texture-States. I needed to disable GL_TEXTURE_2D to use another texture-target like GL_TEXTURE_RECTANGLE_EXT
This led me to another solution: extending Texture and TextureState to support the different targets like 1D, 2D (default), 3D, RECTANGLE_EXT. So for now the TextureState keeps track of the last used target and disables it, if a new texture-target is requested.
The code has alpha-quality and is not tested fully. It should not break any existing code. Perhaps there is a cahnce to integrate it into the official core?
Small right now, because it doesn't seem the right approach. Eg. what if I want to have a 2D texture on texture unit 0, and a 3d texture on unit 1?
Better would be if there's an "AbstractTexture", then Texture1D, Texture, Texture3D and RectangleTexture can extend it. TextureState should then support all types of AbstractTexture.
Don't get me wrong, I'm glad to see someone working on this. And even if it doesn't go into CVS, your code might be very useful to some people. If you have an opinion why it shouldn't be done this way, please tell.
regard my solution as an awful hack – it works for me now, but is completely wrong for 1D and 3D textures. I think Image, Texture and TextureState should be refactored, so it can be better extended to support other texture-types and subloading.
But for doing that I have to spend a lot more time with jMonkey to understand the underlying concepts. I have some experience with SceneGraphs (OpenSceneGraph mainly) but I still need some more time to get comfortable with jME.