Tips for learning IK/Procedural Animation?

I work on a walking ragdoll driven by pure physics simulation, which is one step ahead and much harder than procedural animation, but the thing's i've learned there would be useful to make animation realistic.

Because humans are upright all their motion is dictated by balancing. The COM is very high, and the support polygon is very small, so we end up balancing all the time. The game discussed in the video certainly misses to capture this. (Although i consider it very good - that's progress and interesting, and fun too. Great Work!)

So, balancing works by keeping the center of pressure (COP) inside the support polygon. (Support polygon is the 2D convex hull around the feet, projected to the gravity plane.)

We have control over COP position by ankle torque, but it requires planning ahead and ends up to be a difficult control problem, the equations result in very complex calculus. I've learned some things from robotics papers, but they did not really knew solutions and ended up at approaches that are unable to utilize what's possible, resulting in slow robots, e.g. that cute Honda robot. Exception is Boston Dynamics - they solved this, but they do no longer publicate (they did when it was a university project).

The main problem in practice is: Assume you can not take a step, but you have to move your COM to a target position, e.g. move the pelvis to the right. To do so, at any point you would need to calculate the necessary deacceleration so you are able to stop, which means the COP can bu hold within your right foot. If you accelerate too fast to the right, the contact point that could stop that motion moves outwards the foot. In this moment your COM is till in the support polygon, but tipping over or making a step to keep balanced in the future is already unavoidable, which means you already lost balance.

The most efficient motion you can do at all is to move the COP forth and beck between the edges of your feet. Try swinging your pelvis sideways as quick and wide as possible and observe the forces you apply to the ground from your feet. You see you can not do this very fast, and the forces are big.

So, after you've gone through implementing IK (which is just a necessary detail), you may want to approximate this behavior and add it as a constraint to any procedural target motion, then the result should be realistic. The usual way to do this is to use an inverted pendulum model, which is set up to have equal mass, center of mass, velocities, moment of inertia then the sum over all rigid bodies of the skeleton (if we would talk about physics simulation).

I can not list any resources, sorry, but google for Center Of Pressure, Zero Moment Point and Inverted Pendulum Model.

For now you are probably interested in IK, which is about calculating joint angles to reach target positions with feet and hands, bending spine in curves, looking towards a target... stuff like that.

You will also have to think about the speed and form of motion. What works pretty well is to move with constant acceleration (not constant velocity - that's robotic). Se when grabbing a health pack with the hand, the hand becomes faster as it moves to the midpoint, then starts to slow down and ends up at zero velocity on the target, speaking simplified. (You can model this with matching parabolic curves.)

Good luck!

Thanks Joe this is really helpful, I wasn't quite thinking about physics based locomotion. Though I am very interested in the concept.

There is also cross-over utility between IK, physics based locomotion, and robotics for sure.

I was mainly interested in using it to enhance animation and resolve paired animations mismatching for starters. I found a bunch of resources online in regards to IK Including this article from the University of Cambridge by Dr. Andreas Aristidou. I also found this guys website by Luis Bermudez, its really good for starting out. This guy, Alan Zucconi, although I found less usefulness from the blog, so far. Also this one is for Artists, by Minions Art. Working my way up to Dr. Andreas Aristidou's paper.

Quote

Because humans are upright all their motion is dictated by balancing. The COM is very high, and the support polygon is very small, so we end up balancing all the time. The game discussed in the video certainly misses to capture this.

Edit: Do you have a diagram of what exactly is missing from his approach or something to reference? I don't have a grasp on the visualization of the missing motion. I don't see whats missing from his bunny biped.

I mean there is alot of missing in animation despite current IK for sure. I wanted to find an animated hippo the other day, and I looked at a real hippo, the real hippo in a Nation Geographic video had his folds of fat moving about as it charges through a river. Got me interested in how an extra bone can simulate fat in fleshier quadrupeds. I am trying to get into a studio that animates a lot of horses and animals you see, and stock biped animators don't exactly do the trick. Tacking on an extra pelvis is a bit of a hack... unless the hands are effectively the forequarters. So thats how they do it. Huh.

9 hours ago, WolfHound Coder said:

I was mainly interested in using it to enhance animation and resolve paired animations mismatching for starters. I found a bunch of resources online in regards to IK Including this article from the University of Cyprus by Dr. Andreas Aristidou.

My own take on this is quite different, i have IK solvers only per limb, so one solver per leg, one solver for arm, one solver for spine. This means i do not really need a solver at all, because the problem reduces to a small one which can be solved analytically. So for an action like kneeling down to pick up a object from the floor, i need some higher level logic that works like this: Arms are too short, so lowering the whole body is necessary, which bends the knees into a crouching position. Object is still out of reach, so bend spine to bring shoulders closer. Now the arm can reach and pick the object. So this is very simple in comparison to a full body IK solver, but it works for me because the balancing controller makes the full body constantly adjusting to keep the COM (which is affected by all bodies) balanced. I, thus it looks natural allthough IK only works on local problems.

Also, because i focus just on basic locomotion for now (balancing, walking, running, jumping...), i have no need yet to plan for avoiding self collisions, even handling of joint limits in the IK solver (which i have implemented) turned out to be unnecessary. This is because human body just never runs into such problems or limits while doing basic locomotion. (Many of the 'intelligence' that allows us to move around is already built into the physical shape and construction of our bodies.)

This means you may not need to spend so much work on IK as you think, eventually.

9 hours ago, WolfHound Coder said:

Do you have a diagram of what exactly is missing from his approach or something to reference? I don't have a grasp on the visualization of the missing motion. I don't see whats missing from his bunny biped.

What's missing is simply the dynamics, as in almost any game animation approach. So while watching this, we unconsciously notice this is artificial and not real all the time.

In contrast, when watching this old video of mine:

...You see this this still looks robotic (upper body is stiff and walking is driven by dump state machine), but you also see all that acceleration happening to the chest, the balance is correct. So it looks like a 'real' dump robot, we could say

And you can do this with animation too, see for example this work:

Which enhances traditional animation with some IK retargeting and adding some bouncing physics on top (which is very easy to do).

So you don't need to simulate full physics, but you can utilize its laws to improve realism. Balancing can be added in a similar way (it is just harder to understand - my advantage here is, if i do it wrong, i see that quickly because the character tumbles down. With animation you have no proof like this of course.)