Is it possible to use Spriter lib on JME3?

I’d like to use the spriter lib. They provide an example for use it on LWJGL here:

https://github.com/Trixt0r/spriter/blob/master/SpriterTests/src/com/brashmonkey/spriter/tests/backend/LwjglTest.java

It uses some low-level LWJGL api. Should this work on JME as is or is it needed to develop additional components to run this sample?

Will it conflict with the existing Appstates/rendering?

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…

Is that a problem?

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 can do 2D skeletal animation with blender too (and use regular pipeline, I guess)

or

https://www.youtube.com/channel/UClpb3DM9Cgjv0LNTxEtolQQ

1 Like

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.

Did I understand correctly? Is not possible to call OpenGL 1.1 API from jME, and some rewrite of the lib is necessary?

They also provide loaders for libgdx, java2d and slick2d. Only JME users are left to the cold? :frowning:

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.)

1 Like

Maybe it’s easier than expected. They provide abstract classes that must be implemented in a engine-specific way:

https://github.com/Trixt0r/spriter/blob/master/Spriter/src/com/brashmonkey/spriter/Loader.java

https://github.com/Trixt0r/spriter/blob/master/Spriter/src/com/brashmonkey/spriter/Drawer.java

Maybe you missed my reply :smiley:

It really doesn’t look that difficult, just have a play and see what you can do.

Hey guys,

I am the author of the current Spriter library for Java.

It should be actually very easy to get this working with the JME3 if it supports sprites already.

You just have to implement a Loader, which is able to load and dispose textures and a Drawer which knows how to render the loaded textures.

Just have a look at the backend examples.

Unfortunately I have no experience with JME3 so it may take a while until I provide you an example.

Maybe someone of you can get it work faster and send me a pull request?

– Trixt0r

2 Likes

Hi there, welcome to the forums, it’s always great when authors of interesting things drop by to support their stuff :smile:

Once I get a spare hour or so I might have a go at this, it should be very straight forward, however I suggest @Pesegato give it a go :wink:

1 Like

I’ve forked the repo but I get errors on Maven build. :frowning:

However, the basic problem is that the Loader and Drawer are solving problems which are already managed by jME.

JME is Material based, and as such the drawing is done with shader code, not from java. Have a look at the tutorial example:

http://wiki.jmonkeyengine.org/doku.php/jme3:beginner:hello_asset

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.

1 Like

I’ve already tried yesterday to clone the repo but the maven didn’t build. Since I am a total maven n00b I don’t know what to do :frowning:

About the loading: feel free to :laughing: or :sob:, but this is the best I could came up with:

public class JME3Loader  extends Loader<Sprite>  implements AssetLoader{

    @Override
    protected Sprite loadResource(FileReference ref) {
        
        //now what? load((AssetInfo) ref); ???
    }
    
    @Override
    public Object load(AssetInfo assetInfo) throws IOException {
        InputStream is = assetInfo.openStream();
        
        return is;
    }
} 

Can you give the full log of mvn install?
Maybee I can help, as I have to wrok with maven on a daily basis.

@Empire_Phoenix

http://pastebin.com/Aqw9B9AK

surefire was not found? it seems a bit like your maven installation is a bit broken.

You could try to just beuildd it without maven outside, after all if everything works you only need to write a few adapter classes.

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.

1 Like