> Nathan perhaps we could have an option to switch from 'auto cycle> detect' to > manual number of cycle selection?
If we decide to go the "detect + eval x times" route, perhaps that would be good. But I'm questioning whether going that route is a good idea in the first place. So let's tackle that first. To reiterate (perhaps more succinctly): 1. This is not a real solution to the granularity issue, per se. The proposed depgraph system still lacks fine granularity, and this is an ad-hoc work-around for some of the implications of that. And maybe that's totally fine! But let's not pretend that this is a real fine-grained depgraph solution, please? 2. How will Blender distinguish between true cycles (e.g. that should be reported to the user) vs false "cycles" that are resolved with this ad-hoc system? 3. Performance issues? Integration with simulation, multi-threading, etc.? Tom, your suggestion also brings up the whole "Just Works(tm)" question. How much are we going to expect the user to understand this ad-hoc situation and intervene, vs how much will it "Just Work(tm)"? --Nathan On Fri, Dec 23, 2011 at 1:04 AM, Tom M <[email protected]> wrote: > On Thu, Dec 22, 2011 at 11:49 PM, Nathan Vegdahl <[email protected]> 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? > > Nathan perhaps we could have an option to switch from 'auto cycle > detect' to manual number of cycle selection? > > LetterRip > _______________________________________________ > 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
