in order to use the new nodes to connect path items with each other, the items need a set of new functions:
- createNode – to create a new node (the item has to store it, analog to the config window)
- ‘callback’-functions that get notified whenever a connection to a certain input/output connector is made
additionally, nodes need to be able to display certain UI elements within.
data types
input/output data types will each get a color assigned to them, with white being ‘undetermined’.
White connectors will allow any data type to be connected to them, Â forcing other white connectors to only accept the first data type connected.
e.g. if an ‘add’ node has two inputs and one output, all three connectors are white.
if a 4d vector (red) is connected to the first input, the remaining two connectors turn red, indicating that no data type other than a 4d vector (or compatible types) can be added to the first one and that the result will again be a 4d vector.
This concept can be expanded by allowing compatible types to be connected as well.
int and double are allowed types for addition, so the data type of the first input connector would determine the output type and the way the operation is performed.
saving and loading a node system
the node system is managed by its container, the scene (or a class derived from it).
That class has a save(), load() and postLoad() method in order to save the node graph and restore it.
Saving
the number of nodes are saved, the for each node, its save function is called right after three basic properties are stored in the stream:
the node id, the node type and the id of the node’s parent object (if there is one, else -1 is stored).
loading
the three properties are read back from the stream prior to creating the new node.
Depending on the type of the node, it is either created locally (i.e. ‘add’ or ‘subtract’ nodes) or remotely by calling the createNode() method of the node’s parent path item (‘object’, ‘action’ or ‘trigger’ nodes).
then, after the node has been created, its load() function is called.
post-loading
like with path-items before, post-loading is used to de-swizzle pointers. Parent path item IDs are resolved into pointers, outgoing connections are restored by resolving node ids to node pointers, then creating a connection between the output connector and the input connector(s) of the remote node id.
in order to speed up rendering a bit, check whether it’s possible not to use a depth sampler during gui caching. It’s all drawn in RHW, so depth test is unnecessary anyway. Having to prepare and swap depth samplers multiple times during rendering might cause significant slowdowns.
also, each connector needs a vector of compatible data types:
consider a MUL node, with a matrix connected to the first input.
The second input now has several valid data types, all of which are incompatible: int, vector, matrix.
therefore, these three (int could also be replaced by double, float, etc.) types would have to be pushed into a vector for acceptance testing.
links:
http://www.sgtconker.com/2010/09/article-node-based-scripting/
http://architosh.com/wordpress/wp-content/uploads/2009/12/cheetah3d5screen1.png