Extensions:2.4/Py/Scripts/Animation/Walk-o-matic

Walk-o-matic

About

**Jamesk's Walk-o-matic**
*animates the IK solvers of an Armature to create walk cycles along a path.*
UI location	Opens with Text Editor
Version	0.49.9	Author(s)	Jamesk
Blender	2.42a & 2.45	License	N/A

**Executable information**
File name	Jamesk's Walk-o-matic version 0.49.9 .py


Links	http://www-users.cs.umn.edu/~mein/blender/plugins/python/animation/walkomatic/index.html http://blenderscripts.googlepages.com/walkomatic0.49.9.py

Start a fresh Blender. Make sure it’s Blender Publisher 2.25 and that your Python 2.0 environment is set up properly.
Switch to top-view and add a standard mesh/plane somewhere in the middle of the grid. This plane will serve as a proxy for your character, and its animation defines how you want the final walker to perform.
Tab out of edit mode.
Make sure you’re looking at frame 1, then, with the plane still selected and active, insert a keyframe for location/rotation.
Advance the frame counter until you’re looking at frame 100
Start grab mode and move the plane about 25 units to the north (that’s upwards on screen :)
Insert another loc/rot key.
Go back to frame 1, hit ALT+A and make sure the plane moves along happily
Now open a text window. Split the 3D-view if necessary – it’s important that you can see the animation as well as the text window in the same screen.
Load the “walkomatic0.47.9.py” file in the text window
Make sure that the plane is still selected and active
Now hit ALT+P over the window containing the script. DO NOT CHANGE ANY VALUES.
As the script runs, you will see the plane moving in a jerky fashion through the frames of your animation
When the plane stops moving, you’ll see seven empties added to your scene. These are the tracking and IK targets that you’re going to use for your armature
Hit ALT+A over the 3D window to see the empties “walking” along with your plane

Now, the rest is up to you. You will want to add an armature to your scene, and then set up the required constraints to some of the bones. Some suggestions on how to do that will follow later on in this collection of documents.

Anyway – that was the quick tour. To fully appreciate the implications of this script and its capabilities, I strongly advise you to read the rest of this documentation. There is quite a lot of things you’d want to know...

The complete Walk.O.matic documentation

Table of contents:

How the script works

The user parameters

Quirks and oddities

What’s going to be included in the next release?
How the script works

Rules

The basic idea behind the script is very simple indeed. Rather than thinking in terms of feet and leg movement, you just focus on where the character as an individual object is supposed to be moving, how fast, in what direction, what it will be facing, if it’s going uphill or downhill etcetera. Since the movement of the feet is more or less a simple function of the above, why not just make some automated procedure handle those issues?

Well, that’s what I was thinking too. So here we are. To make things easy to use, you will be able to use any Blender object to represent this “character as an individual object”. This is done by using a character proxy, which simply means “a Blender object”.

There are a few things you need to know in order to get what you want from the script. The following rules apply:

Walk.O.matic only works from within Blender Publisher 2.25
The proxy can be any object. You will use this as sort of a stand-in for your real character. It does not matter what you use – I tend to favour planes, but you can use anything you like. If it’s something that the renderer will eventually be able to “see”, don’t forget to hide the proxy in an inactive layer before rendering.
The script assumes that your proxy has an orientation that reflects how your character will be oriented later – that simply means that something will be considered to be up/down, something else will be left/right and so on. Here’s a list of those assumptions:
The positive Z-axis of the proxy is pointing upwards
The positive Y-axis of the proxy is pointing forwards
The positive X-axis represents “right” and the negative ditto is “left”
The direction of movement [from one frame to another] always defines the direction in which the feet are going to move – even if the Y-axis may point in another direction. This allows more specialised walking styles such as walking “sideways”
To visualise this, simply make sure to toggle the ‘Axis’ button [edit window] for the proxy to make Blender draw the local object axes
To animate the proxy, you can use any method available. That means standard keyframing, parenting to a path or any kind of hierarchical transformations setup. Obviously I haven’t tested every possible arrangement [there are literally zillions of ways to animate stuff], but everything I’ve tried this far has worked as expected
You should NOT try to modify the proxy animation using the TIME-channel of its IPO block. That seems to mess things up quite a bit.
The proxy must be in a visible 3D window while the script runs. This does not mean that you actually have to see the proxy itself all through the entire animation, but you can not run the script from a screen with no 3D window present.
Once you’ve got the foot targets animated to your satisfaction, you really don’t need the script anymore. The information created is stored in standard IPO-blocks linked to each of the target empties. This means that it is relatively easy to tweak certain portions of the result by ordinary IPO-editing. It also means that you can save your file and reopen it in another version of Blender if you prefer not to continue working in 2.25.

