[Bf-committers] Design considerations for data handling in the depsgraph

[Joshua Leung]

Hi Fazekas,

I was going to write up a post about this but didn't get time yet.

Basically, this gets solved by having dedicated nodes in the depsgraph for
representing timestamps that nodes should be evaluated at. This means that
instead of time being an implicit concept, where the whole db is "supposed"
to represent the necessary state on the current frame (but this doesn't
happen in practice as anything requiring stuff at different times ends up
going out and manually recalculating a bunch of stuff for another
timestamp, doing its business, then recalculating all that stuff again to
put it back in the original state), time ends up being treated like any
other type of dependency affecting how stuff gets evaluated:

- The "current frame" becomes a time source node too, instead of something
that gets handled using some parallel system of flags and checks. It is
attached to the root node as the primary time source. Changing frame then
simply becomesca matter of: tag the timesource as having changed, then
treat evaluate the graph as you always do (i.e. evaluating anything that's
tagged, and anything that touches)

- For something like time offset (aka dupliframes - maybe a poor example as
other stuff also needs to happen there - or poor man's secondary motion),
you'll have another time sorce node for the magnitude of this offset (i.e.
-2 frames or -5 substeps), which depends on the primary, and which a bunch
of nodes directly depend on. Only the nodes which depend on these (and
whatever else needs to be evaluated in between to make this happen) will
need to be duplicated. For example, if only the transforms matter, only
those from the transform components get included unless some deformed
geometry is used to affect some other transforms which fedd back in.  These
duplicated nodes will reside either within the same main graph, or dumped
into a subgraph; I'm not sure which is better yet but what is clear is that
the two sets of nodes need to work on separate copies of the transient data!

Hopefully this paints the basic picture. Apologies for the typos (I pecked
this out on my tablet quickly ;)

Regards,
Joshua
On 18/06/2014 7:25 AM, "Fazekas László" <mneko at freemail.hu> wrote:

> Just from outside, but I'd like to ask this:
>
> today I met something interesting in the bugs section. There was a
> calculation to get one object's derivedmesh on a sub-frame time position
> between two frames. The goal was to calculate this fast, without
> involving independent objects of the scene. Calculating a random time
> point is not easy because of the "current frame" concept...
>
> Let's imagine I'm calculating something for the current frame, but
> during this, some nodes on the depsgraph needs data from different
> timeline points.
>
> How the new depsgraph solves this situation? With a "child" depsgraph?
> What parts are shared? What happens if different nodes access the same
> time point? How to minimize calculation time and memory size?
>
> I hope these are useful questions somehow.
> Laszlo Fazekas
>
>
> 2014-06-17 18:06 keltezéssel, Lukas Tönne írta:
> > As requested during last sunday meeting, here is a wiki page with
> thoughts
> > on how to handle data with the depsgraph:
> >
> > http://wiki.blender.org/index.php/User:Phonybone/Depsgraph
> >
> > Discussion would be appreciated. The dependency graph will affect every
> > area of Blender so we better do this right!
> >
> > Regards,
> > Lukas
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> >
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>