On Thu, Nov 6, 2014 at 11:39 PM, Sergey Sharybin <[email protected]> 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 > > =================================================================== > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
