Solaris Jumpstart

Universal Scene Description ¶

Universal Scene Description (USD) is an open source scene description from Pixar for efficiently building and collaborating on 3D assets and scenes. 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 is much more than just another geometry format like Alembic, OBJ, or FBX.

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.

USD also introduces a whole new vocabulary, which unfortunately is sometimes at odds with existing Houdini terminology or conventional CG terminology. Please see the glossary for further clarification.

As a single user or small studio, you might be wondering if LOPs is worth the effort. If for nothing else, it’s worth exploring so you can use Karma, the Houdini renderer that consumes USD and not traditional IFD files. However, just as the idea of a pipeline or shot environment might not seem blindingly obvious at first, once you have used it and mastered it, LOPs may become indispensable.

Prims and Properties ¶

When looking at a USD scene, it is a hierarchy made up of primitives that have properties. A Prim can be of several types (USD calls these types schemas), such as Meshes, Lights, Cameras, Shaders, and so on. USD can be extended to support new schemas, but the core library is fairly comprehensive. Each schema defines all of the properties that each prim type supports.

Properties of a prim can be either attributes or relationships. An attribute 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. Relationships point to a primitive or property in the scene. Attributes which are not part of the schema are custom attributes.

An important characteristic of USD prims is they cannot be permanently deleted from a composed stage. USD does support deactivation, which is a non-destructive deletion. Activation is another opinion, meaning it will be resolved through composition.

Instancing ¶

USD provides instancing in two forms. Native instancing is a property which will tell USD to generate a single “master primitive” in order to efficiently represent many copies of an asset. Native instancing can be set on any primitive, and USD will create “master primitives” as necessary. Master primitives get shares between instanceable primitives automatically if USD detects that multiple instanceable prims are “the same”. 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.

There are LOP nodes for promoting both point instances and native instances, so point instances should be preferred mostly based on the number of instances that will exist.

Composing the Stage ¶

A scene in USD is called a stage, and rather than simply load a file, USD composes the stage. This is because only on rare occasions is the entire scene 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 in 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…

Layers ¶

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

SubLayers ¶

Sublayers are one of the most common composition arcs in USD. Layers can have multiple SubLayers, and the list of SubLayers is ordered strongest to weakest. The ordered list of a Layer and its SubLayers is called a LayerStack.

Here is an example Layer for a shot:

#usda 1.0
(
    subLayers = [
            @shotLighting.usd@,
            @shotFX.usd@,
            @shotAnimation.usd@,
            @shotSetDressing.usd@,
            @sequence.usd@
    ]
)

With USD, artists only need to author their contribution to the scene, as all layers will be composed together. In the above example, Animation’s layer only contains the animated points and/or transforms which they have animated. A shot’s layout only contains transforms, adjusting the sequence-wide set dressing defined in the sequence layer; and it may include shot-specific models or changes due to the camera or story requirements.

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 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.

References ¶

A Reference is the other most common composition arc, and is generally used to compose assets and props into the scene. Unlike SubLayers, References are composed into a specified prim path (namespace) in the scenegraph.

For example, here is a simple trash can asset:

#usda 1.0
(
   defaultPrim = "TrashCan"
)


def Xform "TrashCan" (
   kind = "component"
)
{
   def Cylinder "Can"
   {
       token axis = "Y"
       bool doubleSided = 0
       double height = 2
       double radius = 1
   }
}

Here is a layer which references the trash can asset 3 times, for 3 different rooms in a set:

#usda 1.0
()


def Xform "Scene"
{
   def Xform "Set"
   {
       def "BathroomTrashCan" (
           append references = @./trashcan.usda@
       )
       {
           double3 xformOp:translate = (2, 0, 1.4)
           uniform token[] xformOpOrder = ["xformOp:translate"]
       }


       def "KitchenTrashCan" (
           append references = @./trashcan.usda@
       )
       {
           double3 xformOp:translate = (16.01, 5, -43.072)
           uniform token[] xformOpOrder = ["xformOp:translate"]
       }


       def "OfficeTrashCan" (
           append references = @./trashcan.usda@
       )
       {
           double3 xformOp:translate = (-7.12, 0, 11.9)
           uniform token[] xformOpOrder = ["xformOp:translate"]
       }
   }
}

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.

VariantSets ¶

Another powerful composition arc, VariantSets allow for building discrete variants of an asset. Asset variations to be expressed, while keeping an asset’s namespace intact. Variants aren’t restricted in what they can store, a VariantSet might simply swap materials, or it can change the entire hierarchy. VariantSets don’t have to be defined on the asset, they can be introduced by downstream contributors. Variants cannot be time sampled (i.e. animated).

