Principles of inverse kinematics for a basic 2D humanoid stickman

Question

I do a bit of animation geekery as a side hobby, mostly in Javascript (DOM and canvas based) as well as having done a bit in C# and other technologies. However most of it has been based on sprites, bounding boxes, simple pixel movements etc - and now I'm interested in using vector graphics and implementing a character with realistic moving joints driven by physics forces. I'd like to get something going either in the canvas element or SVG.

There are plenty of questions on here relating to inverse kinematics, but most of them are a bit low level and assume a prior knowledge of vectors, forces, and engineering terminology. What I'd really appreciate is some pointers on the fundamental principles behind how a basic stickman with hip, knee, ankle joints etc can be made to move semi-realistically.

I use Knockout.js a lot and have been wondering if I can implement the positioning of each joint via Knockout's computed functions, where for example the location of the knee joint is computed from the positions of the hip and ankle joints and forces operating on them. But I'm having a hard time finding a starting point: I've been walking in slow motion around my house like an insane man trying to isolate which parts of the human body actually move first and how each part responds to the movements of the others. Is there a generalized approach to how the humanoid figure is set in motion in games and animations?

Bearing in mind that I'm used to working with pixel coordinates as opposed to vectors and forces, am I being naive to try to tackle this in isolation? Will I find that I immediately also need to learn about centres of gravity, momentum, and all the rest?

Any help appreciated, including links to noob tutorials!

Answer 1

Almost 3 years on, I can offer an answer of sorts to my own question. I discovered the JavaScript libraries Physics.js and p2.js, and I delved into their demos and source to try to learn the "physics mindset". In a nutshell, and still speaking as a physics noob - you generally don't move objects explicitly, but rather you model a simplified physics world where bodies have basic physical properties such as mass, and they obey constraints with other bodies, and react to forces acting upon them such as gravity or an explicit directional force such as when a foot kicks a ball. This causes them to attain velocity and angular velocity. The library handles resolution of the center of mass of a body based upon the shapes it is comprised of (e.g. a complex polygon plus a rectangle plus a circle might form a single physics body). The various forces and constraints at play will be in a conflict of sorts, and the library does the work of resolving where and how, after a given "time step" of the physics world, everything should be positioned. This is done via various "solver function" implementations which perform as many iterations as computation allows for the required accuracy.

Both of those libraries separate their physics modeling core from the visual rendering aspect, and allow for different rendering implementations. When I started using p2.js I saw that it was using Pixi.js for rendering in its demos so I ended up building my own simple JavaScript framework which built upon that integration: https://github.com/TomWHall/p2Pixi I haven't constructed a walking humanoid as such, but I have created a "circus unicycle" demo with a humanoid figure which for simplicity is constrained to its unicycle: http://booleanoperations.com/experiments/p2/unicycle/ When the rider is moved left and right (arrow keys or mouse click on either side of the canvas) negative or positive speed is applied to a motorized revolute constraint between the wheel and the shaft, and correctional forces are also applied to various parts of the unicycle and the rider to simulate some form of balancing. Rotational constraints are in place to fix the rider's feet to the pedals of the unicycle and his leg segments together, with rotational limits for the joints. Gravity keeps pulling the wheel down onto the ground, and the movement of the wheel causes the attached leg segments to move with it. This is obviously the reverse of how a unicycle and its rider work together - in reality, the leg segments move as a result of piston-like action of the tendons upon bones, and that leads ultimately to the rotation of the wheel. But that was an unnecessarily complex model of my circus world :-)

Answer 2

If you're doing a more practical sort of game, typically you don't code things like a character's center of balance using a dynamics engine. That would be extremely difficult, especially if you're incorporating soft bodies and muscle dynamics, and would probably devote the bulk of the machine's resources just to balancing the biped, e.g.

Instead games usually apply mostly hard-coded kind of character animation, where the artist supplies the graphics and frames of animation for a skeleton when a character walks, runs, jumps, etc. There the character's sense of balance and motion are carefully made by an artist's touch rather than the result of extensive physics calculations.

The skeleton is basically a simple deformer. It works like a magnet, influencing surrounding vertices/pixels with a soft deformation. The process of determining that area of influence of a skeleton on its surrounding character is called skinning. There's nothing very realistic about it: it's made to look realistic, not to behave realistically. It's similar to the 3D mesh: a hollow surface. It's not modeling things at the level of atoms and molecules: it's made to look realistic, not to be realistic.

Forward kinematics then rotates those bones around, making parts of the character follow along. Inverse kinematics is a way of manipulating those bones in a way where you have an IK goal/effector over an IK chain. Normally you pose characters like a rigid mannequin -- if you want to make a mannequin reach for something, you have to rotate his shoulder, elbow, wrist all separately. IK lets you make that whole arm into a chain and just specify where the wrist should go, allowing the solver to rotate the elbow and shoulder automatically. That allows you to pose things more like a human person, where I can grab someone's wrist and tug on it and the rest of their arm follows.

With that artist-driven traditional approach as a solid base, where you have exceptions is when a character grabs a dynamic rope whose motion is not fixed, for example, and needs to cling on. That's when the artist animations stop and calculated character motions begin.

In such a case, you would use the character's hand grabbing the rope as an IK goal to have his entire body follow, with rotational constraints set accordingly on each joint/bone to prevent him from, say, bending his arm backwards and breaking it or rotating his head 180 degrees Exorcist-style. An unconstrained IK solver would potentially do these things, so rotational constraints prevent the solver from doing things the human body can't do while your high-level game logic is just concentrating on moving the character's hand, parented to the rope, with the IK solver to make the body follow.

A similar case is applied when a character gets hit by a shotgun, for example, and you need him to fly in the air with ragdoll physics -- same idea.

It would be very unusual to try to have a game where the character is entirely controlled by inverse kinematics targets and physics. I've seen goofy attempts at that like a funny game where your character is a drunkard and your whole goal is just to try to get him to walk home and not fall over and die.

So unless your entire goal and ambition is to try to simulate the dynamics of something as complex as a human body, I recommend starting with the traditional artist-driven approach and use those dynamics sparingly on your characters. That's also how 3D packages do it, where most of a character is keyframed by the artist but some parts at some times might be partially calculated by dynamics like the movement of her hair.

Perhaps you can work your way upwards to computing more and more automatically and having the artist do less and less manually. However, I would not start with the approach of trying to automate it all, especially unless you're a master of dynamics and inverse kinematics concepts.

Answer 3

Bearing in mind that I'm used to working with pixel coordinates as opposed to vectors and forces, am I being naive to try to tackle this in isolation? Will I find that I immediately also need to learn about centres of gravity, momentum, and all the rest?

In short, yes. I'm not trying to be discouraging, but if you don't understand at least some of the mathematics behind IK, even the API's of appropriate libraries will be bewildering to you. You'll have less frustration if you do some learning first. By then you should have some solid understanding about where the model ends and where rendering the model begins.