[Bf-committers] Dependency graph design doc (updates, caches, overrides, duplicates)

[Joshua Leung]

Hi Sergey,

I'm not sure whether it's better to reply here on or on the blog post, but
it's probably better here as the blog comments aren't that great for longer
discussions. :)

First of all, I'm happy to see that we're going to be storing the
evaluation data with the depsgraph nodes! This was one of the trickier
things I'd been grappling with when trying to figure out the new
architecture; combining them (more or less) solves quite a few tricky
things you'd run into otherwise.


And now for the concerns/questions I have about this proposal:
1) You say that the UI/tools will work on the File DNA, but that things
like animation/drivers will operate on the Generated DNA. This poses a
little problem: animation/drivers need to be applied to the DNA-data that
the UI/tools see and work with, as that affects what you have to work
with.  Could you clarify how you envisage this will work?

-----

2) Regarding the need for each layer to only be in one time at once, there
are two cases where it's not clear how this would fit in with what you've
got:
    A.  Sequencer Evaluation ("Scene Strips" in particular) -  The
sequencer is probably another whole project in and of itself, but assuming
for now that we're still going to be able to have scene strips which
instance a scene, how do you envisage this will work with this
architecture?  Will the Scene strip effectively create a copy of the
Depsgraph+Generated DNA data, and run its calculations on that copy, thus
bypassing any conflicts?
    B.  Motion Path/Ghosting Calculations - Ideally, we'd be able to run
these things on background threads, so, again, is the intention here that
there is going to be a copy of the Depsgraph+Generated DNA data that these
calculations use?  Also, it's very likely that you'd probably want to be
able to "prune" the depsgraph a bit so that only the stuff we'll actually
need will get updated (or maybe this already goes fine by tagging just the
appropriate result nodes?)

------

3) To be honest, I'm still not totally convinced about the sanity of
keeping the datablocks as the "base unit" for evaluation data, and then
thinking about ways to compress that. Specifically, many datablocks are
just plain fat, heavy, and bloated right now to really want more than one
copy of them floating around.

    - For example, a lot of the time, with duplicates we may only be
overriding/changing the transform info (i.e. a few float properties -> 2-3
4x4 matrices) but if your base unit is the for example the Object datablock
or the bPoseChannel, then you have a lot of extra fluff/junk/garbage for
all kinds of other stuff (e.g. multiple inlined flags, buffers, strings,
nested structs, etc.) that's also carted around in memory. It seems natural
to me to just create a struct containing just transform properties +
matrices, and just use that struct instead of the original DNA datablocks
anytime you want to do anything with transforms. (e.g. you could attach
this to the transform components, and then pass it through all the
transform stack/constraint stack evaluation functions). Also, there's
little/no conflict between this and "everything nodes" AFAIK.

    - Another example is geometry evaluation. Realistically, you really
just want something like a container for the DerivedMesh/Geom + CustomData
buffers. You don't really need very much of the rest (or at most, just some
back-references to the source data)

Then again, since you'll likely be doing the bulk of this work, the final
call is yours ;)   I'm curious to see how this all pans out in the end,
hehe :)


------


Regards,
Joshua




On Sat, Dec 24, 2016 at 5:25 AM, Ton Roosendaal <ton at blender.org> wrote:

> Hi all,
>
> Sergey Sharybin finished the design doc for his work on the "depsgraph".
> Check it out here:
>
> https://code.blender.org/2016/12/dependency-graph-proposal/
>
> It's an important project, essential to do right and it will lead to a lot
> of useful improvements in the coming years. A good reason to carefully read
> or review.
>
> Laters,
>
> -Ton-
>
> --------------------------------------------------------
> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>