> 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
