[Bf-committers] Depsgraph proposal

[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