[Bf-animsys] Depsgraph Refactor - GSoC2013 System Design Proposal
Brecht Van Lommel
brechtvanlommel at pandora.be
Fri Jul 5 22:07:04 CEST 2013
Looks quite good, some questions:
* What is the purpose of ID Groups?
* Scheduling Nodes for Evaluation: I read this in the libEE paper as
well, but I don't really understand the usefulness of caching the
nodes needed for editing some particular value, this seems like a very
quick operation if the dependency graph is already built. Maybe they
aren't caching the graph at all?
* What is the querying API exactly? Reading this it's not clear to me:
>> Tools should be able to ask the depsgraph questions like: “What objects/datablocks depend on this thing I'm editing?”, or “If I'm updating this piece of data, >> what other objects/drivers/constraints do I need to update to correctly evaluate this?”
Later it mentions that only the outer nodes would be part of the
querying API, but to me it seems like if e.g. an operator edits an
object transform, it should be able to tag just the transform as
modified. Same if you would have e.g. a mesh modifier node, you want
to only tag the node for that modifier. But as I understand it these
are inner nodes?
Not all inner nodes maybe be interesting to be able to query, but it
should be finer then just ID block level I think?
* "Filtering", I don't understand what that means here?
* Maybe more related to proxies, but I think we should make a clear
distinction between groups/objects that are instanced (evaluated at
their original location and duplicated into a new place without any
evaluation, so fast and memory efficient) or proxied (evaluated in
their new place, possibly interacting with other objects there).
On Thu, Jul 4, 2013 at 5:28 PM, Joshua Leung <aligorith at gmail.com> wrote:
> Hi All,
> As many will know, I've been working on figuring out what our new
> dependency graph and evaluation engine needs to look like. Many of the
> people subscribed here probably know what this is (i.e. basically it's
> that annoying backend system that keeps complaining that you've
> created cyclic dependencies yet again ;).
> Anyways, I've attached a document outlining the proposed design/goals
> for this system. Please take a look and provide some feedback about
> whether there's really anything missing/overlooked or likely to cause
> us serious grief in future. Also, feel free to ask if any other
> questions/issues come to mind while having a look.
> BTW: Try to keep this discussion here on the bf-animsys mailing list,
> to avoid clogging up the bf-committers list with discussion on this.
> Bf-animsys mailing list
> Bf-animsys at blender.org
More information about the Bf-animsys