Houdini Solaris and USD Guide: Organize Architectural Scenes with Layers

This guide explores the Solaris and USD workflow described in SideFX’s Houdini 22.0 documentation, with a focus on architectural modeling and visualization. Solaris brings together USD scene creation and editing with the Karma rendering process in one production environment. The core idea is to assemble different scene elements through layers and references rather than putting everything in a single file.

1. Plan a layered scene structure

A USD scene can be built from data layers connected to one another. For example, in an interior project, the main scene can bring in elements such as furniture or lighting from separate files. The resulting scene, assembled from these layers, is called a “stage.” A stage is the composed result of evaluating the data together, rather than the source files themselves.

One key benefit of using layers is that edits can be kept separate from the underlying data. Adding a new layer to an existing scene and defining changes there makes it possible to create an alternative without directly modifying the main layer. When an asset is updated, relationships between layers can also help make other edits available alongside the new version. This structure supports multiple people or teams working on a shared scene, but the source materials do not prescribe a mandatory layer scheme for projects.

To get started, follow these steps:

1. Identify the scene elements and the edits that need to be kept separate.

2. Decide whether these elements should live in separate files or in layers created during the workflow.

3. Add and compose the layers in the scene, keeping track of which layer each piece of data comes from.

4. Test whether keeping changes in a separate layer, rather than writing them to the base asset, suits your workflow.

These steps provide a starting framework for understanding USD’s layer logic; they do not define a specific folder structure or file-naming standard.

2. Use LOP networks in Solaris

LOPs in Solaris are nodes that apply operations to a USD scene in sequence. Each node takes the scene from the previous step, modifies it, and produces its own output. A LOP network therefore presents scene creation and editing as a chain of operations. The workflow is similar to SOP networks for working with geometry in Houdini, except that the data processed by the nodes here is a USD scene.

Solaris’s higher-level operations help you build scene content without having to manually edit USD’s lower-level structure each time. Still, understanding foundational terms such as prim, property, and layer makes it easier to see what the nodes are doing. SideFX’s documentation also notes that LOP parameters use USD terminology and, in some cases, rely directly on USD functions.

To inspect the result produced by a network, right-click the relevant LOP node and select LOP Actions › Inspect Flattened Stage. This displays the scene output using USDA syntax. That lets you check the resulting scene structure at the end of the network, rather than looking only at the node connections.

3. Distinguish prims, properties, and connections

A USD scene can be thought of as a tree made up of basic elements called prims. A mesh, light, or material can be represented as a prim; prims can have names, properties, and child elements. Properties that describe a prim’s appearance or data come in two main forms: attributes, which carry values, and relationships, which connect to other prims.

For example, an attribute might store a value such as an object’s dimensions. A relationship can link two scene elements, such as specifying which material is associated with a mesh. This distinction helps you understand, when reading a scene structure, which data is a value and which is a connection.

When layers are composed, the same property may have different values. A value in a stronger layer can override one in a weaker layer. This lets you define a different value for a particular scene without changing the base asset file. In Houdini, a Reference LOP can add another layer as a reference to the layer being created, while a Sublayer LOP can load a USD file into the layer stack of the current stage. These are different operations and should be chosen according to the task.

USD also includes a special type of attribute called a primvar. Primvars can be used to affect material parameters; how their values are distributed across geometry is determined by interpolation information. SideFX’s documentation describes distribution types such as Constant, Uniform, FaceVarying, and Vertex. These details matter particularly in scenes where geometry-bound data needs to affect a material or the rendered appearance.

4. Check file formats and tool capabilities

The .usd extension alone does not tell you whether a file contains readable text or binary data. .usda denotes the text format, while .usdc denotes the binary format. This distinction matters when you need to inspect a file in a text editor or assess its contents technically.

Houdini’s Component Builder tool can set up a network as a starting point for creating a USD model from SOP geometry. According to SideFX’s documentation, the tool supports materials, variants, payloads, and layers. The Solaris documentation also explains that MaterialX-based shaders can be used with Karma. However, this does not mean that all data will transfer seamlessly between different applications; the available sources do not provide a specific compatibility matrix.

The documentation this guide is based on covers Houdini 22.0. If you’re working in another version, check that version’s help documentation rather than assuming the same tools and behavior apply. The sources do not provide details about hardware requirements or licensing conditions, so verify these separately before setting up a project.

Impact on architectural and archviz workflows

A layered USD setup can bring together different types of scene data, such as models, materials, and lighting, while keeping edits separate. Teams working on a shared scene may benefit from being able to add their own changes without directly modifying the underlying data. LOP networks in Solaris also let you build these changes in stages.

Before starting production, decide which layers will hold the files, how references will be used, and which Houdini version the team will work with. Also, check that the project files are compatible with the target applications and available hardware using a small test scene. Since the source documentation provides no definitive requirements for these points, project-specific testing cannot be replaced by a general rule.

Common mistakes

• Assuming a .usd file is always readable text; the extension can also be used for binary format.

• Putting every edit in the base asset file; this overlooks the option of using layers to keep edits separate.

• Treating prims, attributes, and relationships as the same thing; they have different roles as scene elements, values, and connections.

• Looking only at the nodes in a LOP network without checking its final output; inspect the Flattened Stage view when needed.

• Assuming information in the Houdini 22.0 documentation applies in the same way to other versions without verifying it.