Houdini 18.5 Solaris

LOPs and USD Glossary

On this page


The following is a glossary of terms related to LOPS and USD in general.

The full Pixar USD documentation can be found here.

This document has been produced to aid Houdini users in finding and understanding the most common USD terms and will help to clarify any overlap in terms that occur in both USD and Houdini. Each heading starts with a link to the Pixar USD docs. If there is no text under a heading we consider this term to be not among the most-common terms. If there is no USD link, the term is not a USD term, but a Houdini or explanatory term.


Active / Inactive

Original OpenUSD definition

A non-destructive behavior that allows you to “prune” prims (and their children) from a stage. You do this on a composed stage (on the fly). By default all prims are active. It is similar to the concept of the Houdini display flag on object nodes.

An important characteristic of USD prims is they cannot be permanently deleted from a composed stage, (mostly because once something is on the stage, anyone may reference it to drive something). USD does support deactivation, which is a non-destructive deletion. Activation is another opinion, meaning it will be resolved through composition.

This is often used to visualize the scene without some affect, for example removing scene lighting to see character-specific lights better. Just like in Houdini, activation and display are different concepts. However, in Houdini, turning off the display of a light does not effect the light’s contribution to a scene. In LOPs/USD, turning off the display of a light does actually turn off its contribution.

In LOPS, use the ''Configure Layer'' or the ''Prune LOP'' to set activation.

See also “muting” and “visibility”.


HOUDINI NOTE: The point attribute “active” is used in Houdini Bullet RBD sims to control active and inactive objects.

Active Layer

Most LOP nodes perform edits to data on the USD stage copied from their first input. These edits are created in the “active layer”, which is always the strongest sublayer on the root layer of the LOP node’s stage.


Although not part of USD at all, Alembic support is included in USD. However, USD is not “alembic but faster.” USD does comes with its own format that can store data, but it is a much wider scene description with ways to describe variations, layers, nested sub layers, different display purposes, plus the ability to define your own data formats.

See also “USD” and LOPS.

API Schema

Original OpenUSD definition

Choose to create an API Schema when you have a group of related properties, metadata, and possibly associated behaviors that may need to be applied to multiple different types of prims. For example, if your pipeline has a set of three attributes that get authored onto every gprim, and you want to have a robust schema for authoring and extracting those attributes, you could create an API schema for them.

See also "schema".


An AOV is an "auxiliary output variable," and although not a USD term, it is an accepted industry term to describe what have traditionally been called "Extra Image Planes" in Houdini. In the LOPs context we will refer to these as AOVs, but you will still see "extra image planes" elsewhere in Houdini.

An AOV is an rendered image that isolates one part of the rendering process (EX: diffuse contribution, specular contribution) or some arbitrary data (EX: ID, depth, velocity). These are created at render time during the rendering of the "beauty" pass and can be saved as individual files or exr layers.

AOVs may also be referred to as an "arbout" (arbitrary output), a "deep raster," or "rendervars." AOVs are not to be confused with "render passes" which are completely separate renders, (which might include AOVs as well).


Original OpenUSD definition

Assemblies are group models, i.e. models that aggregate other models into meaningful collections. An assembly may consist primarily of references to other models, and themselves be published assets.

Assemblies, groups, components and sub-components are organizational frameworks to help you manage your stage. Let’s look at the example kitchen scene that ships with USD and with Houdini. In this scene we have a kitchen with many other pieces of furniture, appliances, etc. It is obviously beneficial to group these pieces in a way that makes sense in everyday language.

Organizational Name


Model Kind?

Set Draw Mode?

Can Contain Kinds?



Yes ✔

Yes ✔

Assembly, Group, Component ✔


Dining Table

Yes ✔

Yes ✔

Group, Component ✔


Chair 1

Yes ✔

Yes ✔

Subcomponent ✔


Chair 1 Cushion

No ⤬

No ⤬

No ⤬

You cannot put anything under a sub-component. Sub-components may have leaves, (individual polys that make up the cushion for example). You also cannot set the draw mode on a subcomponent, (shaded, wireframe, bounding box).

In USD an assembly is a kind of Model.

See also “model” to understand what a "model kind" is.


Original OpenUSD definition

