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

Nathan Vegdahl nathanvegdahl at gmail.com
Mon Jul 8 00:49:27 CEST 2013


Hi Brecht,

> 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.

Ah, that's a good point.  In that case, it would be nice to just keep
those situations to a minimum.  But yes, I can see why would need
that.

--Nathan


On Fri, Jul 5, 2013 at 3:34 PM, Brecht Van Lommel
<brechtvanlommel at pandora.be> wrote:
> 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.
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys



More information about the Bf-animsys mailing list