Since 18.0

This node will export geometry from a SOP network directly into a USD file.

Parameters

Configure

Import Group

Turn this on and specify a group name (or a space-separated list of group syntax) to import. If you turn this on but leave the field blank, it imports all geometry.

Import Group Type

When enabled, specifies the whether the Import Group is a point or primitive group.

Import Path Prefix

If a prim being imported has an automatically generated name (like mesh_0) because it had no path primitive, or if it has a path primitive but the path is relative (does not start with /), the node automatically prefixes the name/path fragment with this path. This is a way of keeping “un-pathed” prims organized under a single branch. (See how to create geometry hierarchy.)

(The default is /$OS which puts “un-pathed” prims under a root prim with the name of this node.)

Transform

Specifies whether the geometry should be transformed into world space before being written out. This applies the object-level transform to the Relative Path Prefix prim and any other root prims in the generated USD stage.

Primitive Definition

Parameters in this group guide the translation process in terms of how USD primitives are generated from the source SOP geometry.

Packed USD Primitives

What to do with packed USD primitives in the imported SOP geometry.

Ignore

Ignore packed USD primitives in the source SOP geometry.

Overlay Transforms

Import the transformation of the packed USD primitive as an override (Over) prim. This makes it easy to transform the packed USD prims without unpacking them.

Overlay Transforms and Attributes

In addition to Overlay Transforms, point or primitive SOP attributes on the packed USD primitive are imported as primvars with constant interpolation.

Other Primitives

What to do with regular non-packed primitives (points, curves, polygons, spheres, and so on).

Define

Create the USD prims for the imported geometry if they don’t already exist. This is the standard way to import geometry.

Overlay

Create the USD prims as overrides. They will only be visible as changes to any prims that exist at a lower level with the same paths. This may be useful where you only want to import and modify certain attributes from SOPs onto existing USD geometry.

Overlay Transforms

Like “Overlay”, but only imports transform data.

Define Only Leaf Primitives

Author intermediate primitives (for example, any Xform prims created for the Import path prefix) as overrides instead of definitions. This means if they don’t match up with underlying prims in lower layers, the leaf prims won’t be added to the scene. This is useful if you only want to import the geometry if its ancestors already exist in the scene tree.

(Note that all of the data is still imported, it just may not be visible in the scene graph tree or the viewport.)

Packed Primitives

What to do with SOP-native packed primitives.

Create Xforms

Creates an Xform prim from the packed primitive’s transform and attributes, and the packed primitive’s geometry is imported underneath.

Create Native Instances

Import the geometry in packed primitives as instanceable references. This imports each piece as a prototype under a Prototypes prim under the Import Path Prefix prim.

Create Point Instancer

Import the geometry in packed primitives as point instanced geometry. This imports each unique piece as a prototype under the point instancer prim.

You can assign a SOP primitive attribute to the packed primitive named usdinstancerpath to specify the USD scene graph path of the instancer.

Unpack

Only imports the packed primitive’s geometry. Unlike the Create Xforms mode, this does not create any additional hierarchy, and is equivalent to unpacking the packed primitive prior to being imported. This can be useful for importing multiple pieces of geometry without merging their attributes.

Agents

What to do with agent primitives. In all modes, a prim is created from the agent primitive’s transform and attributes, and the agent’s geometry and animation are imported underneath.

Create Instanced SkelRoots

Imports the agent’s skeleton and geometry as instanceable references to a SkelRoot prim enclosing the skeleton and skinned primitives. This imports each unique agent definition as a prototype under an agentdefinitions prim under the Import Path Prefix prim.

Create SkelRoots

Creates a SkelRoot prim enclosing the agent’s skeleton and skinned geometry, which is imported underneath. This will be less efficient than Create Instanced SkelRoots for a large crowd, but can be useful for e.g. importing a single character where instancing is unnecessary.

Create Instanced Skeletons

Imports the agent’s skeleton as an instanceable reference to a Skeleton prim. This imports each unique agent definition as a prototype under an agentdefinitions prim under the Import Path Prefix prim.

Create Skeletons

Imports the agent’s skeleton as a Skeleton prim under the agent’s Xform prim. This will be less efficient than Create Instanced Skeletons for a large crowd, but can be useful for e.g. importing a single character where instancing is unnecessary.

Create SkelAnimations

Only imports the agent’s joint animation, creating a SkelAnimation prim. This can be used to efficiently import a sequence of frames, since the agent’s skeleton and rest geometry are typically unchanged between frames.

NURBS Curves

What to do with NURBS curve primitives.

Convert to Basis Curves

Import the curves as a BasisCurves primitive. This only supports cubic curves, but is useful for rendering through Hydra.

Create NURBS Curves

Import the curves as a NurbsCurves primitive. This provides complete round-tripping of NURBS curves, but has limited support for rendering through Hydra.

NURBS Surfaces

What to do with NURBS surface primitives.

Convert to Meshes

