[Bf-committers] Depsgraph proposal

[Ton Roosendaal]

Hi Nathan,

We can for sure check on inserting bones as nodes in depsgraphs,  
especially for a mixed object/bone graph. Even nicer; a group  
(instance) can have a 'flattened' despgraph too (all bones and objects  
in 1 tree). These cases are probably solvable well.

We should ensure that rigs you want to make are possible and solvable  
in general. But at some moment you hit a wall where blender's design  
won't cooperate anymore, we then have to be practical too. That's why  
I like to try to stick to ID levels first.

If a system is well threaded, having an occasional cycle solve (like  
2% of total data) is very acceptable. That's the thing we can try to  
balance.

And last but not least: I propose to implement a depsgraph system  
that's invisible for riggers or animators. It won't change the  
animation system or ways you set up rigs (apart from that you get less  
cyclic conflicts). It is just meant to work! And if that means we have  
to revise depsgraph specs to make it work, so be it too.

-Ton-

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

On 23 Dec, 2011, at 9:49, Nathan Vegdahl wrote:

>> For sake of simplicity I would consider to have despgraph
>> nodes be ID blocks only. It might give limitations (object ->
>> bone -> object deps), but having each ID be calculated as
>> black box has a lot of benefits with current architecture of
>> Blender data. Granularity can also be achieved by
>> cycle-solvers (detect the cycle exceptions and just call these  
>> twice).
>
> Or thrice, or four times, or five times...?  What about object -> bone
> -> object -> bone -> object?  Or even within the same object: loc x ->
> rot z -> scale y?
>
> Maybe in practice these situations may not come up much, or can be
> painlessly worked around by the user?  But it's hard to know ahead of
> time.
>
> What if we have a character that's crawling over the head of a big
> multi-tentacled monster, and the monster is trying peel him off with
> its tentacles?  And say these tentacles are done with spline IK.  Then
> that's monster_bone -> character_bone -> monster_bone ->
> spline_ik_curve -> monster_bone.  You'd have to re-execute the
> monster's armature rig three times.  And say it's a complex armature
> rig?  That could be a significant performance hit.  Unless you only
> refresh the parts of the rig that are affected... but with that level
> of sophistication you're basically making a fine-grained depgraph
> anyway.
>
> In any case, even if we say this limitation is acceptable (arguably my
> above example is a corner-case that can be worked around; even with
> the finest-grain dependencies there are still issues like that which
> can pop up), let's at least not pretend that "detect cycle + call x
> times" is a real solution to granularity issues.  Blender will still
> have a granularity issues with it's dependencies, it will just be
> pushed x levels down (at a performance cost of x).
>
> Also, how do we then distinguish between "cycles" that are solved with
> multiple calls, vs real cycles that aren't?  It's important to detect
> the latter so that users can e.g. debug their rigs.
>
> (I also wonder how "detect cycle + call x times" would impact
> straight-forward multi-threading implementation? Though I am by no
> means knowledgeable about that.)
>
> --Nathan
>
>
> On Mon, Dec 19, 2011 at 8:11 AM, Ton Roosendaal <ton at blender.org>  
> wrote:
>> Hi all,
>>
>> Here's a proposal for how to split the depsgraph work in parts;
>> hopefully it helps getting this project running that way. There's  
>> also
>> a link to an excellent analysis from Joshua!
>>
>> http://wiki.blender.org/index.php/User:Ton/Depsgraph_2012
>>
>> Thanks,
>>
>> -Ton-
>>
>> ------------------------------------------------------------------------
>> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The  
>> Netherlands
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>