"Parenting" and "child of" differences


I have a problem that’s killing me.

I have an animated armature performing a walk cycle. I then have this parented to an empty (empty_location) which is keyframed to move in the x-axis so that the armature walks correctly with no feet sliding.

For arguments sake let’s say I would like to rotate this whole object so that it walks along in any direction, but without changing the keyframes. Simple, parent empty_location to another empty (empty_rotation). Rotate empty_rotation and the armature will now walk along in this new direction.

BUT… my problem… empty_rotation will remain in it’s original place. Once the armature has walked for a bit the empty_location and empty_rotation are no longer in the same place so I cannot rotate again (without rotating around the wrong centre point).

I’ve tried using the child of constraint as follows:

Empty_location is child of the rotation of empty_rotation.
Empty_rotation is child of the location of empty_location.

but in this case the armature rotates but does not change walking direction. Is there any way round this? I hope this all makes sense. It’s driving me nuts. I’ve tried constraints, paths, everything I can think of.

“Child of … [rotation]” doesn’t seem to properly change the child object’s local space. For example, take an empty object "child of"ed to the rotation of another empty rotated randomly. It will have matched the rotation of the other object. Now try to move it along its local x-axis. If you are seeing what I’m seeing, it ends up moved along the local x-axis it would have if the constraint was not affecting it!

With that behavior, this method would not work for what you want it to. But there are ways to do it! Here’s the method I used just this last week. It assumes the following:

  1. You can move the armature (excluding the feet’s IK targets) around by moving some “center of gravity” or “Allfather” bone around and leaving the armature OBJECT itself in the same place;
  2. Your armature has legs rigged with inverse kinematics (IK targets for the feet not children of the Allfather bone, so you can leave the feet in the same place on the ground even as you move the body around above,)
  3. You have a walk cycle that has the figure moving forward in space; that is, the center bone moves forward, and when you play the walk cycle, the feet do not seem to slip on the ground, but the figure moves continually forward (f-curve modifier: “cycles” helps here, provided you aren’t putting other actions in with the NLA editor; I haven’t gotten that far yet.) This may not be standard practice, I don’t know, but it’s what I did, and it has worked for me in this case.

Try the “follow path” constraint again, only put it on these bones of the armature: the parent bone of the main structure, and the two IK feet targets. Scale the “frames” and “evaluation times” under “path animation” for the path you are using for your object’s motion until an “offset” of 1.0 on the “follow path” constraint moves the constrained object or bone along the path by as close to 1 unit as you can get. (I would recommend trying this with another object first to properly scale the path; you may need to switch the path’s direction.) Then copy the keyframes you had on the “forward” axes for the parent bone and the feet targets to the “offset” on the “follow path” constraints for each of them, and clear the keyframes from the original forward axes. The path is now your new (bent) forward axis. When done, your character’s feet will not slip on the ground, (if they didn’t before,) even though it is not walking in a straight line.

You may be able to modify this technique to fit your armature. It MAY not be necessary that the forward motion for most of the object be done by moving a center-of-gravity bone, but I’m pretty sure that it is necessary to have IK feet targets continually moving along a forward axis (that you can replace with a path) in order for them not to slip on the ground. It may also not be necessary to have offset 1.0 units exactly equal original space 1.0 units, though the length of your character’s stride will change length accordingly.

This will not be so simple for every case (How do you start and stop? Is it easy to go up and down curved staircases? Can you move from one path to another?) I hope to find out the answers to these questions myself, and I hope that this works for you. If it doesn’t, I hope something does, but rest assured, it can be done!

Wow, thank you so much. I really appreciate you taking the time to write such a concise and in depth response. Your method does bypass the problem and also solves a little confusion I had about adding my armature to a path. having separate paths for the feet is a great idea. I think this would ultimately provide me with a solution. Thanks again.

I would love the “child_of” constraints to behave as expected, i.e. like parenting. This would save a lot of hassle. Keyframing the parent object’s rotation whilst changing it’s child’s global direction accordingly (without affecting it’s local direction I think) would be ideal. I wonder if this has been put forward as a bug or recommended change. Seems like a function we could do with.

Cheers Solvent, I will attempt to put this into practice.

there is a very decent video on making a walk cycle connected to a path tutorial here…