Walk cycle velocity speed change (without foot sliding)

First what I do know: for just a general, basic rig and walk cycle I know that many (most?) walk cycles have no forward motion in the actual action; the root bone is what is animated to apply forward motion, and the walk cycle action is just a stationary walking motion (walking in place). I also know that the velocity of the forward motion has to exactly match the appropriate speed of the walk cycle to avoid foot sliding. I have done this, and it works okay for a simple straight walk forward.

What I don’t know is how to make any other kind of forward motion besides just straight forward, constant forward motion work for any given walk cycle without foot sliding. I can’t figure out how to make a rig dynamically change the speed it’s walking (like humans do) without causing foot sliding.

I’ve read about games engines (Unity I think) that allow the dynamic adjusting of the walk cycle action to match the velocity of the forward motion, so there is never foot sliding. Is this possible in Blender?

I don’t expect a full 5000 word description of the method here, just some tips to get started, or just some tips on what topics to research to get started with this would be great. Any ideas? Thank you.

i think it should work if you convert your actions to NLA strips

Thank you for the reply Modron. Is it really possible to dynamically control an NLA strip’s speed? I know you can do across-the-board speed changes, like reducing the entire action’s speed, but I didn’t know there was a more flexible method.

Is that a professional work flow for this too? I know this must be a very common task, so I am interested in knowing what the best, time-tested way of doing it is, not just a method that might work. Thank you again Modron.

Hi,

how did you match the forward root bone speed with the food speed?
The exact way should be a linear interpolation for your ik control bone and root bone, they should have the same gradient (multiply with -1 because the ik move back and the root forward).

if you set it up corect you can just duplicate and scale your nla stripes. To match the root bone gradient correct you can duplicate the first root bone gradient (base nla stripe scale 1) and change only the frame number to the same like your nla stripes, like in the picture.


here is the blend file

Attachments

walkcylce.blend (701 KB)

Thank you so much for the very detailed reply Vanderhorst! I really appreciate the time you took, and the .blend file which helped me understand your method. That is certainly a method that works to alter the speed, but isn’t it kind of cumbersome and inflexible? It allows for non-constant motion without foot sliding, but only very predictably non-constant motion. You certainly couldn’t use this method to easily animate a character wondering around a room a variety of varying speeds (like if the character was looking for something) and be able to easily change it later like in a real production setting. I was assuming that the professionals did something like animating the root bone along a path with some sort of alteration of the speed of the walk cycle based on the current velocity of the root bone’s motion along the path, but I have no idea if that can be done (seems like a Python script could do it, but I have no idea how).

I certainly don’t mean to demean your reply Vanderhorst. You did answer the question I asked and I appreciate it, but I guess I wasn’t asking the right question. But again, thank you very much for your reply.

Is there any more flexible way of doing this?

Game engines have super cool ways of getting around this. I am actually animating dinosaurs these days and I’m having this exact same problem - luckily I only have two or three different run cycles, that’s as many different speeds and adjustments I need to make. You could use an auto-walk technique : link the root’s Z translation to a pre-animated walkcycle, through drivers. The problem is if you accelerate too much, the cycle becomes weird, unrealistic - only for slight speed changes does it work well. Foot sliding will still occur when the character turns though, this I have not been able to eliminate.

Another solution is animating the cycle relative to the root controller - so, actually moving the character forward, then using a cycle offset modifier on every curve to make it infinite. Then, no problem with foot sliding, you can turn the character around using an NLA strip with a slow translation on the hip and the feet. Speeding/slowing down is harder to do in this case though.

I wish some of the coolness of game engines actually landed in Blender someday. I wonder how they deal with such situations in big studios, Pixar et al.

Hadrien

Thank you so much for the reply Hadriscus! The technique you describe involving linking the root’s Z translation with drivers sounds promising. Do you have any tips for getting started with that? I have a basic grasp of drivers but I have no idea how to influence an existing animation with them. Again, I’m not asking for a full tutorial since that would be a huge waste of your time, I’m just looking for some jumping off point that I can tinker with myself.

I know that you can’t speed up/down a walk cycle too much because it will start to look wrong; you’ll need to switch to a run/sneak cycle sooner or later, but I’m just looking for some semblance of flexibility in animating the velocity of a character. Being locked to one exact velocity for every single walk cycle just seems terribly inefficient to me. Thank you again for you reply Hadriscus!

