Inverse Kinematics is, simply put, a method of getting things where they need to go.
OK; that was too simple.
In slightly more complex terms, rather than manually setting the rotation and translation (position in space) of objects or systems of objects, we set target locations or intended results and a kinematic solver figures out how we should manipulate our objects -often within set geometric limitations- to get to the goal.
Inverse Kinematics (IK) is used primarily in two areas: robotics, and computer animation.
Our interest in IK is both in expanding our internal toolsets to include customised animation tools but also combining IK with systems both for simulating realistic or system based movement and generating animations for prototypes without the need for more artistically refined animation.
Researching in IK and other such areas is something we’re always keen to do. Expanding your area of expertise is hugely rewarding and not only helps you realise your client’s projects to a fuller potential but also increases the playground of thought your own concepts can work within.
When looking into IK solvers, we found several methods were favoured, such as variations on the Jacobian technique, however, many of these involved iterative estimations that would lead to an unrealistic ‘journey’ to the solution and in many cases seemed a lot of ground-up work through matrix calculations or trigonometry that would seem out of place in the engine-based toolsets we intended to use IK with.
After looking through some research and dabbling in some youtube searches for demonstrations, we arrived at the Cyclic Coordinate Descent (CCD) method. Ultimately, we were convinced after reading ‘Inverse Kinematics And Geometric Constraints For Articulated Figure Manipulation’ by Chris Welman wherein he reviews many differing methods, combinations of methods, and implementations with the goal of finding the most convincing and efficient way to use IK in animating or otherwise moving a realistic human figure.
One benefit of CCD is its reliance on a hierarchical relationship between joints leading both to the required results but also a set of limitations that exactly match the structure. This is also fantastic for implementing in engines such as Unity, as the hierarchy can be handled inherently by the engine without the need for manually managing matrix inversions etc within our IK code.
Another benefit of CCD is how simply limitations can be added at certain stages to exactly represent each joint’s range of motion. If a knee can only go so far then you just make sure the CCD knows this and it stops, allowing the rest of the leg to move as it should to get to the required position.
In our next post we’ll get into some issues, some more expanded demos and implementing our IK solver into another system of ours we’ll be describing in a separate post very soon.
If you found this post interesting, follow us on Twitter for more updates. It’s only our 4th blog but we’re having fun so hopefully it will expand into something useful and interesting to everyone who’s programming-curious or interested in what goes on at FD.
If you’re interested in working with us on a project, please do get in touch. Our website will soon be updated to include our full range of services and benefits of working with us, along with a dedicated page on prototyping so watch this space.