• Unity

  • Setup pose effecting skeleton when mixing interrupted

Related Discussions
...

Hi,

edit: Initially I only wrote here about our issue with modified AnimationState.cs but since the mixing problems are different between regular and modified I decided to elaborate.

Using the official AnimationState.cs:

  1. Idle animation loops. (no input)
  2. Input happens, mix to walk (0.2s)

At this point I can see the setup pose being mixed with our walk.

Using the modified AnimationState.cs that was recommended here ( Blend Weirdness in Unity 3.5?).

We're seeing issues when mixing our player character skeleton:

  1. Idle animation loops. (no input)
  2. Input happens, mix to walk (0.2s)
  3. Within the mixing window input stops ( < 0.2s), we mix black to idle.

At this point, we see blending from the setup pose to idle instead of whatever pose the skeleton was in mid-mix.

For both situations, the questions are the same:

  1. Why is it using the setup pose? We never want to see the setup pose at all.
  2. How do we fix this? I'm considering the Unity runtime broken at this point. we can't use it.

Thanks.

Thanks for reporting!
Note this affects all runtimes, not just Unity. (as the code in question is in spine-csharp). So this information is especially helpful for everyone.

There's a condition (supposedly a feature) in AnimationState that uses the first animation if it wasn't given the chance to mix out fully. Seems like a bit of a hitch on that part of the code. We'll check it out immediately.

08 Mar 2017 5:13 am

I've confirmed this bug.
Can you try this latest version and see if it causes other undesired effects? https://gist.githubusercontent.com/pharan/cffdc3b2aee9288c9ca8b4ab94ee97d2/raw/65872ae7e970796bf2b9ddf26483d9baf914b5d7/AnimationState.cs

If you repeatedly prevent a mix from completing, it may look a little snappy when you disallow the mix to not proceed, but the unintended setup pose mix SHOULD be gone.

Hi,

If you repeatedly prevent a mix from completing, it may look a little snappy when you disallow the mix to not proceed, but the unintended setup pose mix SHOULD be gone.

This is exactly what I'm seeing. To be honest, it doesn't look acceptable. It's very obvious.

Is this an edit of the official AnimationState or the modified one?

These are revisions of the experimental AnimationState. That's why they're on gist.
There was a separate source of the unnecessary snapping. Try this one: https://gist.githubusercontent.com/pharan/cffdc3b2aee9288c9ca8b4ab94ee97d2/raw/63e997cf28f15f8c2fde68b9f14c0b643f266512/AnimationState.cs

I'm submitting these revisions for review to become part of a release version of AnimationState.
You and I understand that the (current official) version of AnimationState mixing is no good for too many cases.

Hi Pharan,

This seems to work! Thanks for your quick replies and your commitment to support.
Much appreciated.

Cheers
GP

25 days later
Pharan wrote

These are revisions of the experimental AnimationState. That's why they're on gist.
There was a separate source of the unnecessary snapping. Try this one: https://gist.githubusercontent.com/pharan/cffdc3b2aee9288c9ca8b4ab94ee97d2/raw/63e997cf28f15f8c2fde68b9f14c0b643f266512/AnimationState.cs

I'm submitting these revisions for review to become part of a release version of AnimationState.
You and I understand that the (current official) version of AnimationState mixing is no good for too many cases.

Hey Pharan,

I'm new to Spine, but I've been using it for the XNA framework - I've noticed the dipping issues, but just wanted to verify that this version of AnimationState.cs works perfectly so far (haven't noticed anything unusual). Thanks for this!

Thanks for letting us know!
A variation on it will be applied to 3.5 and 3.6. The 3.5 version will behave the current way by default, and the 3.6 beta branch version currently behaves the way that experimental one behaves. The changes haven't been fully applied yet though.