First 30

Question 1

Prims

Answer 1

Short for Primitive, and a quintessential component of USD.
Prims are the nodes within a hierarchy and can thus have parent/child relationships with other prims; meaning that prims can have other prims as children or siblings, or have another prim as a parent.

In the image below, every node in the hierarchy is a prim. The keen-eyed will notice that prims can have a type. Xform, Mesh, Scope and Material are specific prim types. These types come with default behavior and “data”, the mechanism of which is explained in a later chapter.

User s are also able to define their own Prim types

While Prims themselves indicate what “type” of scene element they are, they do not necessarily possess data themselves. However, they can be considered “containers” for named data, this data is generally expressed as Properties.

Question 2

Properties

Answer 2

Prims can have Properties, which are essentially named and typed data.

A Property within USD is actually a collective term for two distinct types of Properties

In the above, you can see that properties are made up from a name and a typed value

These property names can also be namespaced. A property name can have 1 or more namespace identifiers separated by :.
Looking closer at the relationship example, the property name material:binding is actually namespaced. The property’s name itself is binding and it is part of a material namespace.

Namespaces can be used to categorize or group properties together.

Question 3

Attributes

Answer 3

Attributes are Properties with direct values that may vary over time

Question 4

Relationships

Answer 4

Relationships are Properties that point to other properties or Prims

Question 5

Path

Answer 5

Prims and properties are defined through unique paths inside the scene hierarchy. They are a textual representation of a hierarchy - similar to folder paths in most operating systems - where each prim is separated from its parent or child via the / delimiter.

In the example below, the highlighted path /root/remi/head_M_hrc/GEO/head_M_hrc/eyeScrew_L_geo is a path to a prim with the name eyeScrew_L_geo. Constructed from the following hierarchy: / → root → remi → head_M_hrc → GEO → head_M_hrc → eyeScrew_L_geo.-

Properties are also defined by paths. Taking the previous example, inspecting the points attribute yields the path /root/remi/head_M_hrc/GEO/head_M_hrc/eyeScrew_L_geo.points. Property paths are constructed by appending the property name to a prim path, delimited by a . character

Paths in USD are name based, and this means you cannot define the same path twice. In practice this means that you cannot have two or more sibling prims with the same name

Question 6

Layer

Answer 6

A Layer is a collection of Prims and their Properties that can be saved to/loaded from disk or memory. As such, it can be considered a “saveable hierarchy”.

Standard USD Layers can be represented on-disk via

Extension Description
.usda ASCII Text, human-readable format
.usdc USD Crate file format. High performance binary not human-readable format
.usd either Crate or Text
.usdz uncompressed and packaged format (.zip).
USD allows for extending what you can load as a “Layer” via a special kind of plugin (SdfFileFormat). In fact, the file types listed above are actually all plugins of this type.
Using this SdfFileFormat plugin type, it is for example possible to also support loading .fbx, .abc, .obj (or anything really) in Usd.

Question 7

Metadata

Answer 7

Prims, their properties and the layers they are part of can have metadata applied to them. This is additional static (as in, it can not change over time) data that USD or a user can read, use or define.

Metadata can be used to describe behavior, incur meaning, represent documentation, etc. USD comes bundled with an extensive suite of metadata out of the box,

Question 8

Layer stack

Answer 8

Each layer internally keeps track of a “local” stack of layers that contribute to that layer. This stack is an ordered collection of layers used within this layer that contribute to its hierarchy and composition.

A layer’s Layer Stack always has its own data at the top of the stack, making itself the most important.

Question 9

Composition

Answer 9

Roughly put, the act of combining layers and their prims, properties and metadata together through various means known as composition arcs.

While combining layers together could be considered “composing” them, what USD’s composition engine actually uses are the layer stacks of each layer.

Question 10

Stage

Answer 10

The composed result of opening a layer. Think of it as a Photoshop canvas when opening a .PSD document. All the Photoshop layers interact with one another to produce a “final image”. The layers still exist, they can still be edited, deleted, replaced, etc… but what you see is the result, and that is the Stage in USD.

This composed result can be “flattened” and saved to a new layer, which would be similar to taking the aforementioned Photoshop document and exporting it to a JPEG.

Question 11

Opinions

Answer 11

