Bone names and limits

General discussion about JPatch

Postby pndragon » Mon Oct 31, 2005 12:39 am

From Wikipedia:
DOF
degrees of freedom (DOF) describes flexibility of motion. A mechanism or linkage that has complete freedom of motion (even if only in a limited area, or envelope) has six degrees of freedom. Three modes are translation - the ability to move in each of three dimensions.

Three are rotation, or the ability to change angle around three perpendicular axes.

Inverse Kinematics
Inverse kinematics is the process of determining the parameters of a jointed flexible object in order to achieve a desired pose.

Forward Kinematics
The essential concept of forward kinematic animation is that the positions of particular parts of the model at a specified time are calculated from the position and orientation of the object, together with any information on the joints of an articulated model.


I hope that helps.

--- Jim
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby dcuny » Mon Oct 31, 2005 12:44 am

squirrelhavoc wrote:What is DOF?

DOF stands for "degrees of freedom", and refers to how much a particular joint is allowed to rotate around a particular axis.

A hinge joint (like the kind found in your knee or finger) can only rotate (bend) about one axis. You can bend your finger about 90 degrees in one direction, and (unless you're double jointed), no degrees in the other. So that joint would have a 90 degrees of freedom along the z axis, from 0 to 90, and no degrees of freedom on any other axis.

Other joints are more complex. You can bend your wrist about +45 and -45 degrees along the one axis, rotate (twist) it about +90 and -90 degrees along another, and perhaps shake it +10 to -10 degrees along the other axis.

By setting the DOF for various joints, you can help make sure that you character doesn't twist into impossible positions.

What is Inverse and Forward Kinematics?

These are two different ways of manipulating a character.

FK (forward kinematics) is the simpler of the two. You just select a joint, and rotate it about some axis. For example, imagine bending a character's elbow or finger. You select it, and then rotate it about it's single free axis.

IK (inverse kinematics) is a bit more complex. Think of bones as being connected in a chain:
Code: Select all
shoulder --> elbow --> wrist --> fingers
If you wanted to make a character reach for an object using FK, you'd have to rotate the shoulder, and then the elbow, and then the wrist, and then the fingers. That's pretty tedious.

With IK, you can grab the end of that chain (the fingers) and tell the computer where you want the fingers to end up. The computer then calculates how much the shoulder, elbow, wrist and fingers will have to rotate in order to reach that target.

There are times when you may want that chain to be reversed. For example, if you wanted to move a character's foot to some position, you'd expect the chain to be set up as:
Code: Select all
hip --> knee --> ankle --> toes
That way, you could just grab the character's foot and drag it to the position you wanted, and the rest of the character would follow.

On the other hand, imagine that you wanted to the character to squat down. In that case, you'd want to be able to grab the character by the waist and pull it down. The chain would have to be set up in the other direction:
Code: Select all
foot --> ankle --> knee --> waist
Actually, you'd want both legs to be set up like that, with the feet locked to the ground.

Since you might want an IK chain to go in one direction at one point, and the exact opposite direction the other, how is the computer supposed to know what to do?

One solution is to set up ("rig") the bones with multiple IK systems, and toggle between them depending on what you're trying to do.

A more recent solution is called "Pin and Drag", where you create and destroy IK chains dynamically as you're animating. This is the most flexible solution (one implemented by Art of Illusion, for example), but it's harder to implement than static IK.

Did that answer the question?

(Ooop! I see pndragon beat me to it! :))
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby pndragon » Mon Oct 31, 2005 1:11 am

David wrote:(Ooop! I see pndragon beat me to it! Smile)

I like your answers better:wink:

--- Jim
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby squirrelhavoc » Mon Oct 31, 2005 1:24 am

dcuny wrote:Did that answer the question?


That answered all of it, thanks.
Squirrel Havoc

We live as we think, very very slowly....
squirrelhavoc
 
Posts: 180
Joined: Tue Jun 28, 2005 11:17 pm
Location: Oklahoma, USA

Postby sascha » Mon Oct 31, 2005 10:01 am

So that joint would have a 90 degrees of freedom along the z axis, from 0 to 90, and no degrees of freedom on any other axis.

