> 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
