Kazzy

We're encountering a bug in Unity where Animations containing a drawing swap in the animation sometimes chooses to not reset when blending into the next animation.

For example, let's lay out two animations:

1) an IDLE where the character has a smile on their face. There are keys at the beginning and end of the animation stating this smile should be on for the entire duration of the idle animation.

2) an ATTACK where the character has some teeth gritted mouth on their face, but the animation contains a key flagging the SMILE attachment ON, then a few frames in, a flag for the angry mouth to swap in, then a flag at the very end of the whole animation for the angry mouth to stay on this character.

In theory, there are keys establishing that these swaps should occur no matter what, and that even if a new animation starts up, we have "bookend-ed" any appropriate drawings we want the animation to start with.

The PROBLEM we are seeing, is sometimes, only sometimes, using the example above, the angry face will remain on the character when transitioning to the idle again - despite the fact we have a key establishing that at the beginning of the idle, we want that character smiling. It might reset to the appropriate drawing if it transitions to another animation.

So we've had this issue many times in the past, (not just with drawing swaps, actually) and we've concluded that bookends for any bone and anything being keyed in an animation really is the only way to avoid a break in blending of animations. We still encounter this issue from time to time and it's sorta boggling our minds - I can't decide if it's an issue with the blend system or how we're keying animations or what. Generally, our solution has been a seemingly neanderthal approach by just adding a bunch of keys for the attachments to reinforce "YES, we want this drawing to be the visible drawing at this point in the animation!". I'm hoping someone has a better approach or idea as to how to solve this problem.

Thanks!!
Kazzy
  • Postovi: 10

Majicpanda

I'm surprised bookends are helping your issue because it was my understanding that sometimes during a mix or transition, key frames at the end could get skipped.

I am seeing this behavior with bounding box colliders and have gotten around the issue by basically creating 2 "warm up" frames with the collider ON and then when i want it back off 2 trailing OFF frames.. so basically 3 on 3 off because I too believe something is being skipped somehow even in the middle of an animation, not at the beginning or end.

Curious, are you using mecanim or SkeletonAnimator?
Majicpanda
  • Postovi: 197

Kazzy

SkeletonAnimator is what we're using.

So maybe the issue is:
-bookends = good for bones
-bookends = bad for drawing swaps

Bookends have been a necessity for us on the bones since without them, if we transitioned from an attack to an idle and let's say the arm didn't have a key at the beginning of the idle, the arm would be all crazy off to the side or up in the air when going to the idle and wouldn't reset until transitioning to another animation where there was a key at the beginning of that animation for that specific arm. It's now habit for us to select the whole character and set keys when starting a new animation. And then when complete, select everything again, and key everything at the end of the animation.

We haven't had too many run-ins with drawings swaps since they're a little bit of a pain to key and set up in rigging, but we're wanting to be a bit fancier with more characters coming online and it's becoming more and more of a problem. Especially with animations that start out on a whole new drawing vs. the previous animation it transitioned from.

The solution you've come up with for your bounding box problem is pretty much the exact solution we've been applying on our animations. ie: just lump in a bunch of keys essentially demanding that's what you want (so stop skipping over it Unity! >O )
Kazzy
  • Postovi: 10

Majicpanda

Oops SkeletonAnimator IS mecanim.. SkeletonAnimation is runtime, right? So you're using mecanim or runtime?

I'm just curious because this seems to be more prevalent in mecanim and Mitch hates mecanim ;P Like you I also have bookended all our bones for every animation because we don't do any layer animations like legs only etc. I do feel like something is causing keyframing of things to be skipped.. good to know it's not just bounding boxes. Maybe they can take a look at it.
Majicpanda
  • Postovi: 197

Kazzy

Ahmmm, well I know for sure we aren't creating mecanims. We Instantiate SkeletonAnimation when setting up our prefabs from the SkeletonData
Kazzy
  • Postovi: 10

Majicpanda

Ok so the problem also exists outside of mecanim, this is good news... I hope Mitch can take a look and maybe get some test cases :)

I haven't been able to diagnose if it simply misses the frames completely or what's going on, but it's NOT at all related to transitions. I am using a frame at least 20% into the start of an animation to turn on a bounding box collider and then way before the end of the anim to turn it off, and I think you are also experiencing issues in the middle of animations and not only at the very end?
Majicpanda
  • Postovi: 197

Kazzy

Majicpanda je napisao/la:I haven't been able to diagnose if it simply misses the frames completely or what's going on, but it's NOT at all related to transitions. I am using a frame at least 20% into the start of an animation to turn on a bounding box collider and then way before the end of the anim to turn it off, and I think you are also experiencing issues in the middle of animations and not only at the very end?
Actually, yes, now that I think of it, I have seen this happen in the middle of one animation before, but again, it's so weirdly inconsistent between characters and drawing swaps. Usually, the issue we've found is with moving from one animation to another. Going from Attack to Idle and the idle now has an angry face, when it should have swapped to a smiley face. everything has been keyed as it should be, and it functioned perfectly in spine. When in Unity, though, it's sort of a crap shoot.
Kazzy
  • Postovi: 10

BinaryCats

Is there a solution to this yet?

I suspect stuff happens because attachments key frames are handled much like events, and because of this, like events, they don't fire when blending between animations
Avatar
BinaryCats
  • Postovi: 1299

Pharan

They do fire like events (ie, once when the key is crossed). But they're not ignored during mixing.

Will change in v3. I saw it in Nate's list of changes. We've had some sort of solution for this for a while but never applied it to the old runtime.

For now, comment out this line: https://github.com/EsotericSoftware/spine-runtimes/blob/master/spine-csharp/src/Animation.cs#L451
This will cause it to be applied every frame. It's a little inefficient. But the Unity runtime had a few optimizations that offsets it a bit.
Avatar
Pharan
  • Postovi: 5366

BinaryCats

I thought I saw the comment out solution somewhere before, couldn't find it using the forums damned search. Thanks.
Avatar
BinaryCats
  • Postovi: 1299


Natrag na Unity