NCP-OUSD Practice Questions

Turning instanceable off on /ParkingLot/Car2 removes it from the shared prototype, forcing USD to recompute instancing. Car1 stays instanceable, so opinions targeting its children remain suppressed, while recomposition is triggered for any prims whose prototype membership changes—including Car1 via the prototype map update.

A. Instanceable=false is applied only to the edited prim; it does not cascade to other instances.

B. Car1 remains instanceable; child opinions are still ignored, not activated.

D. (selected) Re-indexing the prototype set updates Car1, so recomposition starts there as the prototype owner.

1. Pixar USD “Instancing and Prototypes”, OpenUSD 24.03, §“Breaking an Instance”, para 2-4

2. NVIDIA Omniverse Docs, “Instanceable Metadata”, 2023.r2, §“Effect on Composition”

3. Pixar USD API, “UsdPrim::SetInstanceable()”, OpenUSD 24.03, note 3

A well-defined kind hierarchy (e.g., 'component', 'group', 'assembly') allows applications and tools to reason about the structure of a scene without needing to inspect every prim. This is crucial for performance in large-scale pipelines. Tools can perform efficient stage traversals by choosing to stop at certain kinds of models, such as loading only assembly-level prims in a layout context. This prevents the need to populate and process the entire scene graph, significantly improving load times and interactivity.

B. The composition engine resolves prims based on composition arcs (references, variants, etc.), not the kind metadata. Kind is used by higher-level logic after composition.

C. Data duplication is primarily avoided using composition arcs like references and payloads, or through instancing, not by the kind classification system.

1. Pixar. (n.d.). USD Glossary: kind. In Universal Scene Description. Retrieved from https://graphics.pixar.com/usd/release/glossary.html#usdglossary-kind

2. Pixar. (n.d.). Models, Assets, and Scopes. In Universal Scene Description. "The primary role of kind is to establish a 'model hierarchy' that allows us to reason about and operate on 'models' as single units... This allows us to, for example, traverse a Stage, collecting up all of the models, without traversing down into the guts of each model."

UsdGeomSubset is a schema derived from UsdGeomCollection explicitly designed to partition the faces of a single UsdGeomMesh into disjoint or overlapping groups so that each subset can carry its own material binding or other per-subset attributes. This enables multiple materials on one mesh without duplicating geometry.

B. Visibility/purpose are authored on Imageable prims, not face subsets; Subsets do not affect those attributes.

C. Subsets are logical groupings; they do not force tessellation.

D. Subsets live beneath the mesh they partition, not at the stage root.

