Houdini Solaris and USD: A Layered Workflow Guide for Architectural Scenes

Houdini Solaris is described in SideFX’s Houdini 22.0 documentation as the collective name for its USD-based scene-building, look development, and Karma rendering tools. For architectural visualization teams, Solaris’s core idea is to build a scene as a set of interconnected layers rather than treating it as a single, immutable file. This guide maps the basic concepts of USD to LOP networks in Solaris to explain how to create a repeatable workflow.

1. Plan the scene as USD layers

USD is a system for describing 3D scenes by combining layers. In a residential interior scene, for example, the main scene might reference separate files containing furniture, lighting, and other elements. SideFX’s kitchen example also brings together assets such as chairs and tables, along with lighting, in a main file. This approach is designed to make it easier for different teams to work on parts of the same scene.

Before you begin, decide which content should be managed as separate pieces. For example, keeping furniture assets and the lighting setup in separate layers makes it easier to track where changes are made. Layers are more than just file separation: they can represent a specific part of a scene, such as an asset, character, rig component, or lighting setup. In Houdini, nodes in a LOP network modify the incoming USD scene and produce a new scene output.

2. Keep edits separate and non-destructive

A key benefit of USD’s layer-based approach is that it can keep edits in a new layer instead of directly changing the existing scene. This means a new edit does not automatically affect others using the same base scene; team members can choose whether to use that layer. Replacing an asset with a newer version may also allow existing edits to be reapplied.

In Solaris, you can use a Layer Break LOP when you need to create a new layer in the network. Use a Sublayer LOP to add a USD file from disk to the current stage’s layer stack; use a Reference LOP to reference a layer created within the LOP network. Although these nodes may appear to serve similar purposes, the documentation describes them as handling different operations: one loads an existing sublayer, while the other references a created layer.

1. Define the boundaries of the main scene and the content to be managed separately.

2. Create separate layers for edits that should preserve the existing data.

3. Add a layer from disk with a Sublayer LOP, and a layer created in the network with a Reference LOP.

4. Treat the scene resulting from the combined layers as the stage.

3. Read stages, prims, and properties correctly

A stage is the name for the final prim tree computed by combining USD layers. A USD file can be a layer on its own; in another context, loading the same file as the top level can create a stage. So it is not accurate to draw a strict distinction between a “stage file” and a “layer file” based solely on the file extension.

The basic units within a stage are prims. A mesh, light, material, or object carrying transform information can be a prim. Prims can contain properties and child prims. The two basic types of properties are attributes and relationships: an attribute holds a typed value, such as size or color, while a relationship connects one prim to another. For example, a material assignment can be thought of as a relationship between a mesh and a material.

When layers carry different values for the same property, the stronger opinion in the combined layers can override the other value. That’s why, when an unexpected change occurs, you should check which layer is affecting the property rather than looking only at the final visible value. Solaris lets you build high-level operations through LOP nodes; you do not need to manually edit USD’s lower-level structure in every case.

4. Verify the scene result and file format

To inspect the stage produced by a LOP node, right-click the node and select LOP Actions › Inspect Flattened Stage. According to the documentation, this displays the stage output in usda syntax. It’s a useful verification step for checking which prims and properties are present after the layers have been combined.

Choose file extensions according to your workflow, too. A file with the .usd extension can be in binary or text format. .usda indicates readable plain text, while .usdc indicates binary format. This separation of extensions is intended to avoid confusion in asset tracking or version control when changing file formats. The documentation also notes that you can add plain-text USD code to a stage using an Inline USD LOP; treat this as an option for debugging when needed, not as the usual way to build a scene.

What this means for architecture and visualization teams

This approach is useful for teams that want to manage assets, lighting, and other parts of the same architectural scene in separate layers. Separating an edit from the base scene can reduce the risk of unintentionally changing the work of team members using the same content. The ability to update layers also supports handling asset or lighting changes alongside existing edits. The benefit here is not an automatic render speedup; it’s greater control over how scene data is edited and shared.

Offices evaluating Solaris and USD should first test compatibility with their existing file and asset structures, layer responsibilities within the team, and the Houdini version in use. The SideFX documentation provided is for Houdini 22.0; since no compatibility guarantee for other versions is given here, validate the workflow in the target installation before migrating production scenes. These sources do not provide details about hardware or licensing requirements, so it is not possible to make specific recommendations on those topics.

Common mistakes

• Putting every edit in a single layer can make it harder to track where each change came from. Consider separating content by function.

• Don’t assume Reference LOP and Sublayer LOP do the same thing: the documentation describes them as bringing different sources into a scene.

• Don’t assume the .usd extension always means text or always means binary format. Note the distinction between .usda and .usdc for text and binary formats.

• Don’t use Inline USD LOP as the default editing method. SideFX describes it as an approach that may be useful for debugging when needed.