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

[Sergey Sharybin]

Hi,

Answers are inlined.

On Thu, Nov 6, 2014 at 4:27 PM, Joshua Leung <aligorith at gmail.com> 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?
>

That's all valid yes. But the things like background scenes were never
covered in the design docs i aw so far. It _might_ be helpful to have them
in the future. If not -- sure, we'll survive with just a root node.

But still, code should be consistent at least -- it's kinda pointless to
create time source node to a scene id which is not in the graph even. f we
consider root node as a central one, then time input should be added to it
as far as i concerned.


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

I'm all aware of this, but i wouldn't be so much definite here, it's not
"MUST" it's more like "could" or"handy". Allowing this node in any point of
the graph is rather risky without separating data and state. And for as
long stuff was discussed EvaluationContext was aimed to do such a
separation, allowing the same object to be in multiple states. So once you
modify time, you also need to notify (or duplicate?) EvaluationContext, so
it's all aware of such changes.

Now, as for time-dependent features like local dupligroup offset the most
clear way to do it is to have a subgraph for the group with it's own
evaluation context.Something like this would work for slow parent as well
(maybe not as a subgraph node, but as some node iwht own eval_ctx).

It could still be a node to make it simpler for depsgraph, but the thing
here is: evaluation context should be aware of such a time changes.


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


-- 
With best regards, Sergey Sharybin