Here is an example of a layer which contains a variantSet called “owner”, where each variant’s color corresponds to which character in the story owns that ball:

#usda 1.0
()


def Sphere "toyBall" (
    variants = {
        string owner = "blake"
    }
    append variantSets = "owner"
)
{
    double radius = 1
    variantSet "owner" = {
        "andy" (
        ) {
            color3f[] primvars:displayColor = [(1, 0, 0)] (
                interpolation = "constant"
            )


        }
        "blake" (
        ) {
            color3f[] primvars:displayColor = [(0, 0, 1)] (
                interpolation = "constant"
            )


        }
        "sally" (
        ) {
            color3f[] primvars:displayColor = [(0, 1, 0)] (
                interpolation = "constant"
            )


        }
    }
}

More on Composition ¶

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 3 are definitely the most frequently encountered. But to help you understand the bigger picture of composition, here is a quick summary of the arcs, from strongest to weakest (except for Specializes):

Name	Description
Layer Stack	Layer Stack, which includes a layer’s local opinions as well as sublayers. Contributions to a shot, such as the character animation or camera, would generally be sublayers. See the USD docs.
Inherits	Inherits can be used to re-define the default values but only in the context of a shot or set. Inherits are similar to a local reference, but remains “live” through multiple levels of references. Materials are the primary use case for inherits and specializes.See the USD docs.
VariantSets	Pre-defined changes or variations of part of a scene or asset, without necessarily mutating important parts of a scene. For example, book asset may contain several “title” variants. This allows artists to change which title a book is, without changing the namespace of the books on a table (thus preserving things like light-linking or transforms on each instance of a book in a scene). See the USD docs.
References	Simple mechanism to reference smaller units of a scene into larger ones, such as assets into a set. Think of it as a sort of “macro” to compactly reuse scene description. References would be used to assembly a shelf of books; the bookshelf and the books would references the shelf and book assets respectively. See the USD docs.
Payload	Just like a 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. See the USD docs.
Specializes	Similar to inherits, in redefining default values in a shot or set, without changing the original source. Specializes are a way to broadcast these changes, but without overriding any inhert’s opinions. Materials are the primary use case for inherits and specializes. See the USD docs.

For deeper information see LIVRPS Strength Ordering in the USD Glossary.

Hydra ¶

Hydra is the mechanism with which scene description is drawn in the viewport. The plugin which Hydra talks to, in order to give you images to see, is called a delegate. And just like the monster with multiple heads, Hydra can support multiple renderers. This means that at the flip of a switch, we can look at our composed stage using any number of renderers. USD by default uses an OpenGL renderer called hdStorm (or Hydra GL in Houdini), but also includes a render delegate for RenderMan (hdPrman) and an example Embree delegate. All of these are visible by using the usdview application that ship with USD. In LOPs, or using the usdview which ships with Houdini, you’ll also find the Karma render delegate.

Obviously there is much more to USD, but hopefully these basics are enough to get started using Solaris. For further information on USD, please check out the excellent PDF slides from the USD Course at SIGGRAPH 2019. Also check out openusd.org; the glossary in particular is an excellent resource to keep at-hand.

Solaris ¶

Houdini’s new layout, look development, and lighting 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. This is why an understanding of both Houdini and USD is essential.

Overview ¶

Most USD-authoring applications work on a session layer or on an Edit Target. In contrast, because of Houdini’s procedural cooking and USD being the language/data of LOPs, everything you do in a LOP graph is editing a layer which contributes to your scene.

When you load a layer from disk (whether by reference or sublayer) or create a primitive with a Cube or Sphere LOP, LOPs creates its own layers to contain or access the data you’ve provided. The strongest implicit layer is usually the one LOP nodes are writing to, but LOPs can also write to other layers in the stack, or even add new implicit layers. Most of the time, artists don’t need to worry about these implicit layers. The Output to Disk section has more information about layers in LOPs, and when an artists would likely care about.

There is a session layer and separate 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. The viewer’s stage copies the stage contents from the LOP node with the display flag, after the whole LOP graph’s cook chain is completed.

This presentation by Scott Keating from Siggraph 2019 is an excellent overview of Solaris.

Target Primitive Patterns ¶

The most direct way to target one or more prims, is to manually enter their paths. This will obviously get tedious, so there are a few easier ways to target primpaths:

Drag & Drop - Drag path(s) from the Scene Graph Tree onto a Prim Path parameter
on Selector (white arrow on right side of parm)- Prompts to select in the viewport
Ctl + on Selector - Prompts to select from a primitive tree

