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 < [email protected]> 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<[email protected]> 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 [email protected] 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<[email protected]> > >>> 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 [email protected] > www.blender.org > >>>> Blender Institute Entrepotdok 57A 1018AD Amsterdam The > >>>> Netherlands > >>>> > >>>> _______________________________________________ > >>>> Bf-committers mailing list > >>>> [email protected] > >>>> http://lists.blender.org/mailman/listinfo/bf-committers > >>> _______________________________________________ > >>> Bf-committers mailing list > >>> [email protected] > >>> http://lists.blender.org/mailman/listinfo/bf-committers > >>> > >> _______________________________________________ > >> Bf-committers mailing list > >> [email protected] > >> http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