The Walk.O.matic procedure

While the script is running, the following things happen (simplified):

Based on the user parameters in the top-most section of the script [more about those in section B] and the actual proxy animation, the script will calculate where to place each foot along the path. (Please note that the word ‘path’ here does not imply the Blender object ‘path’). It will look ahead along the frames in the indicated interval and decide when and where a foot should move, how far, how much to lift it, when and where to put it down and for how long it should stay down. Those calculations constitute the core algorithm of Walk.O.matic.

Currently, the script will always start by moving the right foot. As a first step, it will move for half the specified time, and then set down on the ground. After that, the left foot will move, full time, and eventually lock to the ground. Then everything keeps on ticking, with full steps only, until the specified end-frame is reached.

Hence, the most important factors affecting the final result are the script parameters and the proxy animation. The speed at which the proxy moves is particularly important, since it will influence the length of each step. When specifying step length, you set a value indicating for how many frames a foot should be on the move. In other words, the step length is assigned using a frame count rather than a distance. With the same parameter values, the steps will be shorter if the proxy moves slower, and longer if the proxy moves faster. The rotation of the proxy will also affect the placement of the tracking empties, so that your character is able to turn in any direction while the feet keep following all the turns.

You could interpret the internal process of Walk.O.matic as the creation of offset 3D-paths, pretty much in the same way as you can make inset curves in a 2D illustration application. Add to this the “pacing” needed to obtain the move/stop action of ordinary feet walking. B. The user parameters

A tool like this would be pretty useless if you had no control over the details of the animation. As far as this walking business goes, you probably have some requirements concerning how fast the character should shift from left foot to right foot, how far to lift the feet and the distance between the feet and so on. Most of these things can be specified in the editable section of the script, and it’s something you will do before actually running it. Below is a summary of these user definable parameter values, a description of their effect, some min and max values etcetera.

The user section starts like this:

GENERAL SETTINGS:

FF = FIRST_FRAME = 1 # begin evaluating at this frame

LF = LAST_FRAME = 100 # stop evaluating after this frame

These values are hopefully self explanatory. What might not be as obvious, is the fact that the LAST_FRAME value is not an absolute one – the script may continue to evaluate foot targets for a number of frames beyond the set value. This is due to the fact that it doesn’t like leaving a target hanging in mid-air, but will keep going until both feet are safely put down on the ground next to each other.

HS = HEEL_SEPARATION = 3.0 # desired distance between heel targets (in Blender Units)

HEEL_SEPARATION controls how far apart to place the left foot targets and the right foot targets. If you set this parameter to 4.0, you will get the right heel exactly 2.0 units to the right of the centre of the proxy, and the left heel 2.0 units to the left of the proxy centre. All in all, that’s a 4.0 unit heel separation. You can set this value to just about anything. HS=0 would perhaps not be useful, but it would not break the script. A negative value works fine too, resulting in the left and right side being swapped. So, you can use that trick if you want the left foot to be the first one to move rather than the right which is the default behaviour. Naturally, the exact value chosen depends on your character’s size and anatomy.

MT = MOVE_TIME = 8.0 # number of frames/cycle a foot is moving

This specifies the exact amount of time, in frames, that each foot will be on the move per cycle. A foot always moves twice as fast as the proxy for a period of MT frames, then it will stay put on the ground for the same amount of time before starting to move again. MOVE_TIME can be any positive non-zero value. Giving it a negative value will most likely crash the script and Blender as well. Since this value is absolute, the length of each step (in distance, not time) will vary as a result of this value combined with the current speed of your proxy: that is - fast moving proxy = longer steps, slow proxy = shorter steps.

MSD = MOVE_STOP_DELAY = 0 # any value above zero will prolong the time a foot stays in the air.

Normally, one foot will not leave the ground until the other foot has landed. This means that there is always at least one foot locked to the ground at any given time. A situation like that works well if your character is walking, but not if it’s supposed to be running. The MOVE_STOP_DELAY will make a foot remain in the air for an extra period of time, in frames, after the other foot has started its move mode. The result looks more like running, since there will be a period of time in each cycle where both feet are in the air simultaneously. By setting MOVE_STOP_DELAY to any positive value, you get this “air time” result. You should not use values higher than maybe 50% of MOVE_TIME, since that will make things look really weird. Best results are achieved around 20% of a decent amount of MOVE_TIME, for instance MT=16, MSD=4. Using a negative MOVE_STOP_DELAY results in something strange enough to wipe the RiverDance crew off the stage… So mostly you’d want to avoid that.

HEEL_TO_FLAT_DISTANCE = 1 # desired distance between a heel target and foot look-at-target

Once the heel targets have been calculated, Walk.O.matic will add empties that can be used to set up a track-to constraint on a foot bone. Depending on the anatomy of your character’s feet, you will want to place those empties at a particular distance from the heel target. This parameter controls how far in front of the heel to place that track-to/look-at target, specified in Blender units.

FLAT_TO_TLAT_DISTANCE = 0.5 # desired distance between a foot look-at and toe look-at-target

The final step after calculating foot track-to/look-at targets is adding toe bone track-to targets. This parameter controls how far in front of the foot track-to target to place those toe look-at targets, specified in Blender units. The value chosen depends on your character’s foot anatomy.

AL = ALWAYS_LIFT = 0 # set to zero to prevent feet moving up/down when proxy has speed 0

This parameter controls whether the foot targets should continue to perform their up and down motion even if the proxy has stopped. The default value is 0 (zero) meaning that both feet will lock to the ground if the proxy is stationary for a sufficient period of time (that in turn depends on the set MOVE_TIME). Any value above zero means that the feet will keep going up and down even if the proxy doesn’t move. That results in some sort of “dry walk”. The value itself has no meaning, only zero or non-zero.

CTD = C_TARG_DISTANCE = 2.0 # how far above proxy to place center target

In addition to the six foot related targets, the script also adds a center target above the proxy. This can be used for various parenting needs. Usually you would also want to set a copy-rotation constraint on it, copying the proxy rotation, although that’s not necessarily something you need every time. Anyway, the CTD parameter controls how far above the proxy, in Blender units, to place this empty. Any value is fine, though you will mostly use a positive one.

LA = LIFT_AXIS = 'local' # lift feet along global Z or local proxy Z?

When the foot targets are moving from one spot to the next, they will also be lifted according to the lift envelope settings (see below). This lifting can occur in two different ways depending on your needs. For normal walking or running in a standard environment, that is some place where the normal rules of gravity applies, you’re likely to want the LIFT_AXIS to be set to ‘global’. That causes lifting to go along the global Z-axis of the Blender world coordinate system. No matter how you tilt the proxy, the feet will always be lifted in the same global up-direction.

However, if you want a character to walk on walls or on the ceiling, like a fly or a spider or some weirdo from the Matrix, you should go for the ‘local’ option. This makes the local proxy Z-axis define what is ‘up’ at any time. If the proxy is upside-down, then the lifting will be flipped as well.

CTDLA = CTD_LIFT_AXIS = 'global' # raise center target along global Z or local proxy Z?

This works exactly as the LIFT_AXIS above, but will define the up-axis for the centre target alone.

LIFT ENVELOPE SETTINGS:

LP = LIFT_PEAK = 0.5 # how far to lift above proxy initially