<pedantic mode on>
Actually, a degree-of-freedom (talking about rotation) is the ability to rotate around a given axis. The direction doesn't matter, and the limits are just an additional information for the animation-program (to disallow impossible poses).
The maximum number of degrees-of-freedoms is 6, three for translation (up/down, left/right, forward/back) and three for rotation (yaw, pitch, roll).
</pedantic mode off>
:wink:
I'm currently working on rotation DOFs for the joints. I'll later add an additional DOF that allows to shorten/lengthen a bone. It could be used for cartoon like effects.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby sascha » Mon Oct 31, 2005 9:15 pm

I've implemented "smartskin morphs" - nothing magical, it's nothing but a morph that gets applied as you move a DOF slider.

I just recalled how difficult this was to implement when I first experimented with bones and morphs (years ago). This time it worked just "out of the box". This gives me a little confidence in the design of JPatch. It distinguishes between a model's "reference pose" (no morphs applied, all bones at their initial position) and the "current pose" (morphs and bones applied). It can now quickly transform between the two poses by caching the transformation matrices for each individual controlpoint. This way you're not restricted to work in the reference pose - you can pose the model in any way you like and still use all features - moving/rotating/scaling selections, adding morphs, etc. Internally, everything you modify in the current pose is transformed back and actually applied to the reference pose. That's the reason why a standard morph can be used as a smartskin morph without any modifications.

I'm thinking about allowing multiple "targets" per morph. Right now a morph has a 0 % position (nothing changed) and a 100% position (the morph vectors added to the "reference" controlpoints. Adding multiple targets would allow to have more complex morphs, you could e.g. fine tune the morphs 50% position.

It would also ease working with smartskin morphs: Right now I've assigned to morphs to each DOF: One for its minimum and one for its maximum. The system I have in mind would only need a single morph with multiple targets per DOF.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Mon Oct 31, 2005 9:41 pm

I assume there'll be some way to toggle the DOF on and off.

For example, I'm having trouble imagining a situation where I'd want the the surge DOF to be anything other than manual. For example, if I wanted to use a stretchable tentacle with IK, I'd probably want to adjust the bone length manually. For example, I might want to "pre" stretch an arm (in anticipation of a long reach) before the actual reach for the target.

(Actually, I'd probably want to adjust a group of bones (i.e.: the arm bones, if the arm was stretching, or the tentacle bones).

You'd also want the option for overriding limits when you want to add things like bones "breaking" against their joints. Then again, IK isn't going to give you the nice overlapping effect that you're going for anyway. (This is the sort of thing that stored actions are good at).
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Tue Nov 01, 2005 9:00 am

I'm not sure what a "surge" DOF is. I assume it's about "stretching/crushing" a bone?

Two thoughts about IK (I might revoke once I've played with JPatch's system a bit):

I think IK could and should be used in two ways: 1) To quickly set up a (keyframe) pose - moving a hand into a certain position is easier with IK than it is with FK.
2) To keep certain bodyparts in position in the in-between frames. If you'd like a hand to not move and stay in position between two keyframes, you could "lock" its IK target - the relevant DOFs would then no longer be under control of the motion-curves, but of the IK solver.


The overlapping action effect could be done by adding more DOFs: Imaging a character who's about to quickly turn his head: In cartoon style, it might start turning the forehead, and the rest of the head follows some frames later.
I think this effect could be achieved by adding a "twist" DOF to the head-bone.


Some other thought about how "actions" could be implemented:
We've got a number of sliders (currently for morphs and DOFs). What would be nice is a group-slider, that actually groups different other sliders (it is a slider itself and could be used in another group-slider as well). The two types are combination (possibly weighted) and sequence.
The combination-sliders could be used to store simple things (like phonemes - combinations of morphs and a rotation of the yaw bone) and complex things such as entire poses.
A sequence-slider could be used e.g. to blend between different poses then, resulting in an action. If a sequnece's start- end end-pose are equal,it would be a cycle (and could be "played back" repeatedly).

Walking:
Imagine such a sequence-slider (it goes from 0.0 to 1.0 and cycles through some poses that make up a complete walk-cycle). When played back repeatedly, the character would seem to walk, but it wouldn't move.

