Practice Free NCP-OUSD Exam Online Questions
Question #11
Which of the following best defines the primary function of a specialize composition arc in OpenUSD?
- A . It provides a strong overriding mechanism since opinions expressed by the specialize arc always win.
- B . To broadcast specs from a source prim to destination prims as fallback values if no other opinion exists.
- C . When used additively, these arcs make a prim more functionally and descriptively specialized.
- D . To uniformly broadcast stronger specs from a source prim to destination prims.
Correct Answer: B
B
Explanation:
A specialize composition arc broadcasts fallback opinions from a source prim to one or more specializing destination prims. NVIDIA’s Learn OpenUSD glossary defines specializes as a composition arc that broadcasts fallback values from a source prim and applies only when the specializing prim does not already have its own authored opinion. It further explains that specializes is similar to inherits in its broadcast behavior, but differs because specializes contributes fallback values rather than stronger reusable opinions. (docs.nvidia.com)
Option B is correct because it captures the essential behavior: source specs are supplied as fallback data.
Option A is incorrect because specializes is the weakest composition arc in LIVERPS ordering; it does not always win. NVIDIA’s strength-ordering guide states that specializes acts as a new fallback value, winning only when stronger composition choices provide no value. (docs.nvidia.com) Option C describes the conceptual naming idea of specialization but not the primary functional mechanism.
Option D is incorrect because “stronger specs” describes a different strength behavior. This aligns with Composition → Inherits and Specializes, Fallback Opinions, LIVERPS Strength Ordering.
B
Explanation:
A specialize composition arc broadcasts fallback opinions from a source prim to one or more specializing destination prims. NVIDIA’s Learn OpenUSD glossary defines specializes as a composition arc that broadcasts fallback values from a source prim and applies only when the specializing prim does not already have its own authored opinion. It further explains that specializes is similar to inherits in its broadcast behavior, but differs because specializes contributes fallback values rather than stronger reusable opinions. (docs.nvidia.com)
Option B is correct because it captures the essential behavior: source specs are supplied as fallback data.
Option A is incorrect because specializes is the weakest composition arc in LIVERPS ordering; it does not always win. NVIDIA’s strength-ordering guide states that specializes acts as a new fallback value, winning only when stronger composition choices provide no value. (docs.nvidia.com) Option C describes the conceptual naming idea of specialization but not the primary functional mechanism.
Option D is incorrect because “stronger specs” describes a different strength behavior. This aligns with Composition → Inherits and Specializes, Fallback Opinions, LIVERPS Strength Ordering.
Question #12
What is the only reliable way in OpenUSD of encoding the motion of primitives whose topology is varying over time?
- A . positions
- B . velocities
- C . orientations
Correct Answer: B
B
Explanation:
The reliable encoding mechanism is velocities. OpenUSD attributes may vary over time through time samples, but position interpolation assumes correspondence between sampled array elements. When topology changes over time, adjacent samples may not contain the same number of points, and even matching indices may no longer identify the same physical point. NVIDIA’s Learn OpenUSD glossary defines variability as whether a property can change over time, with varying attributes supporting time samples and interpolation behavior. (docs.nvidia.com)
The OpenUSD geometry specification is explicit: “Using velocities is the only reliable way of encoding the motion of primitives whose topology is varying over time,” because neighboring sample indices may be unrelated or may not have the same element count. (openusd.org)
Option B is therefore correct. Positions alone are insufficient when topology changes, because linear interpolation between position arrays depends on stable point correspondence. Orientations describe rotational state, commonly relevant to transforms or instancing, but they do not solve topology-varying point motion. This maps to Data Modeling → Time Samples, Attribute Variability, UsdGeom Point-Based Motion, Velocities, and Animated Geometry.
B
Explanation:
The reliable encoding mechanism is velocities. OpenUSD attributes may vary over time through time samples, but position interpolation assumes correspondence between sampled array elements. When topology changes over time, adjacent samples may not contain the same number of points, and even matching indices may no longer identify the same physical point. NVIDIA’s Learn OpenUSD glossary defines variability as whether a property can change over time, with varying attributes supporting time samples and interpolation behavior. (docs.nvidia.com)
The OpenUSD geometry specification is explicit: “Using velocities is the only reliable way of encoding the motion of primitives whose topology is varying over time,” because neighboring sample indices may be unrelated or may not have the same element count. (openusd.org)
Option B is therefore correct. Positions alone are insufficient when topology changes, because linear interpolation between position arrays depends on stable point correspondence. Orientations describe rotational state, commonly relevant to transforms or instancing, but they do not solve topology-varying point motion. This maps to Data Modeling → Time Samples, Attribute Variability, UsdGeom Point-Based Motion, Velocities, and Animated Geometry.
Question #13
Which of the following are true for SdfChangeBlocks? Choose two.
- A . Notifications are muted for changes done within the block, even after the block exits
- B . Existing metadata and properties can be changed using USD APIs within the same block
- C . It is unsafe to query Prims that are mutating within the same block
- D . It is unsafe to delete or create new PrimSpec hierarchies using Sdf APIs
Correct Answer: C
C
Explanation:
Strictly evaluated against the OpenUSD API contract, C is the only fully correct statement as written. SdfChangeBlock groups multiple low-level Sdf edits so that change processing can be delayed and handled efficiently as one batch. The official API documentation states that opening a change block causes Sdf to delay notifications until the outermost block exits; notifications are queued, not permanently muted. Therefore, A is incorrect. The same documentation gives a strong warning that it is not safe to use Usd or other downstream APIs while a change block is open, because those representations may be stale or may hold expired handles to Sdf objects. Therefore, querying mutating prims during the block is unsafe, making C correct.
Option B is incorrect because it explicitly says to use USD APIs inside the block, which the official guidance warns against.
Option D is also incorrect because the intended safe authoring pattern is to gather required edits first, then apply them directly through the Sdf API inside the change block. This aligns with Pipeline Development → Efficient Authoring, Sdf Layers, SdfChangeBlock, Change Notification, and Bulk Scene Description Mutation.
C
Explanation:
Strictly evaluated against the OpenUSD API contract, C is the only fully correct statement as written. SdfChangeBlock groups multiple low-level Sdf edits so that change processing can be delayed and handled efficiently as one batch. The official API documentation states that opening a change block causes Sdf to delay notifications until the outermost block exits; notifications are queued, not permanently muted. Therefore, A is incorrect. The same documentation gives a strong warning that it is not safe to use Usd or other downstream APIs while a change block is open, because those representations may be stale or may hold expired handles to Sdf objects. Therefore, querying mutating prims during the block is unsafe, making C correct.
Option B is incorrect because it explicitly says to use USD APIs inside the block, which the official guidance warns against.
Option D is also incorrect because the intended safe authoring pattern is to gather required edits first, then apply them directly through the Sdf API inside the change block. This aligns with Pipeline Development → Efficient Authoring, Sdf Layers, SdfChangeBlock, Change Notification, and Bulk Scene Description Mutation.
Question #14
Which of these is the most essential composition arc to put onto the components of a model hierarchy?
- A . payloads
- B . inherits
- C . variant sets
- D . specializes
Correct Answer: A
A
Explanation:
The most essential composition arc for components in a model hierarchy is the payload. NVIDIA’s Learn OpenUSD glossary describes payloads as composition arcs similar to references, but with deferred loading for scalability, and specifically notes that payloads are typically added to component asset root prims for efficient scalable composition. (docs.nvidia.com)
Option A is correct because component models act as the leaf or pruning boundary of the model hierarchy. NVIDIA’s model-kind guidance explains that the model hierarchy is designed to prune traversal at the component boundary, and that component models cannot contain other component models as descendants. (docs.nvidia.com) Payloads reinforce that design by allowing large component contents to remain unloaded until needed, improving stage-opening performance and enabling scalable aggregation of large scenes.
Option B is incorrect because inherits are mainly for reusable class-style opinions.
Option C is useful for alternatives such as LODs or looks, but it is not the essential component-loading mechanism.
Option D is a weaker composition mechanism used for specialization and fallback-style refinement. This aligns with Content Aggregation → Asset Structure, Model Hierarchy, Components, Payloads, and Scalable Scene Assembly.
A
Explanation:
The most essential composition arc for components in a model hierarchy is the payload. NVIDIA’s Learn OpenUSD glossary describes payloads as composition arcs similar to references, but with deferred loading for scalability, and specifically notes that payloads are typically added to component asset root prims for efficient scalable composition. (docs.nvidia.com)
Option A is correct because component models act as the leaf or pruning boundary of the model hierarchy. NVIDIA’s model-kind guidance explains that the model hierarchy is designed to prune traversal at the component boundary, and that component models cannot contain other component models as descendants. (docs.nvidia.com) Payloads reinforce that design by allowing large component contents to remain unloaded until needed, improving stage-opening performance and enabling scalable aggregation of large scenes.
Option B is incorrect because inherits are mainly for reusable class-style opinions.
Option C is useful for alternatives such as LODs or looks, but it is not the essential component-loading mechanism.
Option D is a weaker composition mechanism used for specialization and fallback-style refinement. This aligns with Content Aggregation → Asset Structure, Model Hierarchy, Components, Payloads, and Scalable Scene Assembly.
Question #15
When prioritizing ease of interchange and reducing dependencies between different applications in a pipeline, why might codeless schemas, schemas defined purely in .usda files, be preferred over codeful schemas, schemas with generated classes using usdGenSchema?
- A . Codeless schemas enable interchange by loading .usda definitions directly, avoiding the need to compile or link against custom schema code libraries.
- B . Codeless schemas provide more convenient, strongly-typed C++ and Python APIs for property access compared to code generated via usdGenSchema.
- C . Generated schemas cannot define fallback attribute values within their .usda definition, making interchange less consistent across applications.
- D . Only codeless schemas are added to the schema registry, allowing them to participate in property value resolution correctly.
Correct Answer: A
A
Explanation:
Codeless schemas are preferred when the pipeline goal is portability, easy distribution, and reduced application coupling. NVIDIA’s Learn OpenUSD schema guidance states that schemas define data models and optional APIs for encoding and interchanging 3D and non-3D concepts, and notes a trend toward codeless schemas for easier distribution, with schemas becoming more focused on data modeling rather than behavior implementation.
Option A is correct because a codeless schema can be distributed as schema data and plugin metadata without requiring every consuming application to compile, link, or ship custom generated C++/Python schema classes. OpenUSD’s schema-generation documentation identifies codeless schemas as schemas produced without corresponding C++ classes, where only generatedSchema.usda and plugInfo.json are essential for runtime registration.
Option B is incorrect because strongly typed convenience APIs are the advantage of codeful generated schemas.
Option C is incorrect because fallback values are authored in schema definitions.
Option D is incorrect because codeful and codeless schemas can both participate in schema registration and value interpretation. This aligns with Customizing USD → Schemas, API Schemas, Codeless Schemas, Schema Registry, Data Modeling for Interchange.
A
Explanation:
Codeless schemas are preferred when the pipeline goal is portability, easy distribution, and reduced application coupling. NVIDIA’s Learn OpenUSD schema guidance states that schemas define data models and optional APIs for encoding and interchanging 3D and non-3D concepts, and notes a trend toward codeless schemas for easier distribution, with schemas becoming more focused on data modeling rather than behavior implementation.
Option A is correct because a codeless schema can be distributed as schema data and plugin metadata without requiring every consuming application to compile, link, or ship custom generated C++/Python schema classes. OpenUSD’s schema-generation documentation identifies codeless schemas as schemas produced without corresponding C++ classes, where only generatedSchema.usda and plugInfo.json are essential for runtime registration.
Option B is incorrect because strongly typed convenience APIs are the advantage of codeful generated schemas.
Option C is incorrect because fallback values are authored in schema definitions.
Option D is incorrect because codeful and codeless schemas can both participate in schema registration and value interpretation. This aligns with Customizing USD → Schemas, API Schemas, Codeless Schemas, Schema Registry, Data Modeling for Interchange.
Question #16
Which of the following are valid reasons for choosing to use or develop a standalone converter instead of an importer/exporter for a digital content creation (DCC) application? Choose two.
- A . Standalone converters are the only way to convert proprietary formats.
- B . A converter always produces higher-fidelity results compared to an importer/exporter.
- C . You don’t have access to an SDK to develop a native exporter for the DCC.
- D . Your workflow requires batch conversion that is not suitable within the DCC.
Correct Answer: C, D
C, D
Explanation:
A standalone converter is appropriate when the conversion workflow should operate outside the DCC application. NVIDIA’s Learn OpenUSD Data Exchange lesson defines a standalone converter as a script, executable, or microservice dedicated to translating to and from another file format. It contrasts this with importers and exporters, which are implemented as part of a DCC application’s runtime or plugin system. (docs.nvidia.com)
Option C is correct because if a developer cannot access the DCC’s SDK, plugin API, or runtime integration path, a native importer/exporter may not be feasible. A separate converter can still be built around accessible file-level data, command-line tools, services, or external APIs.
Option D is also correct because standalone converters are well suited for automation, headless processing, farm execution, and batch conversion pipelines that do not belong inside an artist-facing DCC session. NVIDIA’s OpenUSD guidance also notes that data exchange implementations must account for different client needs, workflow performance, and content structures rather than assuming one implementation pattern fits all. (docs.nvidia.com)
Option A is false because proprietary formats can also be supported by native plugins or file format plugins when appropriate access exists.
Option B is false because fidelity depends on data mapping and implementation quality, not on whether the tool is standalone. This aligns with Data Exchange → Importers, Exporters, Standalone Converters, File Format Plugins, and Workflow Requirements.
C, D
Explanation:
A standalone converter is appropriate when the conversion workflow should operate outside the DCC application. NVIDIA’s Learn OpenUSD Data Exchange lesson defines a standalone converter as a script, executable, or microservice dedicated to translating to and from another file format. It contrasts this with importers and exporters, which are implemented as part of a DCC application’s runtime or plugin system. (docs.nvidia.com)
Option C is correct because if a developer cannot access the DCC’s SDK, plugin API, or runtime integration path, a native importer/exporter may not be feasible. A separate converter can still be built around accessible file-level data, command-line tools, services, or external APIs.
Option D is also correct because standalone converters are well suited for automation, headless processing, farm execution, and batch conversion pipelines that do not belong inside an artist-facing DCC session. NVIDIA’s OpenUSD guidance also notes that data exchange implementations must account for different client needs, workflow performance, and content structures rather than assuming one implementation pattern fits all. (docs.nvidia.com)
Option A is false because proprietary formats can also be supported by native plugins or file format plugins when appropriate access exists.
Option B is false because fidelity depends on data mapping and implementation quality, not on whether the tool is standalone. This aligns with Data Exchange → Importers, Exporters, Standalone Converters, File Format Plugins, and Workflow Requirements.
Question #17
What geometric attribute should be kept in sync when updating point position values on an object?
- A . purpose
- B . xformOps
- C . extent
- D . faceVertexIndices
Correct Answer: C
C
Explanation:
The geometric attribute that should be kept in sync is extent. In OpenUSD, point position values describe the authored point locations for point-based geometry, while extent represents the local-space geometric range or bounding box of a boundable primitive. The OpenUSD UsdGeomBoundable specification describes extent as a three-dimensional range measuring the authored gprim in its own local space, and states that if extent is authored, it should be authored at every time sample where geometry-affecting properties are authored to ensure correct evaluation.
Option C is correct because changing point positions can change the object’s local bounds. If the authored extent is not updated, downstream systems may compute incorrect framing, culling, selection bounds, or bounding-box display.
Option A is incorrect because purpose classifies geometry for render, proxy, guide, or default visibility categories.
Option B is incorrect because xformOps describe transform operations on the prim, not the local geometric bounds derived from point positions.
Option D is incorrect because faceVertexIndices describes mesh topology, not the bounding range. This aligns with Data Modeling → Geometry Attributes, Point-Based Geometry, Boundable Prims, Extent, and Time-Sampled Geometry.
C
Explanation:
The geometric attribute that should be kept in sync is extent. In OpenUSD, point position values describe the authored point locations for point-based geometry, while extent represents the local-space geometric range or bounding box of a boundable primitive. The OpenUSD UsdGeomBoundable specification describes extent as a three-dimensional range measuring the authored gprim in its own local space, and states that if extent is authored, it should be authored at every time sample where geometry-affecting properties are authored to ensure correct evaluation.
Option C is correct because changing point positions can change the object’s local bounds. If the authored extent is not updated, downstream systems may compute incorrect framing, culling, selection bounds, or bounding-box display.
Option A is incorrect because purpose classifies geometry for render, proxy, guide, or default visibility categories.
Option B is incorrect because xformOps describe transform operations on the prim, not the local geometric bounds derived from point positions.
Option D is incorrect because faceVertexIndices describes mesh topology, not the bounding range. This aligns with Data Modeling → Geometry Attributes, Point-Based Geometry, Boundable Prims, Extent, and Time-Sampled Geometry.
Question #18
In OpenUSD, when composing a stage, why might opinions from one layer not take effect in the final composed stage?
- A . The opinions are in a non-editable layer that does not allow modifications during composition.
- B . The layer containing the opinion does not use the correct schema for the data.
- C . The layer is not referenced properly, so its opinions are ignored.
- D . The layer containing the opinion has a lower strength than other layers, and its changes are overridden.
Correct Answer: D
D
Explanation:
An authored opinion may be valid and still not appear in the final composed stage because USD resolves competing opinions by strength ordering. NVIDIA’s Learn OpenUSD strength-ordering guide explains that, for each prim and property, the composition engine evaluates opinions from contributing layers and composition arcs using LIVRPS, giving precedence to stronger opinions when conflicts occur. It also states that stronger layers can override or add to data defined in weaker layers, enabling non-destructive edits and overrides.
Option D is correct because a weaker layer’s opinion can be hidden by a stronger opinion authored elsewhere in the layer stack or through a stronger composition context. This is a normal result of USD composition, not an error.
Option A is incorrect because editability controls whether a layer can be modified, not whether its authored opinions can contribute during composition.
Option B may indicate invalid or poorly modeled data, but schema choice alone is not the general reason an opinion loses.
Option C can be a troubleshooting case for missing referenced content, but the question asks why opinions from a composed layer may not take effect. This aligns with Composition → Layer Stacks, Opinion Strength, LIVRPS, Value Resolution, and Non-Destructive Overrides.
D
Explanation:
An authored opinion may be valid and still not appear in the final composed stage because USD resolves competing opinions by strength ordering. NVIDIA’s Learn OpenUSD strength-ordering guide explains that, for each prim and property, the composition engine evaluates opinions from contributing layers and composition arcs using LIVRPS, giving precedence to stronger opinions when conflicts occur. It also states that stronger layers can override or add to data defined in weaker layers, enabling non-destructive edits and overrides.
Option D is correct because a weaker layer’s opinion can be hidden by a stronger opinion authored elsewhere in the layer stack or through a stronger composition context. This is a normal result of USD composition, not an error.
Option A is incorrect because editability controls whether a layer can be modified, not whether its authored opinions can contribute during composition.
Option B may indicate invalid or poorly modeled data, but schema choice alone is not the general reason an opinion loses.
Option C can be a troubleshooting case for missing referenced content, but the question asks why opinions from a composed layer may not take effect. This aligns with Composition → Layer Stacks, Opinion Strength, LIVRPS, Value Resolution, and Non-Destructive Overrides.
Question #19
When constructing an OpenUSD scene, in which scenario is it most appropriate to use a payload instead of a reference?
- A . When an asset requires frequent updates, but the asset should default to the latest version.
- B . When deferring the loading of heavy assets until they are needed, thereby improving initial load performance.
- C . When the asset is small and inexpensive to load to ensure efficient transfer over web protocols.
- D . When it’s important to ensure that all referenced data is immediately available on stage load.
Correct Answer: B
B
Explanation:
A payload is most appropriate when the scene contains heavy assets that should not be fully composed and loaded until needed. NVIDIA’s Learn OpenUSD payload lesson describes payloads as similar to references, but with the added ability to load and unload them on demand. It gives the example of opening a large city scene with all payloads unloaded so the stage loads quickly, then selectively loading only the city block or asset of interest. When loaded, the payloaded layers and their composed dependencies are brought into the scene.
Option B is correct because payloads are designed for deferred loading, scalable working sets, reduced initial load time, and lower memory cost.
Option A describes versioning or asset-resolution policy, not the primary distinction between payloads and references.
Option C does not justify a payload; small inexpensive assets are often fine as references.
Option D describes the opposite of payload behavior, because references are composed immediately, while payload traversal can be deferred. This aligns with Composition → Reference and Payloads, Load/Unload Behavior, Composition Arcs, Scalability, and LIVERPS Strength Ordering.
B
Explanation:
A payload is most appropriate when the scene contains heavy assets that should not be fully composed and loaded until needed. NVIDIA’s Learn OpenUSD payload lesson describes payloads as similar to references, but with the added ability to load and unload them on demand. It gives the example of opening a large city scene with all payloads unloaded so the stage loads quickly, then selectively loading only the city block or asset of interest. When loaded, the payloaded layers and their composed dependencies are brought into the scene.
Option B is correct because payloads are designed for deferred loading, scalable working sets, reduced initial load time, and lower memory cost.
Option A describes versioning or asset-resolution policy, not the primary distinction between payloads and references.
Option C does not justify a payload; small inexpensive assets are often fine as references.
Option D describes the opposite of payload behavior, because references are composed immediately, while payload traversal can be deferred. This aligns with Composition → Reference and Payloads, Load/Unload Behavior, Composition Arcs, Scalability, and LIVERPS Strength Ordering.
Question #20
Considering the following scene description:
def "ParkingLot"
{
def "Car_1" (
instanceable = true
references = @Car.usd@
)
{
}
def "Car_2" (
instanceable = true
references = @Car.usd@
)
{
}
}
Disabling the instanceable metadata on the prim at path /ParkingLot/Car_2 by setting it to false has the following effects: Choose two.
- A . Other prims using the same prototype, such as /ParkingLot/Car_2, will also get their instanceable metadata disabled.
- B . Existing opinions in a local layer from the root LayerStack targeting a child of /ParkingLot/Car_1 will take effect.
- C . Existing opinions in a local layer from the root LayerStack targeting a child of /ParkingLot/Car_1 will be ignored.
- D . Recomposition will be triggered from the hierarchy starting at /ParkingLot/Car_1.
Correct Answer: B, D
B, D
Explanation:
Setting instanceable = false on an instance root is a deinstancing operation. NVIDIA’s Learn OpenUSD instancing material explains that instanceable prims share composed data through implicit prototypes, and that scenegraph instances restrict sparse descendant overrides because instance proxies are not directly editable. In NVIDIA’s instance-refinement guidance, the three practical rules are: prototypes are not editable, instance proxies are not editable and local opinions are discarded, while the instanceable prim itself remains editable. (docs.nvidia.com)
Therefore, when the targeted instance root is deinstanced, local opinions authored under that prim’s
descendant paths can become effective because the subtree is no longer represented only through the shared prototype. USD must also recompose that hierarchy because changing instanceable changes whether the prim contributes to prototype sharing or composes its own local subtree.
Option A is incorrect because disabling instanceable on one prim does not mutate metadata on other prims that previously shared the prototype.
Option C describes the still-instanced behavior, not the deinstanced result. In the screenshot, the stem names /ParkingLot/Car_2 while options B and D name /ParkingLot/Car_1; the correct effects apply to the prim whose instanceable metadata is disabled. This aligns with Content Aggregation → Scenegraph Instancing, Instance Refinement, Deinstancing, and Recomposition.
B, D
Explanation:
Setting instanceable = false on an instance root is a deinstancing operation. NVIDIA’s Learn OpenUSD instancing material explains that instanceable prims share composed data through implicit prototypes, and that scenegraph instances restrict sparse descendant overrides because instance proxies are not directly editable. In NVIDIA’s instance-refinement guidance, the three practical rules are: prototypes are not editable, instance proxies are not editable and local opinions are discarded, while the instanceable prim itself remains editable. (docs.nvidia.com)
Therefore, when the targeted instance root is deinstanced, local opinions authored under that prim’s
descendant paths can become effective because the subtree is no longer represented only through the shared prototype. USD must also recompose that hierarchy because changing instanceable changes whether the prim contributes to prototype sharing or composes its own local subtree.
Option A is incorrect because disabling instanceable on one prim does not mutate metadata on other prims that previously shared the prototype.
Option C describes the still-instanced behavior, not the deinstanced result. In the screenshot, the stem names /ParkingLot/Car_2 while options B and D name /ParkingLot/Car_1; the correct effects apply to the prim whose instanceable metadata is disabled. This aligns with Content Aggregation → Scenegraph Instancing, Instance Refinement, Deinstancing, and Recomposition.