Asset is a fairly common organizational concept in content-producing pipelines. Assets can be a single file (e.g. a UV texture), or a collection of files anchored by a single file that in turn references others. An important quality of assets is that they are generally published and version-controlled. The ascii USD format uses a special syntax for asset-valued strings to make them easily differentiable from ordinary strings, using the "@" symbol instead of quotes to delimit their values. See AssetInfo for an example.


Asset Resolution


Original OpenUSD definition

Attributes are the most common type of property authored in most USD scenes. An attribute, (like in the rest of Houdini) is simply some sort of value (such as a color, a float, a transform matrix, or an array of values). Attributes can be animated, with each time sample stored in an array.

Attributes resolve according to "strongest wins" rules, so all values for any given attribute will be fetched from the strongest PrimSpec. For example, a "weak layer" with a default value will be masked by a stronger layer with animation. This would be the case where the layout department places a prop in the scene, and later the animation department animates that prop.

If you ask USD for the value at the "default" time, it will return the default value if one is set, otherwise it will return an empty value. All time sample values are ignored. If you ask for a value at any other time, and there is any default or time sampled value set, you will get back a value. This value may be the default (if you request the value for a time before the first time sample), the closest time sample value, or a linear interpolation of the two surrounding time samples.

Attribute Block

Attribute Connection

Attribute Variability

Change Processing


Original OpenUSD definition

USD Collections can be thought of as groups for prims, and LOPs has a few mechanisms to make working with collections convenient, some of which are covered in the Target Patterns section. They are similar to Houdini bundles.

A collection consists of a separate "Include" and "Exclude" list.


Original OpenUSD definition

In USD a component is a "leaf" kind of Model. Components can contain subcomponents, but no other models children.

See also assembly for an explanation of assembly, group, component and sub component.


Original OpenUSD definition

Composition is the process that assembles multiple layers together by the composition arcs that relate them to each other. Composition occurs when first opening a UsdStage, when loading or unloading prims on the stage, and when layers that contribute to the stage are edited.

We also sometimes refer to "a composition" or "a composed prim" or "a composed scene", in which contexts we are referring to the result of performing composition.

In LOPS, the Composition tab in the Scene Graph Details will show all composition arcs contributing to a prim/attribute, which are known as "PrimStacks and "PropertyStacks respectively. PrimStacks / PropertyStacks are a bit different from Layer Stacks, though similar in principle.

Composition in USD is a pretty deep topic, so don’t be surprised when it takes a while before concepts start to sink in. You can get an awful lot of mileage out of Sublayers, References/Payloads, and VariantSets. While it’s good to understand all of the composition arcs, these three are definitely the most frequently encountered. Here are the arcs from strongest to weakest:

  1. Layer Stack

  2. Inherits

  3. VariantSets

  4. References

  5. Payload

  6. Specializes

See also LIVRPS Strength Ordering.

Composition Arcs

Original OpenUSD definition

Composition arcs are the "operators" that allow USD to create rich compositions of many layers where stronger layers override weaker layers. The six kinds of arcs are subLayers, inherits, variantSets, references, payloads, and specializes.

See also composition.

Context Options

Context Options are special variables that can be used to alter the context of a LOP network. For example, one could use these to switch a graph between several different shots or for wedging different lighting setups. Context options can be global, or special blocks can be setup in the network, to locally set context options. ForEach LOPs can be thought of as a specialized flavor of context options.

Crate File Format

Original OpenUSD definition

The binary form of a USD file: .usdc. Note the ".usd" file format is special, as files with that extension can be either crate or ascii files. You can convert between file formats using usdcat.


Draw Mode

In CG in general the "draw mode" would be the way geometry is drawn to the viewport, (wireframe, shaded, etc). In USD it is a piece of metadata you can set on primitives that are in a valid Kind Model hierarchy to control whether that prim and its children are drawn as full geometry, bounding boxes, textured cards, or axes at the prim’s origin.

Explicit Layers

An explicit layer is a USD layer created during the processing of a LOP Network as a result of the user asking for a new layer to be created. This includes layers created after a Layer Configure node set to "Start New Layer", or where a save path has been set. Explicit layers will not be combined with other layers during USD output, except in Flatten All Layers or Flatten Stage mode.

See also Implicit Layer.

File Formats

  • .usda: ascii (human readable form usually used for department or high level layers)

  • .usdc: binary Crate (fastest to read and write, usually used for large caches)

  • .usd: can be either of the above


