More Dependency Graph Tricks

The new dependency graph enables several corner cases that were not possible in the old system, In part by making evaluation finer grained – and in part by enabling driving from new datablocks. A nice image to illustrate this is the data block popup in the driver editor:

In the previous image, the highlighted menu item is the only option that is guaranteed to update in current Blender. While testing and development is still very much a work in progress, the future is that all or most of those menu items would become valid driver targets. I’m in progress of testing and submitting to Sergey examples of what works and what doesn’t – this is going to be a moving target until the refactor is complete.

The two examples in this post are based on some of the new working features:

Driving from (shape) key blocks leads to amazing rigging workflow

That weird little icon in the menu above with a cube and key on it that just says ‘Key’ is the shapekey datablock, that stores all the shapekeys in a mesh. And here’s the insanity: you can now use a shapekey to drive something else? Why the heck is that cool, you ask? Well, for starters, it makes setting up correction shapes really, really easy.

Correction shapes here means those extra shapes one makes to make the combination of two other shapes palatable. For instance, if you combine the ‘smile’ and ‘open’ shapes for Proog’s mouth, you get a weird thing that looks almost like a laugh, but not quite, and distorts some of the vertices in an unphysical way. The typical solution is to create a third shape ‘smile+open’ that tweaks those errors and perfects the laughing shape. The great thing about the new depsgraph, is you can drive this shape directly from the other two effectively making a ‘smart’ mesh that behaves well regardless of how it is rigged. If you are curious about this, check out the workflow video below:

Finer Granularity Dependency Graph Tricks

The finer granularity of the Dependency graph lets us work around potential dependency cycles that would trip up the old object based system and make usable rig setups. Once such setup is at least sometimes called the ‘Dorito Method’ for reasons I have not been able to discern.
The goal of the setup is to deform the mesh using shapekeys, and then further enable small tweaks with deforming controls – an armature. The trick is, to make these controls ‘ride’ with the mesh + shapekeys, effectively a cycle (mesh->bone->mesh) but not really, because the first ‘mesh’ in that sequence is only deformed with shapekeys.
The trick to fix the above cycle is to duplicate the meshes: (mesh1->bone->mesh2) where mesh1 has the shapekeys and mesh2 is deformed by the bone. The sneaky bit is that both mesh objects are linked meshes, so they share the shapekey block.
The problem with blender before the dependency refactor, is that everything works *except* driving the shapes and the deforms from the same armature. This was due to the object only limitation of the dependency graph. Now that we have finer granularity (at least in the depsgraph_refactor branch) this problem is completely solved!

Since this is a tricky method, I’ve got some more documentation about it after the jump

1. The above image is an exploded view; in the blend, all three objects (the rig and the two meshes) would be in the same location.
2. The two meshes are linked-data objects. They share the same shapekeys, hence the same shapkey drivers.
3. The bone on the right has a custom property that drives the shapekeys, deforming both meshes.
4. The larger green bone and the square-shaped bone deform the topmost mesh via an armature deform
5. The lower green bone copies the location of a vertex in the original mesh (child-of would be even more forgiving) This is not a cycle since the lower mesh is not deformed by the armature.
6. The visible red control is a child of that bone
7. The larger green bone (the deformer) has a local copy location to the visible red control

This could be simplified somewhat by adding a child of constraint directly to the controller (targeting the original mesh shapekey) but I prefer not to constrain animator controls.
If you were to attempt this in 2.73 or the upcoming 2.74 it would fail to update reliably unless you split out the bone that drives the shapekey into its own armature object. This has to do with the course-grained dependency graph in 2.74, which only looks at entire objects. The downside (and the upside of the dependency graph) is that you would end up with two actions for animating your character instead of one (bleh) or you might have difficulties with proxies and linked groups.
Some reference links below:

• Old Softimage blog post
• Dorito workflow in Softimage vs. Maya
• Dorito workflow in Cinema4D
• Dorito in Blender 2.7x (this one uses a warp deformer but the principle is the same) – .blend here

Further thoughts

If we had some kind of hypothetical “Everything Nodes” we could implement this kind of setup without duplicating the mesh, indeed, without having redundant parent and child bones – the 3D setup would be quite simple, and the node setup would be less hackish and more clear about why this is not a dependency. I’ve made a hypothetical ‘everything nodes’ setup below, to illustrate what the dependencies actually are. In a real system, it’s quite likely you’d represent this with two node trees, one for the rig object, and one for the actual mesh deformation.