It uses opengl < 2.0. Not sure what that lib does for you, but it seems it outputs only a regular png?
If thats the case there are a few examples around showing a sprite animation. Shaderblow for example…
Much more than that. Here, have a look at this cool software for graphics artists:
The artist create 2d animations (with bones) and then the program saves it as a xml file. The spriter lib renders this animations into a texture so that it can be used for example by JME.
You could take that example and instead of using raw LWJGL calls you rewrite it to use the JME api. For instance the loader of textures could be using the assetmanager to load textures and the rendering could simply use a Picture or a simple quad with unshaded material.
The Drawer then needs to change the texture on the material, set the rotation and translation.
JME expects to own the state of the OpenGL state machine. I think you take your life into your own hands if you want to shoehorn someone else’s ownership of the state machine into that pipeline.
You are better off reimplementing it in terms of JME. (The same thing was done for Nifty though nifty already supported that kind of pluggability.)
In particular, loading a Texture and drawing it is done on these lines:
// Create a wall with a simple texture from test_data
Box box = new Box(2.5f,2.5f,1.0f);
Spatial wall = new Geometry("Box", box );
Material mat_brick = new Material(
assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
mat_brick.setTexture("ColorMap",
assetManager.loadTexture("Textures/Terrain/BrickWall/BrickWall.jpg"));
wall.setMaterial(mat_brick);
I guess this means that adding support would imply creating a Material with brand new shader code?
Then the update loop for Spriter could be easily managed by an AppState, but that’s the easy part.
Like I said in an earlier post which I also quoted. I think you simply need to swap the texture on the material. You could basically use the unshaded or gui j3md and then keep swapping the texture out as in material.setTexture(). In theory that should do the trick. You also need to ensure you rotate and translate the “sprite” or node in this case according to the Spriter Object.
The loading bit is super easy, just proxy a call to the asset manager.
I did similar thing for Spine because I’ve used libgdx with Spine and find it’s nice to intergrate. In fact I take a look at libgdx runtime as reference and then make one for jme3 around a week. We can also use existed Blender 2d file and it work as expected with too much effort. Anyway, Spriter or Spine have much better support for 2d and workflow I guess.