Ouch... I think I broke his legs.
Recovers mighty well from a drop! Good job on this :)

Hehe, thanks. Glad you like.

Compare the animation here to the animation showcased in Euphoria's demo video: http://www.youtube.com/watch?v=Qi5adyccoKI
A license for Euphoria costs over 1,000 dollars, while this I built in a couple weeks with comparable results. :D

Haha, I do like when they drop the block on him, though XD
Good job!

I've always been fascinated by procedural animation techniques. You doing this just for fun or do you have a larger project in mind?

Larger project. :)

Enable the debug lines, and see if you can figure out how he works :)

The bones themselves appear to be springs that work with a rest length as well as a rest rotation. The middle debug line, unless it's representing a more complex object in the background, appears to be just another spring itself that attempts to keep a particular distance away from the floor and influences the bone around the hips.

You seem to know quite a bit. :) The ragdoll is made of springs. Springs are so easy to work with, although they lack a rotation along the axis defined by the spring's connected vertices. The springs have a weak rest rotation in global coordinates, but there are angular constraints that keep a relative angle between two connected lines, such as between the legs.

I'm not sure if I should reveal too much now that you seem to know your stuff. ^^

Thanks, yeah I've done a bit with spring systems in the past, although they never really ended up playing nice with what I wanted to to. I think the eventual evolution you get into with this stuff is by writing out your own IK solver :D Which is actually not really all that bad. What you have right now looks great and I'll look forward to seeing it applied to the larger project you are working on.

*chuckles* Don't worry about me, I've certainly got my hands full with my own game project that I work on day and night. Actually as I speak I'm knee deep in making a 2d forward kinematics animation editor >.<

As far as I know, IK solvers and physics pendulums pretty much the same thing. IK solvers, however, have an environment with very high air resistance and high damping, so almost all momentum dissipates instantly. I found that trying to create a spring with full damping or full drag usually caused it to glitch out.

Hah, yeah, spring with too high of tension or dampening will generally freak out and completely screw with the simulation. Springs are great for certain things, but that is basically their weakness. If you do want a system with hard length constrained bones, that is what IK is intended for.

At a glance IK systems appear to have some of the same basic rules as a spring system but it works in a completely different way. The most basic implementation uses an iterative solver to basically reach the "goal" state. Each iteration gets you a closer result to what should be correct, but each time the actual error that is solved is less and less.

I've written one before, though it's been a while so I'm still a bit rusty on the details. One of the most common uses is when you have a pre-animated walk cycle but want the foot to interact with ground dynamically. It's easy enough to determine where the foot would collide with the ground, once you have that you can use IK to then modify the leg bones to move in a realistic manor that is approximate to the original animation.

What you describe about the iterative solver - this is actually similar to what a physics simulation does, except generally there is only one iteration per frame. Increasing the iterations, and in turn, decreasing the forces and velocities per iteration, will get you a higher quality result with less error as well.

Physics simulations cannot use force amounts greater than 100% of the difference between the current and rest length / angle / position / etc. This causes overshooting, and then when the system back-tracks it creates a vibrating effect. High quality physics simulations will actually increase the number of iterations to generate the force, so it never exceeds 100% per iteration, but is more than 100% of the force compared to other forces being applied to the same body.

IE, one of the simplest physics system one could program is something like a floor collider with gravity:

while(running)
{
vel.y -= 0.01;

if(pos.y < floor.y)
{
vel.y += (floor.y - pos.y) * strength;
}

pos.y += vel.y;
}

If the strength variable is kept below 100% (or 1.0) we will not "create" energy, causing the ball to bounce higher than where it fell from.

Now modify this scenario slightly:

while(running)
{
if(pos.y != floor.y)
{
vel.y += (floor.y - pos.y) * strength;
}

pos.y += vel.y;
}

If strength is greater than 100%, the object will resonate more intensely around floor.y with time, until it goes nuts and reaches weird values like Infinity, fucking up your whole game.
This happens because the object would be forced further than the rest position at floor.y, and the resulting momentum would bring it further away from floor.y than what it was at previously.

However, if you think about the physics simulation differently - as though strength represents the time needed for the object to accelerate itself to the rest position - and then apply the same force in fragments over smaller steps, you'd essentially get the result you'd be looking for, just happening over less time.

I completely agree with that yeah.

In a way a normal physics simulation is just an iterative solver. The distinct differences between the two different situations here is that an IK solver doesn't have a concept of time where as a physics simulation does. With a physics simulation you are attempting to extrapolate the positions and rotations of objects given forces that are applied, doing so over a period of time. The iterative IK solver instead is trying to solve for a finite answer that exists but there is no %100 way to go from the beginning variables to the final result, instead you have to run the algorithm over and over to try to get close to the correct answer.

Another example of an iterative solver that doesn't use time is rigid body collision solving. In any given frame you can find out where all the objects are and which ones collide with what, but there is no easy way to correctly solve all of the penetrations in one go. Say you have one object that is stuck between two other objects... if you step through the list of collisions and solve them you get the middle object ending up pushed to one side or the other. In real life of course this couldn't happen, the object can't exist inside either of the objects. However, if you run the simulation several times in the same frame eventually the objects will push each other around to get a more correct solution. This kinda falls into what a colleague and I call "diminishing marginal returns".

*chuckles* Either way there are all sorts of schools of thought when it comes to problem solving certain situations.

Bah... terminology was off there. Should have read "However, if you run the collision solver several times eventually the objects will push each other around to get a more correct solution."

Impressive!