I broke the experimental code IK Mix over Multiple Animations in Quick Succession

Hi there !
We've been creating a LOT of animations in Spine Editor these last weeks and haven't been playing 'em runtime in Unity yet.
Can someone update me about the dipping/blending/whatever issue between animations, is it fixed now ??? ^^

mostly fixed with the above code from pharan, only side effects seems to be my other post

Note the experimental AnimationState.cs was updated to fix some glaring problems noted in bcat's thread.
If anyone is still experiencing weirdness since last time, please try the latest.

Here's the link again.
https://gist.github.com/pharan/cffdc3b2aee9288c9ca8b4ab94ee97d2

08 Mar 2017 3:46 pm

Updated the experimental AnimationState.cs again. This should have much better results.
Do give us feedback or report any weirdness.

What does the update fix? Is it worth potentially breaking everything?

09 Mar 2017, 14:32

yeah.... that update is by far the worst update in spine history :s. It totally breaks our character. idle>jump>fall>idle looks like it keeps the fall position of the legs but with the key frames of the idle being applied.

Ill try to get a gif for you

09 Mar 2017, 14:40

previous experimental (expected result):

HTTPS をサポートしていないため、画像は非表示になっています。 | まだ表示する

Newest:

HTTPS をサポートしていないため、画像は非表示になっています。 | まだ表示する

09 Mar 2017, 14:42

looks like the iks don't get turned on

It's a cool limp effect!

Phaaaaaaaran! :bang:

It fixed the other guy's basic use problem. So amazing.
Setup pose effecting skeleton when mixing interrupted

We have now fixed the "dipping" problem by making multiple mixing optional and disabled by default. You can now choose between multiple mixing with the dipping problem (always smooth transitions, especially useful for long mix times), or no multiple mixing and no dipping problem (only mixes 2 animations at once, interrupting a mix with a new animation can cause a jump).

The commit is here:
Fixed the dipping problem by making multiple mixing optional and disa…@13c34e8

The documentation comment here explains the ramifications of the new setting:
spine-runtimes/AnimationState.java at 13c34e8751aedd48d7914c0e0ff58a322424c18e

Currently this is only in spine-libgdx in the 3.6-beta branch, but we'll get it ported to all other runtimes soon. It will stay in the 3.6-beta branch until the 3.6 release when it gets merged into master, that way 3.5 users don't get an unwelcome surprise from the significant change in behavior. However, it should work just fine with 3.5, so you can likely grab AnimationState from 3.6 and replace the same in 3.5 if you want.

So the fix is to remove the feature? Lol

To be fair, even Unity doesn't do multi-mix-out. They store the previous pose.

But I actually have an idea for how to make multi-mix-out compatible with non-dipping so the proper proportions get applied.

Nate got excited and is giving this to everyone anyway. I think it's better than just having a dipping-multi-mix implementation by default.

My proposal could be a bit messy. Don't know how the extra work will impact performance in multi-mix case but at least it'll be an optional cost. More experimental AnimationStates! Hopefully, this'll be the good fix.

Pardon my ignorance but... what is 'multiple mixing' ? :p

The only thing I do is to mix from 'Animation A' to 'Animation B' in track 0... but I also have higher tracks playing simultaneously (eye blinking, tail swinging, breathing, etc).

Am I covered by this change or are my toons gonna try to return to setup pose like idiots? :notme:

BinaryCats wrote

So the fix is to remove the feature? Lol

No features were removed. Instead there are now two modes to choose from:

1) Multiple mixing disabled. This is the new default. With this you have no dipping problem, but a jump if you interrupt a mix. This is how AnimationState worked pre-3.5, except we've reduced the jump by a lot.

OR

2) Multiple mixing enabled. This gives you smooth mixing of any number of animations, but you have the dipping problem. This is useful when using long mix times. Our goal was to be able to interrupt any mix without causing a jump, so this mode provides that.

The previous, experimental dipping fix relied on timelinesLast, where we used the fact a timeline is the last one to be applied. When interrupting a mix, the new animation may change which timelines are applied last and that causes a jump. This is why there is no solution for dipping when supporting multiple mixing.

Pharan wrote

