Esoteric Software

[ZachHoefler]

One of our artists came to me with this issue:

Most of our animation issues are caused by the fact that key frames are carrying over from different, separate animations.

example: for the Pug, by default it's pupils are visible. 99% of the time you want the pupil to be there. There's only a single face state where the pupils disappear. But because of that single state, it will override all the other animations. So i have to go back and update every other animation so that the pupils are keyed to be "on" when it should just do that by default.

The current solution for fixing this is to make sure that every animation has every single piece keyed correctly on its first frame. This is an unusual way to work as often times most of the rig doesn't need any keys, it can just stay at the default. Adding keys makes the file harder to work with and also increases the file size. It's very time consuming to go back and fix too.

It makes sense that anything not modified by an animation doesn't change or revert back to its original state; otherwise, you couldn't mix animations together. However, it leads to the workflow issue outlined above. We do play multiple animations at once, but they're always on different regions of the character (e.g. "body run" + "face happy")

Are there any Spine features that could help with this situation? Alternately, any ideas on the best way to approach fixing this problem? The only thing I can think of from an engineering perspective is to call a "reset [face/body]" animation between playing animations, but we would have to remember to do that everywhere we set a new animation, which is also extremely cumbersome and prone to human error.

Thank you very much!

[Pharan]

If you're using SkeletonAnimation, it uses Spine.AnimationState.
Spine.AnimationState has a Start event that fires every time a new animation is played so you don't have to keep track of that yourself. That's the ideal place to bind a method that calls mySkeletonAnimation.skeleton.SetToSetupPose().

That way, it'll always reset unkeyed channels (and not inherit the final pose from previous animations).
I've been calling this "auto-reset" in the forums in case you want to do a search. It's not something Spine assumes you want, but it does mimick how the animations switch in Spine editor, so I assume it's what many people expect.

Your code would look something like this:

void Start () {
var skeletonAnimation = GetComponent<SkeletonAnimation>();
var skeleton = skeletonAnimation.skeleton;
skeletonAnimation.state.Start += delegate { skeleton.SetToSetupPose(); };
}

I'm not 100% sure if this breaks mixing. I think it doesn't, except that parts that aren't keyed would reset their transform immediately instead of mixing. Do test it out and see.

One thing this doesn't do though is reset the pose in iterations of looping animations if for any timeline that you animated, you don't have a key at frame 0. So make sure you always have those for looping animations.

[ZachHoefler]

Thanks, I'll give it a shot! I completely missed the SetToSetupPose() function when digging through the documentation, that sounds perfect.

Edit: It works exactly how I hoped it would. Thanks again! This will be a huge time-saver for our artists

[Pharan]

Did it work with mixing? I'm curious to know.