Import the surface as a Mesh primitive, which can be useful for rendering through Hydra.

Create NURBS Patches

Import the surface as a NurbsPatch primitive. This can be useful for round-tripping of NURBS surfaces, but has limited support for rendering through Hydra.

Kind Authoring

How to assign kinds to imported prims.

All Geometry is One Component

Set root primitives in the imported tree to Component. Do not set kinds on descendants.

Nested Groups and Components

Set leaf primitives in the imported tree to Component. Set branch primitives to Group.

Nested Assembly, Groups, and Components

Set root prims in the imported tree to Assembly. Set intermediate branch prims to Group. Set leaf prims to Component.

None

Do not set kinds on the imported prims.

Path Attributes

A (comma or space-separated) list of names of SOP primitive string attributes to use to use as prim paths to put the SOP geometry into. The default is path,name. See geometry hierarchy above.

If the list has more than one attribute, the importer checks each attribute for the first non-empty value.

If the string value a full path, that path is used as the USD scene graph path for that primitive. If the string is a relative path (or just a name), the string is appended to the Import Path Prefix string to generate a full scene graph path.

If none of the listed attributes exist on a given SOP primitive, or all values are an empty string, the importer generates a name automatically (for example, sphere_0).

Prefix Absolute Paths

Whether absolute path values from Path Attributes should be prefixed/parented or not. By default this is off and only relative path values are prefixed.

Import HeightFields as Mesh

If the source SOP geometry contains a height field volume, it will be imported as polygonal mesh. Other layers will be imported as vertex primvar if the values are varying, or constant primvar if the values are constant.

Geometry Handling

These parameters provide options to alter the interpretation of the SOP geometry data.

Treat Polygons as Subdivision Surfaces

For polygon meshes that are not already tagged with a subdivision scheme, author a subdivisionScheme attribute set to catmullClark. This will convert them to subdivision surfaces.

Subdivision Group

If Treat Polygons as Subdivision Surfaces is on, only convert polygons in this primitive group into subdivision surfaces.

Reverse Polygon Vertex Ordering

USD supports an orientation attribute on mesh primitives that indicates whether polygons have a left-handed or right-handed ordering, while SOP geometry is always left-handed ordering. When this option is on, the importer always reorders vertices (and associated primvars) to be right-handed.

This is useful when round tripping right-handed oriented polygons from USD into SOPs and back into USD. The data is always converted to a left handed ordering when importing it into SOPs. If you imported the polygons back into USD without this option, they would be left-handed, unlike the original.

Import Data

These parameters affect the conversion of SOP geometry attributes into USD attributes and primvars, and the choice between default and time sampled value authoring.

Author Time Samples

Whether values imported from SOPs should be authored as default values for the corresponding USD attributes, or as a time sample (at the time in the timeline).

(When the USD system is asked for an attribute value, it returns the default if no time samples exist on the attribute. Otherwise it returns a value interpolated from the time sample data.)

If SOP is Time Dependent

If the SOP node the geometry comes from is time-dependent (is animated or contains animated values), write time samples. Otherwise, write defaults.

If Not Specifically Excluded

Author all values as time samples except for attributes listed in the Single Value Attributes parameter.

Never

Author all values as defaults.

(This is the only parameter on this node you can’t pre-configure on the geometry with the USD Configure SOP. This is because it requires a “live” SOP, not just attribute values embedded in the geometry.)

Topology Attributes

Controls whether USD topology attributes should be authored as time sampled or default values.

Animated

If you know that topology is changing in the source geometry over time, choose this option to record topology attributes as time samples in the USD scene graph. Having animated topology can be very expensive during playback, so only use this option when necessary.

Static

Write topology attributes as default values. This can make playback much faster, but limits how the topology can change over time.

None

Do not author topology attributes.

This is useful when USD data is sent to SOPs for processing, then brought back into LOPs. Using this option tells the importer that the geometry topology has not changed in this process, so only the changing point positions or other primvars will be imported.

Attributes

A space-separated list of attribute names/patterns specifying which SOP attributes to import into USD as primvars.

In addition to matching attribute names directly, there are some values with special meanings:

bounds

Authors the USD extent attribute using the calculated bounding box of the associated SOP geometry.

visibility

Authors the USD visibility attribute based on the value of the usdvisibility geometry attribute.

See importing attributes for information on how the importer deals converts certain well-known Houdini attributes to their USD equivalents.

Indexed Attributes

A space-separated list of attribute names/patterns specifying which SOP attributes to import into USD as indexed primvars.

If a SOP attribute matches this pattern, the importer authors the primvar as an indexed array of values (that is, an array of values call primvars:name, and an array of indices into those values called primvars:name:indices).

Preparing an indexed primvar can be expensive for attributes that are not integers or strings. You should only use indexed primvars where it is likely to result in significant savings in storage size due to a small number of unique values being used across a large number of components.

Import as Single Element Array

