| On this page |
Introduction ¶
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.
Glossary ¶
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”.
Note
HOUDINI NOTE: The point attribute “active” is used in Houdini Bullet RBD sims to control active and inactive objects.
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. Accessing a node’s “active layer” returns a read-only object. To make edits to the active layer, the Python LOP makes available the “editable layer”.
See 
Python LOP.
Although not part of USD at all, Alembic support is included in USD. However, USD is not simply “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. The official Alembic USD plugin page has more technical details.
Alembic data imported to Houdini using SOPs or OBJ nodes uses Houdini’s native Alembic code. Abc files sublayered or referenced using LOP nodes, or the USD Import SOP, rely on USD’s Alembic file format plugin.
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. The UsdRender specification defines these as Render Vars. In the LOPs context we will refer to these as Render Vars and 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).
See also “render variable”.
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 subcomponents 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 |
Example |
Model Kind? |
Set Draw Mode? |
Can Contain Kinds? |
|---|---|---|---|---|
Assembly |
Kitchen |
Yes ✔ |
Yes ✔ |
Assembly, Group, Component ✔ |
Group |
Dining Table |
Yes ✔ |
Yes ✔ |
Group, Component ✔ |
Component |
Chair 1 |
Yes ✔ |
Yes ✔ |
Subcomponent ✔ |
Subcomponent |
Chair 1 Cushion |
No ⤬ |
No ⤬ |
No ⤬ |
Subcomponents may have child subcomponents, or leaf prims (individual polys that make up the cushion for example). You 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.
Asset, or Asset Path, 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.
Asset paths are unique from strings, because they rely on an asset resolver to resolve their complete path. USD denotes these has 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 Asset Resolver for more info.
A special block of metadata to describe useful information about USD Model Assets.
See also “model”.
USD has a special mechanism called “asset resolvers”, which applies to a special flavor of string attributes called 'asset paths'. These are file paths wrapped in @@. When you look at the ascii representation of a USD scene, or inspect values in the Scene Graph Details, you will see Asset Paths. Resolves are a feature leveraged in larger or mature USD pipelines, to represent data or files on disk, without having to alter the contents of USD files.
Attributes are a very common type of property authored in USD scenes. An attribute, (similar to 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 in USD are usually a required part of a primitive, defined by its schema, but custom attributes can also be created. Attributes can be animated, with each time sample stored in an array. Attributes are more strict than primvars, and are not inherited from ancestor primitives.
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.
Blocking is a “reversable delete”, in the same way that deactivating primitives is reversable.
Shader prims have input and output connections, which are special relationship-types that allow shader prims to connect and build up a material graph.
A specififer for a primitive that stores values, but shouldn’t be traversed unless asked to. Class prims are not directly drawn in the viewport by Hydra.
In a USD layer, these prims will have a class prefix in front of them.
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. Within Solaris, target patterns can be used to procedurally populate collection targets, but it’s important to note that collections exported to USD files are not procedural.
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:
See also LIVRPS Strength Ordering.
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 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.
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.
Refers to a specifier in a USD file that creates (i.e. defines) a prim. It doesn’t have to set the type, but it usually does.
When inspecting the ascii-representation of a USD file, these are the prims which have a def in front of them.
Static value authored into a USD layer.
Values that come from a file being viewed, or one of that files sublayers, is a direct opinion. These are the strongest opinions, overriding all others. In Solaris, LOP nodes that create/edit data through their first (or only) input, are direct opinions.
A standard primvar defined by USD for geometry color. Does not require a material binding. Equivalent to @Cd attribute in Houdini.
A standard primvar defined by USD for geometry transparency. Does not require a material binding. Equivalent to @Alpha attribute in Houdini.
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.
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.
Fallback describes required values for a prim type. They are intrinsically required by the schema, and will always be present if no other value is provided in the scene. An example of this would be radius on spheres; without radius, a sphere is not a sphere.
-
.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
Note
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.
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.
A special primitive that represents a subset of a prim’s geometry. GeomSubsets represent a face-set, and must be children of a mesh. Their main purpose is for material assignments to mesh faces.
Graft copies primitives into the main scene graph. Grafting requires actual primitives to copy, so it flattens the layer stack (i.e. any sublayers). Primitives that exist only through references, cannot be grafted without flattening the entire stage first. Within Solaris, a graft can appear reference-like, but it is actually copying data, rather than simply referencing it.
See “flatten” and “references”.
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.
Examples of gprims include meshes, basiscurves, spheres, and cones.
Groups are models that aggregate other models into meaningful collections. They are the “glue” that holds a model hierarchy together. A group is usually an Xform prim with the group kind. 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.
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).
Houdini Procedurals are a renderer-agnostic mechanism to create or modify primitives on the stage at render time. They are invoked by at render time after the given USD scene has composed, and before the pre-render/pre-frame scripts are invoked.
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, Storm on some platforms, and of course Karma.
Tool that renders USD scenes with Karma or any other render delegate it is aware of. It is the command line equivalent to the 
USD Render ROP.
See also husk.
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.
An inert primitive that has been non-permanently “removed”. There is no way to inspect the children of an inactive primitive.
See active/inactive.
Inherits are similar to a local reference, but remain “live” through multiple levels of references. Inherited opinions are stronger than references. They are in fact stronger than any opinion except for direct opinions. You would generally use inherits to broadcast overrides to all members of a “class” of assets or materials.
Metadata on a primitive, that lets USD share common references or payloads, between multiple occurances of that same reference/payload on different prims in the stage. When this happens, it creates “native instances”.
See “instancing”.
USD provides instancing in two forms:
-
Native instancing is a property that tells USD to generate a single "prototype 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 renderer used in LOPS. It ingests USD objects, lights, and materials via /solaris/glossary.html#hydra. Karma’s “CPU” engine is a VEX-based renderer that only runs on CPUs, while Karma XPU is an engine that runs on CPU and GPU hardware.
Note
We will continue to ship Mantra for rendering legacy files but all new development is on Karma.
See also render delegate.
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”.
Kinds can easily be extended in a pipeline, allowing for more specific labels of different assets.
A layer is a container of primitives and opinions. Layers are usually indiviual usd/usda/usdc file on disks, or may also 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.
A layer can be backed by different file format plugins. The most common is ones are usd/usda/usdc files, but USD also includes an Alembic file format plugin. Solaris includes additional file format plugins, which allow users to sublayer, reference, and payload most of the geometry formats that Houdini supports. Most of those, outside of using .bgeo files, probably aren’t valuable in production.
See also Implicit Layers.
Sublayers and references can shift the timing of the animated values it contains, without having to re-author that data.
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 elements in a shot, such as the character animation, shot lighting, or camera work, would generally be sublayers.
The term “leaf” is not a USD term, 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. In USD “leaf prims” are usually gprims.
Refers to the ability of some USD mechanisms to control how the list of values is assembled. References, payloads, and variants can all do this. The presence of a parameter or operation that includes “Prepend” or “Append”, is list editing. Prepend typically gives the most predictable results, and is usually the default in Solaris. See the USD glossary for more technical details.
Primitives authored with a payload, can be loaded or unloaded to make interacting in heavy scenes faster. In production, shots are typically opened with payloads unloaded first, and artist then request which models are loaded. The payload state is a runtime decision, and is not exported to USD files.
See also “payload”
Gather all of the scattered files that are referenced or sublayered together, to produce a given stage, into a single location. The USD ROP has an output processor, which can localize non-USD files into a folder; this is useful when localizing texture maps from various folders, into one location.
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.
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.
MaterialX is a system for describing material networks portable between renderers. Karma only supports rendering USD-encoded networks, using the UsdMtlX plugin.
Primitives, attributes, and layers can all have metadata. The primary UI for inspecting metadata in Solaris is the Scene Graph Details, which has a metadata pane. Metadata can be composed like primitives/attribute values, but layer metadata cannot be composed.
In USD, “model” is neither a singular component nor a plural group container - it is just the “abstract” commonality between components and groups. Models are usually published assets.
USD models can be thought of like a scale model kit: the model is plastic parts, paint, and decals all combined together.
Kind is used to label certain prims as models to organize large scenegraphs into more manageable pieces:
-
a core “leaf model” kind: component
-
“models that aggregate other models”: group
-
“models that aggregate other models”: assembly
Note
Do not think of USD “models” in the traditional Computer Graphic sense of “geometry”. A USD “model” is an abstract concept that is used partition large scenegraphs into more manageable pieces.
The rules around scene graph hierarchy that models obey to be valid.
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.
Primitive namespace is usually the “prim path”. Collections, relationships, attributes, and primvar names can also be namespaced. Some namespaces are schema-defined, others are just by convention.
For example, all primvars are under the primvars: namespace. Karma’s object properties are primvars that live under the primvars:karma:object: namespace.
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.
A specifier for opinions in a layer, that are meant to overlay data on the given prims, which are defined in a weaker layer. Pure overs are visible in the scene graph, but aren’t very useful without primitives defined.
In a USD layer, these are prims which have an over prefix in front of them.
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”
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.
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”.
Each LOP Network allows modifications to its session layer using python scripting. These modifications are applied after cooking the LOP node to be displayed in the viewport or Scene Graph Tree. These modifications can also be written to the output file of a USD ROP, and affect the rendered image from a USD Render ROP. See hou.LopPostLayer for more information.
A prim or primitive is the primary 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.
Note
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.”
The list of all PrimSpec’s which contribute opinions used to compose the prim.
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. Single-value, constant-interpolated primvars are inheritable from parent primitives.
Houdini |
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).
Note
HOUDINI NOTE: Just to reiterate that a primvar is equivalent to a SOP geometry attribute.
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”.
See also “Point Instancers”.
Proxy is an option of purpose, that is generally used for light-weight representations for viewports like Houdini GL or Storm.
Purpose categorizes primitives for specific use cases. Purpose is used by Hydra to tell the render delegate what primitives are candidates for display/render. Primitives with a different purpose than the one being sent to Hydra are not synced through to the renderer.
Default |
No special purpose, always visible/available. |
Render |
Intended for final-quality display. |
Proxy |
Light-weight representation, usually associated with render primitives. Can still be renderable. |
Guide |
Visual reference only; never intended for use beyond interactive work in a scene or perhaps debugging. |
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. References are encapsulated, and any relationship targets that are not contained within the reference are not preserved.
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.
Sublayered relationships are preserved, even if the target doesn’t yet exist on the stage.
Relationships are preserved through References as long as the Relationship target is encapsulated by the Referenced primitive. Otherwise the target will be cleared.
See also “property”.
A render delegate is a renderer of some type, such as a path tracer like Karma, or even a GL viewport like Houdini GL or Storm. These delegates can render USD scenes sent to them via Hydra.
See “hydra”.
Render products represent the output of an image. They refer to one or more render variables, which describe the different channels/AOVs when rendering to an EXR.
See also “render variable”.
Render variables represent the pixels, opacity or other data channels of a rendered image.
See also “aov”.
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”.
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.
Similar to inherits, but is intended to allow for specializations of a base primitive to be refined. Specializes is the weakest composition arc. Think of is as a way to customize the fallback values of primitives, assets, or materials, but without having to re-define any schema definitions.
A specifier is a value in a USD file, associated with a primitive path/location. Because USD opinions can be gathered from many files, each file needs a way to describe its contribution to the scene. Each value defined in each layer must be associated with a prim path, because prim paths are the unique identifiers for describing USD prims. Some layers will be creating prims and scenes from scratch, and others will simply overlay very sparse opinions.
A scene in USD is called a stage. USD composes the stage, because USD scenes are generally composed of many different files. In Houdini, this would typically be called a “scene" in /obj.
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.
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.
The process of visiting some or all of the prims in a stage’s composed scene graph.
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”. Subcomponents are meant to exist as children of components, but subcomponents can be freely nested.
See also assembly for an explanation of assembly, group, component and sub component.
Layers can have multiple sublayers, which are ordered strongest to weakest. This list of layers and SubLayers is called a LayerStack.
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.
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.
USD includes a MaterialX plugin (UsdMtlX), which allows MaterialX shaders to be encoded as USD shading primitives. UsdMtlX currently does not support every feature of MaterialX, as many features in MaterialX are redundant (for example, material assignments).
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.
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.
A variant represents a single, named variation of a VariantSet.
See also VariantSet.
A VariantSet is a mechanism with contains individual variants. A user (or process) can choose one variant at a time, to be operational on the current stage. 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.
VariantSets have few restrictions on what they can store. A variant 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 can also contain references and payloads, as well as other VariantSets. Sublayers cannot be defined directly contained within a variant. Relationships authored within a variant can target primitives outside of the VariantSet primitive. But it is often the case that Variants must be encapsulated similar to references.
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 VariantSet.
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.
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.
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.
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.
Houdini’s native SIMD, or “kernal” language, used for shading and geometry processing. Solaris includes VEX bindings or functions for authoring or modifying USD data.
See also vex.
In USD, volumes are primitives that combines several fields, that are rendered together as a unit. Fields refer to individual volumes such as density or temperature. Fields can refer to OpenVDB, Field3D, or Houdini volumes. The volumetric data is not stored directly in USD, but persists in files on disk.
An example case is a camp fire. A volume prim /campsite/fire declares it has two fields. One is named density and is found at /campsite/fire/density; the other field is temperature, found at /campsite/fire/temp. Each one of these fields equivalent to a single Volume or VDB primitive in SOPs.
