|On this page|
A work item contains attributes, named bits of information similar to attributes on a point in Houdini geometry. If the work can read the attributes to control the work they do. Attributes are passed down to work items created from "parent" work items, so you can use them to have the result of a work item affect the processing of its child items, group items together, and pass information down through the network.
Custom code can read attributes to control generation of work items, however the most common use of attributes is to reference them in parameters of TOP nodes and/or Houdini networks and nodes that are referenced by the TOP network.
For example, let’s say you want to wedge different render qualities. You can use the Wedge TOP to create work items that have a
pixelsamplesattribute set to different values. Then, in the ROP Mantra Render TOP, you can set Pixel samples using
@pixelsamplesto reference the attribute value.
You can also reference work item attributes in external assets/networks called by the TOP network. For example, the HDA Processor cooks a Houdini asset for each work item. You can use
@attributereferences in that asset’s parameters to pull values from the work item.
You can reference a component of a vector using
@attribute.component, where component is a zero-based number, or
z (equivalent of
2). For example
Using attributes in expressions (pull)
When nodes are "called" as part of a TOP network cooking (for example, when TOPs cooks an HDA Processor, or renders frames using a ROP render node), it fills in any
@attribute references using the cooking work item’s attributes.
When nodes cook for display in the viewer, they fill in
@attribute references using the attributes of the currently selected work item. This means you can click around work items and see the visible output of a network change to reflect the output of the selected item.
These are called "pull" references. This is the easiest way you
If you don’t want to or can’t put TOPs-specific expressions in certain parameters, you can instead use an alternate "push" mechanism where you specify in the TOP network parameters to overwrite at run time.
@attribute reference by itself is an Hscript expression, just like
ch('../geo1/tx') * 2 is an expression. You can use
@attribute references as part of HScript expressions to compute values in node parameters.
Remember that if you want to use an expression in a string parameter, you must escape it by enclosing it in backticks (
`). For example, to reference the work item’s built-in
output attribute in a file path parameter, you must enclose the reference in backticks:
You can incorporate an expression within "normal" text in the parameter. For example, to use the work item’s frame number in a file path:
If it’s ambiguous what an
@attribute expression refers to (for example, a geometry point attribute and a TOP work item attribute have the same name), SOP attributes take precedence over TOP work item attributes.
Replacing parameter contents at run time (push)
When using the Wedge TOP to vary parameter values, if you don’t want to put TOP-specific expressions on other nodes (for example, if the ROP you want to render is shared with other pipelines or used manually), you can have the Wedge node replace parameter values with wedge attributes at run time.
See the help for the Wedge TOP for how to override parameters at render time.
When referencing built-in attributes, use
@pdg_name, for example,
Used as a key for sorting work items within a node.
Makes it easier to distinguish individual work items in the interface.
The frame number this item is working on. Of course, not all work items are doing rendering, however needing to store a frame number is common enough that we included it in the built-in attributes.
A list of filenames used as the input for this bit of work. For example, if the work item represents "draw text over a rendered image", this would be the path to the image to manipulate.
A list of filenames produced as the output of this bit of work. For example, if the work item represents "draw text over a rendered image", this would be the path to the output image with the text drawn into it.
As processor nodes generate new work items from incoming work items, the
output attribute of the "parent" work item is automatic assigned as the
input attribute of the "child" work item.