• RuntimesUnity

  • Strange behavior after AddAnimation on Empty track under special conditions

@abuki Thanks for pointing out the exact misleading passages.

Regarding 1:
Yes, please note that track and track entry may sound similar, but are as different as road and car. An empty car on a road is not the same as an empty road.

This in general applies to all our documentation, we strive to choose the wording as technically precise and short as possible, we never use "approximations" just to sound better. In your case I assume that you missed the important documentation about what the empty animation is, so that might be the main cause (which we are trying to improve).

Regarding 2:
We're improving the spine-unity documentation currently in this regard (it's updated and improved, but not yet final):
https://esotericsoftware.com/spine-unity-main-components#Setting-Animations
https://esotericsoftware.com/spine-unity-main-components#Empty-Animation-and-Clearing
We hope that these changes prevent such misunderstanding and missing important documentation sections in the future.

Related Discussions
...

abuki To mix back to the setup pose, set an empty animation with no mix duration. The note about needing one more frame when mix duration is zero is trying to explain that it will take one more apply to do the mixing out, and then the update after that will be able to "end" the track entry (the end AnimationStateListener event).

You don't normally need to worry about this. You just set the empty animation and continue on as normal.

      Nate Looks like you are right, the specific problem was caused by animations on lower tracks starting one frame later than they should. Thanks for ensuring!

        4 days later

        Hi again, this is on very similar topic. My default mix duration is set to 0.1 on the asset:

        private void Start()
        {
            skeletonAnimation.AnimationState.ClearTrack(0);
        }

        private void Update()
        {
            if (Input.GetKeyDown(KeyCode.K))
            {
                Debug.Break();
                skeletonAnimation.AnimationState.SetEmptyAnimation(0, 0);
                skeletonAnimation.AnimationState.AddAnimation(0, animationReference, false, 0f);
                // The added animation starts at track time 0.14, how to force it to 0 or 0.04 or anything similar?
            }
        }

        It works fine when default mix duration on asset is 0

        The animation always starts at track time 0. Do you mean the first time the animation is applied the track time is already at 0.14 seconds, so you don't see the first 0.14 seconds of the animation? I'm not seeing that with:

        state.getData().setDefaultMix(1f);
state.setEmptyAnimation(0, 0);
state.addAnimation(0, "walk", true, 0);

          Nate Do you mean the first time the animation is applied the track time is already at 0.14 seconds, so you don't see the first 0.14 seconds of the animation?

          Yes.
          For some reason, it works fine for default mix = 1 or 0. Tried your code (in Unity) and was playing with the following:
          skeletonAnimation.AnimationState.Data.DefaultMix = 0.1f;
          If you set the default mix to anything between 0.01 and 0.99 this mix duration is added to the animation time at the start of the animation. The same happens if you set it to e.g. 1.2, but in that case only 0.2 is added.

          I am seeing this in a basic script I posted above, no special conditions project specific.
          I am also playing it with animation that is non-looping (seems it is not relevant) and is longer than 2s (not sure how long is your walk loop).

            You're right, there were a few bugs regarding that! We've fixed it in 4.3-beta. 🍻

              Nate Great! Any chance of backporting it to 4.2? Or is the beta stable enough to switch to it when in full production?

                The beta won't be considered stable until it's no longer beta. Can't say yet when that will be.

                We might backport this fix to 4.2, as it's pretty nasty. I'll check with the team.

                  Nate Hi, I already ported your libgdx changes to our C# Unity runtime 4.2 as a quick fix. I can see the above problem fixed. Thanks!

                    Well, to sum it up. I removed all calls to Update(0) and refactored these places to with better understanding what Spine is doing. So it is not a black box anymore for us. Thanks for helping me with that! Now a lot of things seem obvious, but e.g. playing empty animations for proper mixing is nothing easily understandable.
                    And still, I found a runtime bug 🙂

                    Next time I will directly try to isolate and understand what is going on instead of quickly hacking it with Update(0) call.