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ó" <mn...@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@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers