[Bf-animsys] Depsgraph Refactor - GSoC2013 System Design Proposal

[Brecht Van Lommel]

On Fri, Jul 5, 2013 at 11:18 PM, Nathan Vegdahl <nathanvegdahl at gmail.com> wrote:
> I also read the blog post about this, and the descriptions of inner
> nodes sound more along the lines of data-processing nodes (i.e. each
> node represents an operation of some kind) than data nodes (i.e. each
> node represents an object or piece of data).  Am I correct in this
> inference?  And if so, what is the motivation for the inner nodes
> being data-processing style nodes rather than data nodes (especially
> when the outer nodes are data nodes)?

I think you need to have data processing nodes for cases like inverse
kinematics or physics, where you evaluate multiple pieces of data
simultaneously, after they have already been evaluated on their own.

I don't fully understand the outer/inner node stuff yet. I think
"external" access to the depgraph (query API?) is only interested in
data, a tool indicates they modified some data, or the 3D viewport or
render engine want some data to be evaluated. But they don't care
which data-processing operations are done internally.

> If we can do this in some kind of automatic way (e.g. auto-checking if
> data has any overrides on it, and marking it as a pure instance if it
> doesn't), that would be great.  But if the user has to understand that
> distinction and set it up, I think that would impose a bit too much
> and would clutter what could otherwise be a very elegant and seamless
> experience. Being able to link/instance things, and just override
> properties and data on them, would be a marvellous workflow.  (And, by
> the way, then we could finally ditch the confusing "proxy" term ;-)
> Maybe call it "local overrides".)

I'm not sure if it can be completely automatic, but don't think it
would be a big deal. If you use a local override, then it would
automatically evaluate things in the new place and there's no problem.
However there is also the case where you want to e.g. instance a
particle system. The question is then if it should use the original
baked simulation, or take into account the different gravity,
collision, force fields, in the new location even if you aren't
strictly overriding any property. The same issue exists for modifiers
in general, though it's mostly the physics modifiers where you would
notice this.

By default it can just create a fast instance, and you could then have
some setting to locally evaluate it even if you don't override any
particular property.