Hello USD - Part 10: Reading Day

What I thought was going to happen yesterday:

What actually happened:

If I’m going to write a DSL that echos the philosophy of USD, I need to better understand the philosophy of USD. So I started looking for resources that provided overviews.

I did end up finding a bunch of new references using search terms like “USD philosophy”, etc. Also helpful, the ASWF wiki references the “Book of USD” which ended up being one of my top picks. I wanted “USD solves these problems” kind of videos/articles, not “Use our tool to make a thing” info.

Top Picks

Brief Overview - 4 min Video

Brief overview of what makes USD special by one of the folks who was there at the beginning.

In Depth Hello World - 29 min Video

Does include 101 how to information, but also explains why USD does things that way.

Longer Overview - 39 min Video

Has many “where to find more info” resources at the end.

Two Companions

The Glossary on the official documentation site holds a ton of in depth information, but it’s in alphabetical order, so it’s hard to read in a way that presents a cohesive narrative.

The Book of USD resource provides simpler definitions in a useful order as an entry point to learn more. Very helpful. Also loved the ton of screen shots from usdview. Bummed that like many resources it didn’t have much in terms of USDA file outputs, but that’s a me problem.

The authors of the Book of USD recommend that one cross references what they’ve written with the official docs, so I am listing them as companions.

Biggest OMG

https://developer.nvidia.com/isaac-sim No spoilers.

Where to Find More

Learning content hubs

Some of My Takeaways

Some language clarifications from a programmer with no VFX experience. Keep in mind I AM NEW, my understanding may be off.


A “Prim”, short for Primitive, refers to a node in the Stage data structure, which appears to be a tree. Nodes can conform to many types (Schemas). Any node of any type (Schema) is called a Prim, it appears. Prim is an instance of a Schema.

UPDATE: The above is not strictly correct. Node type may actually be SdfLayer not UsdPrim under the hood? Both Stage and SdfLayer conform to / inherit from public TfRefBase, public TfWeakBase which I have not followed up on but the comments on the linked to files were very helpful. I’m still feeling out the relationships here.


A “Layer” is not a visual layer like in 2D graphics program for indicating visual information in front of something else. A “Layer” in USD serves as a modifier, much like ViewModifier where the Prim gets passed through successive modifiers (layers). This is what its talking about when you see the key word over instead of def or class in a prim declaration , that outer Prims features eat the ones inside it, when in conflict. The original prims don’t have their information changed, but the renderers/processors will discard their opinions.

Prims can be referred to as being “composed of their Layer Stack”, ie they are what they ate.


Values aren’t referred to as being “set” as much as a given prim is expressing it’s opinion in the layer stack. It’s opinion may not win. Opinion conflict resolution is what the whole “Non-destructive Composition Engine” thing is about, mediating how to consolidate all the different layers opinions about what should be on the Stage.

For example if a particular opinion NEEDS to win it might be marked as a Specialization. Think css “!important” perhaps? In which case its the composition engine that discovers that and hands of the proper opinion to the renderer.

The acronym LIVRPS (Liver Peas) covers the negotiate order of precedence.


The word schema came into English via Kant from the greek skhēma “figure, appearance, the nature of a thing” etymonline. Websters now has an definition of it:

a mental codification of experience that includes a particular organized way of perceiving cognitively and responding to a complex situation or set of stimuli

This seems apt here.

Schemas in USD answer the questions “What is this thing… conceptually?” and “How do I interact with this thing?” Pixar split its concept of Schemas into two kinds:

Feels a little bit to me at the moment like a combination Classes/Structs, Protocols, and extensions all rolled into one when one gets down to the implementation part.

So a UsdGeoPrim isA Xform (A Schema), but it can have a Material description applied to it via the API MaterialBindingAPI (Also referred to as a Schema)

Warning: USD does use the keyword class, but it is used to create an instance of an Abstract Schema (one without visual content itself but may hold visual content).


If you see the flag instantiable It means something like to “the render doesn’t have to build me from scratch if its already built my Type before”.

Properties vs Metadata vs Attributes

Properties can be changed over time (think animations, think run time). Metadata cannot be changed (can be over-layed, think compile time).

A subset of properties, Attributes appear to be properties that are predefined by the spec, where a property in general could be a user defined key value pair.

Inside a USDA file

From what I can tell if it’s defined inside () it’s metadata, if it’s inside the {} it’s part a property. Properties can have associated metadata because properties are key:value pairs where the key is a String, but the value is what ever Schema you want.

#usda 1.0
    //This is metadata
    defaultPrim = "my_shape"

def Xform "Rainbow" //<- prim Conforming to the IsA schema "Xform"
    def Cube "cube" //<- prim Conforming to the IsA schema "Cube"
        //These are properties
        float3[] extent = [(-2, -2, -2), (2, 2, 2)]
        //This property has meta data and a name space (primvars:)
         color3f[] primvars:displayColor = [(0, 0, 1), (1,0,1), (1,0,0), (0, 1, 0),(0, 0, 1), (1,0,1), (1,0,0), (0, 1, 0)](
          interpolation = "vertex"

Examples from the Spec

A kind is a type of metadata that tags prims with their roll for use during stage traversal. (assemblage, group). These a kind can be user defined.

A purpose on the other hand is an attribute for the renderer to know if its there to be drawn or not. These are not user definable. (default, guide, proxy, render)

What this means for the DSL

Trouble. Pretty straight forward I think to create something that can punt out simpler p5js/Processing style generative art to a flat USD file. But will I really be able to create a multi-file/multilayer USD with references that preserves the composition philosophy? (Inhales sharply) TDB. ARKit doesn’t event want that, but being true to the spirit of USD seems like a good goal.

It would really help to have the Pixar Library as a Package, but even I think using that as a “My First Swift C++ Wrapper” project would be bad news. More tenable might be “My First Swift Python Wrapper”? Is that a thing?