Why does Unity rotate the entire character according to the root bone?

Look at the video here:

Why does Unity rotate my character when I press Play, when Blender does not?

How do I prevent Unity from screwing with my character's base rotation? I embedded it in an extra gameobject, but I really hope I don't need to create a script which reads the rotation of the character and offsets it each update...

I'm using Unity 2018.2.0b3 in this instance.

 

This is related to inherited velocity. Cant remember exactly what steps to set to fix as its been awhile since I had to. However - this is an issue with humanoid. If humanoid rig is not needed use generic where the issue seems to be less inherited.

 

Try baking root transform rotation in the animation settings, by clicking "bake into pose".

 

You are correct, the issue does not appear with the rig set to generic. So I'm guessing everyone using Unity has to work around this bug, that's been there for a long while?

Bake into pose did nothing, but when I switched the line below, which reads "Based upon (at start)" to Original instead of Body Orientation, that helped... in that the orientation doesn't change anymore, but the entire character jumps ever so slightly in the Z direction...



Thank you for the tips both of you, it's better than before, at least!

(EDIT: I just added the "intro" animation to see if animation transitions jump as well, but fortunately, that doesn't seem to be the case, so I'll just fade in the scene so players never see that initial little jump.)

 

Did you bake everything or just the rotation? I think you also baked xz translation, that's why it's doing that.
Anyway if it does like this probably root or hips translation isn't perfectly zeroed and has some movement(other than rotation).

 

Again, baking makes no difference for me, regardless any other setting.

But now I added a transition animation to get into the idle animation, and now suddenly I need to switch that "Based upon (at start)" setting back to "Body Position" for the rotation... which kinda (but not really) makes sense, I guess, because it reads the transformation already there... but not really since the transformation is exactly the same in both clips.

What's driving me up the wall now, though, is that now there's a jump on the Y direction for some ungodly reason, and no amount of flipping these settings changes anything:



Again, the start/end pose between the clips are 100% match. There's zero reason for that jump in Y position!

EDIT: Solved it by basing both the starting animation and the idle animation's Y position on "feet". Wow, importing animations is a lot more difficult than I thought, and it doesn't help that Unity's animation setup screen resets the view to the last imported animation every time you press play, so you get confused about which animation you're actually changing settings for!

 

Pray you won't ever have to retarget several characters then.
To adjust the muscle settings you have to edit the avatar with no way to preview the animation, so it's an:
edit avatar->change settings->apply->start playback( i think muscles aren't evaluated on preview) -> redo everything until you find the correct settings.

 

Oh, great. Puppetmaster correctly reads the character orientation that Unity messes up, so my root transform option workaround doesn't work with the LookAtIK from Puppetmaster, since that actually transforms according to what I see in Blender (ie it recreates the misaligned effect from the original video at the top of this thread, even after the workaround fixed it).

How is Unity this convoluted with animations for this long? I mean, I can't be the only one rotating the (root) hip bone around, but not wanting that to affect the character's forward axis, or am I? I bet someone wants to have the head direction be the forward axis?

 

Yeah, it's a bit strange. I think it should all be original baked as standard personally, so you start with exactly what you exported from the other packages and make changes after that. The other options all serve a purpose and it's great to have them but it's definitely confusing.
Also baked seems like odd terminology just to get back to your original animation, but maybe all of this makes more sense if you are using root motion...

 

Ooh, now I clicked on what 00christian00 said. So I see how the baking options are useful now (but you are right, they should really just be named "static transforms" or something recognizeable as to what they actually do).

Unfortunately, as I mentioned before, my problem with FinalIK persists regardless of baking options, and even though I managed to visually get rid of the misalignment that happened in the first video I posted, I'm still plagued with a small jump in the transform that I can't seem to get rid of regardless of seemingly any combination options.

 

Is that the vertical jump? That does seem odd.Did that jump only appear after you changed these settings?
Have you tried baking the y transform? (As original).

 

If I bake everything, then yes, that goes away, but then I also lose the ability to move the character via animations, which I thought was rather neat.

 

Some scenario are really hard to handle. I have a wall jumping animation which is driving me crazy because the hips do a 180 degree turn but I can't use the raw animation cause the distance has to be adjusted to a programmed destination and it's a real mess to handle.

In your case you either bake the Y translation(which may create other issues) or via script you detect when you are into that specific animation state and using the "onAnimatorMove" you reset the Y value of the root deltaposition before applying it.

 

Another thing that is not explained everywhere, is if you try to mix baked animation with non baked one when transitioning from these Unity will fade the values.
When you bake the hips translation and rotation is kept in the bone itself, when you don't bake these moves are instead applied to the transform that has the animator component.
If I remember correctly(not 100% sure, been a long time since I dealt with it) when transitioning from a baked animation and a non baked one, it expect the hips to be zeroed thus it fade from the current value to zero during the transition length. this may be why you see that jump.

 

Jesus H Christ. Thank you for that. I'm not looking forward to try to unravel this, especially since, like I mentioned, I use two assets on top of these animations which do IK and ragdolls... layers upon layers of frustration.

I understand now why some games just use active ragdolls with applied forces for all animation. Unfortunately, I don't think there's an asset for that (yet... but I'm looking into a few tutorials).