Blender Git Loki

Renamed "DatablockDepsNode" to "IDDepsNode"

While the former was perhaps more descriptive (and looks slightly better),
it also feels like too much of a mouthful to use, besides not really
being that clear that it wraps an ID datablock.

Change argument types for low-level node management functions

Apparently it is not possible to simply pass on the list of arbitrary
arguments down the chain that easily (where the list grows and shrinks
according to the needs of the specific API used). So instead, always use
the full version.

Alternative here is to just have separate copies for each case?

Added a new header for "internal" depsgraph API functions

These are mainly functions which can be used internally within the
Depsgraph, and/or are exported between various parts of the internals
but which shouldn't really be exposed to the outside world (i.e. other
parts of Blender outside of the depsgraph module).

Will review later whether this file is really needed or whether it can
be folded into some of the other headers)

Code reshuffling + "Root to Active" relationship type (for previous commit)

Renaming "data" mid-level outer node type

Having "MID" in the name was a bit dodgy from an API standpoint in the
long run, even if that would have made things a bit clearer as to where
it stands between the levels.

Fleshing out some more depsgraph building functions (skeleton for objects)

Noted potential problem with the way we're trying to build depsgraph nodes

Replace all DAG_add_node() calls with DAG_get_node() calls in the graph building

This is needed so that nodes that others depend on can get added ahead of
time...

Fix for incorrect comment

Experimental fleshing out of scene building step

* Blocked out a few more steps for doing this
* Started experimenting with some of the basic API calls for the core
operations here (to get a feel for the way this works, and for adjustment
to fit better)

Add flag to allow for the possibility of having a dynamically allocated name for nodes

The purpose of this flag is just to make sure we have a way of ensuring that
we don't have any memory leaks from unfreed heap names...

Completing up the trio of outer node types - "Interblock" type now defined too

Base node type now has a name identifier

This will mainly be used/useful when printing out nodes for debugging
purposes. The name will thus provide us with a way of easily identifying
nodes without having to resort to weird hacks to grab the relevant name...

Fleshing out Group Node, ID Node + A mid-level "data" node

* The "data" nodes are mid-level, and intended to sit between ID/Group
"outer" nodes (i.e. optimisation and grouping nodes) and "inner nodes"
to make it easier to query for stuff like bone-deps. They are only used
since we'd be creating them in the meantime anyways.

Then again, these may still go away later, if this just makes things too
hard...

* TODO: some avenue for "dependency injection" within groups is needed
for things like IK Trees being built with different sizes...

Start of experimental code for building depsgraph

Currently there's nothing here except for some includes and an entrypoint
for the building process, starting from scene. Aim here is to start working
on implementing this stuff to clarify a bit design issues of main API and
datatypes, as any difficulties encountered during this process will end up
revealing problem areas in the design (as well as giving us a more solid
technical grounding when looking at things)

Added some commnets to clarify the role of some of the relationship types

Add defines for "time source"

Time source node + time source relationships are used to indicate
things which should be changed when frame changes (e.g. animation
needs to be run, certain modifiers should be updated, etc.)

Rename "nodedata" members to "nd" (as per modifiers, for less typing)

Placeholder stubs in file for core depsgraph stuff

First attempt at a datatype to represent relationships (i.e. node links)

* We need a way of sharing relations between the nodes which use it. The
current design assumes that one link is shared between the two nodes
which use it. Saves mem but induces higher traversal cost?
* The relationship types enum is used to provide additional metadata about
a link, specifically, if the type of data we're interested in reside there