1. Pixar USD Documentation – UsdGeomSubset (https://openusd.org/release/api/classusdgeomsubset.html) §“Overview” lines 7-15.

2. Pixar USD Documentation – “Material Binding” (https://openusd.org/release/api/usdgeommaterialbindingreader.html) §“Per-face material binding using UsdGeomSubset” lines 2-10.

A reference arc composes the referenced layer’s prim contents beneath the local prim. Local opinions (e.g., xformOp:scale) sit in a stronger position than referenced opinions and therefore override any matching property coming from chair.usda.

A. References are one-directional; changes in the composed site do not propagate back.

B. References do not automatically import variant sets; that requires “variants” arcs.

C. Local specs are not ignored; they are stronger than the referenced data.

5. Pixar Animation Studios, “Reference Arcs”, USD Composition Docs, Sect. 4.1, ¶2-5 (https://openusd.org/release/usd/composition.html#reference)

6. Pixar Animation Studios, “Opinion Strength: Local vs. Reference”, USD Composition Docs, Sect. 2.1.2, ¶1-2

Native instancing composes each instance as a unique, addressable prim in the scene graph. This allows individual instances to be selected, inspected, and have their properties overridden independently. In contrast, point instancing uses a single UsdGeomPointInstancer prim to represent a vast collection of instances. The individual instances are not represented as prims in the scene graph; they are implicitly generated from attribute arrays (like positions, orientations, etc.) on the instancer prim. This makes point instancing highly efficient for rendering massive populations like forests or crowds, but at the cost of individual addressability.

A. Prototypes for both instancing methods are statically defined prims that are referenced; neither generates them dynamically during composition.

B. Both native and point instancing can use multiple prototypes. Point instancers use the protoIndices attribute to specify different prototypes per instance.

C. Prototypes for both methods can be defined in the same layer or referenced from external files; there is no such restriction.

1. Pixar. (2023). OpenUSD Documentation: Instancing. "Native instances are 'real' prims in the scenegraph... This means that native instances are individually selectable and queryable... For Point Instancers... The individual instances are not, themselves, prims that can be individually addressed, selected, or overridden." Retrieved from https://openusd.org/release/tutinstancing.html

2. NVIDIA Corporation. (2023). USD Glossary: Instancing. "Native Instancing: Instances are unique, addressable prims on the Stage... Point Instancing: A single prim that represents a collection of instances." (Section: Instancing).

Effective USD asset structure is guided by principles that ensure assets are efficient, maintainable, and easy for artists and developers to use. Legibility ensures the asset's purpose and layout are clear. Navigability means that components within the asset can be easily found and targeted. Modularity dictates that assets should be built from smaller, reusable, and overridable components, which is a core strength of USD's composition features. These principles lead to robust and scalable production pipelines.

B. Redundancy is the opposite of a good design principle; USD's composition arcs are designed to reduce data duplication and promote reuse.

E. Compressability is a desirable outcome of a well-structured asset and the chosen file format (e.g., .usdc), not a foundational principle of its logical organization.

1. Pixar, "The Art of Structuring USD Assets," OpenUSD Documentation. Accessed Oct 2023. This guide explicitly discusses the importance of creating assets that are "easy to read and navigate" (Legibility, Navigability) and "promote modularity."

2. Hooker, M., & Govindaraju, K., "Production-Ready USD," NVIDIA GTC 2021 Presentation S32537. The presentation emphasizes modularity and clear organization as key benefits and best practices for structuring USD assets in a production environment.

B: The usdcat command-line utility is a standard tool in the OpenUSD toolset designed for inspecting USD files and converting between its two primary formats: human-readable ASCII (.usda) and optimized binary (.usdc). The command usdcat input.usda -o output.usdc directly performs this conversion.

C: The .usd file extension is intentionally format-agnostic. The USD runtime does not rely on the extension to determine the format; instead, it reads the file's header to identify whether it is ASCII or binary. Therefore, renaming a .usda file to .usd is a valid operation, as the file's content remains a valid, readable ASCII layer.

A. The usdzip utility is used to create .usdz package archives, which bundle a USD scene and its dependencies. usdcat is for format conversion, not packaging.

D. Renaming a file does not change its underlying format. A .usda file is text-based, while a .usdc file is binary. A parser expecting a binary file would fail on the renamed text file.

1. OpenUSD Documentation, "Tools - usdcat." The documentation states that usdcat can be used to "convert a USD file from one format to another (e.g. .usda to .usdc)."

2. OpenUSD Documentation, "File Format Plugins - usd." The documentation explains that the .usd extension can be used for either ASCII or binary files and that the format is identified from the file's contents, not its name.

3. OpenUSD Documentation, "Tools - usdzip." This page describes usdzip as the tool for creating .usdz archives, distinguishing its function from usdcat.

OpenUSD does not have a native "struct" data type. The established convention for grouping related data components, such as from a compound type in another source, is to use namespace-prefixed attributes. A common prefix is used for all attributes that belong to the group, creating a logical association. For example, a complex primvar might be represented by primvars:myVar:values and primvars:myVar:indices. This approach is fundamental to how schemas like UsdGeomPrimvars organize complex data on primitives.

A. arrays are a value type for a single attribute, not a mechanism for grouping multiple distinct attributes together into a compound structure.

C. structs are a concept from other languages or systems; OpenUSD uses namespace-prefixed attributes to achieve a similar grouping, rather than having a native struct type.

1. Pixar, "USD Glossary - Namespace". OpenUSD Documentation. Accessed Oct 2023. (Describes the use of colons as namespace delimiters in identifiers).

2. Pixar, "UsdGeomPrimvars: UsdGeomPrimvar". OpenUSD Documentation. Accessed Oct 2023. (Provides concrete examples of namespace-prefixed attributes like primvars:displayColor and primvars:myindexedprimvar:indices).

3. Pixar, "Coding Standard: Schemas". OpenUSD Documentation. Accessed Oct 2023. (Section on "Attribute Names" discusses the namespacing convention for schema attributes).

The USD core automatically converts authored time samples from referenced layers so that all samples on the composed stage are expressed in the root layer’s timeCodesPerSecond. Divergent axis or unit metadata (upAxis, metersPerUnit, kilogramsPerUnit) are merely authored values; composition does not reconcile them—clients must handle any mismatch.

B. upAxis differences are not reconciled; applications must re-orient geometry.

C. No automatic mass-unit scaling is performed; values remain as-authored.

D. metersPerUnit is passed through; it is up to clients to scale geometry.

1. Pixar USD “Stage Metadata”, §“timeCodesPerSecond – automatic conversion across layer stacks”.

2. USD Geometry Guide, §“Units and Up Axis” – note on lack of automatic conversion.

3. NVIDIA Omniverse Docs “Reference Best Practices”, §2.3 warning on mismatched metersPerUnit/upAxis.

The Tree prim selects the default variant from the foliagecolor variant set. The definition for the default variant is empty ("default" {}), so it contributes no opinions about displayColor. The Canopy prim also has a references arc to the class basefoliagecolor. According to USD's LIVRPS composition strength ordering, opinions from references are stronger than defaults but weaker than variants. Since the active variant is empty and there are no stronger local opinions, the value from the referenced class, [(0.2, 0.75, 0.1)], is composed as the final value.

A: This value [(0.5, 0.3, 0.05)] is from the orange variant, which is not selected in the Tree prim's variants field.

C: The value is not unset because the references arc successfully provides a value that is composed onto the prim.

D: This value [(0.05, 0.15, 0.05)] is from the evergreen variant, which is not selected.

1. Pixar USD Documentation, "Composition". The documentation details the LIVRPS (Local, Inherits, Variants, References, Payloads, Specializes) strength ordering, which governs how values are resolved. (https://graphics.pixar.com/usd/release/glossary.html#usdglossary-livrps)

2. Pixar USD Documentation, "Referencing and Layering". This section explains how references bring opinions from other files or prims into a composition. (https://graphics.pixar.com/usd/release/tutreferencinglayering.html)

3. NVIDIA Omniverse Documentation, "Deep Dive: Understanding Composition in USD". This guide explains how variants and references interact during composition.