• Unity

  • Mix creating unexpected behavior in new version

Related Discussions
...

So we've just upgraded to the newer 3.5x spine editor and equivalent runtime, but getting some strange mix issues with popping on a few animations that worked fine before.

Example video:

Spine 3.5.25 Pro, launcher 3.5.01
Unity 5.4.2f2

I believe we were using v2.3 of the Unity/c-sharp runtimes before. We tested in Unity AND in the Spine animation viewer and seeing the same issue using any amount of mixing between these two animations. It didn't occur in the previous editor/runtime versions and we haven't changed the animation. Our mix default is set to 0.2 seconds. Both animations have keyframes set for all the same bones.

Trying to figure out if whatever changed to the way mixing works in the new version is something we can workaround or if it's a bug, but I can't find any clear reason it should be doing this pop, especially since it worked as expected in the last version. Any ideas?

AnimationState got a major overhaul in 3.5. Animations are now mixed out to the setup pose. My guess is you are seeing the first animation mix out to the setup pose while the second animation mixes in. Can you post or email the skeleton JSON and images? contact@esotericsoftware.com That will make it easier to see what is happening and consider a fix.

Hi, just emailed the files. Thanks for taking a look!

Thanks. I verified it is the "dip" problem. There's more discussion about it here:
Blend Weirdness in Unity 3.5?

That thread is confusing. =] So how do you get a case where it just mixes from animation A to B? This was very simple in the previous versions and worked as expected since we are queuing the animations back to back.

It feels like because of changes in 3.5, even though it should simply transition from animation A to B, instead it's blending 3 sets of values including some value of the default pose. Is that correct? If so, that feels like incorrect behavior, especially since I can create the issue both after the first animation has finished playing and in the middle of the first animation ( I tested this using the latest skeleton viewer ). Why would it always be mixing in the default pose in some amount?

Mogbot - I agree. I want to see the scenario where this setup 'fixes' multiple animations. A to B is the common case and should be straightforward. It doesn't make sense for Bind Pose to be mixed in - except for 'unkeyed' values on Animation B that were keyed on Animation A. Any value with timelines in A and B should NOT be touched by Bind Pose.

I believe Nate when he says he found a problem doing additional mixing... we just need to see the example case.

P.S. Can you please PM me about what method you used to trigger the edge grab like that? I've been experimenting with a ton of different methods for weeks and not happy with any of my current solutions. It would be greatly appreciated to discuss.

Just to chime in here, I agree. I’m not saying it’s easy to fix, but it’s definitely unintuitive from a non-technical standpoint.

If sequential animations have keyframes on the same bones, I’d only expect the values in the animations to mix. I don’t see a case where I’d want the Setup Pose values to be mixed in.

Setting the mix to 0 isn’t an option for most animations, since usually there are bones that you want to hold and others that you want to mix to new values.

I understand it gets complex because there are potentially multiple animations and mixes, but I definitely felt it worked better before the changes in 3.5. It seems to me the added element of always returning to the setup pose means the dip effect is largely unavoidable, whereas before you had to create the situation yourself.

Nate is there a chance that you have made any progress on the modification to AnimationState that you posted in the other thread? Do you have a version we could test in Unity?

Alternatively, could we have the option to turn the default behaviour of mixing to the Setup Pose on/off?

Or is the best thing just to roll back to the old Runtime/version of Spine? It feels a shame to have to do that since we lose out on future improvements/features.

The old AnimationState sort of did what you want. However, there are a dozen other things where it fell on its face. The rotation mixing had bones jumping around, making it unreliable to ever interrupt an animation. We need a fix for the dip problem, but it has to work with the rest of what AnimationState does.

I know, I hate the dip problem at least as much as you guys. :S If you only knew the blood, sweat, and tears that went into AnimationState, to have such a big issue remaining kills me.

We are working on 3.5 issues and haven't been able to work on the dip problem further. You could go back to the old AnimationState, or make edits to disable setup pose mixing.

Yup, we're here to fix this issue. It doesn't make sense that its such a 'big' problem, which means it's more likely a small bug causing big implications.

Let's sort through it together 🙂

4 months later

So...

We’ve been using the older runtime and old animation state. We recently decided to try Pharan’s new version of the animation state to see if the issue is fixed. It does indeed fix the dipping problem for us, but it also appears to cause other issues. For example, our character’s run animation doesn’t properly mix back to the idle animation. It’s also inconsistent, sometimes it works, sometimes it doesn’t. We are using SetAnimation to trigger these animations, all on the same track. We remade the animations without keyframes to reset from other animations.

This issues seems similar to: http://esotericsoftware.com/forum/Blend-Weirdness-in-Unity-3-5-7263?start=25

You can see in the example video it works properly the first 2 times, but the 3rd time it doesn’t properly mix back to the idle pose, but you can still see the idle playing.

Is this the problem: When she moves from Run to Walk to Idle quickly, then the Idle animation interrupts the mix from Run > Walk?

Here's another example where we just use two animations, idle and walk. It doesn't get stuck all the time, but some of the time. Is this because it's queuing the walk, then idle, then walk again before it can finish mixing? Again, only using SetAnimation for these.

If it’s not possible to have no dipping and multiple mixing using the current AnimationState, are we ok to still use the latest runtime and Spine editor and just paste in the older version of AnimationState? Will that cause any other issues (except for the fact that we will need to keyframe everything on our animations)? Or are we best off sticking to the older runtime and editor?

FWIW, the old AnimationState will work just fine with the 3.5 runtime (with the caveats it has always had, eg keying most things on frame zero).

@mogbot, when did you last try the experimental AnimationState? It's had a few important changes the past couple of weeks.

That behavior is quite odd.
I've tested the current experimental AnimationState on a few skeletons already, playing random animations at random intervals, but haven't seen that sort of behavior yet.
I wonder what's causing it to break.

What do you think about the questions I asked in the previous post? In our case, I'm wondering if it's breaking because it's queuing the walk, then idle, then walk again before it can finish mixing, which would be mixing 3 animations at once. Again, we are only using SetAnimation for these.

We'd be very grateful if you could you specifically comment what changes you made in AnimationState? Or could you specifically explain what changed between the official version and your experimental version so that we can try to isolate the issue?

The latest version of experimental breaks with iks turning on and off, we use the second most recent version

There was a change I accidentally un-applied on that last one.
I'm not sure why it had no effect on most things but I focused on an IK rig and I did see some weirdness when you quickly switch between IK mix 0 and mix 1 animations. No good, bcats!

Re-applying that change seemed to fix IK problems.
Theoretically, this current one should do a bit of extra work but be correct.
But we've yet to have a serious sit-down on AnimationState with @Nate and @badlogic (as he had some proposals for changes of his own).

same link again: https://gist.githubusercontent.com/pharan/cffdc3b2aee9288c9ca8b4ab94ee97d2/raw/a9d167770cb3cb8cce5e07d54bb0895b40d060e0/AnimationState.cs

Ah! It looks like that version fixes all the mixing issues for us. YES YES YES!

ALL THE THANKYOUS! =]