[Bf-animsys] Dependency graph work started

[Ton Roosendaal]

Hi Bassam,

The new despgraph should definitely allow revisiting objects or data many times, to have sequential updating for example (like your node example).

The dorito case needs more studying on - having widgets to control shapekeys and deforms (and good options to layer this) is something we need to pay special coding attention to. 

-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



On 6 Nov, 2014, at 21:34, Bassam Kurdali wrote:

> 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
> 
> 
> 
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys