In place animations vs moving animations?

jmg06
polycounter lvl 5
Offline / Send Message
jmg06 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/

Replies

  • penOr
    Offline / Send Message
    penOr polycounter lvl 5
    Generally you will animate the cycle working in world space and only at the very end (or you can during if you want to track arcs and stuff, but do so with either a layer or some type of WORLD or higher up global control) will you take the WORLD controller and translate it backwards opposite to the COGs forward - which keeps it in place. This way you never destroy or alter your animation, it's just for presentation.
  • HelixEffect
    Offline / Send Message
    HelixEffect polycounter lvl 4

    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.

  • Arturow
    Offline / Send Message
    Arturow interpolator
    This is a tutorial from a guy who work on Desntiny and he use both methods , it could help just like a side note :)

  • slipsius
    Oh man, I love Lico's work. Everyone should definitely follow him. Had him as an instructor at iAnimate, and went for lunch with him in the summer. Amazing guy. All those mouse videos he's been posting are what hes working on at his new studio, Polyarc. His workflow, the locators and what not. All that comes from Monolith studios. 

    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. 


  • Hito
    Offline / Send Message
    Hito interpolator
    Quoted out of context actually. Italicized for emphasis

    "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.
  • Hito
    Offline / Send Message
    Hito interpolator

    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.

    Actually that's precisely what the tutorial in OP's post warns against. When you set Biped to In-Place mode for export, it effectively eliminates all Z motion, and the cycle will appear to bounce up/down as the character slides around according to player input. I suggest adding a bone or dummie at 0,0,0 for Root node, child the Bip node to that, and use Bip node as the Pelvis instead of Root.
  • jmg06
    Offline / Send Message
    jmg06 polycounter lvl 5
    Thanks everybody for answering. I do have a follow up question about game animation. It seems that engines like Unreal and Unity are able to use the worldspace animation to drive the character. So instead of a script with a speed that moves the character it's the animation and the translation of the animation that moves the character around. I think it's called root motion or animation driven locomotion. Is this true or am i getting things mixed up?
  • AGoodFella
    Offline / Send Message
    AGoodFella keyframe
    Hito said:
    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.
    Would that be as simple as just taking the curve for the forward motion and flipping it so its travelling the other way?

    I use the treadmill method but its still common to see people say the forward motion is always constant in a walk/run.
  • Hito
    Offline / Send Message
    Hito interpolator
    jmg06 said:
    Thanks everybody for answering. I do have a follow up question about game animation. It seems that engines like Unreal and Unity are able to use the worldspace animation to drive the character. So instead of a script with a speed that moves the character it's the animation and the translation of the animation that moves the character around. I think it's called root motion or animation driven locomotion. Is this true or am i getting things mixed up?
    That's true. Though at the present I think the majority people prefer not using root motion. Last freelance I was asked to export cycles for UE4 both in-place and with root motion.
    Would that be as simple as just taking the curve for the forward motion and flipping it so its travelling the other way?

    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.

  • slipsius
    jmg06 said:
    Thanks everybody for answering. I do have a follow up question about game animation. It seems that engines like Unreal and Unity are able to use the worldspace animation to drive the character. So instead of a script with a speed that moves the character it's the animation and the translation of the animation that moves the character around. I think it's called root motion or animation driven locomotion. Is this true or am i getting things mixed up?
    That method is when you make the character move forward in space, rather than doing the treadmill. Most studios will have some sort of displacement node, or pill. Studios seem to call them different things. But, its essentially just another bone that is attached to the global root of the skeleton, rather than being part of the skeleton of the character. A lot of the time that displacement is constrained to the hips so that it always follows the character. The game engine will take the global location of that node and update the characters location based on it. So, say you are at 0,0,0. You play your walk (with forward motion) and the character ends at 0,2,0. If you dont have a displacement with the correct code using it, your character will snap back to 0,0,0. If you do use the displacement, your character will start at 0,2,0.  

    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.








  • Hito
    Offline / Send Message
    Hito interpolator
    slipsius said:
    That method is when you make the character move forward in space, rather than doing the treadmill. Most studios will have some sort of displacement node, or pill. Studios seem to call them different things. But, its essentially just another bone that is attached to the global root of the skeleton, rather than being part of the skeleton of the character. A lot of the time that displacement is constrained to the hips so that it always follows the character. The game engine will take the global location of that node and update the characters location based on it. So, say you are at 0,0,0. You play your walk (with forward motion) and the character ends at 0,2,0. If you dont have a displacement with the correct code using it, your character will snap back to 0,0,0. If you do use the displacement, your character will start at 0,2,0. 
    Is that how it really works? If I understand what you said correctly... the global root would have to remain at 0,0,0 for the entire time the character exists the game scene. Displacement node is moved around by the engine; then character skeleton, from the pelvis?, is updated to the Displacement node's position? My understanding is the Root node, parent of the entire skinned skeleton and whatever prop/custom nodes, is directly manipulated by the engine, any ease-in/out is coded into the controller. Cycles are sped-up/slowed down within reason, or blended to a faster/slower cycle, based on the local forward velocity of the Root node. Seems to me having a separate node under the Root and then updating the Root to it's child node would create circular constraint and end up with endless jittering. If the Displacement node is constrained to the hips, it would mean one or more of XYZ is cancelled out and you'd end up with unnatural sliding all over again. The Displacement node would have to be on the same level as the skeleton's Global Root, in global space, in which case, why not simply manipulate the skeleton Root directly? From what I understand "Use Root Motion" extracts the local forward displacement in the cycle and updates the character's global position after each cycle. to use  your example, starting at 0,0,0, the cycle displaces character in 2 units in local space, game engine updates character's global position to 0,2,0. As far as character is concerned, it's back at 0,0,0 local, and the cycle continues. It allows more natural forward/backward acceleration, but makes it difficult to blend in/out, or change global direction mid cycle, and more transition animations maybe required as a result.
  • slipsius
    From my understanding, and that of my programming colleagues, is that when a programmer says ok, move this character 2 units. They move the global root of the skeleton, while playing an animation. So, if you have a treadmill animation, it appears to be walking. 

    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!  


  • Hito
    Offline / Send Message
    Hito interpolator
    right, I think we're on the same page. The position updates would of course happen at whatever the time unit the game engine runs on, that's kind of a rats nest to me since there're different time units depending on what's being updated. I said end of the nav cycle since it was more convenient and understandable.

    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.
Sign In or Register to comment.