Moving it by simply setting up a position-curve for this character is tricky and would most probably result in slipping feet. Here's an idea: Anchors: Normally, a model is anchored at it's origin in reference space. But to walk, you could set the anchor to the left toes at the beginning of the walk cylce and switch it to the right toes in the middle of the walk cycle. From the animator-application's point of view, there would be an abrupt change in position, so I'll need another mode for the curves: Besides linear and cubic I need a "stepping" mode.
An example: The character is at position <0,0,0> and anchored to it's left foot. It starts walking by moving its right foot. When the right foot touches the ground (e.g. at <1,0,0>), the anchor would switch to the right foot (and so the position would change to <1,0,0> abruptly). The rest of the walk cycle would move the left foot, this time the right foot stays in place.
An anchor could be any point or bone-end. All I need is an additional "curve" that stores anchor-changes.
This would solve the "slipping feet" problem in a quite elegant way (the feet would stay in position "per definition") without the need of IK.

What do you think?
Do other application handle e.g. walk cycles in similar ways? Do you think my idea makes sense? Are there better ways?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Tue Nov 01, 2005 10:01 pm

Sascha wrote:I'm not sure what a "surge" DOF is. I assume it's about "stretching/crushing" a bone?
Yes, found that out by following pndragon's link. (To be pendantic about it, it was described as "moving forward and back.")

The overlapping action effect could be done by adding more DOFs: Imaging a character who's about to quickly turn his head: In cartoon style, it might start turning the forehead, and the rest of the head follows some frames later.
If you're describing what I think you are, this would be a place where you might have a distortion added by the "twist".

But movement like that for a head is pretty atypical, even for toons. More typically, you'll turn the head down and then up in an arc, instead of simply turning it straight across, so you'll need a middle pose, not just the end point.

I suspect that overlapping action isn't something that you're going to be able to add automatically.

I think IK could and should be used in two ways: 1) To quickly set up a (keyframe) pose - moving a hand into a certain position is easier with IK than it is with FK.
That'll be the most popular use.

To keep certain bodyparts in position in the in-between frames.
I'm not quite sure what you're referring to here. I'm guessing you mean you'd like to "lock" one of the IK targets in place, and have the chain calculated "in reverse" to keep that target in position. (Feet are another item that comes to mind). In that case, yes, it's certainly useful.

lot of programs seem a problem with IK adding "overshoot", so that ankles and wrists twist when they should be staying still, instead of being "locked" into place. I'm hoping that JPatch's automatically applying linear curves for these sorts of cases will automatically take care of this.

One thing that Animanium does is allow two different types of locks. One locks the joint to a position, but still allows rotation through the joint. The other completely locks the joint and all it's children (which is generally what you want).

I was a bit suprised to find that Animanium (despite having a 'pin and drag' IK system) still had a lot of problems with locked targets drifting. They have a seperate "clean up" option for handling slippage.

The combination-sliders could be used to store simple things (like phonemes - combinations of morphs and a rotation of the yaw bone) and complex things such as entire poses.
I understand on a conceptual level that morphs and bone rotations are two seperate things.

But from a user point of view, I'm not sure I care about that distinction. When I create a morph target for the phoneme "A", it seems a hassle to have to go into the bone actions to create the bone action for the jaw, go into the morph editor to create a morph for the lips, and then go into the combination editor to combine them into a single morph.

Besides, you have to have the bone morph applied in order to adjust the mouth morph. Otherwise, the mouth shape may look fine, but when applied with the bone morph, it may end up totally wacky.

What I really want to do is be able to create this as a single action. If I have to toggle into "bone" mode to move the bones, and then "mesh" mode to move the mesh points, that's fine. Underneath, JPatch may make a distinction between the different types, but I don't think it's helpful for the animator.

Imagine such a sequence-slider (it goes from 0.0 to 1.0 and cycles through some poses that make up a complete walk-cycle). When played back repeatedly, the character would seem to walk, but it wouldn't move.
OK, this is typically how it's done with programs that have an Apply To Path option, like A:M and Blender.

Check out this Blender tutorial for how it works in Blender.

Moving it by simply setting up a position-curve for this character is tricky and would most probably result in slipping feet.
It doesn't seem terribly intuitive, but a lot of programs use it. And you won't get slipping feed if you use stride length to the equation . They also typically ease in/ease out of the walk from and to a target pose.

Probably the most appealing thing about the "path" approach is that it's dead simple to re-time your animation.

