|
HDK
|
Although the names are often used interchangeably, PDG and TOPs refer to two separate components of Houdini. PDG is the name of the underlying dependency graph format and evaluation library, while TOPs is a network context within Houdini that exposes PDG constructs as regular Houdini operators. PDG has its own implementation of nodes, input/output connections and parameters, which are mapped onto Houdini operators concepts through TOPs.
When a TOP graph cooks, it generates an underlying PDG node graph based on the TOP nodes and their parameters. The actual execution of that graph is handled by PDG, which is how the graph is able to cook in the background. TOPs is responsible for displaying progress about the PDG graph as it cooks, for example the dot display and progress badges on nodes in the network editor.
The fundamental unit of work in a PDG graph is a work item. Work items have a number of intrinsic properties like a sort index, frame and priority, as well as the ability to store arbitrary attribute data. Supported attribute types include integers, floats, strings, file paths, Python objects and Houdini geometry data. Attributes can be added to work items by the node that created them, either when the work item is generated or while it is cooking. The majority of the custom data fields on work items are implemented as attributes. For example, a work item has input and output files, both of which are implemented as specially named attributes. Likewise, a work item's command line string, label and custom state string are all stored as attributes.
Work items can also have dependencies on other, upstream work items in the graph. For example, items generated in a processor node typically depend on a corresponding upstream work in one of the input nodes. Processor nodes are also able to add dependencies between sibling work items produced during the same work item generation step. A work item can only cook once all of its dependencies have cooked.
PDG supports cooking work items both in process or out of process, depending on which scheduler node is assigned to the processor node that created the work item(s). It's also possible to create work items that don't cook at all, and simply exist for the purpose of carrying attribute data through the graph.
TOPs itself has very few "real" node definitions – most nodes in TOPs are actually wrappers around an underlying PDG node definition. Unlike other network contexts, it isn't even possible to write a custom TOP node. Adding a custom node to the TOPs context can only be done by writing a custom PDG node, and optionally packaging it into an HDA in order to customize the parameter interface, TAB menu entry, and add other metadata.
Custom PDG nodes can be written either in Python or C++. This document focuses on writing a PDG node in C++ – writing a custom node in Python is discussed in the regular Houdini documentation. It is worth noting, however, that the C++ and Python APIs are generally very similar. Concepts discussed in this document also apply to nodes written using the Python API, and vice-versa.
Writing a custom PDG node requires implementing a subclass of PDG_NodeCallback, which is the base class for all node implementations. The class has various functions that can be overridden by a custom implementation in order to change the behavior of the node.
PDG has two main types of node – processors and partitioners.
Processor nodes generate new work items using the parameter interface of the node and any upstream work items available as an input. Generally speaking, processor nodes apply their procedure in a for-loop for each input work item available using something the following code structure:
This is not always the case, though, and a custom processor node can handle work item generation in whatever way makes sense for that particular node.
Partitoner nodes perform the opposite operation – rather than generating many new work items for each upstream work item, they instead combine multiple upstream work items into subsets called partitions. Valid partitions must contain at least one of the input work items, and the contents of partitions can overlap. For example, a partitioner node might create a partition that contains all work items with a "size" attribute, and another partition that contains work items with a "temperature" attribute. Some of the upstream work items may have both attributes, and would therefore appear in both of the partitions. In other words, partitions are non-distinct subsets of the upstream work items with a size of at least 1.
Schedulers are special types of nodes that exist in a PDG graph, but are not directly connected to any other nodes. Schedulers are responsible for taking work items that are ready to cook, and determine how and where the work item should run. For example, PDG ships with a Local Scheduler that runs work items as separate processes on the current machine. Alternatively, the HQueue, Tractor and Deadline scheduler run work items on various render farm systems.
Scheduler nodes take the information available on the work item, prepare the necessary job specification to run the work item, and then report progress and status back to PDG as the work item cooks.
Custom PDG nodes that are found on the Houdini search path will automatically be available in TOPs. However, TOPs will generate a parameter interface for the nodes automatically based on the underlying PDG node's parameter interface specification. PDG has a very basic parameter format, so the generated interface in TOPs will be a simple, flat list – it won't have any folder groupings, conditional expressions, or other visual arrangements.
In order to create a custom parameter interface for your PDG node, you can right mouse click on an instance of the auto-generated TOP node and select "Create Digital Asset". This will create a persistent .hda file that refers to the custom PDG node definition, and stores any parameter interface customizations made using Houdini's parameter interface editor.
1.8.6 
