I’ve been pretty busy working on other aspects of the game I’m building and felt like something different today and came to the startling, sudden realization that I had no idea how to handle texture coordinates in jME3. I’d planned on using simple sprite sheets for animations and maybe a bit more complex than that, but first things first. After I’ve got a quad, billboard it (hacky billboard method in place =p), and apply a texture material to it, how do I go about changing the texture’s coordinates? I looked around in the source for a way to pull it off but nothing jumped out at me. Didn’t see any variables in the texture shaders either…
I guess I could have a bunch of textures to flop around and just apply them in sequence to pull it off, but that seems like it could be less optimal. Not sure really since I’d probably be using the same amount of memory.
*Crosses fingers hoping post makes it into the correct place in the new forum. XD
Have you considered doing this in a shader?
Say your sprite anim texture is 256x256 (0f,0f is bottom left and 1f,1f is upper right in texture coordinates) and your sprite size is 32x32 so your sprite dims are 0.125f x 0.125f on the texture.
If you had spriteWidth (float), spriteHeight (float), and spriteIndex (int) as uniforms in a shader then you could have the shader do all of the work computing the coordinates on the fly.
I was almost scared that would be the solution as I have no prior experience with shaders. Scary stuff! =p
I guess I’d end up having to make a shader for every animation in this case correct? It also makes me wonder if I could somehow incorporate multiple direction sprites in the shader too, e.g. for walk cycles in different directions.
Come to think of it, can I hard set the texture file (or files) in the shader itself? Odd question to ask, but there’s some benefits to that, that I could exploit.
I’ll take a look at this as soon as I’m able. Learning curve is steep as hell for this for me though, so it might be a bit before I get back with results. I’ve been at a standstill ever since I realized this, because it really is a make it or break it problem for what I’ve got in mind. - *Scoots over to that pdf about materials and shaders…
Looking at the source of the Quad class might help. You can just get the FloatBuffer for the texcoords using Mesh.getFloatBuffer(VertexBuffer.Type.TexCoord).
Then its easy, every vertex has a 2D texture coordinate.
EDIT: But doing it the way hazmat said will probably be faster, especially if you have a lot of sprites (200+). Consider also if texture atlas is good for you. A user on the jme forum actually posted a tool that lets you generate a texture atlas for jme models.
Bumping heads with the shader idea a bit. The one thing that’s killing me at the moment is that I’ve written the shader to use the global g_Tpf for determining frame changes. It doesn’t really “do” anything yet, but I get a null pointer exception thrown in:
at com.jme3.renderer.RenderManager.updateUniformBindings(RenderManager.java:283)
u.setValue(VarType.Float, timer.getTimePerFrame());
I’m building the material and object in SimpleInitApp, is this too early for it to have the time per frame established or something?
— EDIT: Nix the above. I just read something describing how GLSL shaders cannot have variables to communicate from one run to another. So knowing this, the shader cannot handle the actual sliding of the frames because it will have no way of knowing when or which frame to switch to! Soooo, I think I may have misunderstood what you meant hazmat. Did you mean to simply have the shader handle the coordinate shifting and leave the rest to the actual Java logic? (Probably a Control class or some such to control the animation)
the timer attribute is never instanced, i’m gonna try to fix this.
For now a simple workaround is to declare your own m_tpf variable for the shader and set it in the simpleUpdate method.
That’s fixed and committed in the last SVN revision