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

[libGDX] Animation in multiple tracks

ldebrasi

Hi there,

I'm having a problem in the last versions of the spine-libgdx runtime. Here's my case:

I set a "walk" animation in the track #0:

animationState.setAnimation(0, "walk", true);

I set a "costume" animation in the track #1:

animationState.setAnimation(1, "costume", true);

So far so good, everything works great.

After a while, I want to set another animation in the track #0:

animationState.setAnimation(0, "static", true);

What's happend? The track #0 is changed but the track #1 it's cleared. I want to keep the "costume" animation on the track #1.
I can solving this making again a

animationState.setAnimation(1, "costume", true);

But this used to work fine in the previous versions.

Thanks,
Leandro

Maybe the problem it's that I made a

spineSkeleton.setToSetupPose();

between both setAnimations?

But it's weird. As I said, this worked in the older versions.

Thanks,
Leandro

Pharan

You might be mistakenly relying on multiple animations to put a custom skin on your character?

The old attachment key behavior allowed you to predictably override attachments on lower track indexes. This is probably why it worked in older versions. But that code was incredibly slow so it was replaced.

Admittedly, that behavior was useful for some specific conditions, and I do wish a similar predictable-override behavior was doable again.
If you were only using it to change the costume/skin/overall look of your character though, there are better ways to do it. (ways that work well with setToSetupPose, which is super useful)

Could you use Spine's Skins feature instead of a "costume" animation? What does your "costume" animation do?

ldebrasi

Hi Pharan, Thanks for your suggestion! I'll try the Skins 🙂

Nate

Pharan a écrit
I do wish a similar predictable-override behavior was doable again.

Yeah, me too. Maybe we could have Slot#setAttachment(slotIndex, attachmentName) which would use Skeleton#getAttachment(slotIndex, attachmentName) internally. This way the slot could remember the slotIndex and attachmentName and avoid looking up the attachment if it already had the right one. It's a little nasty because if the skeleton has a new skin or default skin set or if either of those skins change, then these fields need to be cleared on all the slots.

Pharan

@[supprimé]
What if AttachmentTimeline.apply only sets an internal string (attachment name) on slots?
And the lookup (and check-if-already-correct operation) only happens after the animations are applied, like after apply() but before updateWorldTransform(). (or in an earlier phase of updateWorldTransform).

So that if several animations get applied, all it does is switch the string variable around, but only looks up once if it changes.
And if only one animation is applied, it behaves as it originally behaved before, but without the cost of a lookup per frame.

Is that what you meant?
I agree that the that's how skins should work. You needed to do some extra stuff when you set skins anyway. This is just one more thing. Or maybe I don't fully understand what you meant.