Before I move on to making this look good, I wanted to make sure I can properly get root motion to work in Unity. My first few attempts reminded me of the problem I had with my custom weapon bone.
Even when I thought “screw this, I’ll make my own custom root motion functionality from code”, I realized why it wasn’t so straightforward.
I made my weapon bone move like an IK handle, because this makes it easier for me to animate it. The left/right hand IK bones then, have constraints that make them “stick” to the weapon bone. But unlike how an IK bone is normally handled, this weapon bone I made is also holding the weapon mesh, visually. So it also counts as a “deforming” bone. This kind of makes it a “floating” bone, independent of the rest of the rig.
To explain the problem, I need to explain what root motion is. Root motion eliminates that foot sliding phenomenon with 3d models who play a walk animation in-place, and is just moved in the game engine.
Foot sliding happens because most of the time, the game engine moves the character only by a constant speed, but due to how some walk/run animations work, in reality, the character speed shouldn’t really be constant.
If you study how your body moves while jogging or running, you may notice there’s tiny moments of acceleration and deceleration that happen on each step. This is especially evident for a character animation that has a weird gait, like if they’re limping on one leg (or have poop in their pants).
Root motion works by having an animation that isn’t walking in-place. The animation is made to move the whole rig forward (enough for at least one walk cycle, so it can be properly looped). This is where the animator uses their skill to ensure that the forward movement looks natural with each step, that the feet don’t slide as the body moves forward.
When that move animation is played in-game, the game engine “extracts” that forward movement from the animation, negates it from happening to the 3d model, and instead puts that motion into the game object in the game.
You only need to negate the motion from the root of the rig (usually the pelvis/hips). This is because all the bones are ultimately parented to the root bone anyway. So when you move the root bone, everything else follows.
But I made this weapon bone to be independent of the skeleton structure, so it has to be its own root motion, even though it’s a child object of the rig. There’s probably some crazy math that can pull it off, but all my attempts haven’t worked so far, so I’ll try that again some other time.
____________________
The trick I ended up doing to make it work is a little silly: it’s two 3d models playing the same animation simultaneously. One has root motion, but with the weapon bone turned off (although it’s still being animated). And I have another doing the exact same thing, but with root motion unchecked, and is parented under the first 3d model.
This is all just to have the weapon bone not be subject to root motion, but is still parented to the game object that
is being moved by root motion.
One of them is down on the ground there because I’ve had to rotate the 3d models a bit (when you start the game they finally adjust to the proper orientation). I suspect it’s because Blender makes use of the Z-axis as its up-to-down direction, while Unity uses Y-axis for that.
I also found that the root motion bone has the same problem. I think Unity expects it to be oriented such that the Y-axis of the bone is pointing upward. By default, Blender Rigify gives me a root bone with the Z-axis as the up. So when I use that as the Root Motion Node in Unity, it ends up flipping the whole 3d model:
It’s a little annoying because the Unity user manual neglects to mention these things.
I could edit the rig so it’s pointing at the right direction. But I usually just compensate for this by applying a rotation to the 3d model once it’s a game object in the scene.
Maybe next time I’ll try figuring out a better way to do all this.
Community
