AnimationState: multiple mixing without dipping

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.

Multiple mixing

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 a or 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.

The "dipping problem"

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.

The holy grail

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.

3.6 beta has clipping

April 8th, 2017

3.6.14-beta is now available and it has clipping! To use clipping, create a clipping attachment which has a polygon similar to a bounding box attachment and an "end slot". All attachments between the clipping attachment's slot and the end slot are clipped by the clipping polygon.

When it comes to computer graphics, there are a few clipping techniques with various pros and cons. For Spine we used a CPU clipping approach because it has the best compatibility with game toolkits. This ensures clipping works in every game toolkit exactly like it does in the Spine editor. Other approaches using shaders either aren't possible in many game toolkits, or can cause conflicts with other shaders an app may want to use.

Keep in mind that clipping comes with a CPU cost. Using complex, concave clipping polygons increases the work that needs to be done. Also, the more triangles you are clipping (ie, complex or many meshes), the more work that needs to be done. If you are exporting images or video from Spine or making a desktop game, clipping performance is unlikely to be important. However, if you are making a mobile app, you will want to keep an eye on CPU usage when using clipping.

There are two additional caveats: 1) Only one clipping polygon can be active at a time, and 2) the clipping polygon must not self intersect, else clipping behavior may look strange.

We continue to work on clipping and other version 3.6 features, but we are happy that you can now try it out for yourselves.

Discuss this post on the Spine forum.

Spine runtime for Unreal Engine 4 released

March 3rd, 2017


We are happy to announce the release of our brand new Spine Runtime for Unreal Engine 4!

The spine-ue4 runtime is based on spine-c and exposes the entire API through both Blueprint nodes as well as C++ components you can easily add to your game objects. Check out the extensive spine-ue4 documentation to get started and try out the sample project.


The spine-ue4 runtime is our newest member in the Spine Runtime family. While we did our best to make it as bug free as possible, there's always a chance you run into an issue with your specific project. Please report any bugs you find on our issue tracker.

Note that spine-ue4 requires Unreal Engine 4.15+!

New Spine Runtimes documentation

October 29th, 2016

We have a big update for our Spine Runtimes documentation! Similar to the Spine User Guide for the editor, we now have a full guide for the Spine Runtimes:

Spine Runtimes Guide

It will teach you how to load, render, and manipulate skeletons in your applications using the Spine Runtimes. Especially useful is the API Reference which we have lovingly crafted and painstakingly cross referenced so you can more easily explore and understand how the runtimes work. Enjoy!

Discuss this post on the Spine forum.