You can use the usdcat utility to convert between file formats.

Fx artists may also be interested to know that for any of the above you can store time samples of your choosing ( 1,2 ,3 4.. or 1.25, 1.50,1.75,2.0). You can also choose if you save each time sample in separate files or in one file for a sequence of samples.


Original OpenUSD definition

Flattening refers to combining multiple USD layers into a single USD layer that is, once composed, equivalent to the original set of layers. USD is capable of two different methods of flattening. In Layer Flattening, the layers are flattened together prior to composing the layers. This means that composition arcs like references and variants continue to exist in the flattened layer. The other form is stage flattening, in which the composed stage is flattened, with all composition arcs already applied. This means the contents of all referenced or payload files are combined into the single generated layer. Variant and other internal arcs are hardened to their current values, making it impossible to know that a primitive ever had a variant arc.


See references.


Original OpenUSD definition

Gprim comes from Pixar’s Renderman terminology, and is a contraction for "Geometric primitive", which is to say, any primitive whose imaging/rendering will directly cause something to be drawn.


Original OpenUSD definition

Groups are models that aggregate other models into meaningful collections. They are the "glue" that holds a model hierarchy together. A group has no geometry of its own, it is a container for other models, similar to object subnets in Houdini.

See also assembly for an explanation of assembly, group, component and sub component.

HoudiniLayerInfo Primitive

LOP stages store additional Houdini-specific metadata that is used during the save process of a USD ROP, or by the cook methods of certain LOP nodes. This metadata is stored on a dedicate USD primitive at /HoudiniLayerInfo in the scene graph, which is a custom USD primitive type called 'HoudiniLayerInfo'. It is not required for any external tools to know about this special primitive type because this primitive is removed during the save process (unless you explicitly request that the save process preserve Houdini specific custom data, which is generally only useful for low level debugging of LOP Network behaviour).


Original OpenUSD definition

Hydra is the mechanism used to draw the USD stage to the viewport. The plugin to which hydra passes the information to be rendered is called the render delegate. Houdini ships with an OpenGL delegate, the example Embree delegate, and of course Karma.

Implicit Layers

Implicit layers are layers created in memory by the LOP Network which may be flattened into other explicit layers (also created by the LOP Network), and thus disappear as independent entities during the save process (though any opinions they express are preserved by the flattening).

This includes the layers created by LOP nodes with the debug flag set, or the new layer started automatically by a Merge LOP in Separate Layers mode.

See Explicit Layers.



Original OpenUSD definition

Inherits are similar to a local reference, but remain “live” through multiple levels of references. You would generally use inherits to derive alterations on a base “class” asset like a tree or material.


Original OpenUSD definition

USD provides instancing in two forms:

  • Native instancing is a property that tells USD to generate a single “master primitive” in order to efficiently represent many copies of an asset.

  • Point Instancer is a special schema that allows for representing vast copies of geometry efficiently.

Both types of instances support transforming the top-level of each primitive and they also allow you to author primvars (on the native instance individually, or on the point instancer primitive) to set per-instance material properties. Native instances are actual transforms on each instance, and each instance is represented in the scene as unique namespaces. They are easily promoted from instances to hero (you just turn their “instanceable” property off).

Point Instancers are fast, but the transforms of all instances are set as array attributes on the point instancer primitive. Promotion involves mutating the scene. Point instances should be preferred mostly based on the number of instances that will exist.


Karma is the new CPU-based renderer used in LOPS. It ingests USD and is designed to work with the Hydra API; we will continue to ship Mantra for rendering legacy files but all new development is on Karma.

See also delegate.


Original OpenUSD definition

We use kind to classify prims in USD into a higher-level categorization than the prim’s schema type provides, principly to assign roles according to USD’s organizational notion of "Model Hierarchy". See the section on assembly for more information.


Original OpenUSD definition

A layer is either an indiviual usd/usda/usdc file on disk, or may be created in memory by LOP nodes, to be written to disk later. It is not unusual to have hundreds or thousands of layers in a scene. They are composed together to present the user with a complete view of the scenegraph.

For example, the contributions of the modelling department could be one or more layers containing a model or models. Each prop/character/asset is likely to have its own layer, and even possibly several layers per asset. The layout department would create layers that reference those individual assets and assemble them into a scene. The contribution of the animation department would be the animation of some or all of those layers.

