• Runtimes

  • Seeking options for integrating Spine runtime output

    inglés

Hello all,

Fast background: Experienced programmer, new to Spine; my aim is to render some Spine content as part of something else. I already have a functional Blender workflow for creating content which I can render and animate programmatically, though Spine would be greatly preferred in this case if I can get it working.

I'm using LWJGL, though not the libgdx library specifically. I do have the Spine runtime examples working with spine-libgdx in a test project, and I have adapted that as far as rendering to a separate target (rather than as a single application), though proceeding to scrape that and feed into a frame buffer in my own OpenGL context would be very inefficient and probably fraught with problems.

While I gather that the correct option in theory is to translate/port/re-implement the entire package (i.e. all of com.esotericsoftware.spine), I'm hoping for something faster for now, and I'm not against having libgdx loaded alongside everything else just for providing Spine output. My thoughts are -

  • Is there a good way to setup/extend libgdx so that it can use an existing OpenGL context (and be called from the existing thread, of course)?
  • Is libgdx wedded to using an Application (e.g. LwjglApplication) and a listener with specific methods for workflow (create, render...), or can it be adapted just to handle loading/unloading assets and making only the GL draw calls?
  • Would the fastest route be to pick through com.esotericsoftware.spine and remove/replace all usage of libgdx?
  • Without a generic Java implementation, would it be better to abandon the above and instead try to build one of the generic runtimes into a native to be loaded dynamically?

The hope is that it can be called up as-and-when, and 'just draw' without worrying about my projection/model transforms or whether it's drawing to an FBO - perhaps by making it a version of the GL20 interface with pass-throughs for the GL calls (which seems to me to be equivalent to having a generic Spine runtime in Java as long as one is willing to load libgdx on the side), or perhaps just by ensuring that everything is using only one central LWJGL library.

Cheers for any pointers!

Related Discussions
...

libGDX is wedded to an Application implementation I'm afraid, just using implementations of GL20 etc. won't work as there's a lot more going on in the background (quite a bit of native code, shared library loading etc.).

I guess your quickest hack would be to take spine-libgdx and remove the libGDX dependencies, then implement your own renderer, which should be pretty trivial if you can load textures and draw meshes in your own framework.

Understood; the plan at the moment will be to remove libgdx natives from the project and adapt it from there, but try to retain as much as possible in the sense of allowing the Spine code to use a standalone subset of libgdx utility functions (indeed, retaining the implementation of e.g. Color, Matrix3 could turn out to be important for a consistent result at the end).

That seems feasible. You can rip out the Color, Matrix3 code from libGDX, provided you retain the copyright headers, then write your own SkeletonRenderer and massage SkeletonJson/SkeletonBinary a bit to work with whatever file i/o API you want to use.

6 días más tarde

Reporting back with a functional result! (Image | Video)

Outline of what I ended up doing:

  • General conversion of spine-libgdx to remove any outside interaction except for the ability to load files via FileHandle (though without Gdx.files) - this is to let it load atlas files as normal, excepting the textures. Speaking of which...
  • All classes which use Texture from libgdx converted to use a general texture-like interface instead (this required making custom versions of the libgdx classes Sprite, TextureAtlas, TextureAtlas.AtlasSprite, TextureAtlas.AtlasRegion, and TextureRegion).
  • A callback is passed to the atlas-loading process which lets it report image file paths (named in the atlas file) and receive an instance of that interface (after loading via my existing pipeline). It doesn't need the actual image/texture for drawing in this case, though it does make extensive use of gets for the image width/height.
  • Similarly, added an extra means for SkeletonRenderer to signal that a particular Spine patch should have a particular texture.
  • Speaking of SkeletonRenderer, re-made draw(Batch, Skeleton) into a method which instead updates mesh data (it just has to pipe the XYs and UVs to me; I have handled any mesh creating/resizing which might happen as a result of its output).
  • On my end, I have modified things to avoid Z-fighting or ambiguities in general - in the specific case when two polygons are part of the same Spine character, the pairwise polygon-sorting now matches the order in which SkeletonRenderer reported them (otherwise reverting to its depth-based ordering).

It's now working, loading my artist's content, and doing pretty much everything I'll need. Thinking ahead, the only other desirable trick may be some way to ensure that it can both depth-test the Spine patches and also write to the depth buffer - but where each test uses a snapshot prior to starting the character, and the writes are 'committed' after the full character is drawn. This would be sidestepped by using an FBO or effectively fixed by using a depth test which passes with some small tolerance (so the patch is still drawn even if it is 'slightly behind' a neighbour), or may not turn out to be an issue at all if my higher-level sorting for Spine characters always succeeds in drawing back-to-front.

In any case, thanks for the pointers!

  • Nate

  • Publicación n.º 7
  • Publicación en inglés

Great! Glad it is working for you.

Looks like you have a PMA problem (see around the mouth). You should ideally use PMA for rendering, otherwise be sure to use an atlas without PMA.

Got it; I'll be sure to require that each loaded character also carries information about the type of blend to be used.
Here's the same thing with PMA instead of regular-A:

Awesome!