May 16th, 2017
AnimationState is a part of the Spine Runtimes which controls applying and queuing animations, crossfading between animations, and layering animations on top of each other. In the Spine Runtimes
3.6-beta branch, we have an AnimationState update for you which provides a better method for crossfading and layering animations. This ensures animation transitions are always smooth, without bones snapping into place.
In the Spine Runtimes, "mixing" is what we call crossfading animations. Multiple mixing is where you are mixing animations
a -> b, then you interrupt that mix by mixing to animation
c. This is common when playing animations based on user input or when using long a mix duration between animations.
In Spine v3.4 and earlier, only two animations could be mixed. We would keep either
b, whichever the interrupted mix was closer to, then discard the other animation, leaving
a -> c or
a -> b. This was suboptimal because snapping occurs when we stop applying an animation mid-mix.
In Spine v3.5 we improved AnimationState by supporting multiple mixing. This allows us to mix between 3 or more animations:
a -> b -> c. Animation
a is mixed with
b and the result is mixed with
c. Since we don't discard any animations, transitions are always smooth, without snapping.
Unfortunately multiple mixing in v3.5 brought a new problem: when mixing
a -> b, animation
a is mixed out to the setup pose while
b is mixed in. If both animations key the same bone property then at the start of the transition, as the application of animation
a drops from 100%, the bone starts to mix out toward the setup pose. Meanwhile the application of
b has just started rising from 0%, so doesn't have much impact. The end result is that the bone appears to dips toward the setup pose until
b reaches more than 50%.
This has been dubbed the "dipping problem" on the Spine forums. Applying animations in this way allows AnimationState to support mixing any number of animations, but the dipping is quite noticeable in many situations.
In v3.6 we wanted to support multiple mixing without the dipping problem. This turned out to be a quagmire. It is surprisingly complex to combine 3+ animations in a smooth and efficient manner while still supporting all the AnimationState features.
After quite some effort, we ended up making multiple mixing optional. When off (the default) you got v3.4 behavior, when on you got v3.5 behavior. This wasn't a real solution, just a stopgap while we worked on two color tinting and clipping.
It took a few more months until we finally had a breakthrough, but now we are happy to report the problem has been solved! With some clever calculations, AnimationState now does multiple mixing without dipping. This is currently in the
3.6-beta branch, but should be a drop-in replacement if you'd like to use it with v3.5.
Discuss this post on the Spine forum.