[Soc-2013-dev] Weekly Report #8 Depsgraph Refactor

[Joshua Leung]

== This Week ==
I've been porting over the existing depsgraph building code over to
the new system.
 * As of the time of writing, the majority of the existing stuff has
now been ported over and/or converted in some way (more on this in a
sec)
 * Particles and collision are the main parts that still haven't been
defined yet
 * Evaluation stuff for geometry data still needs to be fleshed out/completed.
 * The custom dependency-definition callbacks for modifiers haven't
been touched yet either. Dealing with those though will have to wait
until I start integrating the core engine into Blender's source tree
soon...
 * Where possible, when porting over the old code, I've modernised it
to take advantage of the new expressive powers of the new system. This
is most obvious in the animation/drivers/constraints/bones/parenting
parts, which I'm most familiar with and especially mindful of the
severe limitations that used to exist there in the past.
 * Bones are now represented as subcomponents attached to the "Pose"
component. Note: This has very little impact on the final runtime
granularity of operations (as with all other components); this change
just makes it more convenient for managing/getting the nodes related
to bones. Although this generally works, there are just a few issues
currently when trying to identify operation nodes for bones (since
they both currently use the same "name" parameter in the API's for
doing this mapping). Some tweaks to those API's will be needed before
that can work


== Issues ==
1) I'm not quite sure what to do with a few features in the old system
which only half-worked - namely, proxies and duplis. As a first pass,
I could just try and port them straight across in the same way that
they used to be done, though perhaps avoiding some of the absolute
worst problems...

2) ATTN Sergey - While trying to port the Camera tracker constraint
nodes, I was a bit baffled as to what exactly the "Scene Relation"
relationship at the very end was for. Knowing a bit more about what
that is about will help me figure out whether there's some other stuff
which is needed to support that

3) Functionality not supported by old depsgraph (i.e. stuff like
rigidbody sim links). While I'm aware of some of these things (and
will duly add them in the meantime), we are going to have cases where
there's stuff which couldn't be represented in the past but which can
now be represented (but we don't know about this, since the old graph
didn't have anywhere to note these). More likely than not, we're going
to have to need a fine-tuning phase once I get this thing hooked up to
the rest of Blender where others more knowledeable about certain areas
can go through and check that all hooks that are needed but couldn't
exist in the past are now in place...

4) What to do with the customdata and layer flags that used to get
passed around the place? When do these vary and/or need to vary from
what just gets set once at the start? Will need to investigate more
about this...


== Next Week ==
1) Write up a little "How to Guide" for building graph structure/nodes
used in the Depsgraph, based on what I've been doing so far. This will
just cover things like general style-guide for how to go about
breaking things down into nodes (i.e. when a new component type is
needed, what operations should be, how to go about linking up those
components+operations, etc.)

2) Finish porting over graph building code for unfinished bits + make
a few API changes for problems encountered this week

3) Rigidbody support in the graph

4) Start figuring out how to get the depsgraph to feed nodes to
Sergey's task scheduler. I've started taking a look at how that stuff
worked, but will need to investigate a bit more.