The LIFT_PEAK defines how far above the ground to lift the heel target at the first control point of the lift envelope. The value is given in Blender units. The LIFT_PEAK occurs at the first point in the local timeframe of each move action in the cycle. The timing is controlled by the LIFT_PEAK_TIME (see below)

FLATLP = FLAT_LIFT_PEAK = 0.2 # how far to lift foot look-at-target above proxy initially

This works just as LIFT_PEAK, but defines the lift amount for the foot bone track-to target.

TLATLP = TLAT_LIFT_PEAK = 0.2 # how far to lift toe look-at-target above proxy initially

As above, but this controls the lift amount for the toe track-to target.

LPT = LIFT_PEAK_TIME = 0.2 # time to reach lift-peak. (relative to movetime)

This controls the point in time at which the lift peaks above should occur. To make things as flexible as possible, this value is given relative to the total MOVE_TIME. A value of 0.2 means that LIFT_PEAK will be reach after 20% of the move time has passed. For example, if the MOVE_TIME is 10 and the LIFT_PEAK_TIME is 0.2, then the associated target empties will reach their respective lift peak positions 2 frames (10 * 0.2) after the point in time where they left ground.

The rest of the parameters, listed below, do the same thing as the previously described lift envelope parameters. The only difference is that MID_PEAK and friends apply to the second control point of the envelope, and that the FINAL_PEAK parameters fix the third, and last, control point.

MP = MID_PEAK = 0.4 # how far from proxy after lift-peak

FLATMP = FLAT_MID_PEAK = 0.4 # how far to lift foot look-at-target

TLATMP = TLAT_MID_PEAK = 0.4 # how far to lift toe look-at-target

MPT = MID_PEAK_TIME = 0.5 # time to reach mid-peak (relative to movetime)

FP = FINAL_PEAK = 0.5 # how far from proxy before setting down again

FLATFP = FLAT_FINAL_PEAK = 0.7 # how far to lift foot look-at-target

TLATFP = TLAT_FINAL_PEAK = 0.9 # how far to lift toe look-at-target

FPT = FINAL_PEAK_TIME = 0.8 # time to reach final_peak (relative to movetime) C. Quirks and oddities

The most important thing to mention here is the fact that there is no rotational information in the IPO’s for the target empties added by the script. In other words, the heel targets, foot and toe track-to targets do not adjust their rotation at all. In most cases, this will not be a problem since they will be used only for tracking and IK-solutions – and location is the only thing that really matters in such cases.

One solution, if you really need correct rotation, could be to set a copy-rotation constraint on the empties, using the proxy as input. By doing so you might however get some unwanted movement when the feet should be locked to the ground. This is due to the fact that even though the foot targets are stationary while in lock mode, the proxy will not be, and may therefore apply its changes in rotation on the empties, resulting in a slight sliding of the feet.

Anyway, this is something that’s going to be changed in the next release of Walk.O.matic. You should however keep in mind that when used as intended, you will not need correct rotation of the target empties, so don’t let this bother you.

I’m sure there are other strange ‘features’ lurking in the script, but we’ll have to wait for them to reveal themselves as time goes by. D. What’s going to be included in the next release?

Some ideas that have come to my mind while testing the script and writing the documentation:

Correct rotation of the target empties
Explicit hip control
Explicit bounce/jump control
External script to control the parameters over time. This would be a separate file that the user can give to the script in order to have things like move time, heel separation and move stop delay vary within the frame span. For instance: ‘at frame 25 change MT to 12; at frame 90 change heel separation to 3.5’ and so on
A GUI
Better coffee in that strange machine at work

That’s about it.

Hope you enjoy the script!

Greetings,

/Jamesk

Note

Example files & variations on site
Best run in precompiled .blend
May work better in earlier versions of Blender.

Support

Python & Plugins forum at Blender Artists.

Extensions:2.4/Py/Scripts/Animation/Walk-o-matic

Walk-o-matic

About

目次

Support

案内メニュー

個人用ツール

名前空間

変種

表示

その他

検索

案内