Here's an idea: Anchors...
It sounds sort of line "footsteps", where you lay footsteps and mark how far apart they are (in frames). The program then automatically calculates the walk for you.

rune put together a walking system for his POV-Ray AL character, although he didn't release the source code. I don't know how expressive a system like that would be, though. Being able to change the placement of the feet means you can change the stride length of the fly, but you're at the mercy of the program as to how expressive the animation actually is, although you should be able to edit the result.

I think the "path" approach is generally more flexible. You can create various types of walks for a single character, and choose which one you want to apply. You can create a walk cycle for all sorts of things: bipeds, quadrapeds, slugs or winged creatures - and they can all be applied using the same system.

My main problem with the path system is laying down the actual path - I think the idea of creating a spline and the "attaching" the character to it is counter-intutive. What I'd prefer is a system where you put a character at one position at frame 10, and another in frame 80, and then tell the program to apply the walk cycle between those frame. The program would automatically calculate the "path" that would be followed, instead of having to do it the other way around. If you added another keyframe with the character in a new position at frame 45, the program would automatically recalcuate the path for you.

One option would be to add a "walk cycle" to the timeline. Each character would have one "walk cycle timeline", but each walk cycle timeline could contain multiple non-overlapping segments, each with the properties:
  • walk cycle is which walk cycle to use;
  • start frame is the frame to being applying the walk cycle;
  • ease in amount is how quickly it eases to top speed;
  • end frame is the last frame of this walk cycle, and
  • ease out amount is how slowly to slow down from top speed.
I think this hides a lot of the complexity of path animation from the user, like having to create paths and attach things to it (shudder) but still simplifies animation by letting you choose different walk cycles to use.

One possible later refinement to the walk cycle timeline would be to allow transitions from one cycle - such as a walk - to another - like a run.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Tue Nov 01, 2005 10:40 pm

I should note a correction here: I had written that the ease in/ease out parameters related to how quickly the character accelerated to "top speed" along the path.

That doesn't make sense under the scenario where the path is derived from the character's position, because the the acceleration has already been calculated by JPatch.

What would make sense is using that parameter to ease into and out of the first and last pose of the walk cycle. That is, if the character begins walking at frame 10, they need to transition from whatever pose they were into the walk cycle pose, so they can begin walking. Likewise, when they reach the end frame, they need to transition out of the walk cycle and into whatever pose they'll take after they're done walking.

Of course, the character will begin moving during those transitions. Otherwise, JPatch would need to recalculate the path acceleration. :?

It would be useful to be able to put other cycles on the timeline (so the character could walk and chew bubble gum). I assume that the other cycles would possible have ease in/ease out values as well. So what primarily makes the walk cycle different from other cycles is that it's tied to the acceleration of the character, where other cycles would play back at a constant rate.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Wed Nov 02, 2005 11:10 am

lot of programs seem a problem with IK adding "overshoot", so that ankles and wrists twist when they should be staying still, instead of being "locked" into place. I'm hoping that JPatch's automatically applying linear curves for these sorts of cases will automatically take care of this.

I think there's a misconception about what to lock. Imagine the following situation: The character holds a handhold in a subway that suddenly breaks hard - he almost falls, but keeps standing because he still holds on tight on that handle.
In the animation, the character would be moving, but his hand would stay "locked" on that handle. Note that what's locked is the hand's position, not the angle of the hand, elbow and shoulder joints. In fact, if the shoulder moves, those joints must rotate in order to keep the hand where it is!

Technically this is similar to keeping a foot "locked" on the ground during a walk-cycle.

Now imaging our first example, and two keyframes where the hand is in exactly the same position, but the shoulder is in a different position. We agree that the arm, elbow and shoulder joints must rotate between those two keyframes. If this is simply controlled by motion curves (the curves define the amount of rotation for each joint at any given point in time), it is very likely that the hand will "slip away" in the inbetween frames. It is not a matter of cubic or linear interpolation, and it is not a matter of "overshoot" in this curves. Keep in mind, the curves affect the joint rotations - the hands position is only affected indirectly!

I agree that overshoot prevention would help if the curves defined the hand's position directly, but that's not the case here.

So how to deal with this situation: One solution is IK: As you said, you'd "lock" the IK target in place. In effect, the arm, elbow and shoulder joints would no linger be controlled by the motion curves, but by the IK solver: The solver knows where the hand should be and computes the joint rotation for each in-between frame accordingly.

