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

[Joshua Leung]

== This Week ==
I've been working on implementing the ideas presented in the design
doc earlier. Basically, I've been going through the task breakdown at
the end of that doc and working my way down (with one or two
deviations, which I'll mention in a bit). As things currently stand,
the codebase is still heavily in flux (especially the less well
defined areas), though that's entirely to be expected as we flush out
any issues/impracticalities with the proposed design which may crop
up.

The code is currently available as a self-contained module hosted in a
publicly visible repository [1], which will be merged/committed into
either my GSoC Branch (rebranched from Sergey's) or directly into
Sergey's branch when enough of it has been fleshed out and stable for
that to be practical. (NOTE: I've followed the same basic workflow in
the past for at least 4/5 other sizeable refactors I've done, except
without having any usable version control system for the initial WIP
pre-initial-commit stages when doing those).

Short summary of what's been done:
* Core data-structures have now been defined.
  ** In particular, I've set up generic "node" and "relationship"
types which are detached from whatever way we're currently trying to
model dependencies+evaluation tasks between things in Blender. This
way, at the very worst, if we do need to make any significant pivots
down the track (e.g. the design we're currently trying turns out too
complex or some new feature comes in which requires a rethink), at
least the core/lowlevel depsgraph mechanics of representing and
ensuring that dependencies get handled correctly will still work
without needing another overhaul.
  ** Initial defines for outer+inner nodes system described in doc.

* Started coding/porting code to build depsgraph from scene data -
Originally, I wasn't going to do this until the whole core was fleshed
out (including having ported over all logic for ensuring that graph is
properly traversed/updated/sorted/etc.) However, to keep things from
growing too widely impractical, I've decided to try attacking the
problem from another front too, to validate that our design can
actually be used/coded up as intended.

Parts of system "on hold" for now (as in, not targets for initial
version/release at this stage):
* Querying and Filtering API - I've decided to put this on hold for
now, until I've got at least a basic running system for representing
dependencies in more depth running. Partly this is to give me more
time to figure out exactly what's required, but also, since the exact
contents of the graph are still very much in flux atm, it makes sense
to just delay work on this a little bit longer.
* Dealing with instancing/proxy/duplis problems - These are complex
issues and will be addressed in time. But for now, I've got enough on
my plate as it is to deal with. I'll revisit the state of this in 2-3
weeks time.

== Next Week ==
Current targets (at time of writing are):
1) Continue fleshing out depsgraph building code
2) Start fleshing out logic for the various node types
3) Also start porting over and sanitising some of the low-level depsgraph logic

(ETA for initial compiling/working system at this stage is 2 weeks)

== Links ==
[1] https://github.com/Aligorith/DepsgraphRefactor