A space-separated list of attribute names/patterns specifying which SOP attributes to import into USD as primvars with Constant interpolation (an array with a single value for the whole primitive), regardless of whether the SOP geometry attribute is a point, primitive, or vertex attribute. If multiple values could be chosen for a particular USD primitive, the importer chooses the first value it encounters. Importing as a single element array (versus Import as Single Value) can be useful since it allows the primvar’s interpolation to be overridden without changing the primvar’s type.

Import as Single Value

A space-separated list of attribute names/patterns specifying which SOP attributes to import into USD as primvars with Constant interpolation and a single value for the whole primitive, regardless of whether the SOP geometry attribute is a point, primitive, or vertex attribute. If multiple values could be chosen for a particular USD primitive, the importer chooses the first value it encounters. This is the default behavior for how detail attributes are imported. This is similar to Import as Single Element Array, but the primvar’s type is a scalar value instead of an array with a single element (for example, vector3f instead of vector3f[]).

Boolean Attributes

A space-separated list of attribute names/patterns specifying which integer SOP attributes should be converted to primvars of type bool.

Set Default Values

A space-separated list of attribute names/patterns specifying which SOP attributes to always author as default values for USD primvars (never time samples). This is the list of exclusions when Author Time Samples is set to “If Not Specifically Excluded”.

Partition Attributes

A space-separated list of attribute names/patterns specifying which SOP primitive string attributes represent subsets of the geometry. For mesh and curve primitives, the importer puts elements with the same value for this attribute into their own geometry subsets.

The importer will try to set the subset name to the attribute value, but may need to change the name make it a legal USD primitive name. The importer stores the raw attribute value on the geometry subset prim as Custom Data with the key partitionValue.

Prefix Subsets with Attribute Name

When creating subsets from Partition Attributes, the subsets are named by combining the attribute name with the partition attribute’s value (a string or integer). This avoids name collisions when multiple partition attributes contain the same values, but can be undesirable if precise control of the subset names is required. For string attributes, if this option is disabled the attribute values will be directly used as the subset names.

Subset Groups

A space-separated list of group names/patterns specifying SOP primitive groups. SOP polygon and curve primitives in each group will be imported as a geometry subset, named for the group.

USD Custom Attributes

A space-separated list of attribute names/patterns specifying which SOP attributes to import into USD as attributes (rather than primvars).

Translate UV Attribute to ST

Convert the SOP vertex attribute uv into a USD primvar called primvars:st. Whether you need to turn this on depends on which renderer you are using and how your shaders are authored. If you are rendering with Karma, leave this off.

(As of this writing there is no strict standard for texture coordinate naming in USD, but the use of st is a common convention, whereas in SOP geometry, using uv is the common convention.)

Export

Save to Disk

Click to write out the layers generated by a LOP network to USD files.

Save to Disk in Background

Starts another copy of Houdini in the background and instructs that copy to cook and save the USD files generated by the LOP network. This allows one to continue working in the current Houdini session.

Controls

Click to open a dialog that lets you launch a “one-off” render with different frame range and dependency settings.

Valid Frame Range

See saving animation above for more information.

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. The Flush Data After Each Frame parameter controls whether to write out data to disk after each frame, or to generate animated data in memory before writing out all the data at once.

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 save to disk. If the stage does not have this metadata set, executing a save 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.

Render with Take

Render with the parameter values stored in this take.

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.

Flush Data After Each Frame

When this is on, the node writes out each frame’s data to disk before cooking the LOP Network to generate the next frame of data. When this is off (the default), the node cooks the data for all frames into memory and writes out the animated files all at once. Turning on this option ensures that only a single frame worth of data is in RAM at any one time, allowing arbitrarily large USD files to be created. But saving each frame can be slightly slower, and the generated files may be larger because of the way USD files append new data to an existing file. See saving animation above.

When this option is on, this ROP can also generate separate USD files for each frame. To do this, embed the local variable for the current frame number in the Output file path (and other layer save paths) so each frame will write out files with unique names. For example:

$HIP/usd/scene_$F4.usd

See expression in filenames for more information.

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.

Use Relative Paths

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.

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).

Scripts

A script command can be specified for execution at various execution points. The expression language selected for the script parameter determines whether the command is in hscript or python.

Prior to execution, this node is automatically set as the global current node.

To run statements from a file, specify the path to the file with either a .cmd extension (when the language is set to Hscript) or a .py extension (when the language is set to Python). Additional arguments to the script can also be supplied. They will be parsed in a shell-like manner.

Pre-Render Script

Run this script before any rendering.

Pre-Frame Script

Run this script before each frame.

Post-Frame Script

Run this script after each frame.

Post-Render Script

Run this script after all rendering.

Initialize Simulation OPs

Initialize DOP simulations before rendering.

Alfred Style Progress

Print percentage complete value as files are written. This is in the style expected by Pixar’s Alfred render queue.

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.

See also

Geometry nodes