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
