HDK
|
When you write your own node, the process depends somewhat on which network type you are writing for. It is necessary to implement the code which performs the operator function utilizing the defined parameters to control it's operation. Usually you will subclass from the root of your network type, such as SOP_Node or DOP_Node. Then depending on the parent class, you need to override the appropriate virtual function to perform operations specific to your node. For example, SOP_Node subclasses should override SOP_Node::cookMySop(). Several examples of custom operators are provided with the toolkit. Detailed documentation can be found in the modules on the main Houdini Operators page.
Architecturally, the cooking architecture is one of the functional programming paradigm. One may think of node cooking as sort of function that evaluates to the same data whenever given the same values. ie. without side effects. Nodes are never cooked unless they are asked for their data. In the normal course of operation, it is normally some UI element (such as the viewport) that observes the nodes whose display flag are enabled. When it is informed that such a node is out of date (aka "dirty"), then the UI element asks the node for its data. Only at that point in time, when the node is asked for its data and itself is out of date, that it recooks. When the node recooks, it will in turn ask for the data of its inputs, which then propagates up the cook chain. If Houdini at any point encounters a node that is up to date, then no further cooking will be done.
While cooking, the user may choose to abort it at any time (usually by hitting the Esc key). It is the custom operator's responsibility to detect such situations and gracefully abort when asked.
To detect such situations, use the global UT_Interrupt singleton obtained by UTgetInterrupt(). The easiest way to automatically use it via the UT_AutoInterrupt class in your custom cook methods,