• entries
743
1924
• views
583818

# Baffled

144 views

Cry for help entry:

I'm baffled by how to get a keyframe animated model to remain flat against a plane (e.g. the ground is a good example).

Take the following (very simple) example - imagine two keyframes:

Note that in both frames, the soles of the feet are against the ground plane.

The interpolated frame halfway between these is as follows:

The soles of the feet have sunk through the floor.

I understand what causes it - there are two transformations happening between the frames: the rotation of the hips and ankles and the movement up and down of the pelvis.

As the Y value of the bones involved in the rotation is obviously based on the equation of a curve, whereas the Y component of the up-down motion of the pelvis bone is just a normal linear interpolation, they move in and out of sync as you interpolate between the frames.

Putting more keyframes between them helps hide the problem, but does not address the fundamental issue, so perhaps someone out there can help.

Given that an interpolated keyframe animation is normally based on a combination of movements and rotations, how do you interpolate without sinking through the floor plane between frames?

Any help on this would be much appreciated.

[EDIT]

I've come up with one solution to this, although I'm not sure if it is the best.

I'm either moving existing bones where possible or adding dummy bones if needed so that there is a bone location at every possible extremity of the character. For a character that just walks, these are just at the tips and heels of the feet and tips of the hands, although this would vary depending on the animations.

Once I've generated the matrix palette from the skeleton, it is actually then quite trivial to get the minimum and maximum x and y values of all the bones based on the current pose and the y-axis rotation.

These can then be used to generate an accurate bounding box around the skeleton in an arbitrary interpolated pose and as long as the positions of the extremity bones match the extremity vertices of the model, all should then work okay.

Feels a bit over-complicated though. I'd still be interested to know how normal games handle this.

In the art, artists typically apply constraints to the animation rig. So in this example, there would be a constraint set on the feet such that they can't go below the ground plane. There might be other constraints such as locking a particular foot to a specific position to prevent it "skating" as the rest of the model is posed. In the modeling package, these constraints will be continually applied by the application, and so all the poses used as keyframes will look fine, and so will all the interpolated frames in between.

The problem still raises its head on export though - typically only the keyframes are exported, and constraints are usually thrown away (they're hard to code for anyway as you need a fairly decent IK solver as part of the animation system, not to mention a lot of extra data hanging around).

This means the nice animation from the modeling package still looks bad in the engine, with feet skating around and not sticking to the floor.

One generally used solution for this is to ignore the artist generated keyframe data. Instead, the export process samples the animation at a high rate, using the modeling package itself to do the animation. This means that all the constraints are applied exactly as expected. This produces a large number of keyframes, regularly sampled (feel free to *also* sample on real keyframes for added accuracy). Then this data can be reduced down by fitting each channel to a curve (basically, throw keys away if they happen to be an interpolation of adjacent keys).

This gets you some nice ordinary keyframe data which keeps all the constrained movements.

Hope that helps...

Quote:
 Original post by _Sin In the art, artists typically apply constraints to the animation rig. So in this example, there would be a constraint set on the feet such that they can't go below the ground plane. There might be other constraints such as locking a particular foot to a specific position to prevent it "skating" as the rest of the model is posed. In the modeling package, these constraints will be continually applied by the application, and so all the poses used as keyframes will look fine, and so will all the interpolated frames in between. The problem still raises its head on export though - typically only the keyframes are exported, and constraints are usually thrown away (they're hard to code for anyway as you need a fairly decent IK solver as part of the animation system, not to mention a lot of extra data hanging around). This means the nice animation from the modeling package still looks bad in the engine, with feet skating around and not sticking to the floor. One generally used solution for this is to ignore the artist generated keyframe data. Instead, the export process samples the animation at a high rate, using the modeling package itself to do the animation. This means that all the constraints are applied exactly as expected. This produces a large number of keyframes, regularly sampled (feel free to *also* sample on real keyframes for added accuracy). Then this data can be reduced down by fitting each channel to a curve (basically, throw keys away if they happen to be an interpolation of adjacent keys). This gets you some nice ordinary keyframe data which keeps all the constrained movements. Hope that helps...

That's interesting. Thanks.

I've actually found a solution that works a bit better than the one above - I still require dummy bones at the front and back of the base of the foot. After the frame is applied, I transform just the bone co-ordinates via the skeleton matrix array in software. Since these are in local space, I can then just work out if the lowest bone's y is less than zero. If so, I just add its negative value to the model's y in its world transform when I render.

This means I can put together, say, a walking animation in Milkshape without having to align the model on a ground plane (which is a bit of a pain to do along with a skeleton in MS). I just make sure that all the frames descend below the y plane, then the above system corrects for this when it is rendered, without having to adjust the actual theoretical position of the model from a physics perspective.

I appreciate the input though. I still don't understand though - even if sampling at a very high rate, surely it is possible for interpolated frames to descend below the ground plane? Also, MS doesn't seem to have a constraints system anyway, so I guess my own software constraint is the best option.

Quote:
 Original post by EasilyConfused I appreciate the input though. I still don't understand though - even if sampling at a very high rate, surely it is possible for interpolated frames to descend below the ground plane? Also, MS doesn't seem to have a constraints system anyway, so I guess my own software constraint is the best option.

The idea is, you use the constraints (in a package that supports them!) to stop parts of the model ending up in places you don't want them. These constraints are applied in every frame, not just the keyframes. This typically involves solving a bunch of IK stuff to move joints around.

This constrained movement is then sampled at a very high rate - high enough that if you were playing it back, you simply wouldn't have any interpolated frames anymore.

So at this point you'd have a massive amount of keyframes, but a very well behaved animation.

Then you reduce the keyframes again, but obviously you only remove ones that don't change the animation.

Say you have the most simple leg animation - one frame with the leg to the back, and one frame with the leg to the front. A simple interpolation would rotate the joints smoothly and go right through the floor. A constraint solver would bend the knee as the legs moves through such that the foot remains on the floor. The motion is no longer a simple curve, and so the two keyframes plus the constraint are producing an animation curve which is more complex, and probably discontinuous.

Sampling this would result in loads of keys, but the chances are that the resulting motion could be represented with only a single extra key (right in the middle).

Obviously if you're animating without constraints you kind of have a simpler problem, and your solution may well be perfectly good. In fact working out where the feet actually are and translating the model to place them on the floor is basically implementing a simple kind of constraint anyway.

## Create an account

Register a new account