Apart from providing full primpaths, there is some useful extra syntax to make targeting primpaths easier and more expressive. Please see the Tech Notes for more information on pattern matching.

Many/most LOPs have their default set to `opinput(“.”, 0)` This expression is intended to be a convenience, to reduce tediously re-typing primitive paths over and over. When a LOP cooks, it can store any prim(s) it operated on and/or generated as it’s last modified prims. The lopinputprims() is convenience around lastmodifiedprims(). This mechanism is also convenient because if the upstream paths change, the LOP nodes will likely retarget any altered prim paths automatically.

Configuration Nodes ¶

LOPs provides a suite of nodes for setting core properties of different parts of your scenes.

Configure Layer
- Sets layer properties, such as it’s save path, default prim, flattening, etc…
Configure Primitives
- Configure a prim’s purpose, setup proxies, and add asset information. This primitive is currently more robust at pruning than the Prune LOP, so use it for activation/visibility needs.
Configure Properties
- Add more specific metadata about properties and attributes on primitives.
Configure Stage
- Set layer muting and population masks for the scene.

Merging ¶

Because LOPs works with USD scene description, merging inputs has some important considerations that SOPs or other contexts don’t have. Merge has 3 modes:

Separate Layers - merges each input’s layer stack and combines them all into a new layer stack (default)
Flattened Layers - flattens all of the layers in each input’s layerstack down into one layer
Flattened Inputs - flattens each input into a layer

Separate Layers mode does not itself strip out any layers marked by a Layer Break; only the two ‘Flattening’ modes do that.

This table illustrates the behavior of each Merge style:

Merge Style	Num Inputs	Layers per Input	Resulting Sublayers
Separate Layers	3	3	9
Flattened Layers	3	3	1
Flattened Inputs	3	3	3

It is important to remember, that Merge is a LayerStack, a list of Sublayers. This means the input order matters, with the first input weakest and the last input strongest. This ordering can be seen in the Layer Stack tab of the Scene Graph Details.

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.

There is also a Contexts Options Editor found under Edit ▸ Context Options which provides a rich interface for defining context options.

VEX, Wrangles, and VOPs ¶

Please see Using USD with VEX for more info.

VEX is Houdini’s programming language used for everything from deformers to shaders to solvers. As VEX is a SIMD language, its code/network snippets are designed to run on each ‘element’ being targeted. In LOPs this means primitives by default, meaning there is no need to add a loop to iterate over each target primitive; that happens automatically. Each attribute of the primitives is accessed using the @ syntax, or Bind VOPs.

Wrangle and VOP LOP also have a second mode, Run on Elements of Array Attributes. In this case, the elements over which the code will run are the elements of array properties on primitives. This allows for faster operations over PointInstancer or Points prims, or even the points of heavy meshes.

Collections ¶

USD Collections can be thought of as groups for primitives, and LOPs has a few mechanisms to make working with collections convenient. Collection specifiers can take three forms:

/foo/bar.collection:collection_name
%/foo/bar/collection_name
%collection_name

Other collections can be an Include Pattern; however Exclude Patterns cannot target another collection yet; only explicit paths can be excluded. Most parameters looking for prim path(s) can also take a collection specifier.

Stage Manager ¶

A very interesting utility LOP, the Stage Manager LOP is 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. Mostly these only work on prims which have been defined in the same layer/lop network which the stage manager is functioning, since USD doesn’t allow a layer to re-define existing prim paths/namespaces.

Graft Stages and Graft Branches ¶

Graft is a different animal. It uses some low-level USD functions to do something USD normally doesn’t do well, it combines different input stages together, at arbitrary locations in the scene graph.

Here is a more detailed explanation from the developer:

The first input is passed through unchanged. The second and following inputs each have their layers flattened to a single layer (one layer per input). Then the root primitive of each of those flattened layers is copied (using SdfCopySpec) to a location on the stage. Each input can be sent to a completely different location. The path that serves as the root for each input is calculated by taking the Primitive Path parameter, and appending the per-input string specified in the Inputs widget at the bottom of the parameter dialog. If a given input doesn’t have a value specified, it instead appends the “Destination Path Default” parameter to the Primitive Path parameter (where the Destination Path Default gets evaluated separately for each input).

The fact that SdfCopySpec is used to bring the inputs' contents onto the stage, and that the layers of each input are flattened can make this a pretty expensive operation. But it effectively allows you to combine a bunch of separate stages together with each stage being put at an arbitrary location in the final scene graph tree. This manipulation of the scene graph hierarchy is not something that USD generally makes very easy to do.

