Houdini PDG/TOPs Guide: Building Variation and Render Workflows with Wedge

SideFX’s Houdini 22.0 documentation describes PDG/TOPs networks as task workflows that turn data into work items and process those items with different nodes. This guide covers generating parameter variations with Wedge TOP, comparing results, and running render or simulation tasks with ROP Fetch TOP. The ROP Fetch page notes that the node has been available since Houdini 17.5. The approach focuses on managing repeated scene generation, procedural geometry, and simulation alternatives in a single workflow.

Creating controlled variations with Wedge

1. Identify the asset to vary. The digital asset or network used in Houdini should contain the parameters to be changed. In SideFX’s example, values such as the height, number of bricks, and tone of a brick wall are treated as variables. An architectural project can also explore alternatives through the parameters already present in its assets. The key point is that Wedge does not create new design parameters on its own; it passes specified attribute values to work items.

2. Define attributes with Wedge TOP in a TOP network. Wedge generates work items with different values for one or more selected attributes. Each work item can be processed as a separate task in subsequent steps. Multiple attributes can be changed in a single Wedge node; according to the documentation, these attributes vary independently within the specified number of variations.

3. Pass work item values to the called network. Nodes such as HDA Processor and Geometry Import can be used to run Houdini assets or networks. To have parameters in the called network use the current work item's values, use the relevant attribute expressions:

@attribute

Once this connection is in place, each work item can process the same base asset with different values. Even if an attribute has been created, the expected geometry or simulation differences may not appear if the called network does not use that value.

1. Compare variations visually. Render the generated geometry to review the alternatives. SideFX notes that a node is available in TOPs to combine a set of images into a mosaic; the documentation does not confirm the node’s name. A mosaic output makes it easier to evaluate different results side by side. Deciding which option is right for the design, however, remains up to the team.

Wedge combinations and simulation tests

When more parameter combinations are needed, Wedge nodes can be connected in sequence. A Wedge that receives input generates its own variations for each incoming work item. This makes it possible to create permutations of different attribute sets. The approach is useful for preparing many alternatives from the same base asset, but the number of work items can grow as the number of Wedge nodes and the variations in each one increase. For that reason, starting with only the variables that will inform the decision helps keep the workflow manageable.

In SideFX’s example network, wall variations are generated first, then settings such as the speed of the ball hitting the walls are varied for an RBD simulation. At a later stage, smoke simulation and smoke density can also be varied with a separate Wedge. This setup lets teams generate and review geometry and simulation alternatives within the same task workflow. Wedge is not limited to random changes: the documentation also notes that regular, evenly spaced values can be used to generate geometry at different levels of detail.

Managing frames and outputs with ROP Fetch

ROP Fetch TOP can run a ROP node or network from the current Houdini file or an external .hip file through TOPs. It creates work items per frame according to the frame-generation settings. Work items can be combined into a single job covering all frames or split into smaller frame batches. In simulations, combining all frames into a single job can keep simulation data in memory rather than caching it to disk. For a fast-running ROP, smaller batches—such as 4 frames per job—can help reduce the overhead of loading the .hip file.

ROP Fetch’s ability to recognize generated files is important for output tracking and caching behavior. For standard ROPs, the output path can be read from the node parameters. If automatic detection fails for a custom ROP, the name of the output parameter can be specified. Another option, Custom Path List, tells PDG the paths of files written by the ROP; it does not change the ROP’s actual output location.

If the outputs from a custom driver node need to be identified through the log, SideFX documentation refers to a toggle parameter named pdg_logoutput and a matching format for log lines:

OUTPUT_FILE:{file_path};

With this approach, matching file paths can be registered as output files for ROP Fetch work items. First verify which files the ROP actually writes, then check that PDG recognizes those outputs correctly.

Considerations for architecture and archviz workflows

Wedge can be useful for architecture firms and visualization teams that want to generate alternatives from the existing dimensions, material, or simulation parameters of the same scene component. TOP networks can define task workflows that support running jobs on a local machine or a render farm. However, the documentation does not provide specific hardware requirements or performance guarantees. Before scaling up to many variations, renders, and simulation jobs, run a small test to observe the number of work items, output files, and resource usage.

Using an external .hip file also affects network dependencies: according to the source documentation, Source Node Path is not used when External HIP File is enabled. An incorrectly defined output path can also make it harder for PDG to track the expected file. So start with a limited frame range and a small number of variations; expand the network after verifying output paths and cache status. If you plan to use a server or render farm, check the working environment and license terms separately as well.

Common mistakes

• Creating Wedge attributes without connecting them to parameters in the called Houdini network.

• Adding Wedge nodes in sequence without accounting for the resulting number of work items and permutations.

• Failing to match Custom Path List to the actual files written by the ROP; the list does not route the output, but tells PDG where the files are.

• Assuming the ROP Cook Order setting is effective in every execution mode; the documentation limits its effect to batch processing or a single work item covering all frames.