Layers contain opinions about the prims in the scene graph. Some of these opinions define prims and values, while others overlay values. Layers are read in from files on disk, and can also exist purely in-memory (known as “anonymous” layers).

You can mute a layer or sublayer which causes it to not affect the scene. This is useful when a layer breaks something or slows down playback or interactivity.

In LOPS, you would use a ''Configure Layer LOP'' to set a layer’s properties and a ''Configure Stage LOP'' to set layer muting and population masks for the scene.

See also Implicit Layers.


Original OpenUSD definition

LayerStacks are the keystone to understanding composition in USD. The definition of a LayerStack is simply: "The ordered set of layers resulting from the recursive gathering of all SubLayers of a Layer, plus the layer itself as first and strongest."

The LayerStack is important to understanding composition for two reasons:

  • Composition Arcs target LayerStacks, not Layers. When a layer references (or payloads or sub-layers) another layer, it is targeting (and therefore composing) not just the data in the single layer, but all the data (in strength-order) in the LayerStack rooted at the targeted layer.

  • LayerStacks provide the container through which references can be list-edited. Many of the composition arcs (as well as relationships) describe not just a single target, but an orderable list of targets, that will be processed (in order) according to the type of the arc. References can be "list edited" among the layers of a LayerStack. This can be a powerful method of non-destructively changing the large-scale structure of a scene as it flows down the pipeline.

For example, we might have a generic version of a special effect added into a scene at the sequence level. Now, at the shot-level, we have a shotFX.usd layer. In this particular shot, we need to replace the generic turbulence effect with a different one, which may have completely different prims in it. Therefore it is not enough to just "add on" an extra reference, because the prims from turbulence.usd will still "shine through" - we must also remove the weaker reference, which we can do via list editing.

Contributions to a shot, such as the character animation or camera, would generally be sublayers.


The term “leaf” is not a USD concept, but a general concept meaning the part of a branching structure with no children. In a file tree, the final file in a nested list of directories and files is a leaf type.

LIVRPS Strength Ordering

Locked Stage

When the output of a LOP node is accessed through the second or layer input of a Sublayer LOP or a Reference LOP, or when the composed stage of a LOP node is accessed by a LOP Import SOP, the composed stage generated by that LOP node needs to be locked. A locked stage is a copy of the LOP node’s shared stage, but with the contents of the active layer copied to the root layer of the stage. A locked stage is guaranteed not to change, and like a file on disk, cannot be modified by other LOP nodes further down the cook chain.


Houdini’s lighting and look development context is LOPs, which stands for Lighting Operators. LOP Networks are similar to SOPs, however instead of using Houdini’s geometry model, LOPs uses USD scene description.

LOP Stage / Shared Stage

Every LOP node can generate a composed USD stage. But the underlying USD stage may be shared between several LOP nodes in a chain, for performance and scalability reasons. So when referring to the composed stage generated by a LOP node it may be referred to as either the LOP Stage or the Shared Stage, depending on whether or not it is relevant that the stage may be shared. But both terms refer to the same thing.


Original OpenUSD definition

In USD, "model" is neither a singular component nor a plural group container - it is just the "abstract" commonality between components and groups.

We label certain prims as models to partition large scenegraphs into more manageable pieces:

  • a core "leaf model" kind: component

  • "models that aggregate other models": group

  • "models that aggregate other models": assembly


Do not think of USD "models" in the traditional Computer Graphic sense. A USD "model" is an abstract concept that is used partition large scenegraphs into more manageable pieces.

Model Hierarchy

Muting (Layer Muting)

One important characteristic of layers is they can be muted. When a layer is muted, the stage is recomposed and all opinions from the muted layer(s) are no longer affecting the scene. If a layer ends up breaking something in a shot, or has some undesirable effect, it can be muted rather than removed from a list of sublayers. A layer does not have to be a sublayer, in order to be muted, but generally those are the ones that would end up being muted in production.

For example, FX might have authored at the above shot.usda layer, and shot playback is super slow. In this case, an artist loading the shot could just mute the shotFX.usd layer, which would make USD recompose the shot, but ignore all opinions coming from the shotFX.usd layer.

See also active.


Original OpenUSD definition

