• Unity

  • Unexpected behaviour for AddAnimation with delay < 0

    anglais

I noticed something today when trying to debug some of my animation code.

If I set a delay of -1 when calling AddAnimation, the queued animations all fire their start events simultaneously, and either all play simultaneously or only one plays (i couldn't tell which from my test setup). If i set the delays to 0 the animations queue correctly and play one after the other.

anim = GetComponent<SkeletonAnimation>();        

anim.AnimationState.SetAnimation(1, first, true);
anim.AnimationState.AddAnimation(1, second, false, 5); // delay of 5 before interrupting first animation
anim.AnimationState.AddAnimation(1, third, false, -1); 
anim.AnimationState.AddAnimation(1, fourth, false, -1);
anim.AnimationState.AddAnimation(1, fifth, false, -1);
anim.AnimationState.AddAnimation(1, first, true, -1);

This seems contrary to the behaviour described in the docs (quoted below). Is this a bug or did i misunderstand the description in the docs?

delay If > 0, sets delay. If <= 0, the delay set is the duration of the previous track entry minus any mix duration (from the AnimationStateData) plus the specified delay (ie the mix ends at (delay = 0) or before (delay < 0) the previous track entry duration). If the previous entry is looping, its next loop completion is used instead of its duration.

Related Discussions
...

Using 0 will give you a delay of previousAnimDuration - mixDuration. If the mix duration is 0 then it's just previousAnimDuration. This means this animation starts when the previous ends.

Using -1 will give you a delay of previousAnimDuration - mixDuration - 1. If the mix duration is 0 then it's just previousAnimDuration - 1. This means this animation starts one second before the previous ends.

What is the duration of your animations? If it's less than 1 second, then passing -1 for delay will mean this animation starts right away.

It's extremely common to want an animation to start using a delay previousAnimDuration - mixDuration, which is way most calls pass 0. Passing > 0 makes sense if you want to specify the delay yourself, without any magic. When passing < 0 the delay parameter has the special behavior described above, the idea being that you can use it to have your animation start sooner without having to write code to get the previous animation duration and mix duration.

Ah of course, sorry i mis-read the doc entry. I missed "...plus the specified delay"

Thanks for clearing that up.