Circling back to properties, when you set a value on an attribute or metadatum or author a relationship within a layer, you are effectively expressing an opinion on that value. This is named an opinion because value assignments can always be changed by others! This is a very important concept for composition.

A different way of looking at this would be that “setting a value” implies that that action is final and the value itself becomes immutable; whereas with opinions you merely mean

“Within this layer, I want the value for this to be <INSERT>”</INSERT>

If the value already existed before, you are essentially “overriding” it

Question 12

Over rides

Answer 12

When expressing an opinion within a layer, it is possible to “redefine” a previously defined value of the property being edited. This mechanism is known as overrides because you are overriding what was there before. However, it is very important to note that the original data remains unchanged. The override only exists within the layer where you are defining it

This is by far the most important aspect to understand about USD. Opinions and their “value resolution” (resolving which value gets applied in the end) are key to the entire composition mechanism.

Below is a simple example of overriding a previously defined attribute’s opinion.

Question 13

Stage traversal

Answer 13

Generally a concept used when programming with USD, but it is important to understand for users too. Stage Traversal is essentially iterating over the scene graph of a layer opened in a stage. Traversal can be filtered via “rules” (or predicates), limited to sub-trees, parts of the hierarchy can be pruned during traversal, and so on.

By default, USD Stage Traversal will only consider prims that are active, defined, loaded and are not abstract. Depending on which tool is used, users may be able to change this behavior. Using the programming interface however, developers have full control over this behavior.

Question 14

Kind

Answer 14

Kind is a prim-level metadatum that can be used to “categorize” prims and their descendants into higher level concepts than just their definitions (ex. Mesh, Sphere, Cube, etc…).

Question 15

Purpose

Answer 15

Purpose is an attribute that can be used to give a prim and its descendants a high-level “visibility flag” in context of rendering.

For example, if a prim has its purpose attribute set to render, it will be excluded from being drawn in a renderer that only wants to draw proxy prims.

In some sense, setting purpose could be considered Stage Traversal but for rendering
.

Purpose Description
default
The prim has no special rendering purpose and it will be included in all rendering paths

guide
A prim tree marked with guide is generally used by interactive applications that have asked to show “guides”. Think of it as requesting to visualize controller geometry for rigs, skeleton data, etc

proxy
Proxy is usually reserved for a lightweight representation of another object to be used in an interactive renderer such as a DCC viewport

render
The “final quality” data to be imaged. Usually enabled for offline rendering or final quality rendering

Question 16

Specifier

Answer 16

When defining a prim in the scene graph, there are three different ways of doing so.
def

A concrete definition. This is generally used when you want to define a prim for the very first time, or when a prim needs to be redefined. defs always contribute to scene composition.

over

This tells USD that a prim is to be overridden. If the composition engine cannot find the prim targeted by the over specification, the override will be ignored and will not contribute to scene composition.

class

An abstract prim definition that does not contribute to stage traversal by default. Meaning, it does not show up in the stage hierarchy. Other prims can however, inherit from this class (more on that in the next chapters)

Question 17

Composition Arcs

Answer 17

USD’s composition engine utilizes a few different ways of composing, these are known as Composition Arcs. Simply put, they are a set of operators that determine how layer stacks and their opinions are combined together.

Let’s look in more depth about each different composition arc type.

Question 18

Local sublayer

Answer 18

Layers can sublayer other layers, grafting multiple layer stacks together in order into one. Sublayering is in fact how Layer Stacks are made!

Order matters when sublayering.

To emphasize how order matters, given a Cube prim at path /Foo in layer_a.usd and a Sphere prim at path /Foo in layer_b.usd; when sublayering both in layer_c.usd, the final type of /Foo will depend solely on the order in which layer_a.usd and layer_b.usd are brought in.

Question 19

Reference

Answer 19

Beyond sublayers, layers can also be grafted underneath prims. Using the example Cube and Sphere from Local/Sublayer, we can also create prims and have them point to these layers respectively.

Layer References
Beyond sublayers, layers can also be grafted underneath prims. Using the example Cube and Sphere from Local/Sublayer, we can also create prims and have them point to these layers respectively.

Question 20

Layer Prim References

Answer 20

