Introduction
Installation
Pre-Rigged Models
Rigging
Contact
Animation
IK Ranges
Aligning Chains
Chain Visibility
Pivoting
Motion Paths
Automatic Features
Follow Rotation
System
Throughout the Kinematic Tool User Manual, I've explained the systems in various ways to address their uses in context. However, I like when systems are laid out in a digestible way, so this page is intended just to give you a clear bird's eye view of the major kinematic switching system that helps make the Kinematic Tool one of the coolest animation addons in the universe, and hopefully along the way you'll understand why things are the way they are and why certain choices were made.
First off, the reason we even have all these extra bones and chains in the first place, rather than relying on a single chain to handle what we need, is because A) the transform data that bones hold are handled differently when a bone is part of an IK chain versus when it's part of an FK chain and B) the parenting relationship of the end bone on an FK chain is different than the parenting relationship of the end bone on an IK chain. The FK end bone needs to be parented to the middle bone, the IK end bone needs to be free to move the chain around.
Believe me, I'd love to have a single-chain system, and I even spent the first many months building this tool trying to create a single-chain system. I succeeded, but only by creating some weird complicated mess where the tool records the transform data of the chain right before the chain switches kinematic modes, turns on or off the IK constraint, then dips into Edit mode to change the parenting relationship, heads back to Pose mode, then forces the new chain to adopt the previous transform data, and concludes by keyframing the new transform data. This is all supposed to happen in real time as an animation is playing, and as you can imagine it completely tanks the frames-per-second. I was clocking around 8 fps on a character with a standard set of limbs. Essentially, it was impractical (albeit a fun and interesting pursuit).
I'm convinced that if the Blender Foundation wants to have a world-class animation system, they should seriously consider the innovations I've implemented in the Kinematic Tool as well as find a way to develop a robust and simple single-chain system. There's nothing glorious about having to work with a bunch of bones to handle a fundamental element of 3D animation, especially when a simpler solution is possible (it would have to be coded into Blender using C++ and some of the systems would need to be overhauled). They would have to find a way for an IK chain to store the transform data of both IK & FK modes simultaneously in the timeline and manage the weird parenting problem.
Anyways, I say all that to at least give you a sense why we do this ridiculous song-and-dance when it comes to just trying to do what I think is a fundamental element of 3D animation: kinematic mode switching. Both FK and IK have their advantages, and since all human, animal, robot, and creature rigs not only benefit from but rely on kinematic mode switching to easily produce quality animations, why not integrate a simple world-class system for dealing with kinematic switching? A lot of the quality-of-life I see being implemented in future Blender versions is nice and all, but these features mostly seem like icing on a cake (I like icing!), rather than addressing the fundamental problems and interactions that every animator interacts with, namely kinematic mode switching. In my eyes, the kinematic switching workflow should require very little technical fiddling. Until that vision is realized within native Blender, we have the Kinematic Tool to rescue us.
The kinematic switching system of the Kinematic Tool works by establishing three chains: a "deform" chain, an "FK" chain, and an "IK" chain. The FK and IK chains are controlled by the animator and the deform chain copies the transforms of either chain depending on the value of a custom property that lives on the middle IK bone of an assembled limb.
This custom property, named "Kinematic Mode", drives the kinematic switching system. The "Kinematic Mode" custom property (which exists in Pose mode), is a simple floating point number that ranges between 0.0 and 1.0, and is keyframed when using various kinematic mode operators (see IK Ranges for more context on those operators.). The "Kinematic Mode" custom property drives the influence on the constraints of the deform bones that copy the transforms of the IK bones. The driver turns on the constraints when the value of the "Kinematic Mode" property is 0 or 1. When the value is anything otherwise, like 0.38 or 0.67, the drivers turn off the constraints and the deform chain goes back to its default mode of copying the transforms of the FK chain.
Not only does this "Kinematic Mode" property drive the influence on the constraints of the deformation bones, it also helps to drive the Chain Visibility system that is incorporated into each of the animation bones' custom shape scales.
The other part that makes this system work is a certain special manipulation of the interpolations of the keyframes of the "Kinematic Mode" property. The way the Kinematic Tool is able to accomplish maintaining IK mode on the final keyframe of an IK range, as well as throughout a range, is by carefully modifying the interpolations of the "Kinematic Mode" property keyframes.
When starting an IK range, the "Kinematic Mode" property is keyframed at 0, and when ending an IK range, the same property is keyframed at 1. By setting the property keyframe to Constant Interpolation at the beginning of a range, the value is maintained at 0 up to the final keyframe, at which point it then becomes a value of 1. So the value of the "Kinematic Mode" property while inside this range will always force the deform bones to copy the transforms of the IK chain. The "Kinematic Mode" property, where it's keyframed to a value of 1, is set to Bezier Interpolation. This way when moving between one range and another (and going from 1 to 0), or when going from the end of one range to an FK keyframe column (going from 1 to 0.5), the "Kinematic Mode" property is then at some value that's inbetween 0 and 1, such as 0.83, and it informs the drivers on the constraints of the deformation bones to turn off and allow the deformation bones to copy the transforms of the FK bones.
This system is essentially a set of clever drivers and keyframe interpolations. The Kinematic Tool provides operators to help you manage all of this and it's all covered in the IK Ranges section and throughout the user manual.
Arriving at this system was the result of a lot of banging my head against the wall (figuratively, of course), questioning the foundations I had learned, testing countless approaches (darn you "Child Of" constraint, you're a bewildering nuisance! Gone with you!), and turning over almost any stone I could think to turn over. I just want to thank every one of you who, over the past year, have provided input on your experience using the tool. Thank you! I think the journey was worth it because there's clearly a need for a better workflow with kinematic mode switching. I listened to my gut, which was telling me that animating was becoming quite a chore because the kinematic switching experience (despite it being obviously useful) was too technical, too slow, and too frustrating to provide a comfortable workspace for endless experimenting and animating. I hope you get a lot of value out of using the Kinematic Tool and that it truly does speed up your animation workflow :) Let's get animating!!! Let's goooooooooooooooo!