Layers contain opinions about the prims in the scene graph. Some of these opinions define prims and values, while others overlay values.

Opinions are the atomic elements that participate in Value Resolution in USD. Each time you author a value for a Metadatum, Attribute, or Relationship, you are expressing an opinion for that object in a PrimSpec in a particular Layer. On a composed Stage, any object may be affected by multiple opinions from different layers.

Here is an example: We have a ball that is authored by the assets department. They decide this ball is red and give this ball a diffuse color of (1,0,0). This is the diffuse color “opinion.” Later, the lighter decides the ball should be blue and gives it a diffuse color of (0,0,1) in the local layer stack. This “opinion” is stronger as it lives in the strongest layer and the ball will be rendered as blue.

There is no "opinion" operator or LOP. Opinions are authored using LOP nodes and the opinions are parsed by USD to determine the composition of a stage.


Original OpenUSD definition

In USD ascii syntax (and documentation), paths are enclosed in angle-brackets. For example:

  • </Root/Child/Grandchild> represents an absolute prim path of three nested prims

  • </Root/Child/Grandchild.visibility> names the property "visibility" on the prim Grandchild

  • </Root/Child/Grandchild{modelingVariant=withCargoRack}/GreatGrandchild> represents the child prim "GreatGrandchild" authored inside the Variant "withCargoRack" of VariantSet "modelingVariant"


Original OpenUSD definition

A payload is a special kind of reference, but can be unloaded for optimization. Most heavy parts of assets (i.e. geometry) are generally behind a payload within an asset for this reason. Payloads are weaker than references. When files are combined with payloads it is easy to control which parts of a scene are loaded into memory, keeping memory use and processing time down by letting you load and focus on only those parts of a scene in which you are interested.

By default Houdini loads all payloads (and so they behave exactly like references). But the Configure Stage LOP and the Load Masks controls in the scene graph tree allow you to disable default loading of payloads, and then choose which specific payloads you want to load.

Path Translation

Point Instancers

Original OpenUSD definition

USD comes with its own point instancer model, this is extremely powerful and can be used for instancing geometry, volumes, other hierarchies, even instancing other point instancers.

The Point Instancer schema is designed to draw vast amounts of geometry as fast as possible. It was designed and implemented primarily for FX artists, who are often required to simulate and animate lots of debris. The Point Instancer LOP uses Houdini’s standard instance attributes on points to adjust the transform of each instance.

Each model instanced across the points is called a ''prototype'', and Point Instancer prims can assign any number of prototypes. If the per-instance variations cannot be expressed via the Point Instancer primitive’s attributes, then different prototypes may have to be used. Prototypes can contain animated geometry, and Point Instancer prims can be prototypes for other Point Instancers.

The downside is Point Instancers are much less flexible for the pipeline to work around. Parenting to individual Point Instancer instances requires extra work, and any changes to individual instances is limited to the attributes available from the schema. Also, although one can use any number of unique prototypes, too many prototypes can offset the performance advantages that come from using Point Instancers.

LOPs provides a few LOPs for conveniently working with Point Instancers and Native Instances:

  • Instance Variation - randomize different properties of instances using VEX snippets

  • Instance Retime - change the time of prototypes

  • Instance Extract - extract and promote instances

  • Instance Transform - for hand-editing individual instances

See also “Instancing”.


Original OpenUSD definition

A Prim is the primary container object in USD.

A Prim can be of several types (USD calls these types, “schemas”), such as Meshes, Lights, Cameras, Shaders, and so on. Each schema defines all of the properties that each prim type supports.

Prims can contain other prims, creating a "namespace hierarchy" on a Stage, and prims can also contain properties that hold meaningful data. Prims, along with their associated, computed indices, are the only persistent scenegraph objects that a Stage retains in memory, and the API for interacting with prims is provided by the UsdPrimclass.


HOUDINI NOTE: From the description above, it is obvious that a USD “prim” is not equivalent to a Houdini “primitive”. In Houdini a primitive is the simplest thing that can be rendered, (with the caveat that in Houdini points are renderable but are not primitives). For example, this could be a single polygon in a sphere, a single line, or even a "primitive sphere.”


Original OpenUSD definition