I actually have an idea for how to make multi-mix-out compatible with non-dipping so the proper proportions get applied.

If you can solve it without having 2 modes, we'll switch to that! The problem has been burning for so long, I'm just happy we now have something so people aren't stuck.

Abelius wrote

Pardon my ignorance but... what is 'multiple mixing' ?

See the method comment here:
spine-runtimes/AnimationState.java at 3.6-beta

When false, only two animations can be mixed at once. Interrupting a mix by setting a new animation will discard one of the two old animations, keeping the one closest to being fully mixed in. Discarding an animation in this way may cause keyed values to jump.

When true, any number of animations can be mixed at once without causing keyed values to jump. Mixing is done by mixing out one or more old animations while mixing in the newest one. When animations key the same value, this may cause "dipping", where the value moves toward the setup pose as the old animations mix out, then back to the keyed value as the new animation mixes in.

Nate wrote

BinaryCats wrote

So the fix is to remove the feature? Lol

No features were removed. Instead there are now two modes to choose from:

1) Multiple mixing disabled. This is the new default. With this you have no dipping problem, but a jump if you interrupt a mix. This is how AnimationState worked pre-3.5, except we've reduced the jump by a lot.

OR

2) Multiple mixing enabled. This gives you smooth mixing of any number of animations, but you have the dipping problem. This is useful when using long mix times. Our goal was to be able to interrupt any mix without causing a jump, so this mode provides that.

well I mean, if you want multiple mixing, the dipping bug will still be there. So if you don't want this bug to happen, you need to disable the multiple mixing :S

Yeah, that is the unfortunate part. I think it isn't possible to have both. To avoid dipping, you need to look at what timelines will be applied by subsequent animations. Since subsequent animations can be added at any time, mixing differently based on that can cause a jump when a subsequent animations is added.

I don't follow. An empty track is not a requirement for seeing dipping. All you need is 2 animations which key the same property with the same value. When you mix from one animation to the next, the value of the property dips toward the setup pose midway. No empty track is involved.

Not sure if related, but I'll post it here.
I think there is still some weirdness when mixing animations on a track that overwrites previous track.

On the left there is only one track, track0 is playing a2, then mixes to a3.
On the right there are two tracks, track0 is playing a1, track1 is playing a2, then mixes to a3.
track1.alpha = 1, so it is supposed to overwrite track0, right? Looks like it's "dipping" to the value on track0.

I'm using AnimationState.cs from here
https://gist.githubusercontent.com/pharan/cffdc3b2aee9288c9ca8b4ab94ee97d2/raw/ec10be8fe92900d1dcb6bc22cad0a1e6fa21c803/AnimationState.cs

I don't recommend using the experimental gist AnimationState anymore. The AnimationState from the 3.6-beta branch should work well.

You have 3 animations being mixed: track0 applies a1 and track1 applies a2 and a3. Because you have > 2 animations being mixed, it's the same problem as trying to fix dipping with multiple mixing, which unfortunately isn't possible to fix. The only real fix is to only mix 2 animations, never > 2.

You can try changing this line:
spine-runtimes/AnimationState.cs at 3.6-beta

float alpha = timelinesLastItems != null && setupPose && !timelinesLastItems[i] ? alphaBase : alphaMix;

I'll explain this code: timelinesLastItems is non-null when multipleMixing is false (the default). timelinesLastItems is true when the timeline is the last one to affect a property. So this code says, "Use alphaBase to apply the timeline full strength, because another timeline is going to applied afterward". This is safe to do when setupPose is true, which means this timeline is the first to be applied, so applying it full strength won't overwrite another timeline.

If you change that line to:

float alpha = timelinesLastItems != null && !timelinesLastItems[i] ? alphaBase : alphaMix;

This will fix your problem, but may negatively affect other situations. By removing the setupPose check, every timeline for a property will be applied full strength, except for the last one, which is mixed with the second to last one. So the side effect from removing the setupPose check is that when you are using multiple tracks, only the last 2 tracks which affect a property are mixed. This actually kind of makes sense when multipleMixing is false. Anyway, you may see a snap when adding a 3rd animation to the mix, because the 1st will suddenly no longer be affecting the final pose.