

The main problem with the auto IK system is that it tends to 'lock' the position of individual bones in such as way as to prevent those that aren't part of a direct " Parent » Child" relationship chain from being moved away for their point of origin (point around which a bone rotates) when grabbed (" G"). The movement 'above' a bone on a chain with an IK constraint applied is the result of Auto IK active on the entire armature.

Any bone further down the chain - bones 3 and 4 - will simply rotate around their origin axis, they will have no effect on bones 2 or 1. However, if the IK constraint is placed on " bone 2", moving that will only move " bone 1" because it's directly 'above' it in the chain. However bone 1 < bone 2 < bone 3 < bone 4 If the IK constraint is placed at "bone 4" and that then moved, all the bones along the chain 'above' it (bones 3, 2 and 1) will be effected by the movement. For example bone 1 < bone 2 < bone 3 < bone 4 What this means is that bones will move relative to where the IK constraint is placed in a chain. As a result, Blenders developers implemented an ' Automatic IK' system which, once enabled in " Pose mode" (" Ctrl+Tab"), applies a generalised set of ' Inverse Kinetic' parameters, " IK constraints" to use their proper name, to the Armature based on the hierarchical structure of a skeleton 'child' bones automatically effect a bone directly above itself and on up through the 'chain'. Setting up IK constraints in Blender can be a tricky and often breaks an Armature if not set up correctly in relation to what Blender is wanting to see. Being able to now manually set up bone influences and relationships mean Armatures can now have similar behaviour without the caveats of the restrictions associated with Auto IK Limitations of Automatic IK ^ Because of the way characters for games tend to be rigged using the " Auto IK" system, certain types of Armature set up become problematic because of the restrictions and limitations placed on the rig via the use of the automated rigging system.
