abuki We have a fairly complex track setup for the main characters, playing multiple animations in different tracks. And now it looks like when on one track the animation is interrupted and mixed to another that does not have keys for the bone the previous had, the pose for the bone is kept instead of mixing to the setup pose. Which should be the correct behavior, right?

If two animations are on the same track, then mixing out an animation by starting another one will mix out the changes of this animation if there is no key in the second animation. If there are animations on lower tracks, it's not mixed to the setup pose but the lower track will show. It's the same with the empty animation, which has no keys and mixes out the preceding animation, but does not apply the setup pose (which would be strange, overriding everything on lower tracks). If you want to mix to the setup pose on higher tracks overriding lower ones, you need to set a key identical to the setup pose, and have Animation clean up disabled in the export settings (otherwise these setup-pose keys will be removed again automatically during export).

abuki Which should be the correct behavior, right?

This sentence was a bit ambiguous. What do you assume to be the correct behaviour?

Harald have Animation clean up disabled in the export settings (otherwise these setup-pose keys will be removed again automatically during export).

Or check Layered!

abuki It rises some questions, but if there is a detailed documentation for this, please give me the link, but I am unsure if I was able to find it.

See:
https://esotericsoftware.com/spine-applying-animations
More specifically:
https://esotericsoftware.com/spine-applying-animations#Tracks
https://esotericsoftware.com/spine-applying-animations#Playback
https://esotericsoftware.com/spine-applying-animations#Empty-animations

abuki What is the correct and expected behavior? After the mixing, should bone A have keys from setup or from interrupted animation1 (depending on when we started mixing)?

"Track 2 - another third animation3 that has no keys for A" is irrelevant for bone A.
If the lower tracks don't key bone A as you've mentioned, and you're mixing-out the animation on track 1 which keys bone A to an animation which does not, you should end up with the setup pose.

If this is not your result, you might have discovered a bug. Could you please describe what result you get? Unfortunately it's a bit ambiguously written.

abuki Didn't know about the Layered tick box! That sounds very useful, can you please share a more detailed info or docs link on it?

When selecting an animation in the Tree view, you have options Export and Layered.

abuki just wanted to read some more detailed info how exactly the Layeredworks.

Normally animation clean up assumes the animation is applied on top of the setup pose -- in other words, that the animation is the first one to be applied. Clean up (among other things) will delete keys at the start of the animation that are the same as the setup pose.

When an animation is applied on top of another animation, those keys that are the same as the setup pose may be needed to override the animation below. Without this Layered check box, you can't use clean up because it will delete those keys. If you check the box you can still use clean up without losing keys at the start of the animation that are identical to the setup pose.

Layered is described in the docs under Clean Up:
https://esotericsoftware.com/spine-keys#Clean-Up

Here is the tooltip for layered:

When checked, clean up will preserve more keys by assuming this animation will be applied on top of other animations

abuki Yeah, I found it, just wanted to read some more detailed info how exactly the Layeredworks.

Note that you can also always hover over items longer or hit F1 to display the tooltip.

abuki Here is code for an isolated problem, see the last lines with TODO and comments. I would like to hear your thoughts on this?

Thanks for digging deeper! Your reproduction code can be simplified by removing anything on track 1:

using Spine;
using Spine.Unity;
using UnityEngine;

public class AnimationTest : MonoBehaviour
{
    [SerializeField] private SkeletonAnimation skeletonAnimation;
    [SerializeField] private AnimationReferenceAsset animWithKey; // animation with keyed bone
    [SerializeField] private AnimationReferenceAsset animWithoutKey; // animation without keyed bone

    private void Start () {
        skeletonAnimation.AnimationState.SetAnimation(0, animWithKey, true);
        skeletonAnimation.AnimationState.Start += AnimationStateOnStart;
    }

    private void Update () {
        // remark: hit U, wait a bit and then hit T and observe the leftover applied keys of anim0WithKey
        if (Input.GetKeyDown(KeyCode.U)) {
            skeletonAnimation.AnimationState.SetAnimation(0, animWithKey, true);
        }
        if (Input.GetKeyDown(KeyCode.T)) {
            var mainTrackEntry = skeletonAnimation.AnimationState.SetAnimation(0, animWithoutKey, true);
            mainTrackEntry.MixDuration = 0; // 0.001f fixes the issue
        }
    }

    private void AnimationStateOnStart (TrackEntry trackEntry) {
        if (trackEntry.Animation == animWithoutKey.Animation) {
            skeletonAnimation.Update(0); // TODO: This is causing the problem!
                                         // When Update(0) is called, the bone stays in idleAnimation position where it was interrupted
                                         // When Update(0) is not called, the bone mix to setup position as intended
                                         // This behavior changed after spine runtime update
                                         // Update(0) is here to prevent missing heads for one frame in some specific cases, but not sure if should be needed?
        }
    }
}

The problem seems to be due to skeletonAnimation.Update(0) being called from the callback which is called from within AnimationState.SetAnimation itself. While changing animation state from within callbacks must be done carefully (see this documentation section), we'll further investigate why exactly this is causing things to go wrong.

A quick fix BTW would be to set the mix duration to a tiny value other than 0 in the following line: mainTrackEntry.MixDuration = 0.001f;

@abuki Sorry for the long delay!

The problem is that you're first calling AnimationState.SetAnimation, then through the Start callback you're calling skeletonAnimation.Update(0) which calls AnimationState.Update(0) and after it has already been updated, you're calling mainTrackEntry.MixDuration = 0; which messes with the internal mixDuration state.

In general you shall always finish setting up the TrackEntry settings before calling AnimationState.Update. In most cases that's no problem, but in your case where the default mix is 0.2 and you're later setting mixDuration to 0.0, it unfortunately triggers a problem.

So to fix your issue, whenever calling SetAnimation, calling skeletonAnimation.Update(0); from the Start callback makes little sense, instead just call it like this:

 var mainTrackEntry = skeletonAnimation.AnimationState.SetAnimation(0, animWithoutKey, true);
mainTrackEntry.MixDuration = 0;
skeletonAnimation.Update(0);

Consider a different scenario, if the default mix was 0 and you did this:

var mainTrackEntry = skeletonAnimation.AnimationState.SetAnimation(0, animWithoutKey, true);
// SetAnimation above triggers your start callback which calls Update(0).
// If the default mix duration was 0, the mix has already completed!
mainTrackEntry.MixDuration = 0.2f; // Too late! This animation is already current.

You must ensure you do not call Update until after configuring your track entries. There is no reason to do it in a start callback. As Harald showed, call SetAnimation or AddAnimation, then configure the track entry, then call Update if needed.

@abuki We missed to reference the documentation earlier. This requirement is documented here as follows:

The mixDuration can be set manually rather than use the value from getMix. In that case, the mixDuration can be set for a new track entry only before update is first called.

The start event is fired "when this entry has been set as the current entry". That happens when you call SetAnimation or AddAnimation, before you get a chance to configure the entry. It also happens when you call Update and a queued animation (one added with AddAnimation) becomes current.

If the start event is not what you want, what is the event you want and when does it fire?

If we added an event when AnimationState Update or Apply updates or applies an entry for the first time, it'd be too late for you to call Update(0).

Your code that calls SetAnimation or AddAnimation knows when it is done configuring the TrackEntry. That is when you should call Update(0), if needed. I don't see any scenario where it makes sense to use a callback to do that. There are many use cases though, so if you can describe a use case where the callbacks aren't giving you what you need, we can try to address that.

Yes, I think your code looks good. When using SetAnimation you run your "started" logic after configuring the entry. When using AddAnimation, you run your logic in the start callback, which will be called by AnimationState Update when that entry becomes the current entry. In both cases you are only running your "started" logic on a fully configured entry, so you can call Update if needed.