Consistency through Usability
The current functionality of the Dependency Graph within Blender, is to evaluate an Armature in whole rather than each Bone within the scene.
Although, this works effectively for simpler rigs when utilizing IK Splines (within a rig setup) this system can become somewhat more tedious and less forgiving.
It can be argued that usability should subsequently become a more important consideration, when dealing with greater scene complexity. Learning a new system while creating a complex setup could in many ways contradict the principles of good usability. Of course, expectations of the user are always a contestable topic in scenarios such as this but in this particular case we already have an existing database of knowledge sources to draw from.
Abstraction of Low-Level Complexities
Blender like many high-end 3D packages possibly takes into consideration existing cognitive human to computer, habitual interactions when implementing features that propagate to the end user.
After all, there is no need to re-invent the wheel particularly when the outcome of the interaction is not isolated in it’s scope of application.
However, the lack of finer granularity within the DepsGraph results in the absence of each bone, that constitutes an Armature, having its own node for individual evaluation at runtime, which is fine… but the limitations of this system often become exposed to animators when existing transitional-knowledge (from other 3D applications) contradicts how complex relationships of a similar type in Blender are correctly setup.
Lets take into consideration one of the most obvious artifacts resulting from this functionality which can be seen through the Outliner. To be clear, however the Outliner is not a visualization of the DepsGraph but is nonetheless pretty much as close as you’d ever want an animator to get to that. Notwithstanding Aligorith’s proposal for a Rigging Dashboard, which would be far more ideal. However, before there is a possibility of implementing such a feature, consideration of how a user visualizes an animation rig needs to be addressed. A simple IK Spline setup as demonstrated in this file can subsequently result in 3 Armatures populating the scene. This kind of visualization might not intuitively represent what an animator expects or wants. So before visualization of the scene occurs lets have a look at why 3 armatures are necessitated.
Dependency Cycles Are More Likely To Occur In Complex Rigs
There will invariably be more benefits for an animator that has the ability to transform multiple bones with a single controller associated with multiple complex relationships as opposed to the conventions of a direct acyclic graph relationship. Setting up an IK Spline with intuitive controls in Blender, attributes this sentiment.
The unfortunate side-effect of the conventional approach is that having a bone being controlled by another object which has dependencies on another bone within the original armature will likely result in a dependency cycle, and evaluation will be terminated unexpectedly. In order to rectify this multiple armatures can be constructed with the aforementioned dependencies. However, visualizing this setup in the Outliner does not clearly represent the relationships between the different Armatures let alone their relationship to the character they are controlling. Furthermore, the need to expose the complexity of this relationship to an animator, could also be unnecessary.
Abstracting the complexity of a character including it’s geometry, rig, transform and animation data under a single node within the scene’s hierarchy (certainly by means of the Outliner) has the obvious benefit of maintaining a cleaner scene structure. Having a node for each bone within the DepsGraph could lead to a more intuitive approach for rigging a character particularly for those transitioning from other 3D packages, as this would address the dependency cycle issue.
In conclusion here are some examples of how a rig with a dependency cycle will not evaluate as expected. The image on the right has been forced to update resulting in the transforms on the bones to match the animators expectations, however the image on the left depicts what occurs at runtime. As the scene is re-evaluated when a transform is invoked the bones are forced to move to their expected positions, subsequently the keyframe data cannot be corrected by conventional means.
Of course, these issues can be avoided if the user is aware of how Blender addresses more complex dependencies utilizing an IK Spline controller, the problem however is that this approach contradicts the premises on which good usability is based on.