WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Understand USD fundamentals

Understand USD fundamentals

Spatial ComputingGraphics & GamesWWDC 2022
Watch original video

Highlight

This Session is an introductory introduction to the USD format, aimed at Apple platform developers who are not familiar with USD. USD is a universal 3D scene description format developed by Pixar and used heavily by Apple in ARKit and RealityKit.

Core Content

When many teams first come into contact with USD (Universal Scene Description), they treat it as a 3D file format. This understanding is too narrow. The definition given at the beginning of Session is more accurate: USD has three parts, scene description specification, API, and rendering system (01:22). This lecture only talks about the first part: how to describe, organize and put scene data into files.

The problem comes from the collaboration of 3D assets. An AR product model may have geometry, materials, lighting, animation, and physical properties. Modelers, materialists, toolchains, and apps all have to modify the same asset. Bake all the contents into one file, and any modification will become a full replacement. USD’s answer is to split the scene into Stage, Layer, Prim, and Attribute, and then use Composition to combine them.

Apple explains this model with two examples. The first is the pancake scene: aPancakesPut it under transformBlueberry_01, and then put mesh and material binding in Blueberry (06:55). The second is the chessboard scene: the chess piece assets come from the catalog layer, the position comes from the layout layer, the color is switched through variantSet, and the repeated chess pieces are reused through instanceable metadata (08:05).

This is the core value of USD. The asset file saves the basic data, the layout file saves the placement, and the variant file saves the switchable scheme. The final Stage is composed of these Layers. You can replace a layer without destroying other layers.

Detailed Content

Stage, Layer, Prim: First split the scene into levels

(02:43) USD’s Stage is a scene graph. It organizes all scene elements hierarchically. Stage consists of one or more Layers; Layers are usually files containing scene information. The basic container in Stage is Prim. Prim can continue to contain Prim, forming a tree structure.

Here is a conceptual USDA snippet based on the “Sphere and Cube” example from the talk:

#usda 1.0

def Sphere "Sphere"
{
}

def Cube "Cube"
{
}

Key points:

  • #usda 1.0Indicates that this is the ASCII text representation of USD, which is used in speech to explain the file contents. -def Sphere "Sphere"Define a file namedSphereThe Prim, type is alsoSphere。
  • def Cube "Cube"Define a file namedCubeThe Prim, type isCube.
  • Prim types come from schema. The speech said that schema provides structured meaning for common concepts such as geometry and materials (04:10).

Schema also declares attributes. for speechSphereSchema example: the sphere hasradiusandextent, and can have a default value (04:23). When a Sphere Prim does not explicitly set radius, it will use the default radius in the schema.1。

Attribute and metadata: data is placed at the correct level

(05:12) Prim’s attribute is called Attribute. Each Attribute has a type and a value. Prim, Attribute, and Stage can also carry metadata. Metadata is key-value information, used to describe the auxiliary data of the scene.

The speech lists three common stage metadata:metersPerUnit、upAxis、doc(06:26). The following is a conceptual way of writing:

#usda 1.0
(
    metersPerUnit = 1
    upAxis = "Y"
    doc = "Pancakes scene for workflow tracking"
)

Key points:

  • metersPerUnitDefine scene scale units. It affects the entire Stage, so it is placed in Stage metadata. -upAxisDefines which axis is the upward direction in the camera. The speech explicitly mentions that it can be one of X, Y, Z. -docSave description text for workflow tracking.
  • metadata should be written at the level it affects. If it affects the whole world, write it in Stage; if it only affects a single Prim, write it in Prim.

This rule is very practical. After the AR assets enter the app, the scale and coordinate direction are wrong, which will directly lead to the wrong size and wrong orientation of the model. Writing global metadata clearly is more reliable than making temporary corrections in the app.

Reference and defaultPrim: reuse assets, do not copy data

(08:40) The board example starts with reference. The function of Reference is to allow a Prim in one Stage to refer to another Layer or a Prim in the same Stage without copying data. This reduces duplication and allows different people and applications to update data separately.

Speech suggestions USD assets are always author onedefaultPrim(09:28). When an external layer references this asset, USD knows which Prim should be brought in by default.

Conceptual example:

# Pawn.usda
(
    defaultPrim = "Pawn"
)

def Xform "Pawn"
{
}

Key points:

  • defaultPrim = "Pawn"Written in Stage metadata, specify the Prim exported by this file by default. -def Xform "Pawn"Define the asset root Prim.
  • Other Layer referencesPawn.usda, you can get it directlyPawn, no need to write additional paths.

if notdefaultPrim, or you want to reference something other than the default Prim. The speech gives another way: explicitly specify the Prim path (09:53). Prim path is the unique identifier of Prim in Stage, such as/World/Pawn、/World/Knight。

Payload: Lazy loading of large data

(10:44) Reference brings assets into the scene. For large scenes this may be too heavy. USD provides payload, which is a type of reference that can be loaded lazily. The talk recommends using payloads when referencing complex geometry, large scene graphs, props, or characters.

Conceptual example:

# Catalog.usda

def Xform "Pawn"
(
    payload = @Pawn.usda@
)
{
}

Key points:

  • PawnIs the Prim in the catalog layer. -payload = @Pawn.usda@Represents this Prim’s actual scene description as coming from an external asset.
  • When opening the Stage, you can not load the payload first, and the scene will be displayed as empty.
  • The chess pieces will not enter the scene until payload loading is enabled.