The name primvar comes from Renderman, and stands for "primitive variable". In Houdini-speak, a primvar is equivalent to geometry attribute. Like geometry attributes, primvars can be per-point, per-primitive, per-vertex, etc. Of course, different interpolations have different names in Houdini and USD.



Point Attribute

USD primvar with vertex interpolation

Vertex Attribute

USD primvar with face-varying interpolation

Primitive Attribute

USD primvar with uniform interpolation

Detail Attribute

USD primvar with constant interpolation

There are two key aspects of Primvar identity:

  • Primvars define a value that can vary across the primitive on which they are defined, via prescribed interpolation rules, (just like attributes in Houdini).

  • Taken collectively on a prim, its Primvars describe the "per-primitive overrides" to the shader(s) to which the prim is bound, (again, just like in Houdini).


HOUDINI NOTE: Just to reiterate that a primvar is equivalent to a geometry attribute.


Original OpenUSD definition

Properties are the other kind of namespace object in USD (Prims being the first). Whereas prims provide the organization and indexing for a composed scene, properties contain the "real data".

Properties of a prim can be either Attributes or Relationship.

See also “relationship” and “attribute”.



Original OpenUSD definition

A Reference is one of the most common composition arcs, and is generally used to compose assets and props into a stage, (such as assets into a set). Unlike SubLayers, References are composed into a specified prim path (namespace) in the scenegraph.

The primary use for References is to compose smaller units of scene description into larger aggregates, building up a namespace that includes the "encapsulated" result of composing the scene description targeted by a reference.

While references may give the appearance of instancing, they are not actually instanced. A prim can be declared instanceable, and USD will then optimize and share those prims among each instance. However instance-references cannot have unique overrides to prims below the instance root.

Think of references as a sort of “macro” to compactly reuse scene description. References would be used to assemble a shelf of books; the bookshelf and the books would references the shelf and book assets respectively.

Referencing is the only way to load the same layer file multiple times into a single scene graph in different locations. No matter how many times a file is sublayered into a scene graph, the result is the same as adding it as a sublayer once (though it is actually not permitted to sublayer the same file multiple times). But a file may be referenced many times into many different scene graph locations.

The Reference LOP and Stage Manager LOP create references. The Graft Stages and Graft Branches LOPs do something similar to referencing, but rather than creating references they actually copy the referenced scene graph data into the main scene graph. It can be thought of as a "hardened" reference. It is also different from a reference in that it doesn’t refer to a file on disk. You can only graft other scene graphs authored in LOPs.


Relationships point to a primitive or property in the scene.

See also “property”.

Root LayerStack


Original OpenUSD definition

Prims are organized into types defined by the Schema. Examples of schemas are Meshes, Lights, Cameras, Shaders, and so on. Each schema defines all of the properties that each prim type supports. You can author your own schemas, but the ones that ship with USD are probably sufficient.

See also "API schema".

Session Layer

Original OpenUSD definition

Most USD authoring applications (outside of LOPS) work on a session layer. This is a kind of “scratch space” to configure, override, and experiment with the data contained in files backing the stage.

In contrast, LOPs always operate on the strongest layer on the stage. When you load a layer from disk (whether by reference or sublayer), the LOP which loaded it will have a stronger layer above the layers loaded from disk. Each subsequent LOP will then operate on this strongest layer, until a new layer is declared in the node graph.

There is a session layer and stage used for the Scene Viewer, but the only edits that currently end up there are activation/visibility opinions set via the Scene Graph Tree.


Original OpenUSD definition

Similar to inherits, but is intended to allow for specializations of a base primitive to be refined.


Original OpenUSD definition

A scene in USD is called a stage, and rather than simply load a file, USD composes the stage. In Houdini, this would typically be called a “scene.”

Only on rare occasions is the entire stage stored in a single, flat file. Usually there are at least a few layers (each .usd/.usda/.usdc file on disk), and they are composed together to present the user with a complete view of the scenegraph. The composed stage is a hierarchy of prims , representing all of the models, characters, props, etc.

Stage Manager

A very interesting utility LOP, designed to be a one-stop location for referencing assets from disk, transforming them in 3d space, and adjusting your scene hierarchy. It has a custom Qt interface and Python State, to take care of the UX part, but the node itself is capable of creating, moving, copying, and deleting primitives.

The Stage Manager will flatten layers on its input into a single layer so that it can perform these operations on any input. However using this facility will combine all the layers in the layer stack, which is not something to be done lightly.