Output to Disk ¶

USD Layers can be written to disk using a ROP USD Output LOP. This can be a simple operation, that writes out a flattened stage to a single USD layer on disk. Because USD composition arcs can be intricate, USD exports have support for elaborate multi-file exports. This section is not exhaustive, as the topic can get quite complex, but should provide enough context to understand what the USD ROP is doing.

USD ROP ¶

The ROP USD Output LOP is the primary engine which writes out USD layers to disk. It has options for writing out per-frame files, which directory to store sublayers, and omitting start/end timecode metadata. It also supports render-time Context Options. The key parameter though is the Save Style. This determines how the LOP graph and the scene description it generates, is expressed on disk.

Flatten Implicit Layers - Flattens layers implied by Configure Layer LOPs or “Save Path” parameters. Also has options to flatten any SOP layers and/or File layers. References are preserved.
Flatten All Layers - Flattens all sublayers into the Output File, ignoring implicit layers. References are preserved.
Flatten Stage - Every bit of composed scene description on the stage is flattened into the Output File. Useful for debugging or portability, but not generally used. Can produce extremely large files and take a very long time, on large scale production scenes!
Separate Layers - Every layer on the Layer Stack is saved to disk, and is a Sublayer in the Output File. Preserves all sublayers and references

When writing out multiple layers at once, layers with the .usd extension will use the same layer extension as found on the ROP’s Output File. If you want to force a Save Path layer to be ascii or binary, you must use .usda or .usdc respectively.

.usd - binary, or use output file extension
.usda - ascii
.usdc - binary

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).

Layer Break ¶

SOP Layers ¶

SOP Layers can be brought into a scene either as References or as Sublayers (SOP layer names end in “.sop”, which can be seen in the Layer Stack or Composition tabs of the Scene Graph Details pane). By default, a SOP layer’s node path will be its path on disk (relative to the Output File or Sublayer Directory). The USD Configure SOP can be used to override the layer’s output path to a specific location on disk.

SOP I/O ¶

LOP Import ¶

The LOP Import SOP brings part or all of a scene into SOPs. Based on the primitive pattern and purpose, you can import USD primitives as USD Packed Prims into SOPs. By default it ignores layer breaks. Also the Time at which the prims are imported is the scene’s start frame by default; if you need to bring in animated geometry, you can to set Time to $FF. However, this will be slow and does a lot of work unnecessarily, most of the time. You can get much faster results by animating the usdFrame intrinsic via Wrangle or VOP, found on the USD Packed Prims in your scene.

setprimintrinsic(0, “usdFrame”, @primnum, @Frame);

SOP Import ¶

For bringing SOP data back into LOPs, use the SOP Import SOP. There is a USD Configure SOP which has all the same options, for setting up output layers and options in SOP-land, which is used when Load as Reference is turned on. Be aware, USD defaults to right-hand oriented meshes, whereas Houdini’s is left-handed. If your meshes are right-handed, remember to turn on ‘Reverse Polygon Vertex Ordering’ when modifying geometry in SOPs. You’ll also want to make sure the mesh prims are properly set to be Subdivs or not.

There are some point attributes, which can be used to create new primitives in USD, based on points in SOPs:

s@usdprimtype - sets the usd prim type
s@path - the prim path
s@name - the prim name
s@usdkind - set the kind
Standard Houdini transform attributes can set the transform of the prim (P, N, etc…)

When converting SOP geometry back to LOPs, try to be as efficient as possible. By default, attributes will be time sampled, but you can designate attributes to not be time sampled by adding them to ‘Set Default Values’. Remember to also set the Topology Attributes to Static as well, to get non-time sampled attributes. USD (and specifically Hydra) do more work when values are time sampled, even if there is only a single time sample. In small setups it probably won’t make much difference, but larger scenes will definitely have an impact.

Here is the conversion between Houdini Geometry attributes and USD primvars interpolation:

Houdini	USD
Detail	Constant
Primitive	Uniform
Vertex	faceVarying
Point	Vertex

These standard Houdini attributes convert to the equivalent USD standard by default:

Houdini	USD
Cd	primvars:displayColor
Alpha	primvars:displayOpacity
widths, width, pscale	widths
P	points
N	normals
bounds	extents
v	velocities
id	ids

Note that for the widths attribute, preference is given to @widths, then @width, then @pscale.