This is suitable for asset browsers, level editors, and large AR scenes. The user sees the structure and placeholder first, and then loads the geometry when details are needed. The memory pressure will be much smaller.

Layering: Change the position in the new Layer

(11:28) After the chess pieces are brought in, they have to be placed on the chessboard. The lecture does not modify the catalog layer, but createsChessSetStage and passsublayersIntroducing catalog layer and layout layer (12:06).

The order of Layers has a strong or weak relationship. The upper layer is stronger and can add or overwrite lower layer data (11:30). This makes moving pieces a non-destructive modification.

Conceptual example:

# ChessSet.usda
(
    subLayers = [
        @Catalog.usda@,
        @Layout.usda@
    ]
)

Key points:

  • ChessSet.usdais the stage file that is finally opened. -Catalog.usdaProvide chess piece assets. -Layout.usdaSave chess piece position overlay.
  • movePawn_01At this time, only the translation attribute in the layout layer is changed, and there is no need to change the pawn asset itself.

This workflow is ideal for multi-person collaboration. Asset team maintenanceCatalog.usda, level or space layout team maintenanceLayout.usda. The final App loads the combined Stage.

VariantSets: switch to different solutions for the same asset

(13:39) The opponent side of the board requires dark pieces. Instead of making another set of dark models, the speech added a variantSet to the assets. VariantSet dynamically switches discrete options on the Stage. Options can be materials, geometry, or any data that USD can represent.

Conceptual example:

# Pawn.usda

def Xform "Pawn" (
    variants = {
        string color = "Light"
    }
    prepend variantSets = "color"
)
{
    variantSet "color" = {
        "Light" {
            # use light material
        }
        "Dark" {
            # use dark material
        }
    }
}

Key points:

  • variantSets = "color"Indicates that this Prim has a namedcolorset of variants. -string color = "Light"Set default variant. The default chess pieces in the speech use light material. -"Light"and"Dark"are two switchable variants.
  • Change the variant of a certain Pawn in the catalog layer toDark, the chess piece will use a dark material (14:49).

This concept can be directly transferred to the product configurator. The wood grain of furniture, the color of cars, and the equipment of characters can all be expressed using variantSet. There is only one copy of the asset, and the configuration is saved as the selection result.

Instancing: Duplicate scene graph shared data

(15:09) There are many duplicate pieces on the chessboard. USD’s scene graph instancing allows multiple Prims on the Stage to share the same scene graph. The presentation noted that it would bring memory and performance improvements.

Conceptual example:

def Xform "Pawn_01" (
    instanceable = true
    payload = @Pawn.usda@
)
{
}

def Xform "Pawn_02" (
    instanceable = true
    payload = @Pawn.usda@
)
{
}

Key points:

  • instanceable = trueIt is the metadata written on Prim.
  • Both Pawns reference the samePawn.usda.
  • USD can treat these Prims as candidate instances and reuse the same scene graph.
  • The picture remains unchanged, but the duplicate data is reduced.

Chess pieces are just examples. The speech also mentioned scenes with a large number of repeated objects such as foliage and furniture (15:20). Mobile AR scenarios especially require this type of optimization.

File format: usda, usdc, usd, usdz

(16:48) Finally, the speech summarized the USD file format into four categories:

  • .usda: ASCII text, readable, the examples in Session are explained using it. -.usdc: Crate binary format, more compact and more efficient loading. -.usd: Can be ASCII or binary crate. -.usdz: Uncompressed zip package containing USD files and auxiliary files such as textures.

Can be used during development.usdaSee the structure clearly. When publishing to the Apple platform, it is common to encounter.usdz, because it packages resources such as models, textures, materials, etc. into a single file, suitable for transmission and preview.

Core Takeaways

1. Make an AR asset structure checker

  • What: Read a USD or USDZ asset, list Stage metadata, defaultPrim, Prim tier and payload usage.
  • Why it’s worth doing: Speaking advice is always authordefaultPrim, and emphasize that metadata is placed at the correct level. Inspectors can detect structural issues before assets enter the app.
  • How ​​to start: Learn the concepts of Stage, Prim, and Layer from Pixar USD documentation, output firstdefaultPrim、metersPerUnit、upAxis, Prim path list.

2. Make a product material configurator

  • What to do: The same 3D product is available in multiple colors or materials, and users can switch configurations in the App.
  • Why it’s worth doing: variantSet expresses exactly discrete alternatives. The presentation illustrates this workflow with chess pieces switching from Light to Dark.
  • How ​​to get started: Complete material selection during the asset creation phasecolorvariantSet, the App side saves the variant name selected by the user.

3. Make a lazy loading browser for large scenes

  • What to do: Display the scene structure and placeholders first, and then load the complex model when the user approaches a certain area.
  • Why it’s worth doing: The payload is used for lazy loading of complex geometries and large scene graphs. It reduces the initial cost of opening a Stage.
  • How ​​to start: Make large props or characters into payload references. The browser first reads the Stage level, and then presses the interaction to trigger the payload loading.

4. Make a non-destructive AR layout editor

  • What: Let users move, rotate, and place 3D objects without changing the original asset file.
  • Why it’s worth doing: Layering can separate assets and layout. in speechCatalog.usdaandLayout.usdaThat’s the pattern.
  • How ​​to start: Put the asset reference in the catalog layer, write the transform overlay into the layout layer, and finally use a Stage to combine the two layers.

Comments

GitHub Issues · utterances