[Bf-committers] Depsgraph proposal

[Nathan Vegdahl]

> 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