Although I've tried to gleefully update to today's 3.6-beta Unity runtimes, but I've received a critical error saying something about Skeletons.Extensions not having a method that supported three parameters (or something like that).

AnimationState is like perl, look away for half an hour and you've completely forgotten how it works!

First there is TrackEntry setTimelineData which populates the timelineData and timelineDipMix fields. The important part is here, where we apply a "mixing from" track entry. timelineData tells how to mix:

SUBSEQUENT1) A previously applied timeline has set this property.Result: Mix from the current pose to the timeline pose.

FIRST1) This is the first timeline to set this property.2) The very next track entry applied after this one does not have a timeline to set this property.Result: Mix from the setup pose to the timeline pose.

DIP1) This is the first timeline to set this property.2) The very next track entry to be applied does have a timeline to set this property.3) The very next track entry after that one does not have a timeline to set this property.Result: Mix from the setup pose to the timeline pose, but don't use the mix percentage which means the timeline pose won't mix out toward the setup pose. We don't mix it out to avoid the dipping problem, and that is OK because a subsequent timeline will set this property using a mix.

DIP_MIX1) This is the first timeline to set this property.2) The very next track entry to be applied does have a timeline to set this property.3) The very next track entry after that one does have a timeline to set this property.4) timelineDipMix stores the first subsequent track entry after that one that does not have a timeline to set this property.Result: This is the same as DIP except the mix percentage from the timelineDipMix track entry is used. This handles when more than 2 track entries in a row have a timeline which sets the same property. Eg, you have A -> B -> C -> D where A, B, and C have a timeline to set the same property, but D does not. When you apply A you don't use A's mix percentage to avoid dipping, however a later track entry (D, the first track without a timeline which sets the property) is actually mixing out A (which affects B and C). Without using D's mix percentage, A would be applied fully until mixed out, then there would be snapping.

You may notice we only apply the dip fix for adjacent track entries. Eg, if you have A -> B -> C where A and C set the same property but B does not, then you'll have dipping. In practice it doesn't matter that much because A was being mixed out before C started.

That's the basics of it at least. There's lots of other stuff, like when it's safe to stop applying a track entry. It's quite tricky! It was an absolute nightmare to do mixing in this way, but it is quite powerful -- we support both crossfading (transition between animations on the same track) and layering (multiple tracks) of any number of animations. In 3.6 you can use the Preview view to see how your animations are mixing right inside of Spine, and you can edit your animations will watching the preview! We hope this will enable people to better understand and do more with the mixing capabilities.

The only remaining caveat the when mixing animations which have rotation near 180 degrees difference, sometimes the "wrong" rotation direction is used, causing the bone to spin around an extra time. There is no actual wrong direction, but what happens is Spine chooses the shortest direction when the mix begins. Over the mix duration, the animations continue to be applied, so this shortest direction can become the longer direction. It would be very odd to change rotation directions, so Spine continues using the direction it initially picked. If the bones are rotating in opposite directions, this can even mean the mixing rotation distance is > 360 degrees.