slot detachment keyframes ignored in reverse

indiepig

If I have a keyframe to attach a slot, reversing the animation will not detach the slot.
With the previous version of the libgdx runtime, I could add a keyframe to detach the slot, and that would work, but with the latest version the slot never detaches.

I don't know if I'm awake enough to do a pull request just now, but here's what seems to fix my problems:

Animation.java Line 505 in AttachTimeline

public void apply (Skeleton skeleton, float lastTime, float time, Array<Event> events, float alpha) {
         float[] frames = this.frames;
         if (time < frames[0]) {
            skeleton.slots.get(slotIndex).setAttachment(null);
            return;
         }

     int frameIndex = time >= frames[frames.length - 1] ? frames.length - 1 : binarySearch(frames, time) - 1;

     if (lastTime <= time) {
        if (frames[frameIndex] <= lastTime) return; // no-op
     } else {
        if (frames[frameIndex] >= lastTime) return; // no-op
     }
     String attachmentName = attachmentNames[frameIndex];

     skeleton.slots.get(slotIndex).setAttachment(
        attachmentName == null ? null : skeleton.getAttachment(slotIndex, attachmentName));
  }

Nate

If time < frames[0] then it should not set the attachment to null. When played forward, the attachment should not change until the first AttachmentTimeline key. Set a key at the start of the animation if you want it to change when played in reverse.

Does that solve your problem without needing to change spine-libgdx?

indiepig

Setting a key at the start of the animation doesn't solve my problem.

To try to explain it in a different way. The behavior I'd expect is that for any type of animation, if I play it in reverse, it should match exactly what it was forward, but in reverse order.

So if I add an attachment at frame 5, if I play the animation in reverse, I would expect the attachment I added on frame 5 to be removed when reaching < 5.
That is what I see in Spine, but not what I see in LibGDX (without my monkey patch).

Why do you say that if time < frames[0] shouldn't set the attachment to null?
Let's say that in setup I have a sword, but I have it marked as hidden. Then I have a sword swing animation, and on frames[0] I attach this sword (or any other frame for that matter). If I play this animation forward, then play it in reverse, I would expect the sword to no longer be attached at the end of the reverse animation. It should be exactly as it was before I played the animation forward.

-Nick

Nate

Say you have a sword and an axe in slot "weapon". Your skeleton has the sword equipped and you play an animation that at from 5 shows the axe in the weapon slot. What happens when you play the animation backward? The animation doesn't know what attachment used to be attached before frame 5.

indiepig

So if I'm understanding correctly, you recommend to never have something detached in setup pose and for every animation at time 0 detach everything unused?

It sounds like it might make more sense to me to attach equipment only via code.

Nate

Setting an attachment key at frame zero (whether empty or an attachment) will let your animations play backward. You could use code to remember the attachment before an animation plays, and when it is played backward you could modify the animation's key at frame zero, or use code to set the attachment if the animation sets it to empty. You could use code to check the attachment every frame after the animation is applied, then you could record the attachment changes so you can make the reverse changes when played backward. Another alternative might be to use events to run code to do the attachment change, again so you can keep track and make the reverse changes when played backward.

indiepig

Yeah, this is rather tricky... I believe you and I agree that when you run an animation in reverse, the animation should be the reverse of what it was forward. The place where it breaks down is "what is the state before the first keyframe?" In my use cases the state of the attachment before the first keyframe is always what it was in the setup pose, but I get that going to the setup pose won't work for everybody.

There's another problem that's somewhat related. In ColorTimeline#apply there's the line "if (time < frames[0]) return;" which makes it so when playing an animation in reverse, the color doesn't end up on exactly what it was at frames[0]. This is particularly noticeable for alpha tweens.

Ok, I think I figured out a disconnect we were having. Having a frame at time 0 for attachments didn't solve my problem because of this oddity:

If you play an animation forwards, in order to hit frame 0 correctly you need to do: from: < 0, to: > 0
If you play an animation backwards, in order to hit frame 0 you need to do: from > 0, to: == 0

Nate

For ColorTime, again if you set a key at frame zero it should work (the time < frames[0] becomes impossible).

I don't understand your "from: to:" notation. :wonder:

Say you have attachment key A at frame 0 and key B at frame 15. A is applied from frame 0 inclusive to 15 exclusive, B is applied from frame 15 inclusive and higher. This is true when playing forward and backward.