March 12, 2014, 13:39 (GMT) |
Renaming graph->root to graph->root_node, as used in graph building code |
March 12, 2014, 13:39 (GMT) |
Increasing whitespace |
March 12, 2014, 13:39 (GMT) |
Add a hashtable on depsgraph (just like in trunk) for quickly finding node for ID |
March 12, 2014, 13:39 (GMT) |
Jotting down more logic for finding nodes... * ID Nodes * Data nodes within ID nodes |
March 12, 2014, 13:39 (GMT) |
Start of node search code... This is all still quite crude, and eventually, we may just move all this to be the lowest level of the querying API... |
March 12, 2014, 13:39 (GMT) |
Define a few more node type register calls |
March 12, 2014, 13:39 (GMT) |
Added comment detailing current decision to use hash vs array for typeinfo registry |
March 12, 2014, 13:39 (GMT) |
Node types registry - Use a GHash for now This makes it easy when dealing with the types, which can now have arbitrary codes given to them, instead of having to be tightly packed. However, this may turn out to be overkill, since we only really have a few core node types, so using an array may prove to be a better strategy overall... |
March 12, 2014, 13:39 (GMT) |
New node adding code fleshed out to use typeinfo |
March 12, 2014, 13:39 (GMT) |
Added another callback in typeinfo for handling outer-node queries |
March 12, 2014, 13:39 (GMT) |
Start of node typeinfo handling * All (core) nodetype defines will now be in depsgraph_type_defines.c * Made a few tweaks to make the API's nicer * Still need to figure out how to define the rest |
March 12, 2014, 13:39 (GMT) |
Defining typeinfo for core node types, and a little API to work with these |
March 12, 2014, 13:39 (GMT) |
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. |
March 12, 2014, 13:39 (GMT) |
Draft stub for creating a group node (as necessary) during graph building |
March 12, 2014, 13:39 (GMT) |
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? |
March 12, 2014, 13:39 (GMT) |
First skeletal draft of the internal node management functions * DEG_get_node() is fully fleshed out * DEG_add_node() and DEG_find_node() still need to be figured out... |
March 12, 2014, 13:39 (GMT) |
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. |
March 12, 2014, 13:39 (GMT) |
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) |
March 12, 2014, 13:39 (GMT) |
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... |
March 12, 2014, 13:39 (GMT) |
Noted potential problem with the way we're trying to build depsgraph nodes |
|
|
|


Master Commits
MiikaH:n Sivut a.k.a. MiikaHweb | 2003-2021