[Bf-animsys] Dependency graph work started

[Bassam Kurdali]

On Thu, 2014-11-06 at 18:56 +0100, Ton Roosendaal wrote:
> Hi all,
> 
> For your interest, here's the doc with planning and analysis by Sergey:
> http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
> 
> (With funny disclaimer :)
> 
> We also received a link to a new doc from Joshua with a design a proposal.
> https://drive.google.com/file/d/0B6MoRLgRcIqabXBHaVl0ZXpFbDA/view?pli=1
> 
> Sergey started working already, a lot of groundwork can be done already without much discussions. We'll make sure Joshua gets closely involved as well. 
> 
> I would really like to see experiemced animators/riggers to carefully check on it and keep involved.
> Reviews and discussions can be held on this list!
> 
Hi all,

First of all this is fantastic, and the work involved looks like it will
'cure' Blender's dependency graph issues for the current capabilities of
Blender, within reason.

My question is whether this makes Blender 'better' than other apps which
require workarounds in special (but really common) cases, or even
enables the really flexible nodes setups for some hypothetical 'Nodal
Blender' design.

What I mean is: if you have a node graph (defined by the user, not the
dependency graph) you should be able to have dependencies based on the
node graphs, not just on datablock level. So you can have a nodetree
influencing a surface shape up to a certain level, that influences other
objects, that in turn influence the surface; in other words, you want to
do a partial evaluation of the graph on object A, then evaluate object
B, then finish evaluating object A.

A real life (classical rigging) example is the so - called Dorrito
method[1] Here, riggers want tweak controls to be 'on the surface' of a
mesh that is deforming (usually via shape-keys). This would be circular
in most dependency graphs, so they create a so-called Dorrito-mesh: a
redundant, non rendered copy of the mesh, that deforms 'up to a point'
and drives the control positions, which in turn drive the 'real' mesh.

Due to blender's issues with proxies and current dependency graph
limitations, this method is only barely possible, and breaks a bit with
proxies and instances. It would be possible (perhaps) with the proposed
update, but it would be great to ditch the second mesh, not do a
workaround at all. 

Future examples might involve using levels of broad deformations - e.g.
skeletal of facial deform - to drive further deformations - e.g.
wrinkles or bulges... etc.[2] 

Cheers,
Bassam

[1]https://drive.google.com/file/d/0B4oFZ9-fK91aaDh5bG9OdUZwWFU/view?usp=sharing
[2]http://urchn.org/blender/granular.svg