| On this page | |
| Since | 18.0 |
Overview ¶
This node writes the USD generated by a LOP network to a temp file, then launches an external process (by default, husk) to render an image or image sequence from the USD.
Rendering uses the same USD interface (Hydra) as is used to render the Solaris viewport, but instead of displaying the generated pixel buffers, the renderer saves them to image files. You can choose to render using any Hydra client registered with USD.
Configuration ¶
Traditionally in Houdini, the renderer was configured using parameters on the render node. In USD, however, render settings are stored in a RenderSettings primitive in the scene tree.
See the help for the 
Render Settings LOP, 
Render Product LOP, and 
Render Var LOP for more information about creating USD render settings.
The parameters on this node primarily deal with launching the render process, with just a few options to override key options for controlling the render.
Available renderers ¶
-
The list of renderers is filtered based on the data returned by the
usdrenderers.pyscript. The husk utility, and by extension the USD Render node, only support renderers that can generate AOV buffers (that is, renderers whoseaovsupportattribute isTrue). -
To render to other delegates, such as Houdini GL and Storm, that do not support AOV generation, use the
OpenGL ROP (this basically updates the viewport and takes a snapshot of its contents).
Tip
You need to make sure the render delegate is found by the USD plug-in search, using the PXR_PLUGINPATH_NAME environment variable.
You can also set the environment variable TF_DEBUG to PLUG_*, which causes the USD library to print out useful information as it scans for and loads plug-ins.
Parameters ¶
Render to Disk
Renders with the last render control settings. This blocks Houdini until the render completes.
Render to MPlay
Render directly into an MPlay preview window, instead of to an image file. (You can save the image to disk from inside MPlay.)
Render to Disk in Background
Renders with the last render control settings in a background process.
Controls
Click to open a dialog that lets you launch a “one-off” render with different frame range and dependency settings.
Valid Frame Range
Render Current Frame
Render the current frame number (in the playbar).
Render Frame Range
Render each frame in the range set by the Start/End/Inc parameters below.
Render Frame Range (Strict)
The “Render Frame Range” option may generate frames outside the given range if they're requested by a render dependency. If you choose this option, this node will never render frames outside the given range.
Render Frame Range From Stage
Examines the USD stage of the source LOP node for a start and end timecode value. These are used as the start and end of the frame range to render. If the stage does not have this metadata set, executing a render operation will result in an error.
Start/End/Inc
When Valid frame range is “Render frame range” or “Render frame range (strict)”, the start and end frames (inclusive) and interval.
Preroll/Postroll/Inc
When Valid frame range is “Render stage’s frame range”, the number of frames before and after the stage’s official start and end frame to save, and the interval between time samples.
Render All Frames With a Single Process
Render all frames in a background process. Default is off. This allows continued interaction with Houdini while the render process runs.
To render multiple frames, the render process renders an image then advances the time on the scene and renders the next image (just like how the Solaris viewport plays back animation). If there is a lot of data shared between frames, this can render significantly faster compared to rendering a single frame per process.
Render Delegate
The Hydra client to use to render the images. The default is Karma. Alternate Hydra clients must be registered with Houdini’s USD libraries. See how the node gets the list of available renderers above.
LOP Path
Render the USD stage output by this node. If this is blank, the node uses the node with the display flag.
Render Settings
Scene graph path to the RenderSettings prim to render with. If this is blank, the node looks for default render settings on the root prim. If the root prim has no render settings, the node will use default settings.
Override Camera
Scene graph path to the Camera prim to render from. If this is blank, the node uses the camera specified on the render settings primitive.
Override Output Image
If this is not blank, render to this file path instead of the output specified in the RenderSettings prim. When starting a new render process for each frame, this parameter can use standard Houdini variables such as $F4 to specify unique per-frame image files. When Render All Frames With a Single Process is enabled, this parameter must pass an un-expanded frame specifier (such as $F4 or <FF>) to husk. This may require the use of a backslash to prevent variable expansion when evaluating the parameter.
Override Resolution
Override the resolution by either scaling the USD resolution by a percentage or by specifying a specific resolution.
Resolution Scale
Specify a scale (as a percentage) for the output resolution.
Resolution
Specify a resolution explicitly.
Husk ¶
Rendering ¶
Instantaneous Shutter
Disable motion blur by setting the camera to have an instantaneous shutter time.
Headlight Mode
When husk determines there are no lights on a stage, it will add a headlight. In some cases, husk may not properly identify geometry light sources and add a headlight erroneously. This option overrides the default behaviour, explicitly telling husk what type of headlight to create (if any).
Population Mask
Comma or space separated list of primitives that have to included in the render. If this is enabled, all other primitives will be omitted.
Include Render Settings and Cameras
Enabling this will append all cameras found in the stage, as well as the render settings (assuming they're in /Render) to the population mask.
Purpose
Comma separated list of purposes to render (from geometry, guide, proxy, and render). The default is geometry,render.
Complexity
This setting is defined by USD and Hydra to control for the number of iterations to use to render “refine-able” (subdivision) surfaces. Karma mostly ignores this setting, since it measures the surface in screen space to decide how many iterations it needs to render the surface smoothly. Instead, Karma uses this setting more like a subdivision on/off switch. If this is set to Low or Medium, Karma renders the (chunky) hull. If it is High or Very High, Karma renders the (smooth) limit surface.
Other renderers (such as RenderMan or Storm) will treat this setting differently, using it to determine subdivision quality. If you need to render the same scene in Karma and another renderer, remember to use High or Very High to make sure Karma renders subdivision surfaces smoothly.
Enable Legacy EXR Mode
When saving OpenEXR images with multiple AOVs, husk will normally save the images using multi-part EXR files. This extension (introduced in 2013) lets programs read a single AOV without having to read the entire image. This allows most software to work much more efficiently.
Some applications have not transitioned to support multi-part images. If your pipeline uses software that doesn’t support OpenEXR v2.0, this option will force husk to write out images in an inefficient, but more compatible format.
Delegate Products
Turn on render delegate products. These allow render delegates to save non-raster products like deep images or photon maps. These render products are render delegate specific.
Restart Delegate
Normally, when rendering sequences, husk uses UDS delta operations to make rendering more efficient. The delegate is only told about scene data that changes frame-to-frame so it can share work between frames.
This option will force the render delegate to be restarted when rendering sequences.
Since restarting the delegate will cause the scene to be rebuilt, using this option can have significant performance impact and should only be used if required.
Snapshot Interval
Whenturned on, the renderer writes out a snapshot file and partial image at every interval of this many seconds.
Time Limit
When turned on, the renderer will terminate if the render time limit is exceeded. Time Limit is measured in seconds. Note that husk will save the partial result before terminating.
Time Limit Per-Image
When rendering multiple frames in a single process (Render All Frames With a Single Process), the time limit specified is applied per image rather than the entire sequence of images.
Monitor ¶
MPlay Monitor
When rendering to disk, open an MPlay window to interactively monitor progress.
AOVs
This is the list of AOVs to display in the MPlay monitor. Specifying - will monitor all AOVs.
Monitor Zoom
This is a zoom factor applied to the monitor. The monitor will display images at a fraction of the full resolution while the image written to disk will be full resolution.
MPlay Session Name
When rendering to MPlay, all Houdini sessions will send the output to the same MPlay flipbook. This can be problematic when running multiple Houdini sessions. The MPlay Label lets you specify a label for the MPlay associated with the output driver. Only renders which match the given label will be sent to that MPlay.
Houdini Process ID
Uses the operating system process identifier so that the MPlay flipbook will only accept renders from that Houdini session.
HIP Name
Uses the $HIPNAME variable so the MPlay will only accept renders from the running $HIP file.
Output Driver Name
The MPlay flipbook will only accept renders from the given output driver. For example, if you copy paste the output driver, each output driver will be sent to different MPlay flipbooks because the operators will have different names.
If there are multiple Houdini sessions, there may be output drivers in the other session which match the same operator name.
For example, say you have two output drivers: “High quality” and “Low Quality”. If you set the MPlay Label to different values for the two output drivers, each render will be sent to different MPlay sessions.
Python ¶
Similar to how Houdini can run scripts during rendering, husk can also run Python scripts. These Python scripts can access the Usd stage using the stage variable in Python.
Husk Pre-Render
The Python script husk runs before any rendering begins.
Husk Pre-Frame
The Python script husk runs before rendering each frame.
Husk Post-Frame
The Python script husk runs after rendering each frame. This is run after all render products are saved.
Husk Post-Render
The Python script husk runs after all rendering.
Tiles ¶
Tiled Render
husk can break up a single large image into multiple tiles and render each tile independently. It does this by overriding the dataWindowNDC setting defined on the render settings.
Count
The number of tiles in the X and Y resolutions.
Index
This is the tile that husk should render. The value should be between 0 and the total number of tiles (Count.x*Count.y).
Suffix
Each output image will be suffixed with this string. The string supports the same variable expansion husk does on output images, but replacing the %02d with the tile index instead of the frame number.
Statistics ¶
Print Command Line to Console
This option can be used to debug exactly what command the ROP is executing.
Verbose
How much information to print out while rendering.
VEX Profiling
Profile VEX performance while rendering. Normally, you should avoid “Profiling and NAN Detection” since it can impact performance (though it can be useful for debugging)
USD Trace
This enables USD tracing. This information can be used to profile Usd performance in husk.
Chrome File
When using Chrome tracing, this is the file where the trace log should be stored.
Log Output
Capture the output from husk and store the log in a file on disk.
Append to Log Instead of Overwriting
Normally husk will overwrite the log file on each run. This option will cause output to be appended to the text in existing files.
Output Log
This is the file where normal messages should be saved.
Error Log
This is the file to which error messages should be saved. If this is the same file specified for the Output Log, the output and error messages will be interleaved (in the same way they are written to the console).
Output ¶
Render Command
This is the external command used to render. If this parameter is disabled (by turning off the Run command parameter) the command is not executed. The USD scene will still be output to disk, and the command will be output to the console (if Print command line to console is turned on), but the command will not actually be run. Disabling the running of the command also prevents the deletion of the generated USD files, even if they are in the Houdini temp directory. This mode can be very useful for debugging or for batch farm rendering.
Render Existing File
Use this option to render an existing USD file from disk rather than the input lop.
Resolver Context Asset Path
This file path is passed to the render command line as the resolver-context option. This argument is used to create an asset resolver context that helps the asset resolver find files while composing the USD stage. The default of this parameter is an expression that returns the corresponding parameter on the LOP Network that contains the selected LOP path
Number of Resolver Context Strings
These arguments are passed to the render command line with the render-context-string option. The resolver context can be configured using multiple separate strings. Each string is used to configure one resolver. One string (with no URL prefix specified) is sent to the default resolver used for all asset paths that are not in URL format. Other strings can be paired with a URL prefix to configure the resolver associated with that prefix.
If there is at least one non-empty resolver context string value provided, this takes precedence over any resolver context asset path, and the resolver context for the LOP stage will be created using the ArResolver::CreateContextFromStrings method instead of ArResolver::CreateDefaultContextForAsset.
Enable
Individual resolver context configuration strings can be enabled or disabled with this toggle.
URL Prefix
This string value will be sent to the resolver responsible for the specified URL prefix. If no prefix is provided, this string value will be sent to the default resolver.
Value
The string value sent to the resolver determined by the URL Prefix.
Number of Variant Selection Fallback Rules
These parameters are passed to the render command line with the variant-fallback option. Configures what variant selection fallback values to use for specific variant sets when no explicit variant selection opinion is provided on a prim. These fallback rules are applied on top of any global variant selection fallbacks configured using the USD library plugin mechanism.
Enable
A specific variant set fallback setting can be disabled with this toggle.
Variant Set Name
Name of the variant set to configure.
Fallback Selections
A space or comma separated list of variant selection values to attempt to use on this variant set when no explicit variant selection opinion is available.
Wait for Render to Complete
Causes Houdini to freeze after starting the render process, and only resume when the renderer exits. (This is included mostly for parameter parity with the old Mantra render nodes. It may be useful to implement a crude form of dependency ordering when batch rendering.)
Alfred Style Progress
Print percentage complete value as files are written. This is in the style expected by Pixar’s Alfred render queue.
Create Intermediate Directories
Create intermediate parent directories for output files as needed, such as for generated images.
Maximum Threads
Uses the -j command line option to husk to specify the maximum number of threads that process should use. This parameter can be enabled to ensure that some portion of the computer’s processing powere remains available for tasks other than the render. Positive values specify an absolute number of threads. Negative values indicate that the number of threads should be equal to the number of CPU cores on the machines minus the specified number.
Initialize Simulation OPs
Initialize DOP simulations before rendering.
Report Network Use
Print the number of bytes sent or received by the distributed simulation nodes during cooks triggered by this node.
This does not track network usage from, for example, saving a file to an NFS mount. It only tracks the network communication of distributed Houdini nodes.
USD Export ¶
Output File
The “top-level” USD file to write the root layer to. Other layers that have file path metadata set will be written to their own USD files. A default output processor (see below) translates external file references in nodes to be relative to this file’s directory, as is recommended.
Delete Files
Controls whether or not files (USD and VDB) saved to disk are deleted when the render process completes. In addition to deleting the files, any containing directories are also deleted if they are empty after deleting the USD. The modes of operation are:
Delete if Saved to Temp Directory
Files saved to the Houdini temporary directory ($HOUDINI_TEMP_DIR) are deleted. Files saved to any other directory are not deleted.
Always Delete
All files generated by this ROP are deleted.
Never Delete
Files generated by this ROP are not deleted.
Save Style
This node can apply some transformations to the layer stack before writing out files. These transformations do not affect the final composed stage, only the number of layer files generated.
Flatten Implicit Layers (Collapse Implicit Sublayers, Preserve References)
The default. Composes anonymous in-memory layers down onto the nearest layer with a file path (so the node will write out any layers that have file path metadata to separate USD files). This preserves references, variants, and other composition arcs.
Flatten All Layers (Combine All Sublayers, Preserve References)
This composes all layers (both anonymous layers and layers with file paths) into a single layer. This preserves references, variants, and other composition arcs, so the node may still write out more than one file if external files were referenced in.
Separate Layers (Preserve All Sublayers and References)
Don’t compose any layers in any way. Even anonymous in-memory layers will be saved out to their own files (you should turn off Error saving layers with implicit paths so the node doesn’t error trying to save anonymous layers).
This may be useful for debugging, especially in combination with debug flags on nodes, to see what each LOP node is doing.
When the node has to write out a layer without file path metadata, it will automatically generate a relative file path based on information such as the node path of the node that generated the layer.
Flatten Stage (Collapse All Sublayers and References)
This flattens all layers into a single stage, and “bakes in” all composition arcs, even variant selections. This discards information such as which opinions came from which layer, and unused variants. This writes out a single USD file.
This may be useful if you want to “delete history” and make it seem like it a file wasn’t composed from layers, references, variants, and so on.
Tip
If you want to “preserve history” but want the convenience and portability of a single file, use the 
USD Zip render node to generate a .usdz file.
Strip Layers Above Layer Breaks
Enable this option to prevent layers authored above Layer Break nodes from being written to disk by this ROP. This allows a Layer Break node to dictate which portions of the LOP Network are to be saved. Disabling this option allows this behavior to be overridden, forcing the full stage authored by the LOP network to be written to disk. This may be used for debugging purposes, or to write a complete scene to disk for rendering.
Strip Post-Layers
Enable this option to prevent layers added using the hou.LopNetwork.editablePostLayer method from being written to disk. With this option disabled, these post-layers are flattened into the layer Output file layer.
Track Primitive Existence to Set Visibility
LOP networks may generate vastly different scene graphs from one frame to the next. When combining these scene graphs over a frame range into a single animated scene graph, the set of primitives in the combined scene graph will be the union of the primitives in each frame’s hierarchy. But if a mesh appears at frame 50, this generally means that it is desired for this mesh to not be visible prior to frame 50. Enable this option to cause this node to track a list of all primitives at each frame, and automatically author animated visibility attributes for any primitives that are added to or removed from the scene graph over time. This gives the appearance of primitives being added and removed over time.
Only subclasses of UsdGeomImageable primitives will be tracked this way, since these are the only USD primitive types which respect the visibility attribute.
Use Network Drive Safe Save (Windows Only)
When running on Windows, the USD library often has issues saving layers to network mounted drives when those layers are currently loaded into a USD stage. This can make it impossible to overwrite a USD layer that is in use, even by the current Houdini session. This option works around this issue by having the USD ROP mute each layer right before ti is saved to disk (but only when running under Windows - on Linux and MacOS this parameter has no effect). Once the layer is saved, it is un-muted. This approach incurs a performance penalty as any stages using this layer will be recomposed twice instead of once. But in some settings this can make the save process much more robust.
Extra files ¶
Files to Save
A list of patterns matching which files the node is allowed to save. If this is blank (the default), the node saves all files. You can use this, for example, to avoid rewriting layer files that you know will never change.
Error Saving Layers With Implicit Paths
When this is on (the default), the node errors if it would otherwise write an anonymous in-memory layer (that is, a layer with no file path metadata) to disk.
You will usually only turn this off if you are using the Save style “Separate layers” to write out every layer separate for debugging purposes.
Save Updates to Modified Files From Disk
If you use the 
Load Layer LOP to bring a layer onto the stage, this “editable” version of the layer on disk has metadata marking it as originally coming from disk, rather than being created from scratch by LOPs. When this is on, layers created this way are saved to disk just like any other layer with file path metadata.
Turning this off prevents saving these layers to disk. This can be useful if you never want these “edited from disk” layers to overwrite the original files, or at least prevent overwriting them until you are certain the output of the LOP network is correct, when you can allow the edited layers to be written to disk.
Flatten File Layers
When Save Style is “Flatten Implicit Layers”, files loaded from disk with a Sublayer LOP are not considered anonymous layers, and so are not composed down. Turn this on to flatten layers from disk as if they were anonymous layers. This can be useful for generating more portable USD layers that rely on a minimal number of external layers. It can also be used to “harden” the sublayered files on disk in their current state if they may be changing, but you are generating a USD file for archiving purposes and do not want it to reflect any upcoming changes to the external files.
Flatten SOP Layers
When Save Style is “Flatten Implicit Layers”, layers generated by importing data from SOPs with 
SOP Import are not considered anonymous layers, and so are not composed down. Turn this on to flatten layers imported from SOPs as if they were anonymous layers. This can be useful for generating more portable USD layers that rely on a minimal number of external layers.
Output processing ¶
Output Processors
Add an output processor to this node. Output processors are Python plugins that can alter the file locations and file path strings used for external files. The USD render node starts with one default output processor (called Use Relative Paths, see below).
(See output processors for information on how to write an output processor plugin.)
The following built-in processors are available:
Use Relative Paths
This is automatically added by default. This processor changes absolute file paths to relative paths in layer files. This allows you to use paths such as $HIP/usd/foo.usd for loading, but have them written out as paths relative to the source file. This is recommended practice so you probably do not want to remove this processor.
Make Output Layer Extension
Normally, if you change the extension of the output file, it only affects that “top-level” output file. All other external files are written to their embedded save paths, with their embedded extension. This processor changes the extension on all paths to match the extension of the output file. This means if you change the output file to use .usda (the textual format), when this processor is active, all external USD files will also switch to .usda.
Save Paths Relative to Output Path
Causes any Save Path parameters that are relative paths to be treated as if they are relative to the Output File parameter value. This makes it easy to ensure all files generated by a LOP network are saved into a common root directory. Changing the save location of the output file will implicitly change the save location of all other files.
This processor has a Root Directory parameter which, if set, specifies a location other than the Output File to which Save Paths will be considered relative.
Use Search Paths
This processor includes a Search Path parameter. Each asset path is compared against the directories listed in this path. If the asset is inside one of the search paths, the asset will be referenced with a search path rather than a full path or relative path.
Copy All Assets to Referencing Layer Directory
This processor makes copies of all non-USD assets (such as UDIMs, texture maps, and volume files) in the same directory as the USD file that references them. The USD file is updated to refer to these local copies of the assets. These updated references will use absolute paths, so it is recommended that you use this in conjunction with a Use Relative Paths output processor. This localizing of assets makes it much easier to create USDZ archives of assets, since that format requires texture maps and similar assets to be in or contained under same directory holding the USD file.
This processor has an Output subdirectory parameter which causes the assets to be copied into a specific subdirectory inside the directory where the USD file is being written. This parameter should be a relative path, such as textures, not a full path to a directory.
USD assets are not localized because doing so would break relative path references within those USD files. If USD data must also be localized to a single directory, it is recommended that this be accomplished by setting the Save Style on the USD ROP to Flatten Stage, which will gather all USD data into a single layer.
If an asset file doesn’t exist, or the asset file is already located in the same directory or any subdirectory of the referencing layer file, the asset is not copied.
This output processor should be moved above the “Use Relative Paths” output processor to ensure that the asset paths written to the USD file produce the simplest possible paths to the localized file locations.
USD Output Directory
The directory where any required USD files will be saved. If this directory is in the $HOUDINI_TEMP_DIR, it will be deleted automatically when the render is complete.
Layer metadata ¶
Default Primitive
Set this to the name of a root primitive on the current stage to set it as the default primitive for the top-level file.
Error Saving Layer With No Default Primitive
When this is on, the render node will error and stop cooking if you haven’t specified a default primitive for all layers being written out.
This is a way to force yourself to make sure layers have default prims, so you know you can reference in files without having to manually specify a top-level prim.
Save ROP’s Time Information to Output
Write the start and end frames, as well as the current frames per second setting, to the top-level output file.
Clear Houdini-Specific Custom Data
LOP networks often attach Houdini-specific custom data to layers, prims, and properties. Houdini does not need this data to be stored on disk (usually it is related to how to write files), so by default Houdini strips out this data before saving. Normally there’s no reason to turn this parameter off (it’s possible it might help SideFX diagnosing a problem).
Ensure Basic Metrics are Set on All Layers
This options ensures that the upAxis and metersPerUnit metadata is set in every USD file written to disk. If a value has not been explicitly authored on a layer by the LOP Network, the default up axis and meters per unit values from the Lighting Preferences are used.
Context options ¶
Set ROP Cook Context Options
Controls whether this node sets the @ropcook, @ropstart, @ropend, and @ropinc context options when rendering. If enabled, these context options are automatically set to 1 for @ropcook, and the values of the Start, End, and Increment Frame values from this node for @ropstart, @ropend, and @ropinc. Using these standard context options it is easier to set up predictable behavior for Cache LOPs, LOPs that create ranges of time sampled values, and LOP nodes that are only used for generating viewport previews or final rendered output.
Number of Options
Lets you specify context options that only apply while writing out files from this node. Set the number of context options to define/override, or use the plus and minus buttons to add or remove options.
You could have two separate USD render nodes with different context options, so they would write out different USD from the same LOP network depending on uses of @contextoption references in expressions. This could be useful for wedging, or to cause the LOP network to configure the stage in ways that are not good for interactively, but should be written to disk.
Option Name
For each option, the name of the option. You can reference this option in an expression using @name.
Option Type
For each option, the type of data stored in the option, either a floating point number of a string.
Option Value
For each option, the value of the option (while this node writes out USD).