But, if only one target needs to be locked, I think there's no need for IK locks and my approach with the anchors would probably work better:
It sounds sort of line "footsteps", where you lay footsteps and mark how far apart they are (in frames). The program then automatically calculates the walk for you.

No, that was actually not what I meant. I'll try to explain my idea in more detail.

When modeling a character, you model it in the model's reference space (there are x/y/z axis and there is an origin). Normally the origin is where the character stands (in its reference pose). The hip and torso are some feet above the origin. Now imagine a walk cycle: You'll usually animate just the legs and feet - the hip might go up and down, but it will stay above the origin, the legs and feet will move back and forward.

Here's an example (made with A:M) I've found on the internet:
Image.

Now, if you position a character in the animator, you'll move it from it's reference space into world space. That is, if the charactrer should be at position <1,0,5> - what really happens is that you move the origin of the models reference space to position <1,0,5> in the animators world space (Scales and rotations are also applied relative to the models origin).

If you now try to animate the character's position using a motion curve, you'll most likely end up with somthing like
Image.

It will be almost impossible to tweak the position-curve without key-framing every single frame (shudder). What would help is to "lock" the feet to the ground using the IK solver (as described above), but that would nullify the concept of walk cycles at all.

So, on closer inspection, the root of out problems seems to be that we animate the position of the models origin, which is basically its hip. Wouldn't it make much more sense if we simple declare the origin to be the left foot for one half of our walk cycle, and the right foot for the other. From the animator application this would look like:

We start with a pose where the left foot is on the ground, the right foot is behind. The model is "anchored" to the left foot, and is on position <0,0,0> (meaning that the left foot is at <0,0,0>). Our next keyframe is at frame 12 (1/2 of the cycle) - the right foot swung forward and just touched the ground (let's say at <0,0,1>. Since the model is still anchored on the left foot it is still at position <0,0,0>, but as the pose has changed (the left foot is now behind) it looks just like the character has made one step forward!
Now we switch the anchor to the right food. I.e. at frame 13 the position of the model changed to <0,0,1> (abruptly) - it's noch anchored to the right foot and can finish the walk-cycle - at frame 24 the left foot will touch the ground at <0,0,2> - we'll switch the anchor to the left foot again and can repeat the walk-cycle.
The result would be a nice walk with perfectly "locked" feet!
To follow a path, you'd have to rotate the model during the walk, but as the rotation will use the anchor as the pivot, this will not cause any problems: The character would always rotate around the foot that is currently on the ground.

In this case, you'd need "in-between" IK only if more that one target had to be locked. You could use the anchor primarily, and IK for any secondary targets (e.g. the hand pressing a button during a walk cycle).

Note that this would not be compatible with the concept of a variable stride-length. But you could define any number of walk cycles for each character. E.g. with normal, short and long stride-length, one for running, and even for different "moods", etc...

From the workflow, you'd neet to set at least two key-frames per cycle (where the anchor switches). You can modify the rotation at these keyframes to control the path. That is admittedly a bit tricky, but it would be easy to automate it - e.g. with a spline path. You woudln't be able to predefine where the character should step, but it would follow the path.

You'r example with setting a keyframe at frame 0 and the next at frame 80, and the character should walk between those two frames sounds nice, but I doubt that it works in any animation-application. It certainly would work, but I think it would have the look of realtime games. In an animation it should be the animator who brings the characters to life, not the computer - so having the application to "tween" 79 frames doesn't sound reasonable to me.

For a good result you'd have to fine tune a lot anyway, so the additional effort needed for my "anchor" system is minimal compared to that.

You could fade in/out to any pose before/after the walk - if fact, from the animator-application's point of view there is no walk cylce at all, just a set of key-frames: One at the beginning, two for each walk-cylce, one at the end. The pose at the start and the end can be arbitrary, and the speed (of the fade in/out and the entire walk) can be varied by the rate the keyframes are inserted.

The full workflow could be like this:
1) Start with any pose and tell the program to anchor the character on its left foot.
2) Go to frame 12 and apply a walk-cycle pose (e.g. "walk1.right-foot-ahead). The pose could contain a hint to switch the anchor automatically when it is applied at a keyframe.
3) Go to frame 24 and apply a walk-cycle pose (e.g. "walk2. left-foot-ahead).
4) Repeat steps 2 and 3 as often as required. To control the path you could either manually change the orientation at each key-frame. Alternatively a "follow path" tool could do this for you.
5) Go to the last key-frame and apply any pose.

