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

[Nathan Vegdahl]

Okay, I've had a chance to go through the proposal more carefully now.
 It still looks good, but I have a few questions/comments:

First, regarding this:
> Inner nodes are used to actually keep track of relationships
> on a fine-enough scale that most pseudo-cyclic situations
> won't show up as such. To be precise, the set of inner nodes
> (i.e. all the nodes on the right hand side of the diagram)
> defines the full set of evaluation steps that can be
> performed/executed in the scene in response to tagged
> changes. Each individual atomic node here is an evaluation
> step that doesn't really contain any others.

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)?

Second:
> A second example here is for handling/hosting animation
> evaluation for “character + props”, where it'd be nice to
> be able to include the props in the same action as the
> character animation[...]

I just want to make sure we're on the same page here.  My hope for the
future of the animation system is that actions can be used to hold any
related animation data.  So this isn't just characters+props (although
that is a major use-case), but it's also cases like
lights+scene-background-color.  I would absolutely love to see a way
to group objects for animation purposes (even just using object groups
for the purpose, perhaps), as that would cover probably 95% of
use-cases.  But as you yourself noted in the current paper:

> Experience so far says that everytime you go, “Bah! Users
> won't need that '1%' case for flexibility and crazy setups”, the
> day you release your system, it is exactly that '1%' case that
> turns out to be either the blocking-link or the thing they really
> need or end up trying to use (often as the first thought/priority!).

Ultimately, I think your original proposal for the animation system
way back in 2008 or so was really good.  The idea being that actions
would work in concert with the scene hierarchy.  So an action on an
object could contain animation for its material.  And an action on a
scene could contain animation for its objects, and those object's
materials, etc.  If I recall correctly (and I may not), the current
system is already set up that way to a certain extent, but there are
just certain cases that aren't evaluated properly.  If we make those
cases evaluate properly, then down the line we can maybe start
implementing tools to allow the user to tap into that power.

Finally, and this is actually for Brecht:

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

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

--Nathan


On Thu, Jul 4, 2013 at 11:31 AM, Nathan Vegdahl <nathanvegdahl at gmail.com> wrote:
> Hi Joshua,
> I've only had a chance to skim over the document (I'm currently at a
> conference), but so far it looks like an excellent plan!
>
> I'll likely have more say in a day or two when I have the chance to
> read the paper in more detail.
>
> Thanks for your efforts!  Of all the GSOC projects, this is easily the
> one I am most excited about. :-)
>
> --Nathan
>
> On Thu, Jul 4, 2013 at 8:28 AM, 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.
>>
>> Cheers,
>> Joshua
>>
>>
>> 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
>> http://lists.blender.org/mailman/listinfo/bf-animsys
>>