No problem I am glad to be of help to a fellow animator even though results are not guaranteed. As for the thing I suggested you try : instead of creating every animation curve with time as a factor, create them with a controller’s rotation value as a factor (so, drivers instead of fcurves) - so that rotating this controller 360° will play the walkcycle normally, 720° over the same span of time will play the walkcycle twice as fast, and so on. Like you said this can work only with slight speed shifts, and probably only with a relatively “neutral” walk.

This is a bit convoluted and could probably be automated, but I wouldn’t exactly know how, so there’s my advice : create your walkcycle first. From there open a fresh version of your character with no animation and update the rig to include a rotatable controller that will drive the entire walk. Then, create a driver for each value of each controller provided it is part of the walkcycle (better create one first and use copy/paste driver since every curve will be linked to the same controller, so you don’t need to specify it every time) and recreate the anim curve you made already. It’s a bit more work but there might be a way to automate it, let’s hope someone with a better knowledge of python and Blender api can chime in.

The other obvious solution I see is baking the (cycled and developed) walk to keyframes and adjusting it by hand for when you want it to accelerate (simply scale keyframes and tweak few things that might look weird as a result).

Thank you again for the quick reply Hadriscus! I’m afraid I don’t know how to drive an action with a rotation value except to use the “Action” bone constraint. Is that what you’re talking about? I’m currently experimenting with it.

From your first reply I thought maybe I could drive the “scale” of an NLA strip of a walk cycle with some expression-modified input from the location of the root, but some quick tests didn’t seem to be accepting the driving of the NLA strip’s scale. I’m not sure though; I’ll need to try that again too.

HI

i invested some more time in this interesting task and some problems came up.

The following parts seams not be able to animate.

  1. Bone Offset
  2. x or y position of a keyframe in the graph editor.
  3. gradient value of a generate modifier in the graph editor.
  4. aditional driver for a already animated bone location axes.

All these listed things makes it really difficult to automate a sectionally function and unfortunatly walking with different speed over time is exactly this kind of function :frowning: and if a curve is in the game its getting more worst.

Her is another kind of try.

1.Use a bone with a constant speed (with the same speed gradient like the ik foot controler) and drive the foward (y) location of the root bone.
2.use another bone(its calles speed in the blend example) as a multyplier for the root bone in the root bone driver panel. Use scripted expression (var*var_001).
3.use the speed controler bone also to scale the NLA stripe for the walkcycle.
4.use a limit location for the speed controler bone otherwise the NLA stripe stops updating if the multiplier is 0.

With this example its possible to animate the speed along a curve (clamp to) but its not possible to stop.
Just animate the speed controler and see what happen.
Speed up works fine but slow down…hm.

Attachments

walkcylce.blend (674 KB)

No I meant though drivers. I don’t really know how the action constraint works, maybe it’s worth investigating.

Oh jeeze. It’s going to take me a while to go through your suggestion, but thank you for the detailed instructions!

I do have a hopefully quick related question: when you’re not worried about any of this variation in velocity that I’m talking about and you’re just working with a constant forward velocity for the walk cycles that you’re working with, what is the best way of being able to move and control it and maintain it across different scenes and situations?

The best way of doing it that I can think of is to just make two location keyframes on the root bone that result in the proper speed and setting the Extrapolation mode to Linear in the Graph editor, then parenting the root bone to another bone and moving/rotating that to change the starting location/orientation. Is that it, or is there a better way? I know asking for “a better way” has wasted a lot of your time thus far, so if the answer is no, that’s fine! :slight_smile: Thank you very much again Vanderhorst!

The best way of doing it that I can think of is to just make two location keyframes on the root bone that result in the proper speed and setting the Extrapolation mode to Linear in the Graph editor, then parenting the root bone to another bone and moving/rotating that to change the starting location/orientation

This is not useful for two reasons.

  1. if you change the position of the parent, you add just aditional distance to your root bone and
  2. if the velocity from A to B is linear you get additional velocity to your root bone.

The only way how this works is, if you add the proper speed and distance of your root bone to your NLA stripe for one walkcyle and than set the parent bone in stepped mode,with this setup the root bone jumps all time back to his start position and the parent bone jumps forward with no velocity. Its true that you can change the offset of the root bone in this way but cant change the the parent bone velocity as long as you make a NLA stripe.

in my view is the only way to handle this kind of stuff with access to the x and y value of each key of the (y location) graph of the root bone or the python modifier to define the constant acceleration motion functions.
With this access you could connect the nla scale of your walkcyle with the velocity gradient of your root bone and you could make a sectionally function for the distance.

But dont forget we are talking about only one kind of walkcyle with one constant step distance.

i wish you good luck :wink:

