Depsgraph - Pose Component Graph Building Example

This is a just quick update with a scanned diagram showing the steps involved in building the depsgraph nodes for pose evaluation (and ensuring that this setup has dependencies hooked up correctly to enforce evaluation order constraints for the scheduler).

In this diagram:

• Boxes represent component nodes - i.e. Containers of operation nodes, which correspond to entities/evaluation results
• Ovals represent operation nodes - i.e. Callbacks which will get queued up to be executed by the scheduler to execute various dependencies)
• Black Arrows represent data linkages - i.e. Component A contains Operation B
• Solid Red Arrows represent old/existing relationships within this component
• Open Red Arrows represent incoming/outgoing relationships to other components (not represented here)
• Solid Green Arrows represent relationships which were newly created during this step, and used to describe some evaluation-order-dependency)
• Open Green Arrows represent relationships which were newly created during this step too, but are used instead to just absolutely enforce that some operation must follow another. They probably aren't really needed, but are added for extra security (though perhaps we can cut these for efficiency concerns later...)

Hopefully this provides a bit of a taste for what exactly needs to go on when building the graphs.

Some additional notes:

• The link re-routing steps are needed to ensure that evaluation orders are accurately represented and handled by the scheduler. In this example, this step is most critical when dealing with the handling of the IK Solver evaluation step, which must take place sometime after all the bones (whose results it depends on) have been evaluated, but before other bones which depend on it have been handled.
• To make it easy to query relationships between various pieces of data later, it may be necessary for components to hang on to the links to the relationships which used start/end from them, even though those relationships don't actually point to them anymore. For instance, if some object was parented to bones 1 or 2, we could then still be able to resolve which of the bones it was actually dependent on (even though, for evaluation-scheduling purposes, we had to redirect that link to start from the IK Solver)
• Constraint stacks are currently represented as a single node for simplicity of handling. Eventually, with node-based constraints we'll need to explode out the stack, and make it so that the nodetree is really used as a front-end for allowing users to directly wire up these sorts of graphs (perhaps with one or two core or mundane/necessary operations still abstracted away and added automatically as needed). See notes on Transform Stack component graph.

~~~~

With an impending paper deadline in a few weeks, Blender-hacking time has nearly completely dried up at the moment. Unfortunately, it's looking increasingly likely that I probably won't get around to doing any further major work on depsgraph stuff again until late November/December, when the current set of paper-submission and admin commitments for my research work have all been attended to.