> [!abstract] Summary > Extended USD course — the **L4 workshop** version. Covers the **history of USD** (Toyotory → Presto/TidScene → OpenUSD), **why it matters** (non-destructive composition, parallel workflows, single source of truth), **studio adoption**, the **four pillars** (Stage, Layers, Prims, Properties), essential terms (**Composition**), the **USD toolset** (`usdview`, `usdedit`, conversion), the **programming languages** used in USD (C++, Python, USDA ASCII) --- # USD Storyline ![[image-59.png]] - **Toy Story (1995)** was a big organizational mess. Starting with *A Bug's Life* (1998), Pixar developed **Presto** and **TidScene** — two workflows laying the base of what USD would become. Presto provided architectural foundations and TidScene introduced cached scene description. - In **2012**, Pixar launched the USD project. It was first used in production on *Finding Dory* (2015). - **2016** — Pixar released **OpenUSD** at SIGGRAPH. - Companies like **Autodesk**, **Apple**, and **NVIDIA** are now active members of the **Alliance for OpenUSD (AOUSD)**. > [!info] Sources > - https://www.pixar.com/openusd > - https://www.linkedin.com/pulse/how-pixars-usd-sparked-debate-aec-what-can-we-learn-from-diggins-nqgxe/ --- # Why Does It Matter ## Revolutionary Non-Destructive Composition USD's fundamental innovation lies in its **opinion-based architecture** that treats every piece of scene data as a contributory "opinion" rather than a permanent modification. This enables **unlimited layering** of changes while preserving complete data integrity throughout production. - **Traditional approach:** Permanent modifications → Data loss. - **USD approach:** Layered opinions → Preserved originals. > [!example] Vulgarised example > ``` > Base Character Asset: Hero_Character.usd > └── Core geometry, materials, rigging structure > > Shot-Specific Layer: Shot_0100.usd > ├── Opinion: "Hero wears red costume variant" > └── Opinion: "Hero position [X, Y, Z] at frame 24" > > Lighting Layer: Shot_0100_lighting.usd > └── Opinion: "Additional rim light from [direction]" > > Automatic Result: All opinions compose seamlessly > ``` > [!note] Observed behavior > This is why, when you duplicate an asset in **Solaris** without any changes, nothing happens visually — the asset and its duplicate share the same opinion, so no changes are expressed. ## Parallel Workflow - **Traditional sequential workflow:** modeling → texturing → rigging → animation → lighting → rendering… - **With USD**, multiple departments work **simultaneously** on shared assets without waiting for upstream completion: - **Accelerated timelines** — departments operate concurrently rather than sequentially. - **Improved quality control** — early issue detection while corrections are less expensive. - Every department contributes to the USD file = **LAYERS** = **LAYER STACK** (one per department). ## Single Source of Truth USD establishes a unified **single source of truth** for all scene data while maintaining flexibility for specialized departmental contributions. This eliminates the version conflicts and integration complexity that plagued traditional multi-file workflows. - Contains everything to render (**but no rig, no sim setup**). > [!example] Vulgarised example > ``` > Hero_Character.usd > ├── Automatic integration of all contributions > ├── Consistent version management > ├── Single access point for all departments > └── Seamless update propagation > ``` ## File-Format Evolution Context | Format | Summary | |-------------|---------| | **FBX** | Autodesk's proprietary format; widely adopted, but showing age and limitations. | | **Alembic** | Open-source; excellent geometry caching, limited material support. | | **OBJ** | Universal compatibility, but extremely basic. | | **USD** | Comprehensive scene description; open-source; designed for full production workflows. | ## Studio Adoption Examples - **DreamWorks (2017)** — transitioned *How to Train Your Dragon 3* to USD in 80 days. [SIGGRAPH paper](https://dl.acm.org/doi/10.1145/3214745.3214816) - **Disney Animation (2021)** — rebuilt the production pipeline around USD for *Encanto*. [SIGGRAPH paper](https://dl.acm.org/doi/10.1145/3532836.3536236) - **Animal Logic** — developed a sophisticated entity-fragment architecture leveraging USD. [SIGGRAPH paper](https://dl.acm.org/doi/10.1145/3543664.3543677) — see also [[ANIMAL LOGIC use of USD]]. - **DNEG** — adopted USD for *Ron's Gone Wrong*, demonstrating VFX-to-animation pipeline flexibility. [RenderMan story](https://renderman.pixar.com/stories/rons-gone-wrong) - **Superprod (2023)** — first French studio implementing a USD-based pipeline. [indac article](https://indac.org/blog/superprod-becomes-the-first-french-studio-to-deploy-a-pipeline-based-on-pixars-usd-technology/) - **The Yard** — progressively moving to USD (2025). --- # USD Source Code - [github.com/PixarAnimationStudios/OpenUSD](https://github.com/PixarAnimationStudios/OpenUSD) - Everything is open — you can deploy USD at home, build your own workflow, and extend it. --- # The Four Pillars of USD USD's architecture rests on four interconnected concepts: > **Stage → Layers → Prims → Properties** ## The Stage The **Stage** represents the final composed result of all USD data — think of it as the "theater" where the entire 3D scene comes together. - Contains the complete scene hierarchy after composition. - Manages temporal data and animation. - In **Solaris**, the first LOP level is the stage. ## Layers - Layers are individual USD files that contribute **opinions** about scene content. Each layer can define new prims, override existing data, or add information **without permanently modifying other layers**. This enables parallel workflows where multiple artists work simultaneously on the same assets. - A single `.usd` file is a layer. A `.usdz` file, by contrast, can contain multiple layers in a single archive. - A layer can represent a "piece" of a scene — a prop, a character, part of a rig, a lighting setup, etc. It can also represent **defaults** referenced in as a baseline (e.g. a layer holding settings for a sequence, referenced into each shot file). > See [how to organize layers and stages](https://www.sidefx.com/docs/houdini/solaris/usd.html#organize) for more. ## Prims **Prims** (short for *primitives*) are the fundamental organizational units within USD scenes. They form a hierarchical tree — similar to a file system — where each prim can contain child prims and associated data. Prims don't directly store geometry or scene data; they are **containers** for properties and hierarchy. **Essential prim concepts:** - **Path-based identification** — every prim has a unique path (e.g. `/World/Characters/Hero`). - **Hierarchical organization** — parent/child relationships create scene structure. - **Type specification** — prims have types that determine their role (`Mesh`, `Light`, `Camera`, etc.). - **Schema compliance** — prim types follow standardized schemas defining their behavior. **Common prim types:** ``` Xform — transform containers that can have children Scope — organizational containers without transform capabilities Mesh — geometry containers for polygonal data Material — material definition containers Light — lighting primitive containers Camera — camera definition containers ``` ## Properties Properties are the actual **data containers** inside prims. They split into two fundamental types — **attributes** and **relationships**. ### Attributes — Value Storage Attributes store typed data values such as positions, colors, sizes, or any other numerical/textual information. They represent the **what** of scene data — the concrete values that define object characteristics. **Common attribute examples:** ```usda xformOp:translate: (1.0, 0.0, 0.0) # Position vector points: [(0,0,0), (1,0,0), (1,1,0)] # Vertex positions array primvars:displayColor: [(1.0, 0.0, 0.0)] # Color values size: 2.0 # Scalar size value ``` ### Relationships — Connection Management Relationships establish **connections between prims**, expressing the **how** of scene organization. They don't store values directly but instead point to other prims or properties, enabling complex scene graphs and data dependencies. **Relationship examples:** ```usda material:binding → /Materials/HeroMaterial # Material assignment proxyPrim → /Characters/Hero/ProxyGeo # Proxy geometry reference collection:lightLink → /Lights/KeyLight # Light linking relationship ``` --- # Important Terms ## Composition The USD libraries include software for **composing** (overlaying) multiple layers into the full scene (stage) created by the top-level file. Composition merges the following differences between layers: - New prims. - Prim ordering. - Whether a prim is [active or inactive](https://www.sidefx.com/docs/houdini/solaris/usd.html#active). - [Variants](https://www.sidefx.com/docs/houdini/solaris/usd.html#variants%20and%20variant%20sets). - New properties (attributes and relationships). - Attribute values. Higher layers can also **block** (unset) the value of an attribute so it appears unassigned. - Metadata values. > [!info] Houdini > Houdini automatically composes the various on-disk and in-memory layers created as you edit USD. Built-in tools let you understand what's on each layer and how layers are composed. --- # USD Toolset ## USD Format and Conversion ![[USD Extension]] ## USD View - [openusd.org — `usdview`](https://openusd.org/release/toolset.html#usdview) - **TODO:** example with the Houdini command line. ## `usdedit` `usdedit` is a simple script that converts any single USD-readable file into its (temporary) `.usda` text equivalent and opens it in your chosen editor (taken from the `EDITOR` environment variable). When you quit the editor, changes are converted back to the original file's format (if the `FileFormatPlugin` allows writing) and the original file's contents are replaced. **Usage:** ```bash usdedit [-h] [-n] [-f] [-p PREFIX] usdFileName ``` --- # Programming Languages in USD ## C++ — The Foundation Layer Core USD library implementation, performance-critical operations, and native integrations. **Usage areas:** - **USD core library** — the entire USD runtime, composition engine, and fundamental data structures are implemented in C++. - **Performance-critical operations** — scene traversal, composition resolution, large-scale data processing. - **Native DCC integration** — Maya-USD plugin, Houdini Solaris, and other integrations use C++ for performance. - **Custom schema generation** — the `usdGenSchema` tool generates C++ code from schema definitions. ## Python — The Scripting and API Layer High-level scripting, pipeline automation, and accessible USD manipulation. **Usage areas:** - **USD Python API** — complete bindings for all USD functionality, enabling scripting and automation. - **Pipeline integration** — custom tools, asset management systems, workflow automation. - **Rapid prototyping** — quick scene creation, testing, and development workflows. - **Educational use** — learning USD concepts through accessible Python syntax. ## ASCII (USDA Syntax) Defining custom schemas, data structures, and USD scene descriptions. **Key features:** - **Human-readable** — ASCII-based syntax, easy to read and edit. - **Schema generation** — used by `usdGenSchema` to create C++ implementation code. - **Version-control friendly** — text-based, works well with diff tools. - **Extensible** — supports custom metadata, attributes, and relationships. > [!example] Real file example > See [[../USD Practice/USD Analysing usda files|USD Analysing usda files]] for a walkthrough of reading a `.usda`. --- # 🔗 Related - [[6.30 USD Theory]] — condensed theory with Rodeo-pipeline examples. - [[USD terms and definitions]] — quick glossary. - [[USD Extension]] — `.usd` / `.usda` / `.usdc` / `.usdz` formats. - [[ANIMAL LOGIC use of USD]] — entity-fragment architecture at studio scale. - [[../USD Practice/USD Analysing usda files|USD Analysing usda files]] — reading a real `.usda` file. - [[../USD Practice/USD Jemalloc use|USD Jemalloc use]] — memory allocator notes for USD workloads. - [[../USD Practice/USD Maximizing Performance - by pixar|USD Maximizing Performance — by Pixar]]. - [[USD MOC]]