[Bf-committers] Depsgraph proposal

[Nathan Vegdahl]

> 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 <letterrip at gmail.com> wrote:
> On Thu, Dec 22, 2011 at 11:49 PM, Nathan Vegdahl <cessen at cessen.com> 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
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers