On this page |
Overview ¶
USD defines a hierarchy of model kinds. “Component” models are roughly equivalent to Geometry Objects in Houdini. A component represents a single “thing”, like a lamp or a kitchen table, which can be referenced or instanced. (The other kinds, “group” and “assembly”, represent higher-level groupings of components. The component kind is the “leaf” type, and is not allowed to have other model kinds inside it.)
If you're coming from a traditional Houdini background, a component is like an Object-level HDA which contains geometry, as well as its own material network. You can re-use it, and also customize a particular instance without changing the original.
The Component Builder tool automates or enforces various best practices (this is especially useful for artists and studios new to USD):
-
Sets up the geometry as a payload so the artist can easily unload it, and still see a bounding box in the viewport.
-
Organizes the files on disk in a directory structure.
-
Makes it easy to add variants (alternative shapes and/or material looks for the model).
-
Sets up composition arcs on the prims so the model inherits from a class primitive. This makes it easier to apply shot-level customizations to the component.
-
Each component keeps its geometry and materials in separate files (layers). This adds flexibility, for example to replace a file without having to regenerate, or reference in just the component’s geometry without its materials.
Often, you will have a single small .hip
file just to generate and write out the USD for a component, or possibly one large .hip
file that has multiple component builders to generate different components all from the same file. Then in a separate .hip
or USD file for a scene, you would reference in the generated component layer file for each component.
See using the component output for more information on writing the result to disk and how to use the component.
Nodes ¶
The tool creates a network snippet with the following nodes:
|
Contains a SOP network you use to define the model’s geometry. Double-click this node to dive inside to the SOP network. |
|
|
Contains a material network you use to define materials specific to this model. Double-click this node to dive inside to the material network. |
|
|
Assigns materials from the material network onto specific faces/surfaces of the component geometry. You can assign materials defined in the model-specific node above. |
|
|
Puts together the other parts (geometry, material, metadata) and creates a final USD prim for the model. |
There is an extra node you can add to the network to create model variants, that is not created by default:
|
Lets you merge multiple Component Geometry nodes as variants of the component. See how to create variants below. |
How to ¶
To... | Do this |
---|---|
Set up and use the component builder network |
|
Materials ¶
To... | Do this |
---|---|
Assign materials to groups (face sets) |
|
|
Variants ¶
To... | Do this |
---|---|
Build geometry variants |
USD lets you switch a model between multiple variants. For example, one tree component can contain multiple different tree models for different species (elm, spruce, larch, and so on).
The default name for the geometry variant set is |
Use materials specific to a geometry variant |
If a material is specific to a geometry variant, you can assign it using a Component Material node (with a Material Library or Reference node connected to its second input) wired in between a variant’s Compontent Geometry node and the Component Geometry Variants node.
|
Build material variants |
The default name for the material variant set is |
Set the default variant(s) |
You can set the default geometry and material varaints (the ones used when someone references the component without explicitly specifying a variant they want).
|
Extras ¶
You can double-click the Component Output node to dive into a contained LOP network. You can wire additional LOP nodes (starting from the Input Stage
pseudo-node) into this network to further modify the prims created by the component nodes under /ASSET
. Any modifications you do in this network are separated into an extras.usdc
layer in the file output that overrides the weaker opinions authored by the component nodes.
This might be useful, for exmaple, for lighting, or some keep-alive animation cycles.
Tips and notes ¶
-
You can insert other LOPs between the Component Material and Component Output node. Just set them up to edit the “temp” asset prims (under
/ASSET
) created by the Component Geometry and Component Material nodes. -
If the geometry you want to use for the component already exists on disk or in an existing SOP network, you can swtich the Component Geometry node’s Source parameter from Internal SOP network to File or External SOP.
-
If the geometry you want to use has already been imported into LOPs earlier in the LOP network, you can switch the Component Output node’s Source parameter from Upstream Component Geometry to Scene Import (to process an existing prim that was generated by the Scene Import LOP) or Input Primitives (to use an existing prim with geometry and materials under it).
-
Currently the component builder network does not allow multiple or nested geometry variant sets.
Prim output ¶
The output scene tree looks like the following, where <component>
is the name of the root prim (see about the class prim for information about the extra prim under __class__
).
/<component> (xform) ← Component Kind /geo (scope) ← Display Purpose: default /mtl (scope) /__class__ (class) /<component> (class) ← Inherited by /<component>
If you use the extra outputs inside the Component Geometry node to define display and/or simulation proxy geometry, the geo
prim will have extra branches under it:
/<component> (xform) ← Component Kind /geo (scope) /proxy (scope) ← Display Purpose: proxy /render (scope) ← Display Purpose: render
Managing purpose on a parent primitive can help Hydra avoid update issues and crashes, and it also makes it clear to artists what geometry to expect at that location in the scene.
Use the component output ¶
The end goal of a component builder network is usually to write out the component to its own self-contained USD file, which can then by referenced by other USD files (or Houdini Solaris scenes) that need to use the component. This hierarchy of files referencing files referencing files one of the main organization principles of USD.
Within the LOP network you set up to generate the component, the output of the node is a stage with the component in a prim at the root level. This prim is ready to be written to a USD file (it conforms to the requirement that files to be referenced in have a single prim at the file’s root level). The information is not actually written to disk until you use the controls on the Component Output node to write out disk files.
Tip
The component builder network is set up to output files to disk, but you can reference the output component prim from elsewhere in the same network if needed (see below).
When writing to disk, the component builder always outputs a directory of related files (see directory structure below for more information). This is a best-practice. It groups together related files (layer files, a thumbnail image of the model), it makes it easy to add more files related to the component (for example, a read_me.txt
file), and it only requires the directory name to be unique (the files inside can have generic names).
To... | Do this |
---|---|
Write the component out into a directory of USD layer files |
|
Reference a component file in another scene |
|
Reference the component within the same network |
You can reference the component into a separate scene tree in the same network without having to write it out to disk.
|
Generate an automatic thumbnail image |
The Component Output node has options for creating a thumbnail image for the component. You can use this thumbnail image in Houdini’s asset gallery or an asset management system.
If you set Mode to Render or Houdini GL , you can turn on Auto-generate on export to always regenerate the thumbnail when you write out the USD files. Tip If Houdini finds a |
Generate a thumbnail image with custom camera and lights |
The Component Output node has a second input, which can be used to setup a camera, lights, and other objects for an asset’s thumbnail.
Tip You can turn on Save Thumbnail Scene to Disk, which will create a |
Add the component to an asset gallery database |
The Component Output node has a button to automatically add the files written to disk to the USD asset gallery (as used by the Layout node). This requires that you have already written the files to disk. It simply uses the file paths of the output files to add an entry to the layout database. Note that the default output path for files puts the files in a directory relative to the current
Tip To view the asset gallery in a floating window, in the main menus choose Windows ▸ New Floating Panel. Then right-click the pane tab in the floating panel and choose Solaris ▸ Layout Asset Gallery. |
About the class prim ¶
The component builder sets up the component so it inherits from a prim at /__class__/‹prim_name›
(for example, if the root prim is /campfire
, that prim inherits from /__class__/campfire
).
Inherits are a very powerful and useful feature of USD. Basically, every time the component is referenced into a scene tree, USD checks whether in that tree a prim exists at the path it wants to inherit from. If the inherit-from prim exists, its attributes override those on the component. This lets you customize prims based on the context in which they appear.
In Houdini, when you reference in a prim with an “inherits” composition arc on it, you can right-click the prim in the Scene Graph Tree and choose Edit Primitive ▸ New Node to Edit Inherit ‹inherited path›. This will automatically create a new Edit Properties node in the LOP network that lets you override properties on the inherited prim (and so customize the inheriting prim in this scene only).
(Future versions of Houdini may add tools to make inherits easier to set up, visualize, and edit.)
Directory structure ¶
The directory output of a component builder network (without variants) look like this:
/campfire campfire.usd ← Main file, points to payload payload.usdc ← References shape and material layers geo.usdc ← Shape data mtl.usdc ← Materials thumbnail.jpg
The directory may contain other files, such as texture maps. If you added extra nodes inside the Component Output’s contained network, the directory will include an extra.usdc
file with the changes created by that network.
Tip
You can change the names of the “sidecar” layer files (payload.usdc
, geo.usdc
, mtl.usdc
, and extra.usdc
) in the Component Output node’s parameters under Caching ▸ Export Options.
This diagram shows how the “main” asset file references the other files:
(The payload layer uses references, rather than a sublayering, to ensure that the opinions of each layer can override the preceding, weaker layer, even when using variants.)
Variant files ¶
If the component builder network sets up variants, the Component Output node generates a sub-directory called variants
. Inside the subdirectory, for each variant there is a thumbnail and a simple layer file that references in the component with the given variant set as current. This makes it easy to treat variants as individual assets, for example in the Solaris asset gallery.
/campfire campfire.usd payload.usdc geo.usdc /maps wood_diffuse.exr wood_normal.exr mtl.usdc thumbnail.jpg /variants campfire_blazing.usd campfire_blazing_thumbnail.jpg campfire_calm.usd campfire_calm_thumbnail.jpg campfire_smoldering.usd campfire_smoldering_thumbnail.jpg
See also |