I'm currently looking at implementing inverse kinematics in an existing (but relatively small) project. The idea is to move a characters hand as an inverse kinematics enpoint, and have the lower and upper arm react to the hand movement. So far I only found a handful solutions and algorithms. The most promising real IK implementation I found so far is a website with paper and demo project by Samuel R. Buss and Jin-Su Kim. However, their solution does not take into account joint constraints which would be nice to have. I read another approach that uses a fullfledged physics engine and uses the engine's joints to set up the character's skeleton. I guess one could apply a force to the hand to make the rest of the joints move. Does anyone have experience with implementing inverse kinematics? Which implementation/approach did you chose. And which of the above approaches seems to be the easiest or best? [Edited by - Structural on May 9, 2008 10:23:50 AM]

I'm all for the "Keep it Simple" algorithm. Starting with the first joint, rotate and point to the target. Move to Next Joint. Repeat. Repeat until target reached. (not sure of the offical name for this method)

There are solutions out there that attempt to compute the final position of the rig, without using the method describe above, very heavy on the matha, But those can get very computationally expensives with the more joints you add.

I'd try building a simple 2D application, to test the algorithm above and expanding it yourself, with constraints etc.. See if you can get your rig moving in the way you expect it too.

The problem comes, because there is more than one solution to how a set of joints can be arranged too reach the target. In my system I opted for a quaternion solution instead of basic trig. for computing the rotation of the joint. Much better!

I myself got a little frustrated with an IK solution and opted for a basic tweening/animation system instead. I wrote a little rig editor which has IK in it for creating keyframes for the main rendering system.

We're currently working on a simple IK solution based on this excellent resource (section 7, Motion Control). It may not be the most fancy approach mathematically, but the relaxation in this model makes adding contraints a lot easier. If formulated well, the system will basically enforce new constraints automatically.

Quote:Original post by remigius

We're currently working on a simple IK solution based on this excellent resource (section 7, Motion Control). It may not be the most fancy approach mathematically, but the relaxation in this model makes adding contraints a lot easier. If formulated well, the system will basically enforce new constraints automatically.

I skimmed over this page and at first glance it kind of looks like a physics engine. Reading up on the verlet integration thing I notice it's designed for particle systems. So I wonder if engined like ODE/BULLET/PhysX can do this for me.

@moosedude: I also read about the method you mention. Here on gamedev. Can't remember the name either though.
I'm not strong in the math area, so I'd rather avoid writing this myself and rather use an existing (working) implementation. That's why the solution that takes an existing physics engine sounds so good.

Quote:Original post by Structural
I skimmed over this page and at first glance it kind of looks like a physics engine. Reading up on the verlet integration thing I notice it's designed for particle systems. So I wonder if engined like ODE/BULLET/PhysX can do this for me.

It is one, but it has the nice side-effect of being very useful for IK too. Ragdols and IK in one relatively simple solution, what more could you want? [wink]

To get back to this, I think I'm going for ODE for this project.
The

">reason for chosing ODE is that I found a Torque resource that does IK with ODE, and since I use Torque for a second project that might also need IK this would integrate nicely.