Blending animation to "still" pose

I’ve been searching other threads, but can’t find the answer.

I have a character being controlled by user input, but in my case there is the chance the controlling can be temporarily “lost” momentarily. So I have a few pre-canned animations/resting pose-loops in the character’s FBX that I want to quickly blend to at the moment I lose connection.

Is it because I am manually rotating the bones and then want to play an animation? I’m not sure if that is my problem but I can’t seem to get .Blend or .Crossfade to work.

I can get something to work when I set the animation’s layer property = 1 and the blendMode to Blend - but then the character starts folding in on itself like a monkey grinder. And the pose I am at when i start the blend is very close to the start of the animation so it’s not like it is needing to rotate through itself or anything…?

Am I missing something here? Any hints or tips in debugging this would be appreciated.

thanks! :slight_smile:

If the poses are similar you shouldn’t really get that kind of weirdness… Do you have any colliders or rigidbodies attached to parts of your character? Are you sure there isn’t something happening in your code while the blending is occurring (like maybe the bones are still being “manually” rotated)?

As a test you could try turning off all the scripts which are rotating the bones programmatically, and just adjust them slightly in the editor. Then run the game with just the portion of the script that blends to the idle animation and see if this behaviour still occurs.

A side note: I just learned myself that you can alter the pose of an animation in progress by setting the rotation/position of a bone in LateUpdate() as opposed to Update(). LateUpdate occurs after the animation is applied to the model.

ok thanks, Antitheory I will check that, and try LateUpdate as well and see if that helps and let you know.

hmm… I removed my controlling code, so the character is posed initially in Start() and then I tried on mouse click in Update() to use Blend or CrossFade or CrossFadeQueued and they just snap instantly to those animations regardless of the fadelength param.

Any ideas what I’m doing wrong?

thanks! :slight_smile:

So does the Animation.Blend only work from one animation to another?

Can if blend from a manually adjusted bone pose to blend into (i.e. blend to starting) a given animation? Like say I put the character in a T pose manually by manually rotating bones. Can’t I blend from that pose into say an “idle” animation with the character breathing and with its arms by its side? If so, what’s the trick?

thanks again for any help or ideas or links to other threads that may help. :slight_smile:

To answer your first question: Yes it seems that’s the way it works. If you read the documentation it sort of explains it.

To answer your second question: I don’t think that it’s possible, though I don’t really know that there’s a good reason why it’s not. It would be nice… and it might be possible (though difficult I assure you) to write a routine that achieves this. Maybe somebody else with a greater knowledge of the animation system will chime in… I can’t imagine you are the only one who has had this problem.

One way I could imagine achieving this would be to somehow create a new single-frame AnimationClip which represents the pose that you are currently in, and just loop that animation while you fade back to the idle pose. I don’t think you can just create the AnimationClip object on the fly… but you can edit a pre-existing dummy clip perhaps.

Yes I can’t imagine I am the only one needing to do this either. :slight_smile:

hmm so I recall reading the only way to do something like this is in the IDE to duplicate an existing animation to a new one in the scene. Then you can edit the keyframes for that duplicated one in Unity.

So are you suggesting I dupe the animation in the IDE and then programmatically set the bone’s keyframes to the last “still” pose I was at inside that (looping) animation and THEN blend to the new idle animation?

thanks for clarifying the approach because this method seems convoluted to me for wanting to transition into an animation…

Yes that’s exactly it. I’m not really recommending it exactly… just postulating that it might be possible that way. I haven’t delved into editing the animation curves through code, but I imagine it wouldn’t be too difficult. I might actually need to do that on the project I am currently working on.

I also cannot assure you that such editing of the animationClip would occur seamlessly (ie: without a brief pause while Unity updates the clip). I wouldn’t imagine it would be a problem though.

There could be another solution to your problem though… Why exactly do you need to rotate the bones programmatically? Is there any way you could make these as canned animations?

No, unfortunately I have to rotate them programmatically because I’m rotating them via an external Kinect controller - then when input is “lost” momentarily or for whatever reason, I need to blend animate from the last pose I was just in, into a precanned idle (or other) animation already in the FBX.

does that make sense?

Seems weird blending from a procedural pose to an animation isn’t more obvious or possible than this. I will try this workaround approach you mentioned and see if it works. i would prefer a more elegant solution if anyone has one. :slight_smile:

I find myself in a similar situation. i know this threads old but maybe a bump will attract the posters back to let me know if a suitable solution was found?

I have a procedurally animated rig and our plan is to then have animations blended on top (many of these are limb animations and will be animated just because they are so small, that its simpler to animate that generate. Other, more full body animations are just too complex to procedurally generate).

However on applying my animations I realized the slight snap as the animation began regardless of blending weights, so here I am.

Anyone form the original post or anyone else who sees this have any ideas?

note: using unity 3.5 still.