[SESI logo]

Houdini Development Toolkit - Version 6.5

Side Effects Software Inc. 2004

Houdini

Architectural Overview

It is useful to have an understanding of the overall Houdini architecture and how it relates to the classes you may be working with when making customizations. Having used Houdini you are aware that the operators are managed in a hierarchy which is referenced by pathnames such as /obj/geo1/file1. Each of the "directory" levels in this path is internally referred to as a Network (class OP_Network). In Houdini, 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 SOPs, which are types of OP_Nodes.

Note that the terms node and operator are sometimes synonymous. However, the term operator is most applicable to the leaf nodes of the hierarchy which tend to be the data generators (e.g. SOPs, COPs, TOPs).

The top level root network (pathname "/") is sometimes referred to as the Director (class OP_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 network that contains plain node types (i.e. non-network nodes). The following outlines the structure of the hierarchy:

Object Manager (path "/obj")
Contains Objects which are networks derived from OBJ_Node.
Objects contain SOPs which are nodes derived from SOP_Node.
Channel Manager (path "/ch")
Contains CHOP Networks which are networks derived from CHOPNET_Node.
CHOP Networks contain CHOPs which are nodes derived from CHOP_Node.
Output Manager (path "/out")
Contains Output Drivers which are nodes derived from ROP_Node.

Each network has associated with it an Operator Table (class OP_OperatorTable). This table defines the set of node types that can be created within that network. For example, the object manager has an operator table containing an entry for each object type:

  • Geometry
  • Camera
  • Light
  • Ambient Light
  • Fog
  • Null
  • Bone
  • It is this table that controls the operators that can be created with the opadd command and via the creation menus and toolbars available in the interactive editors. If you are customizing Houdini by creating new operators you are essentially adding new entries to the operator table for a given type of network. Each entry in the table is an object of class OP_Operator which basically defines everything Houdini requires in order to create nodes of the new type. This includes:

  • The short operator name
  • A more readable version of the name (for menus and such).
  • The minimum number of inputs required.
  • The maximum number of inputs required.
  • A method which constructs nodes of this type.
  • A list of the templates defining the parameters to this operator.
  • A list of any local variables used by the operator.
  • A lot of the leg work involved in creating a new operator is setting up the parameter templates. These templates are used to create the parameter list for the operator as well as the parameter dialog that appears in the interactive editor for the given operator type. The other main aspect to creating a new operator is implementing the code which performs the operator function utilizing the defined parameters to control it's operation. Several examples of custom operators are provided with the toolkit. For example: COP_HFlip. From this example you'll see the following:

    void
    newCopOperator(OP_OperatorTable *table)
    {
       table->addOperator(new OP_Operator("flipx", "Flip horizontal",
    				 COP_HFlip::myConstructor,
    				&COP_HFlip::myTemplatePair,
    				 1,     // Minimum input count
    				 1,     // Maximum input count
    				&COP_HFlip::myVariablePair));
    }
    

    This function is the one which Houdini runs to create the new operator and add it to the operator table. Note the arguments to the OP_Operator constructor which supply all the construction information previously mentioned.

    Although an operators purpose in life varies depending on the type of operator, once an operator has been defined and instantiated in a network, the method OP_Node::cook becomes the focal point for cooking the network and generating data. (Although some networks do actually generate data, such as images or geometry, it is worth noting that some networks, such as objects, only prepare some internal state information, such as transformations, for later use.) The cook method defined in OP_Node performs preliminary testing and preparation of inputs before actually calling the pure virtual cookMe method which must be defined in the sub-class to actually perform the cook. (It's also worth noting that not all calls to the cook method will result in calls to the sub-class cookMe method. The cook method will avoid doing an actual "cook" if it deems it to be unnecessary. A cook might be unnecessary if the data is already cached and nothing critical has changed since a previous cook.)

    Some operator types (such as COPs) define another virtual layer on top of the cookMe method in order to insert another layer of abstraction and gain some operator specific code sharing. In the case of COPs the pure virtual method copCook actually performs the final compositing operation. For SOPs the method cookMySop must be defined in the sub-class and for CHOPs the method cookMyChop must be defined in the sub-class.


    Table of Contents
    Operators | Surface Operations | Particle Operations | Composite Operators | Channel Operators
    Material & Texture | Objects | Command and Expression | Render Output |
    Mantra Shaders | Utility Classes | Geometry Library | Image Library | Clip Library
    Customizing UI | Questions & Answers

    Copyright © 2004 Side Effects Software Inc.
    477 Richmond Street West, Toronto, Ontario, Canada M5V 3E7