You can also switch between different walking styles in the process by simply applying poses from other walk-cycles, or change the speed by changing the number of frames between the key-frames.

Of course you can also apply different poses in parallel. It would make sense to be able to exclude some joints from the cycle. E.g. a normal walk cycle would also define hand movement. But if the character is e.g. carrying something it should be possible to apply the walk-cycle just to the legs and animate the arms manually.

What do you think?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Wed Nov 02, 2005 12:23 pm

It sounds complicated! :P

I think you're having trouble believing that walk cycles actually work, and it's related to the idea that feet have to be "locked" into position. As a result, you're trying to solve a problem that doesn't exist.

Walk cycles really do work. They're used in 2D animation, as well as Animation:Master and Blender.

Here's a walk cycle, with the character walking "in place":

Image

It's looks like he's on a treadmill - his feet move, but his body remains locked into the same position.

Here's the breakdown:

Image

Note that the foot on the ground moves at a constant rate. That's key to this whole thing working properly. Now let's move him forward:

Image

The exact opposite happens: his body moves, but his feet appear "locked" into position. That's because their backward motion is exactly offset by the movement of the character forward. So there's no "slipping" of the feet, even without IK lockdown. As long as you use the correct "stride length" to move the character ahead, it all happens correctly.

Unless the character is making a very tight turn, you can have them follow a curving path, and the walk will still look good.

There are situations where you need to hand key the animation - for example, a character may be making a tight turn, or walking up steps. In those cases, you'll need to hand-key the walk.

But for a common walk, there's no need to "lock" the feet into place.

Did I misunderstand what you were trying to say?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Wed Nov 02, 2005 12:56 pm

I think you're having trouble believing that walk cycles actually work, and it's related to the idea that feet have to be "locked" into position. As a result, you're trying to solve a problem that doesn't exist.


Possibly, yes :)
But I have seen some tutorials for A:M that actually suffered from feet slipping on the ground.

Note that the foot on the ground moves at a constant rate.

Ok, that shifts the problem from the actual key-frame animation to the design of the walk cycle. How can you ensure that the foot on the ground moves at a constant rate whan creating the cylce?

The only way that I can imagine is to manually tweak every frame in the cylce - certainly less work than keying every frame in the entire animation, but still problematic: How can you apply the walk at a different rate? How do you vary the stride-length?

And how can you ensure the constant rate when e.g. blending from walking to running?
How does it work when fading in/out the walk-cycle?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Wed Nov 02, 2005 7:41 pm

Sascha wrote:But I have seen some tutorials for A:M that actually suffered from feet slipping on the ground.
Could you point me to one of those? I've seen a problem with feet slipping in It's A Pitch, but that was an overshoot issue, not an alignment during a walk cycle. Looking at an example would help give a better understanding of the problem.

Ok, that shifts the problem from the actual key-frame animation to the design of the walk cycle. How can you ensure that the foot on the ground moves at a constant rate whan creating the cycle?
I knew you were going to ask that. :)

It doesn't actually have to be exact - you've got room for slop. You basically have to make sure:
  • The "planted" foot (the one with the weight on it) is always moving, relative to the ground.
  • The stride length is fairly accurately measured.
If either of these have problems, you'll get slippage of the feet, and the illusion will be ruined. If you've seen the A:M tool for creating walk cycles, you'll see they've got "ruler" at the bottom so you can measure the distance between strides.

For something like a car (you can put them on walk cycles, too), you'll need to calculate the diameter of the tire. I vaguely recall there being some potential issues with rotations and walk cycles, having something to do with how the actual angle is stored. In this case, it might actually be beneficial for the program to consider a full rotation the same as none at all... :?

The only way that I can imagine is to manually tweak every frame in the cycle - certainly less work than keying every frame in the entire animation, but still problematic: How can you apply the walk at a different rate?
The equation is fairly simple:
Code: Select all
numberOfCycles = totalDistanceTravelled / strideLength
If the character has to walk from 0 to 40 and their stride length is 5, they'll go through 8 walk cycles in the process.

