Manage Render Variations with Wedge and ROP Fetch in Houdini TOPs

The Wedge and ROP Fetch nodes in Houdini’s TOPs documentation bring variation generation and render job scheduling together in a single workflow. SideFX’s documentation for both nodes describes their features from version 17.5 onward. Wedge creates separate work items based on the attributes to be changed, while ROP Fetch runs a ROP node or network and creates jobs for individual frames. This guide covers the basic setup for anyone looking to compare options systematically in architectural visualization and animation scenes.

1. Define variations with Wedge TOP

Add a Wedge node to your TOP network before the render node. According to the documentation, render TOP nodes create frame-based work items for each incoming work item. This passes each variation created by Wedge to the render stage as a separate input.

In the Wedge Attributes section, add the attributes you want to change and give each an Attribute Name. You can change multiple attributes in the same Wedge node. Values can be distributed evenly across a range, selected from a list, or randomly sampled from within a range. These options let you prepare controlled comparisons for the same scene; however, which scene parameter is linked to an attribute depends on the network setup and parameter connections.

Wedge Count sets the number of work items to generate. Values defined as a range are divided into that number of steps. When using a list, if Wedge Count exceeds the number of values in the list, the list starts over. For random selection, changing Random Seed produces different samples. So, keeping the same seed during a comparison helps maintain consistent variations; change the seed when you need new samples.

2. Link attributes to render parameters

There are two ways to pass Wedge values to a render node. With the “pull” approach, an expression in the render node’s parameter references the work item’s attribute. For example, if the attribute is named scale, the expression shown in the documentation is @scale. This method is flexible, but because it uses TOPs-specific expressions, it may not be suitable when the ROP node needs to remain runnable manually outside TOPs.

With the “push” approach, specify the target parameter using the Target Parameter option in Wedge. Wedge creates special attributes that override the parameter during rendering. TOPs then passes the render values through, without changing the parameter in the scene’s HIP file during this process. The Set Value As option determines whether the target parameter is set as an attribute reference, a direct value, or an expression.

Use caution with the option that changes the target parameter for preview when a work item is selected: according to the documentation, this actually changes the parameter, can trigger a recook, and can leave the HIP file unsaved. If the file is saved, the previewed change may be retained. This behavior affects only the active Houdini session; when the network runs, “push” values are applied without changing the HIP file. Check parameter values after previewing to avoid leaving unintended changes in the file.

3. Run frames and jobs with ROP Fetch

After Wedge, use ROP Fetch TOP to run a ROP node or network from the current HIP file or an external HIP file. The node creates one work item for each frame, according to the frame-generation settings. Grouping multiple frames into a single job can be useful in scenarios where simulation data remains in memory. Smaller batches—the documentation’s example uses four frames per job—can help reduce the overhead of reloading the HIP file for fast-running ROPs. These are usage examples, not required settings for every scene.

ROP Fetch’s Cache Mode option determines what happens when the expected output files already exist. Automatic can treat a job as complete without scheduling it again if the file exists; upstream work items writing new files can invalidate the cache. Automatic (Ignore Upstream) also checks for the file, but upstream file writes do not invalidate this node’s cache. Read Files marks a work item as failed if the output is missing. Write Files always schedules jobs, regardless of whether the file already exists. Choose how to handle rerendering or using existing files according to your workflow.

You can track outputs by getting file paths from ROP parameters or by using Custom Path List. Custom paths do not change the output produced by the ROP; they tell PDG which files are expected outputs. If a custom ROP’s output parameter is not detected automatically, specify the parameter name in Output Parm Name. If files written by the ROP cannot be captured automatically, you can enable the pdg_logoutput key documented by SideFX; lines in the node output matching the format OUTPUT_FILE:{file_path}; are detected as outputs.

4. Impact on architectural visualization workflows

Wedge is useful for visualization teams that want to organize multiple combinations of settings for a single scene as separate work items. ROP Fetch can then split these jobs by frame, group them, and manage rerun behavior based on existing output files. This makes it easier to track work items and outputs, especially during repeated render tests.

The documentation does not provide information about hardware performance, licensing terms, or compatibility with other software. Therefore, you should separately assess the network’s workload, the render node’s requirements, and the scheduler environment in use. Starting with a small number of wedges to verify connections and file paths can help limit the impact of incorrect settings before running a large number of variations.

Common mistakes

• Overlooking that values defined in a list cycle if there are fewer of them than the Wedge Count.

• Expecting a ROP to work outside TOPs without accounting for the fact that pull expressions are TOPs-specific.

• Forgetting that previewing a parameter by selecting a work item can modify the HIP file.

• Assuming Custom Path List changes the ROP’s output location; it only identifies the expected files.

• Treating old output files as valid without understanding Automatic cache behavior.