- Изменено
Animations do not work as inteded, not all bones are updated
... when changing animation state.
Observed behaviour The animation runs perfectly fine until it changes the state. For example when running and then changing back to idle, the legs stay in the last frame of the run animation instead of going back to the idle position. This happens during all animation state changes.
Expected behaviour The animations should be played completely as expected for all bones.
What I did: I am using the platform pro "pugin in" to control the animation. But after checking back with the autor of the plugin this seems not to be a platform pro issue. The animations are done in Spine -> exported and used as bone driven mechanim animation in Unity.
What I tried to fix it. - In the animatior component I changed the update and culling modes. - Unchecked/Checked the 3D Bridge checkbox that ensured that each animation is played for at least one frame - Tried all 3 modes for the layer mix modes. It is now on normal.
The video is quite small and the legs are a bit hard to see. But it should still be visible that the legs do not update properly. Thank you for your help.
UPDATE:
I reset the camera to get a better view and I figured out that even the idle animation at the beginning does not play properly. I guess its overwritten by the falling animation state that is used at the very beginning.
Изображение удалено из-за отсутствия поддержки HTTPS. | Показать
Oh, by the way. You can ignore the orange robot character, its the template character from platform pro I am using as a helper.
10 Dez 2015, 15:15
I spent another day finding a solution for my problem. I re rigged the character several times and one point I even had a working version. I tested this Spine export with the exact same unity scene and it worked, but it does not work with the other versions.
I really would like to understand this problem because it will haunt me in the further development. And the one version that is working is not properly set up, its just a test version and the rig does not work properly. So I have to redo it at least once but I have to understand what is going on to be able to do that. So if you have an idea, please help me out! This makes me crazy and costs a lot of development time right now.
Here is a new video that shows the working version (first version) and the not working version (second version).
Hmmm that's interesting. I suspect some parts of your animation does not have keys set. Do you have keys set at frame 0 for the legs in all your animations?
You could try using setBonesToSetupPose when switching animations to see if this fixes it for you. If this corrects the problem it's almost certainly caused by keys not being set for all your bones at frame 0.
You can read more about it here:
http://esotericsoftware.com/spine-using-runtimes#Skeleton
Thank you Shiu for anserwing. I will test this out. Sounds like a possible solution. I would be happy, if this is rhe problem, since it can be fixed rather easily. I will keep you updated.
16 Dez 2015, 09:47
Thank you very much. Its so simple now I have your answer. You have been very helpful. Thanks again.
While trying to find a solution I had recorded the character Setup in Spine. Maybe someone finds this useful:
This is where I'm very confused about what you are SUPPOSED to do. The devs have posted not to key frame every single bone at the beginning of every animation for performance issues, yet issues like these can arise if you do not correct? If you create an idle animation that doesn't manipulate the leg bones and then play a run animation then that's obviously a problem since nothing knows to pose them back?
@Magicpanda
You're right.
You're not supposed to key every single bone.
Crossfading only works when the from-animation and the to-animation have keys for the same properties. So you're supposed to key only the bones that are ever animated, or that need to mix.
If only the from-animation has the keys, it won't know what to transition to.
If only the to-animation has keys, it will snap immediately to that position.
That you're "supposed to" keep track of which bones are animating in one animation and all possible animations and only key those, is kind if insane.
I wish there was a way to tell the editor : "I want these two animations to be able to crossfade/mix" and it'll generate the setup-pose keys where they're missing so they can mix.
But you definitely shouldn't key everything. Keying everything will quickly make your project really confusing and difficult to work with AND cost a lot extra performance to process at runtime.
I've asked people to use the autoreset logic (calling SetToSetupPose at the start of every animation, via the event subscription to AnimationState.Start) and it's supposed to work with SkeletonAnimation's mixing just fine. It just eliminates the case where it doesn't know what to transition to but it still immediately snaps into the setup pose if nothing is keyed.
I don't really use mixing/crossfading myself and I don't use Mecanim (not familiar with the weird things it does by itself, and the weirder things it does with how SkeletonAnimator interfaces with it).
But I know Mecanim doesn't have callbacks... so you can't stick autoreset there?
I don't know how to proceed here. Sorry.
You can use mecanim 5 state machine OnStateEnter and OnStateExit which fire any time an animation is entered or exited. It's quite possible these could be used to fire a method on the skeleton.
It would have to be a StateBehaviour or something, right?
Yea you can add a script to any node now in Mecanim with Unity 5 or simply add it to the entire FSM and have every node's OnStateEnter fire SetupToPose().
OnStateEnter works for the every single node in the current layer, so if you had 20 animations on the same layer and made 1 script you could technically make all of them perform an OnStateEnter which should fire before the animation is processed. Would need some testing.. but I'm still close to abandoning Mecanim if we get the Hitman and the "FSM" logic whatever it is in there looks easy enough to adopt.
I'm really missing being able to have reliable events for doing stuff like creating an overlap sphere for hit detections etc.