There's no need to move at a constant speed. All you need to do at any point along the walk is determine the current distance that your character has travelled, and take the modulus using the stride length. That'll give you the position in the walk cycle to use. So you can still ease in/ease out/accelerate - it's all handled automatically.

How do you vary the stride-length?
You don't - you change the rate at which a character cycles through the walk cycle. Using the prior example, if you've got to move 40 units with a stride length of 5, you'll go through 8 walk cycles. It doesn't matter if you've got 10 frames to do it in, or 100 frames - you'll still go through 8 walk cycles.

If you pay attention to when you walk, you'll note that your stride length remains fairly constant, if you're walking fast or slow. When you hit a certain pace, you'll "shift" to another type of gait, from "walking" to "striding" to finally "running". But you'll pretty much keep the same stride length within a given type of walking style - it's the rate at which you move your legs that changes.

So if a character needs to get from one point to another quickly, you'll want to use a "run" cycle, instead of a "walk" or it'll look pretty silly - like the Keystone Kops, when the camera playback is much faster than the speed the film was shot.

Below is an example of a "run" and a "fast run" - you can see that more than just the stride length has to change. The faster the character is going, the more they're leaning forward. I've read that walking is basically the process of constantly falling down, but catching yourself before you do. I guess leaning forward allows you to fall faster: ;)

ImageImage

And how can you ensure the constant rate when e.g. blending from walking to running?
You'd use the stride length, same as before.

Consider the case where you're blending from a standing position to a walk - you still calculate the position in the cycle relative to the distance that they've travelled, even though they started standing still.

So at the point where the walk becomes a run, you count that point as the beginning point of the run cycle and calculate from there. If the walk cycle was at 50% when you crossed over to the run cycle, you'd obviously want to start the run cycle at 50% so it would match better.

Blending different cycles obviously is a bit more work, but conceptually, it shouldn't be too hard.

How does it work when fading in/out the walk-cycle?
It works in exactly the same way. The ease in/ease out helps smooth the transition. Remember that the distance travelled is what drives how fast the character cycles through their walk cycle. The ease in/ease out ensures that they slow down at the end of the walk, and makes the transition to the target morphs smoother.

The Blender tutorial notes:
For the animation doesn't start nor end briskly we can use the BlendIn and BlendOut options, where we can set the number of frames used to blend actions and in this way doing a more natural transition between them. In this way the character will smoothly change its pose and everything will look fine. If we do use a BlendIn or BlendOut value, to be set in the NKEY dialog, then we should start the action BlendIn frames earlier and finish it BlendOut frames later, because the character should be still moving while changing poses.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Wed Nov 02, 2005 8:27 pm

Hmmm... :roll:
Ok, ok, ok,,, I guess you're right again :wink:

But I won't abandon my "anchor" idea that easily... What about that: Our character picks up a hammer with his right hand. From that frame the hammer should move with the hand until it is released again. I'm not sure if "anchoring" is the right term, but in lack of a better one I'll use it here: Wouldn't it be nice if we could simply click on a point on the hammer and on a point on the hand - from this time the point on the hammer would be "anchored" to the selected point on the hand. The "points" could be actual controlpoints, bone-ends or arbitrary points in the respective reference space.

This could still be relevant to walking, this time the other way round: What if our character enters a e.g. paternoster elevator or steps on an escalator? He could finish the "ease out" of the walk cycle or continue to walk, but this time relative to the paternoster's or escalator's space, not to world space...

I think there should be a way to switch the frame of reference during a shot.

But I have seen some tutorials for A:M that actually suffered from feet slipping on the ground.
Could you point me to one of those? I've seen a problem with feet slipping in It's A Pitch

Oh, I almost forgot. IIRC it was on the A:M tutorial page with those flash/shockwave screen-captured tutorials. I think it was "It's a Pitch".
I wasn't very impressed by the system: The IK solver came up with poses that looked very uncomfortable (I think A:M has no way to define joint limits), and well, there was this overshoot issue.

I think I'll start with implementing it the "standard" way, as you suggested. I can always later add the "anchoring" system - No one is forced to use it after all, if you're happy with the default behavior you could leave the anchor at the model's "origin".
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

PreviousNext

Return to General discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron