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.