[Bf-committers] Depsgraph proposal

Tobias Oelgarte tobias.oelgarte at googlemail.com
Sat Dec 24 10:58:44 CET 2011


For me this would be the most important things:
* Treat bones like own objects. Currently we have this armature A 
depends on armature B and vice versa problem, even so there isn't a real 
cyclic dependency. This could also fix the delay between bones from the 
same armature connected by drivers. Currently it is treated as a cyclic 
dependency.
* Let an action store the animation for multiple objects at once, not 
just only for armatures.
* Separate drivers from actions. Currently every action must inherit the 
drivers from a "driver action" or they won't be working, since they 
aren't there.
* Give the the editors a tool to view the dependencies. They really like 
to see them to find possible errors, even if it is their own.

Just some thoughts that came quickly to my mind thinking about the 
dependency issues i and others had.

Tobias Oelgarte

Am 24.12.2011 00:57, schrieb Nathan Vegdahl:
>> 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!
> Awesome.  We are in agreement on that point. :-)
>
>> We can for sure check on inserting bones as nodes in depsgraphs,
>> especially for a mixed object/bone graph.
> That may be a good compromise.  Arguably, a lot of the
> hard-to-work-around issues with the current depgraph are due to bones
> not being independent nodes.  I'll think on this some more.
>
>> 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.
> Of course. :-)  I just want to make sure that we know what limitations
> we're imposing on ourselves for the future, and that these limitations
> are acceptable.
>
> --Nathan
>
>
> On Fri, Dec 23, 2011 at 2:59 AM, Ton Roosendaal<ton at blender.org>  wrote:
>> 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
>>>
>> _______________________________________________
>> 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
>



More information about the Bf-committers mailing list