Inverse Kinematic using Cyclic Coordinate Descent method

Long time ago ( in 1995 !), I intuitively wrote for my master in Computer-Science an IK-solver that also seemed to be used in robotic, then in computergraphics world under the name of "CCD" (Cyclic Coordinate Descent) method (I really didn't know anything about this, at this time. In fact, I am not even sure CCD was used in 1995, at least in computergraphics).

I decided to re-implement it for more specific purpose. this CCD is using quaternions and basic vector calculus and is largely good enough for nice looking results, as long as you put a decent amount of iterations.

My purpose: revisit typical animation process for games; see how to interactively perform minor corrections to traditional artist-animated motion.

As an example: when the feet encounter the floor ealier than expected, it is important to do a minor correction of their placement so that they don't penetrate the floor...

My favorite example SOTC (see the making of : http://www.bruno-urbain.com/resources/making_of_sotc.pdf : what they call "motion addition"). I bet many other games do this. But I was surprised to not find so much litterature about this topic. Furthermore, when looking at recent games, I have the feeling that most game developers don't bother about IK-corrections in realtime.

The cool thing about CCD is that its starting position is an important information. When the solver will start its iteration from the animated frame, it will tend to be quite close to what it looked at first glance. Attached is an image showing the FK (Forward Kinematic) joint in black; and the IK in Green.

In order to blend correctly the IK to the FK, it is possible to change the blending factor of IK over FK. For example, when the foot didn't reached the floor, the blending factor is zero; when the foot reached the floor, the blending factor will be 1 and the IK handle will correct the foot so that it doesn't penetrate the floor...

Next steps :

• add DOF constraints (as I did years ago...). But this time I plan to make these constraints more precise and plan to expose them visually into Maya, thanks to the "Locator" object.
• I will also try to introduce the idea of "cost" : the bigger the angle is; the more it is expensive. This could help the solver to spread more correctly the joint rotation...
• Export the data so that we can do the exact same outside of Maya (Maya is really here only for the setup)
• use the asset in an interactive situation.
• See how we can accelerat this with the GPU (CUDA/Compute etc.)