[Bf-committers] [Bf-blender-cvs] [6876c3b] depsgraph_refactor: Depsgraph: Playback doesn't crash now

[Joshua Leung]

On Thu, Nov 6, 2014 at 11:39 PM, Sergey Sharybin <noreply at git.blender.org>
wrote:

>
> This raises some questions:
>
> - Who don't we have Scene ID node in the graph so far?
>

As a counterpoint: Why *should* we have a Scene ID node for exactly? Sure,
eventually we might need one for some things, but as a starting point, it
should be noted that we're currently using such a "scene" node as a general
catchall (for global-stuff that should happen outside object eval but which
we don't know where to put) when really, there are several different things
going on there:

1) Root Node == The current/active scene; the one which the evaluation
stuff gets called from.

2) Sequencer scene strip stuff - Sequencer scene strip handing is probably
needs to feed into this somehow (each scene strip = one subgraph?)

3) Sound System - The sound system stuff should end up being its own
operation

4) Evaluate all animation in file - Each ID's AnimData goes to it's own
operation node (and dependent on time source). As for evaluating the
animation on the scene datablock itself - that gets handled as for any
other ID, and indeed will eventually need some form of Scene ID node to
handle

5) Rigidbody Sim - As operation node interleaved with the rest of the
object transform+geom node evaluations

6) LOD - Similar to Rigidbody and Sound

7) Compositing - Umm... what exactly would this need to do?



> - Do we really need a time as an operation node, or it's something
>   more up to the EvaluationContext.
>
> Time ABSOLUTELY MUST BE an operation-like node (even if said node doesn't
really perform any operation in practice):
1) The current (master) implementation of having time dependencies as being
an implicit/pseudo-dependency thing that gets represented via flags and/or
a set of completely parallel checks and handling operations
throw-it-in-the-canal sucks. Having an explicit time node means when
changing frame, we just tag the time node, and propagate updates normally.

2) Time and time again, we have users begging, moaning, and banging their
heads on their desks about wanting to do time-delayed stuff. Things like
doing slow parenting, or grabbing the position of some object/bone 5 frames
ago, and stuff like that. With time nodes - and yes, there can be more than
one (i.e. the primary/absolute timesource attached to the Root Node, then
some secondary ones for the time delays), such requirements get explicitly
handled.



> Later one raises the bigger design question: what should we try to
> do with the depsgraph and what is we're gonna to solve with the
> evaluation context?
>
> The answer here should be: everything which describes the (sub)graph
> state should be in the evaluation context. This way this context will
> finally become some key which totally corresponds to the (sub)scene
> state.
>

Ok, I agree that state should be in the context, while the graph describes
the sequence of operations (which pull data from the context to do their
work, and write their outputs back to the context).

See the following for more thoughts on how this breakdown should work +
diagrams of how these graphs fit together:
https://drive.google.com/file/d/0B6MoRLgRcIqabXBHaVl0ZXpFbDA/view?usp=sharing


>
> ===================================================================
>