Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[libgdx] Z vertex

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!

adunato

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.