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

Strange behavior after AddAnimation on Empty track under special conditions

abuki

Hi, thank you very much, I think I am starting to understand what is happening on our side.

Regarding the docs, I have two points:

https://esotericsoftware.com/spine-api-reference#AnimationState-addAnimation2 - wording of If the track is empty, it is equivalent to calling setAnimation. was misleading to me as I could easily think you mean trackentry which is playing empty animation. Now, I got that you really mean empty track itself (= cleared)
https://esotericsoftware.com/spine-api-reference#AnimationState-setEmptyAnimation might be nice to add link to https://esotericsoftware.com/spine-applying-animations/#Empty-animations as I wasn't aware again of this and your example there (set empty, add after) is probably what I will need to do in my case.

I will now deep dive into my code and report back when I solve all the issues.

Nate

Agreed, we'll make those changes to the API reference!

abuki

Doing a huge refactoring and have a question regarding setEmptyAnimation.
From docs: A mix duration of 0 still mixes out over one frame.
So what is the best way to mix directly the next frame without calling Update(0)?

Calling ClearTrack is not what I want, I want to directly mix to setup on a specific track right the next frame. What am I missing now? 🙂

Nate

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.

Harald

@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.

abuki

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!

abuki

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?
            }
        }

abuki

It works fine when default mix duration on asset is 0

Nate

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);

abuki

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).

Nate

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

abuki

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

Nate

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.

abuki

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!

abuki

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.

Page suivante »