bunny

Hello,
We're experiencing animation transition problems in Unity. It seems like these animations have carried over the bones from the last animation that aren't animated in the new one. It's causing weird output; for example, our skeleton is staying rotated even though the setup pose has no rotation. Default Mix is set to 0, so it shouldn't be blending the animations at all.
Thanks

bunny
  • Mesajlar: 2

Pharan

I expect we'll be adding this as a built-in checkbox soon.

But here's the basic logic to make it reset when you start playing an animation, so the state of the skeleton doesn't persist from the end of the previous animation, just like in Spine editor.
void Start () {
var skeletonAnimation = GetComponent<SkeletonAnimation>();
var skeleton = skeletonAnimation.skeleton;
skeletonAnimation.state.Start += delegate { skeleton.SetToSetupPose(); };
}
You can add this to any MonoBehaviour on the same object as SkeletonAnimation, or apply the same logic to your animation controller anywhere else.

It's not "blending" animations. The Spine runtime doesn't assume you want to reset to the Setup Pose or when you want to if you do. So it just doesn't.

-- 02 Dec 2015 11:32 pm --

You can also download this C# script and attach it to the same GameObject as your SkeletonAnimation. It's basically the same logic as the above code.
Bu mesaja eklenen dosyaları görüntülemek için gerekli yetkilere sahip değilsiniz.
Kullanıcı avatarı
Pharan
  • Mesajlar: 5366

bunny

We're actually already using a script like that on our characters. We were having similar problems that went away after adding the script, but they showed up again recently even with the script attached.

Strangely, the problem seems to have fixed itself just now after we added new animations and re-exported the characters from Spine. Is it possible the problem might have been caused by the export settings somehow?
bunny
  • Mesajlar: 2

Pharan

Not sure. But note that autoresetting doesn't apply to looping animations.
Make sure for looping animations, for anything you keyed, always include add a key at time 0.
Kullanıcı avatarı
Pharan
  • Mesajlar: 5366

richmond

Hi I'm the main animator on this project. I'd like to go into more depth regarding the problem we are having and how it is affecting our work.

The main issue is that keys are carrying over from one animation to another once the animations go into Unity.

For instance, the characters in our game have two sets of faces, for front and side views.

01_front_and_side_view.jpg


By default, they are set to side view. So when I'm animating a regular animation, I don't have to set keys for the side view face to be present, it's just there already while the front view is turned off (don't need to key that either).

02_side_view.jpg


If I make a front view animation, then I have to set keys to turn off the side view face and turn on the front view.

03_front_view.jpg


We've found that once these animations go into the game, if the front view animation plays before a side view animation, then the keys will carry over from the front view to the sideview animation and the side view face will be turned off.



This is just one example. There are many other cases where keys carry over and states get blended and look off.

Our current solution to this problem is to always key everything on the 0 frame. This isn't an ideal solution for the following reasons:

-It increases the size of the file
-It is a time consuming process
-It is a very error prone process

Our characters have a lot of parts and many animations. When i say "key" i don't just mean the bones, it also includes things like opacity, whether a node is turned on or not, meshes, draw order etc, so this really adds up over the course of production.

Ideally we would love it if keys didn't carry over from animation to animation and each animation would just play as it looks in Spine. Is there a solution to this that we are missing? We tried the code suggested above (thank you for that!) but it didn't solve our problem. Is this something you are working to fix in the future?

This is a very obtuse problem, so please let me know if my explanation was confusing.

Also, regardless of this specific issue, I'd like to thank you guys for making such a great animation package. Spine is a joy to work with. I've recommended it to every other developer and artist I know that's interested in making object based animations. Thanks for your time and hard work!
Bu mesaja eklenen dosyaları görüntülemek için gerekli yetkilere sahip değilsiniz.
Kullanıcı avatarı
richmond
  • Mesajlar: 8

Pharan

First of all, we all agree that you SHOULDN'T KEY EVERYTHING (especially if you're not animating them).
On top of the reasons you mentioned, it's also costly performance-wise at runtime.

For loops, you only need to add a key at 0 for the things you animated in that particular animation. Not other animations.

The poses are not supposed to carry over once the auto-reset code is there. It's supposed to work reliably. I use it all the time. Other people have used it too.

It doesn't reset meshes and colors. The color reset can be added to the callback, but the mesh vertices is likely something you should key. Everything else should reset.

The reason why this needs to be handled on a case-to-case basis is because Spine can be used with any setup. The code above is supposed to handle most setups, even mildly complicated ones.

Beyond that, there must be something else you're doing that's causing it not to work.


My suspicion is that you're causing the SkeletonAnimations to regenerate a new AnimationState where the auto-reset callbacks aren't subscribed, so it's not working. If you're manually instantiating anything or calling Reset, look for that and remove the offending code.

If that's not it, it's still certainly something about your setup and we can continue to investigate if you have more info.
Kullanıcı avatarı
Pharan
  • Mesajlar: 5366

richmond

Pharan, thanks very much for your response. I've passed this information on to our programmers. Thanks for your help!
Kullanıcı avatarı
richmond
  • Mesajlar: 8


Dön Unity