[Bf-committers] Depsgraph proposal

Sat Dec 24 18:45:59 CET 2011

Indeed, when i think in DAG problems this is mostly what hits me, I wish
this was solved properly, it's a considerable disadvantage of our "armature
object" aproach

Daniel Salazar

On Sat, Dec 24, 2011 at 3:58 AM, Tobias Oelgarte <
tobias.oelgarte at googlemail.com> wrote:

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