|
HDK
|
Houdini's scene file is organized into an hierarchy of nodes. Each node can be uniquely referenced via pathnames such as /obj/geo1/file1. Each of the "directory" levels in this path is internally referred to as a Network (class OP_Network). Networks are structures that contain a collection of Nodes (class OP_Node). Since this is a hierarchy, we must be able to recursively create collections within collections and hence a network in Houdini is also a node (i.e. the class OP_Network is derived from the class OP_Node). For example, /obj/geo1 is an object which is a type of OP_Network, and contains a collection of SOP_Node objects (geometry nodes).
The top level root network (path /) is sometimes referred to as the Director (class OP_Director, MOT_Director). The nodes within the director (which are also networks themselves) are sometimes referred to as Managers. The hierarchy continues below the managers until reaching a node that contains no child nodes. The following outlines the structure of the hierarchy:
/obj) /ch) /out) /shop) /img) /vex) In addition to the managers above which can be always found under the / path, each manager can also exist within any other network to contain a network consisting of a different context.
Often, Houdini users find it very convenient to to group a set of nodes together and work with that encapsulating group rather than with the explicit list of nodes. Such groups could be then specified in parameters where Houdini expects a node paths, and Houdini would expand the group to retrieve the set of nodes it needs to access. This was the motivation for the concept of OP_Group, which provides such grouping capability. However one limitation of OP_Group is that it can contain only nodes of the same type and only at one level of the node hierarchy (i.e., siblings contained by one parent node). To make the node grouping more flexible, OP_Bundle was introduced, which allows members nodes to be of different types and to be located at different levels in the node hierarchy (i.e., have different parents). The OP_Bundle concept, however goes one step further than explicitly listing the member nodes; it allows the use of globbing (ie, pattern matching) to define the bundle membership. This powerful feature makes it attractive to use OP_Bundle in C++ code for pattern evaluation that collects the set of matching OP_Nodes in the scene.
The global OP_Director singleton instance (obtained via OPgetDirector()), represents the top level root network (path /). From this instance, global node operations can be performed such as searching for a node given its absolute path. It also contains methods for manipulating the current working node path, and the global node selection.
For hscript command execution, OPgetDirector()->getCommandManager() returns the global command manager. See the Calling hscript from C++ chapter for more information.
For time manipulation, OPgetDirector()->getChannelManager() (or equivalently, CHgetManager()) returns the global CH_Manager instance. This stores the global animation settings, controls scoping of channels, and has methods for querying the current evaluation time as well as methods for time conversion.
Nodes are all subclasses of OP_Node. For each node in the network view, there is an OP_Node instantiation in memory. Each specific node type is implemented by a subclass of OP_Node. In the class diagram above this is SOP_Star (SOP_Star.C). As demonstrated in the class diagram above, these node type implementation classes do not derive directly from OP_Node. Node types are grouped into different network types, each of which has a common base class for all nodes belonging to that network type. Examples of these common base classes include SOP_Node, OBJ_Node, DOP_Node, CHOP_Node, etc. These network type base classes are derived from OP_Network and each have an associated OP_OperatorTable class.
The OP_OperatorTable class defines the set of node types (OP_Operator) that are allowed to be created as children of the associated OP_Network node. Each of the network type instances share the same OP_OperatorTable object. For example, all SOP_Node subclasses have a reference to the same OP_OperatorTable object containing OP_Operator entries for all SOP nodes. All instances of a particular SOP_Node type (eg. all the Box SOP nodes in the scene) in turn share the same OP_Operator object.
To get the OP_OperatorTable and OP_Operator of a node, you can use OP_Director::getTableAndOperator(), where the path argument can be either an operator node path, e.g., "/obj/geo1/box1", or an operator type name with a table, e.g., "Sop/box". For operator names that include namespaces, the operator type name would be, for example, "ArtistX::Sop/myhda". There are a few utility functions to convert between namespace components and also between an operator name with and without the table name: UT_OpUtils::getComponentsFromFullName(), UT_OpUtils::getFullNameFromComponents(), UT_OpUtils::combineTableAndOpName(), and UT_OpUtils::splitTableAndOpName().
OP_Node itself is derived from OP_Parameters, which provides an abstraction for manipulating a set (PRM_ParmList) of parameters (PRM_Parm). When a specific node type is created, it supplies an array of PRM_Template objects to the created OP_Operator representing it. Then when the node is created (by OP_Network::createNode()), the PRM_ParmList is created with PRM_Parm entries from each of the corresponding PRM_Template objects. All nodes of the same type share the same array of PRM_Template objects.
1.8.6