In place animations vs moving animations?
polycounter lvl 5
So lately i have been seeing more and more animations guides and tutorials creating walk cycles that move in 3d space instead of looping on 0,0,0 xyz. Does this have to do with root motion? Is this a recent thing or am i looking at more advanced stuff as an animator? Hopefully someone can shed some light on this. Thanks in advance.
This guide even states: "Never, EVER remove the forward, (Z-Axis), movement keys from your character’s root/pelvis bone..." http://www.gameanim.com/2013/09/11/seamless-mocap-cycles-tutorial/
This guide even states: "Never, EVER remove the forward, (Z-Axis), movement keys from your character’s root/pelvis bone..." http://www.gameanim.com/2013/09/11/seamless-mocap-cycles-tutorial/
Replies
I've always animated cycles in 3D space within 3Ds Max and when I'm happy with how the movement plays out there is a simple tool which then locks the character in place within 3D space. This has to be done before importing the character into engines such as Unreal, otherwise if you don't do this, the character will move away from their 'true' location when the anim is played. This can obviously cause major issues.
I also find its easier to animate in moving in 3D space as I can get a feel for the correct sizes of things like strides etc before then triggering the character to hold in place.
That gameanim link you posted is talking about mocap data though. And in the game industry, when you have displacement nodes, its easy to do. But even then, a lot of the time, people working on those types of cycles will mute the forward motion to make it loop nicely. That way when they unmute that motion, it still moves forward, and has that more realistic look to it.
That said, I think it comes down to personal preference. If you arent using mocap, you can definitely do it in place, if you find that easier.
"Never, EVER remove the forward, (Z-Axis), movement keys from your character’s root/pelvis bone to see your character cycling on the spot unless you want them to plane forward in an unnatural manner when you key them forward again. We don’t move linearly in real life, and instead push a little with each step in a rhythmic fashion. To see a stationary cycle, add a second layer and key the character backwards linearly, removing the layer again later if required for exporting into your game engine."
The part you quoted means the COG should have slight forward/backward motion inside of the Root node instead of only Up/Down motion. That you should never manually clear out, or minimize, the Z-Axis motion from the mocap data. This way the COG will appear to speed up/slow down a little bit with each push-off when combined with the forward motion from player controls. In other words, The pelvis should never stay fixed relative to the Root in any axis. It is still common to see Pelvis only moving in Y, or X+Y relative to the Root in game cycles. The last sentence describes what Lico is doing, in reverse, in the video linked by Arturo.
Since that tutorial was dealing with MoCap data, there is already Root motion in the loop. So you key backwards to cancel it out, in order to see in-place cycle. If you were doing this as hand-keyed cycle, you key the Root forwards linearly at a speed you get from the designer, and animate the cycle through space, taking care to make sure the Pelvis moves naturally in all XYZ. Then you key the Root in reverse in another layer for in-place. Tick that layer on/off to check the loop in-place, and for export.
3rd way is set up a treadmill, markers that slide backwards at the move speed you need to match, to give you reference to plant the feet through the cycle.
I use the treadmill method but its still common to see people say the forward motion is always constant in a walk/run.
I don't know. though I doubt simply reversing the mocap data will get you the best results.
I think part of all this comes from confusion between what is the COG and all the different names people use that may or may not refer to the same thing.
Rigs usually place COG at the Pelvis, with a Root node at 0,0,0 between the feet. Game engine only cares about Root node when it comes to navigation in game, and the Root's motion is almost always moving at a constant speed since players push the stick all the way forward, or if using WSAD all you have is 0 or 1. Even with a modifier key, you have a 2nd setting at some constant % of full speed. That's what people mean when they say "forward motion is constant". Because you simply can't expect a player to twiddle with the control stick when navigating through a game, just to emulate a physical body in motion. When you key the Root or key it in reverse, you are emulating the player behavior in game in order to compensate for it in your animation. Has nothing to do with emulating reality.
Back to the COG, for most rigs it is always at the Pelvis. This is convenient for building the rig and using the rig. But in reality, a body is not a single point mass but a series of connected masses. Each will move according to the force applied to it, and affect masses that are connected to it, and those in turn will affect masses connected to them. This means the real COG of a body changes depending on the pose. When standing straight, the COG is in the abdominal area above the Pelvis triangle, over the ball of the feet. If you raise one of your legs, you have to shift your body to compensate for two things, one you lost one support and your COG is no longer fully supported. Two your COG actually shifted slightly toward the raised leg side because the overall distribution of masses has changed. Ric Lico has it down to a script, though I think most animators simply estimate it based on intuition or experience.
So, the perk of that is that you can make a more natural looking walk cycle where you slow down and speed up. You can also speed up the animation in engine based on movement speed and not have a problem.
Actually, here's a few youtube videos by Gwen Frey you might find interesting. She goes into how she does her walks. How she deals with feet dropping down to the ground when they stop, so it doesnt look silly. They`re short videos, but super informative on the subject.
If the animation has forward movement built in, then if the programmer moves the root 2 units, and the animation has 2 units, then at the end of the cycle, the character would be 4 units away from the start, but only the character model will appear to be that far. In the code, on a low level of it all, the characters root is actually only at 2 units. Not 4. So lets just say their global position is 2, but visually they look like they`re at 4. This is where the displacement node comes in.
For reference, this is generally how the skeletons are set up.
So, the programmers can choose to use the displacement or not. If they aren't using it, they just move the global root. If they check the box to use the displacement, or put it in their code to use the displacement, then the engine somehow takes the global position of the displacement and updates the roots global position to be the same as the displacement.
What I`m fuzzy about is if that update happens at the end of the cycle, or if it happens every "tick" of the internal clock.
So I'm not entirely 100% sure on how it all works behind the scenes. But I do know that collision is usually connected to the displacement as well. So, when a character jumps straight up, that displacement also moves up, then back down. But during a treadmill walk cycle, that displacement doesn't move at all. The programmer just moves the global_root (which also moves the displacement with it, since its a child of the global root).
If I am at all wrong, or if someone knows a better way to explain it, by all means, please jump in!
As far as Root motion it's specifically displacement of the Root node or Displacement node, whatever is used by the engine to calculate the cycle's displacement. Not whether the character appears to move in-place or through space while animating, since it's entirely possible for Root node to have no displacement while the character appears to be moving through space. For game cycles, if I wanted to animate a cycle through space, I would key the Root node first, before anything else. The character is moving in-place relative to the Root node. If I had animated the character through space by moving the Pelvis or whatever Character Master controller, and not Root node, I would end up with exactly the situation you described where the character appears to move through space twice as far.