Something to be aware of, when importing geometry back from SOPs. After your mesh/points prim(s) are unpacked via USD Unpack SOP, a point attribute called ‘usdxform’ is added. This represents the computed world transform of the UsdPrim that point came from. Because the unpacked points are in their computed world space position, we can use @usdxform to return the points back into UsdPrim-space. This can be done using a Transform by Attribute, and toggling on ‘Invert Transformation’.

SOP Modify/Create ¶

An HDA wrapper around a SOP network and LOP/SOP Imports, to quickly modify and/or create geometry. The SOP Modify is a general-case/best-practice example of taking prims through a LOP-SOP-LOP cycle. It provides built-in support for transforming points back into UsdPrim-space automatically.

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 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 now provides a few LOPs for conveniently working with Point Instancers and Native Instances:

Modify Point Instances - transform individual instances, modify w/ SOPs
Extract Instances - extract and promote instances
Material Variation - authors primvars for shading variation

Interfaces ¶

Network Editor ¶

The network editor for LOPs is quite similar to SOPs in Houdini. Nodes which don’t contribute to the current display are styled differently. By default the descriptive parms are often the targeted prim path(s), and there is another label showing the number of layers being displayed.These can be turned off via the Network Editor’s Display Options (View ▸ Display Options ▸ Text Badges).

LOP nodes have a Debug Flag, and its function is related to how LOP networks are cooked. Normally each LOP makes a copy of the strongest layer in the stack, does its work on that working copy, then copies its contents back to the strongest layer on the stack. When a node has the debug flag enabled, instead of copying back to the strongest, it adds its working layer to the top of the stack. This makes the LayerStack grow with each node, instead of staying constant.

The Network Editor also puts a colored outline around LOP nodes which are editing the same layer. The color itself is random, and does not indicate anything apart from their editable layers being the same. This can be disabled in the Network Editor, under View ▸ Show LOP Layer Colors

Scene View ¶

By default, LOPs has its own HoudiniGL delegate which allows for selecting prims and using handles to edit your scene. The selection tools allow for using kind to select elements of the scene. Different Renderers can be selected from the drop-down (currently only Houdini GL and Hydra GL are practical), and one can look through cameras and lights.

Currently, if your current node is a Camera LOP, you can (more or less) lock the view to the Camera and navigate, as is possible outside of LOPs. However, controlling lights this way is still a bit troublesome.

To customize the context menu of the Scene Graph Tree, you can create UsdStagePrimMenu.xml on $HOUDINI_PATH; this same menu is also used with the Scene Graph Tree.

Scene Graph Tree ¶

Displays the composed USD stage in the top section, and Collections in the bottom section. Visibility/Active and Draw Mode opinions expressed here are stored in the session layer, but won’t get written out to disk. A few operations will actually create a new node in the graph, such as changing a variant. The Scene Graph Tree is also able to load and unload payloads. It also has various options for filtering prims/collections, and displaying different prim metadata. There is also a section for showing Collections.

The stage shown comes from the node selection, not necessarily the node w/ the display flag by default. However, there is a preference (Edit > Preferences > Lighting) to change this behavior.

The text of primitives will change color/style to indicate more information about the scene:

Green	Orange	Dark Orange	Blue	Dark Blue	Red Dot
Reference, Specialize, Inherit	Payload, Reference w/ Payload	Unloaded Payload	Instance	Master Prims (instance children)	Viewport override

To customize the context menu of the Scene Graph Tree, you can edit/create the same UsdStagePrimMenu.xml used by the Scene View.

Scene Graph Details ¶

Shows the properties of the selected primitive, as well as any metadata, and the layers contributing opinions to the selected prim. The Composition tab will show all composition arcs contributing to the selected prim/attribute, which are known as PrimStacks and PropertyStacks, respectively. PrimStacks/PropertyStacks are a bit different from LayerStacks, though similar in principle.

Scene Graph Layers ¶

Allows for inspecting the layers used in the scene. It also has some mechanisms for muting layers, but this particular muting only affects the viewport, it doesn’t persist in the scene graph the same way that muting a layer via Configure Stage does.

Edit Properties ¶

An extremely powerful LOP, the Edit Properties LOP used to create and edit USD primitives. Its interface is defined from the Edit Properties button on its UI, allowing you to pick and apply properties based on specific primitive schemas or just USD property types in general. Edit Properties can also be directly turned into a digital asset; several native nodes such as Light, Camera, and all of the “primitive” LOPs (i.e. Cube, Cone, etc…), are actually HDAs generated by Edit Properties.

Preferences ¶

There are a few preferences provided for LOPs, which can be found under Edit ▸ Preferences ▸ Lighting.