Esoteric Software

[adunato]

Hello,

I'm trying to translate a skeleton on the Z axis to enable rendering of a billboard-style entity.

Looking at existing posts the closest to my issue I could find is the following based on MonoGame.
http://esotericsoftware.com/forum/Rendering-Spine-Characters-as-2D-Billboard-in-3D-World-12192

Looking through the libgdx runtime code however the structure of the mesh doesn't seem to use a zero z vertex, but rather no z vertex at all.

Is that an option to translate a skeleton on the Z axis? I'm starting to think that the only way is to write a custom draw function which includes z-index / vertex but I really hope there's a quicker way.

FYI I have tried to translate the whole Batch to prove-concept this and it does work however this solution is not viable as each entity has its own Z position and I would have to flush the batch for each object which doesn't make a lot of sense.

Thanks!

[Nate]

The usual way to do this would be using the batch transform and projection matrices. Otherwise you'll need your own Batch implementation that has Z coordinates (specify 3 Usage.TextureCoordinates when creating the Mesh). You probably want to base yours on a copy/paste of TwoColorPolygonBatch from spine-libgdx if you care about two color tinting, else on PolygonBatch.

[adunato]

Hi Nate,

Thanks for the reply.

The usual way to do this would be using the batch transform and projection matrices.

I suppose you mean something along the lines of..

batch.getTransformMatrix().idt().translate(0,0,zTranslateValue);

In which case, custom batch implementation will have to be the way to go as I need a per-skeleton z value.

[Nate]

Yep, if you don't want the extra batching from manipulating the matrices, you'll need your own batch that has a Z attribute per vertex.

[adunato]

OK. I cloned TwoColorPolygonBatch, implemented the z vertex and it works fine but it also involved changing SkeletonRenderer and RegionAttachment. Whereas I don't mind using my own batch implementation it's not ideal to have to keep merging changes to native spine runtimes every time a new version comes up. Plus given that both classes keep all their members private I can't either override the affected methods.

As a general question, are there any smarter ways to patch a library with your own code other than maintaining your own version control and merging changes once a new version is available?

I suppose there's no hope of having 3-dimensional vertices this ever being a supported feature in runtimes?

[Nate]

Regarding patching, I would likely copy the source into my project and just compile and use it from there, especially since spine-libgdx is a simple project. It should always be a manual process when updating the dependency to reapply the patch, otherwise things will go wrong.

I can't see a nice way to support a third vertex attribute for the Z axis without making the API clunkier. Sorry! FWIW, it should be rare you need to reapply your patch.

[adunato]

That's pretty much how I do it today to manage an existing patch, and you're right it's not really a complicated task. Still, I think I'll take this as an excuse to create my own repo / branch to manage patching via git.

No worries about API management of z values, I appreciate that using spine in a 3D environment is not a core use case but it's great that it can be adjusted to work with minor intervention.