But, this goes even further! Remember, composition acts on layer stacks, not individual layers; so it is also possible to reference specific prims from another layer’s layer stack. Even if these prims themselves are the composed result from the target layer’s layer stack

Question 21

VariantSet

Answer 21

VariantSets and variants allow for authoring a “switchable” state of a prim within a layer. In the example below, a top level prim with the name Implicits is authored which defines a VariantSet named Shape. This VariantSet defines a few different entries (aka variants ) that each do something different. When changing the active variant, USD will inject anything that is defined within that variant into the current composition. In our example, each variant adds a child to Implicits with differing types. One is a capsule, another a cube, a sphere, and so on.

Question 22

Payload

Answer 22

Payloads are lazily loaded references. When a prim uses a payload, USD can be told to opt out of loading these layers unless the user requests to do so. When a referenced layer is heavy due to the amount of data or hierarchy complexity, it is often beneficial to have the user manually load those in after opening the layer in a stage. Generally speaking, non-important layers should be behind payloads. If they’re not loaded, they also cannot be traversed and should not contain anything considered “important”. The definition of “important” depends entirely on the use case of course.

Question 23

Inherits

Answer 23

Very similar to the concept of “inheritance” in programming. Prims can “inherit” other prims (concrete or abstract), meaning that they reflect the hierarchy and properties defined in the prim that they are inheriting from. This also means that if a change is authored on the base prim or its hierarchy, any prims that inherit it immediately get those changes applied to them. Within context of a singular layer, inherits does not offer a noticeable difference between it and a local reference. However, when using inheritance in a multi-layer composition environment, it does differ. References tend to become fully encapsulated within the layer stack they’re referenced. Meaning that references loose any sense of “connectivity” to their referred layers outside of their layer stack. Inherits on the other hand are always live, no matter how deeply nested within a composition, or how many redefinitions of its base. A prim is always able to backtrack to its original “base”, regardless of composition depth!

Question 24

Specializes

Answer 24

Specializing is taking a base definition of a prim (and its hierarchy) and further refining it into a specialized version of itself. For example taking a Metal material and specializing certain properties to make a CorrodedMetal material. This specialization could refine certain material properties, redefine or add shaders, textures, etc… It is not dissimilar from inherits, however with one key difference. Opinions expressed as specializations always win If you try to express an opinion on a specialized property, your opinion will essentially be discarded. This is not the case however with inherits. You cannot specialize an ancestor or descendant of a prim. Only siblings or prims outside of the Specialization’s definition are allowed

Question 25

Strength Ordering (LIVRPS

Answer 25

Composition and opinion value resolution go hand in hand, and in order to remain sane; there are rules. Each composition arc has a “strength” assigned to it. Meaning that if for example opinions targeting a property are authored on 3 different composition arcs within the same layer stack, the composition arc that is the “strongest” wins. This is where the acronym LIVRPS (Liver Peas) comes into play. It stands for L ocal I nherits V ariants R eferences P ayloads S pecializes This list acts as top-down stack. When USD needs to resolve an opinion for a property or metadatum, it will look for opinions via these composition arcs in this exact order. If an opinion has been found, any subsequent searches down the stack are immediately aborted and the opinion is resolved. If no authored opinion has been found, USD will fall back to the property/metadatum’s default value. All composition arcs besides Local will trigger a recursive LIVRP(S) evaluation. However, within this recursive evaluation, S (pecializes) is ignored except for the Specializes composition arc. It triggers a full LIVRPS evaluation if encountered.

Question 26

Default Prim

Answer 26

When authoring a layer, it is possible to also define a “default prim” for it. This is a layer metadatum that contains the name of the prim that should be used automatically when the layer is used in a reference or payload composition arc without an explicit prim path. This name must point to a root level prim, meaning a direct child of the PseudoRoot . Therefore, it is not allowed to point to a path.

Question 27

List-Editing

Answer 27

List editing is a feature within USD that allows for non-destructively editing listtyped elements within a scenegraph. You can append, prepend or delete items from a list during composition. Or even explicitly override the entire list. This is generally referring to references, relationships, custom metadata, inherits, specializations and variantsets. Attributes of a list-type cannot be list-edited. In the example below, we override the list of references on a prim to also prepend a new reference to another layer. This results in the prim referring to two layers (assuming the original definition only points to a single layer).