That’s a good trick… however that kind of thing can mess up motion blur and whatever physics simulation you might have set up (because of the sudden jump in local space over a single frame). If you haven’t, then don’t worry about it, but that’s generally bad practice (depends on software…).

As for your question… if you need to make the character change direction as they walk the best solution is probably still to develop the cycle - by that I mean making the cycle “still” inside the root bone and then moving the root bone - to be clear. This way you can always rotate the root bone to change direction, and the pivot will always be under the character’s feet. A problem would arise - like vanderhorst said - if the character were away from their root bone - in this case rotating the root bone would not be reliable at all. Now it’s not perfect : rotating the root bone, even when right under the character’s feet, can cause feet to slide just a little, but this can be fixed as a very last thing with an additional nla strip (in blender this is quirky though, maya’s layers are better for that use case) or by baking to keyframes and changing them on an individual basis (also perfect for adapting the walk to an uneven terrain). Overall I think this is still the best method. That doesn’t invalidate the “autowalk” thing though, which might be a little hassle to set up but can be handy. You can try it with a simple rig, four bones, ten keyframes, to see if it fits.

All this text and after re-reading I feel this is chaotic and not helpful at all. I hope you make sense of it and find a good solution for your case. Please share it when you do !

Good luck

Hadrien

Man, I won’t say I’m not confused :slight_smile: but this does give me a lot of information to try to work with and research myself. I will definitely have more questions, but I can’t ask anymore without trying some stuff out.

Thank you very much for all your time and effort here Hadriscus and Vanderhorst!

Okay, another question already (sorry!)

I’ve totally abandoned my original question about dynamically varying the speed of a walk cycle to match the velocity of the root’s motion; if Blender can’t do it, fine, I’ll move on.

I’m also not going to worry about changing the direction of a walk cycle causing foot slipping either right now; maybe later. Right now I do want to just make sure I totally understand the proper way of handling just regular, straight forward, constant velocity walk cycles without foot slipping; because this discussion has made me realize that I don’t know a way that works in all situations.

Hadriscus you raised a very good point; Vandorhorsts explanation of the method whereby the root bone is moved in “stepped mode” (thank you for that BTW Vandorhorst; it’s still useful) is the method taught by the majority of tutorials I’ve seen, but I totally understand how that could definitely cause problems with motion blur and dynamics (like cloth on a character)! I never realized that because I guess I never actually ended up rendering out any of the animations I did that way with motion blur. But motion blur will be really important for what I’m trying to do.

Can we forget about variable speed and changing direction and just discuss the best way of repeating and re-using a walk cycle in different situations without foot slipping in a way that will not cause any problems with motion blur? Jeeze; I’m sorry to ask so much here, but frankly I’m shocked I haven’t heard more discussion of this sort of thing. It seems like a big freakin’ deal. :slight_smile:

Well, from some experimenting with the NLA editor it can be done by starting with an animation with the proper forward motion that does not cause foot slipping, separating the armature walk cycle from the root translation (if not done already) then putting the walk cycle armature animation in one NLA strip and the root bone’s translation in another NLA strip, and then setting the root’s NLA properties to “extrapolation: hold forward”, and “blending: add” and then duplicating the root’s NLA strip. It causes some unintended slight jumping of the location of the root that I don’t understand, but it sort of works. But again, the only way I can think of changing the starting direction* of the animation is to parent the root to a parent bone and rotate the parent bone, but Vanderhorst discussed the problems with doing that already. Am I on the right path at all here? Thanks to anyone with any ideas!

*(I’m not talking about changing directions mid-walk like as we discussed would cause foot slipping, I’m just talking about orienting the walk in the desired direction to walk straight depending on the scene.)

Oh this is actually real simple, you just need a parent controller above your “walk” controller in the hierarchy. Place/rotate the parent however you like and the “walk” controller will inherit its orientation. I usually have two or three “roots” on my characters.

For your last post : I think you don’t actually need to use the NLA for this, you can use a “cycle” modifier on the forward motion curve of the root.

Okay, thank you for the reply Hadriscus. I just wanted to make sure I wasn’t missing something with that.

Is there any way of applying (or even determining) a constant forward motion? Seems like a method like that could assist with the process, like changing direction, although I know there’s still the foot sliding issue.

The other day I worked on a shot with 6 dinos and the terrain was super uneven, so I used motion paths. The technique is the same as animating the root on its forward axis but you animate the constraint’s offset value instead (follow path constraint in Blender). At least the changing direction part is solved, granted you still have to counter-animate the feet. Try that !