Stage Traversal


Original OpenUSD definition

Subcomponents provide a way of setting up levels of organizational complexity within component models, providing intermediate interfaces/views of a model’s organization that sit in-between "just show me a single prim for the entire model" and "expand all hierarchy down to leaf prims".

See also assembly for an explanation of assembly, group, component and sub component.


Original OpenUSD definition

Layers can have multiple sublayers, which are ordered strongest to weakest. This list of layers and SubLayers is called a LayerStack.

Target Patterns

When writing syntax to act on particular prims in LOPs, you will need to identify them. The most direct way to target one or more prims, is to manually enter their paths. Please see the LOPs Intro for more detail on pattern matching.


When people refer to “types” of data, they are probably referring to USD Schema. USD does have "primitive types", which are defined by primitive schemas.

See also schema.


Universal Scene Description is an open source scene description for efficiently building and collaborating on 3D assets and scenes. It is a file format which describes a Scene Graph. In Houdini it is implemented in LOPS. Using USD via LOPS allows multiple users/departments to work on the same scene non-destructively. It provides not only a framework for a studio’s pipeline, but the actual infrastructure to provide fast and efficient ways of building, presenting, inspecting, and editing a stage (scene). USD works in layers which can be composited, much like layers in an application like Photoshop.


Not a USD concept but a very useful tool for inspecting USD files. This is a standalone tool from the open source USD library.

You can use it to visually inspect your stage with the Hydra viewport, playback animation, inspect properties and metadata, even switch variants or prototypes and debug scenes.

User Properties

Value Resolution

Original OpenUSD definition

Value Resolution is the algorithm by which final values for properties or metadata are "composed" from all of the various opinions. Value resolution is the act of composing potentially many pieces of data together to produce a single value.

This is a complex topic, so please consult the Value Resolution USD docs for more information.


Original OpenUSD definition

A variant represents a single, named variation of a VariantSet.

See also VariantSet.

Variant Set

Original OpenUSD definition

A VariantSet contains individual variants from which a user (or process) can choose. For example, you might have a “tree” VariantSet and inside have ten different trees, (variants). The user can then choose which tree he or she wishes to use.

In Houdini, you might think of this as a digital asset which contains various read nodes of different trees piped into a switch SOP with the switch control promoted up.

Variants aren’t restricted in what they can store, a VariantSet might simply swap materials, or it can change the entire hierarchy (see "Variant Layer”). VariantSets don’t have to be defined on the asset, they can be introduced by downstream contributors.

Variants work without changing namespaces (thus preserving things like light-linking or transforms on each instance of a book in a scene), down to the prim that owns the variant set.

Viewport Load Masks

The viewport stage allows for the configuration of various USD methods for controlling the loading of data. This provides the ability to choose which parts of a very large scene to actually load and display in the viewport. These various capabilities are jointly referred to in LOPs as the "Load Masks". The load masks encapsulate the ability to selectively load payloads, to set the stage population mask, and to mute layers. See the USD documentation for descriptions of each of these features.

Viewport Overrides

The viewport stage provides the ability to make modifications to its session layer in order to set opinions on USD primitive aspects such as activation, visibility, and draw mode. Being in the session layer, these opinions are stronger than anything coming from the root layer or its sublayers. These overrides are primarily controlled through the Scene Graph Tree pane, but can also be modified with python scripts.

Viewport Stage

Each LOP viewer has its own stage, which is what is actually displayed in the viewport. This stage is generated as a copy of the LOP Stage of the node with the display flag set on it. See the section on Performance Considerations for an explanation of why the viewer has its own stage.


Original OpenUSD definition

Visibility and activation are similar concepts. Visibility (like activation) affects child prims. That is, you can’t make a child of an invisible prim visible (or a child of an inactive prim active).

In LOPS, use a ''Configure Primitives LOP'' or ''Prune LOP'' to set visibility.

See also active and muting.


In USD, a “volume” is essentially a set of named “fields” that are rendered together as a unit. So a volume prim /campsite/fire would say that it is made up of a field named “density” found at /campsite/fire/density, and a field named “temperature” found at /campsite/fire/temp. Each one of these fields equivalent to a singleVolume or VDB primitive in SOPs.




Karma renderer