NVIDIA OpenUSD Development (NCP-OUSD)

✅ Option A (Correct)
Reasoning: In USD, when an attribute's time samples are authored in a stronger layer (like "rootLayer.usda") using the = assignment operator, it completely replaces the entire set of time samples from weaker layers ("layer1.usda"). By defining double3 xformOp:translate.timeSamples = {45: (0, -5.0, 0)}, the Sphere's translation will be explicitly set to (0, -5.0, 0) at timeCode 45. As the question notes that it is acceptable for other time codes to change, this method effectively achieves the desired position.

✅ Option D (Correct)
Reasoning: The += operator is used to add or override specific entries within a time-sampled attribute without replacing the entire collection from weaker layers. By using double3 xformOp:translate.timeSamples += {45: (0, -5.0, 0)}, a new time sample is introduced at timeCode 45 with the value (0, -5.0, 0). This sample takes precedence at timeCode 45, while other original samples from "layer1.usda" (e.g., at 1, 30, 60) are preserved and compose with the new sample. This precisely places the Sphere at the desired position at timeCode 45 while maintaining the overall animation structure for other time codes.

❌ Why the other choices are incorrect:
* Option B is incorrect: Option B defines double3 xformOp:translate = (0, -5.0, 0). This sets a default value for the attribute in a stronger layer. According to USD composition rules, a default value in a stronger layer overrides any time samples for the same attribute in weaker layers. While this would indeed place the Sphere at (0, -5.0, 0) at timeCode 45 (and effectively for all other time codes by making it static), it's a different class of override than directly manipulating the timeSamples property. Options A and D are more direct ways to modify the time-varying attribute itself. Given the requirement to choose two and the original attribute being time-sampled, options A and D represent direct time sample manipulation.
* Option C is incorrect: This option attempts to use .points metadata with timeSamples. The .points metadata is typically associated with geometric primitives like Basis Curves to define control points, not for overriding specific time samples of an xformOp:translate attribute. The syntax is incorrect for the intended purpose of modifying time-sampled translation values.

Reference: https://graphics.pixar.com/usd/release/spec_composition.html

Based on the principles of Universal Scene Description (USD), setting the instanceable metadatum to false on a prim that was previously instanceable = true (and thus had an implicit prototype) has the following effects:

Existing opinions will take effect (Option B): When a prim is marked instanceable = true, any opinions authored on its descendants are typically ignored to maintain the shareability of the prototype. By setting instanceable = false, the prim is no longer instanced. The descendants are no longer encapsulated in an immutable, shared prototype, and any previously authored opinions in the layer stack for those descendant prims will now be composed and take effect.

Recomposition will be triggered (Option D): The instanceable metadatum is a composition-affecting piece of metadata. Changing it forces USD to re-evaluate the composition structure for that prim and its hierarchy. As a result, a recomposition is triggered starting from that prim's path.

The def Xform "wall_a_inst" is marked with instanceable = true. This property designates wall_a_inst as a prototype for efficient instancing. When a prim is instanceable, only the scene description that defines its prototype (typically through references or payloads) is considered for instancing. The def Sphere "Sphere" is defined at the root level of the USD stage, making it a sibling of wall_a_inst, not a child, and not part of wall_a_inst's composition (e.g., within its variants or referenced content). Therefore, the Sphere is not part of the definition of the wall_a_inst prototype. If a USD viewer is interpreting the stage in the context of wall_a_inst as the defaultPrim and an instanceable prototype, it may focus on composing and displaying only the content that is part of that prototype's instanced scenegraph, thereby excluding the independently defined Sphere from the view. While the option's phrasing "inside of wall_a_inst" is technically inaccurate (the sphere is a sibling), the critical point is that the sphere is not part of the instanced scenegraph defined by the instanceable wall_a_inst.

• Cone1 Orientation: The cone1.usda layer defines upAxis = "Y" and the cone's axis = "Z". The root layer coneScene.usda specifies upAxis = "Z". When a Y-up layer is referenced into a Z-up layer, Universal Scene Description (USD) applies a standard corrective transformation: a 90-degree rotation around the X-axis. This transformation maps the original Y-axis (up) to the new Z-axis (up), and the original Z-axis (cone's axis) to the new -Y-axis. Therefore, Cone1 will be oriented along the -Y-axis in the final scene.
• Cone2 Orientation: The cone2.usda layer defines upAxis = "Z" and the cone's axis = "Z". The root layer coneScene.usda also specifies upAxis = "Z". Since the upAxis matches between the referenced layer and the root layer, no corrective transformation is applied. Therefore, Cone2 will maintain its orientation along the Z-axis in the final scene.
• Conclusion: Cone1 points along the -Y-axis, and Cone2 points along the Z-axis. Option B states "Cone1 pointed along the Y-axis, Cone2 pointed along the Z-axis", which is the most accurate description among the choices, interpreting "along the Y-axis" to include both positive and negative directions.

Here is the step-by-step breakdown of what happens when the code is executed:

refStage = Usd.Stage.CreateInMemory(): Initializes a new, empty USD stage in memory.

refSphere = refStage.OverridePrim("/refSphere"): Creates an over (an override) for a prim at the path /refSphere in the root layer.

refSphere.GetReferences().AddReference("./HelloWorld.usda"): Adds a reference to the HelloWorld.usda file onto the /refSphere prim. In USD, adding a reference using the Python API defaults to prepending the reference.

print(refStage.GetRootLayer().ExportToString()): This prints the string representation of the root layer.

Based on the OpenUSD API behavior for adding references, the root layer will contain an over for /refSphere that includes the prepended reference to @./HelloWorld.usda@.

The correct output is:

A: File format plugins are responsible for translating foreign file formats into OpenUSD-compatible data. This statement is correct. OpenUSD's plugin architecture includes file format plugins (e.g., for OBJ, FBX, Alembic) that enable the system to ingest and export data from various external formats, translating them into OpenUSD's native data model.

B: Custom plugins can extend OpenUSD by adding new data types and behaviors. This statement is correct. OpenUSD is highly extensible. Plugins are the primary mechanism to introduce new schema types (custom data models), prim types, attribute types, shading nodes, asset resolvers, and other custom functionalities, without modifying the core USD codebase.

C: OpenUSD plugins can be developed as Python-only plugins for faster, iterative development. While Python can be used for certain types of plugins (e.g., Asset Resolvers, Shader Definition Registry nodes) due to its benefits for faster iteration, many performance-critical or deeply integrated plugins (like new schemas or render delegates) are still primarily developed in C++. Therefore, while true for some cases, it's not a universally applicable statement for all OpenUSD plugin development compared to options A and B which describe core functionalities across the entire plugin ecosystem.

D: All plugins require recompiling USD so that they can be used and recognized by USD. This statement is incorrect. A fundamental design principle of OpenUSD's plugin system is dynamic loading. Plugins are typically compiled as shared libraries (DLLs, .so, .dylib) and are discovered and loaded at runtime by USD, without requiring recompilation of the core USD libraries.

✅ Option C (Correct)
Reasoning: When the point position values (typically stored in the points attribute for geometric primitives like meshes) on an object are updated, the spatial bounds of that object change. The extent attribute in USD defines the axis-aligned bounding box (AABB) of the object's geometry. To ensure that the object's bounding information remains accurate for purposes like culling, intersection testing, and scene traversal, the extent must be recomputed and updated to reflect the new positions of its points. Failing to update the extent can lead to incorrect rendering, collision detection, and performance issues.

❌ Why the other choices are incorrect:

• Option A is incorrect: purpose describes the intended use of geometry (e.g., render, guide, proxy) and is unrelated to the physical bounding box determined by point positions.
• Option B is incorrect: xformOps define the local transformation (translation, rotation, scale) of an object. While transforms affect the final world-space positions of points, updating the raw point values themselves within the object's local space necessitates updating the extent, not the xformOps, unless the local transform itself is being modified.
• Option D is incorrect: faceVertexIndices defines the topological connectivity of vertices to form faces in a mesh. It changes only if the mesh's topology (how vertices are connected or the number of faces/vertices) changes, not when just the positional values of existing points are updated.

Explanation:

Deferred Loading: Payloads are designed specifically for deferred loading. Unlike references, which are always composed when the stage is opened, payloads are optionally loaded, allowing users to keep large parts of a scene "unloaded" to save memory and processing time.

Syntax: The snippet correctly uses prepend payload = @asset_path@ inside the parentheses of the prim definition (def "Character"), which is the standard way to author composition arcs in USDA. Other options either use incorrect syntax (like payloads in plural or referencing reference instead of payload) or lack the correct composition block structure.

✅ Option C (Correct)
Reasoning: In OpenUSD, a Usd.EditTarget is a fundamental mechanism that explicitly designates the specific layer within a composed UsdStage where subsequent authoring operations (such as creating prims, setting attributes, or adding relationships) will be recorded. This allows artists and developers to non-destructively modify parts of a scene by directing edits to an overlay or a specific sublayer, preserving the original asset definitions in lower layers.

❌ Why the other choices are incorrect:

• Option A is incorrect: Usd.EditTarget does not automatically merge edits across layers. Its role is to specify where new edits are written, not to consolidate existing edits. Merging typically involves manual processes or specific tools.
• Option B is incorrect: While you can set the edit target to the root layer, Usd.EditTarget does not 'override all layers' or force all changes to the root layer. It simply provides the flexibility to direct edits to any desired layer in the stage's layer stack.
• Option D is incorrect: Usd.EditTarget has no impact on layer composition. Composition is the process by which USD combines layers to form the final stage; the edit target only governs the destination for new authored data, not the evaluation or disabling of existing layer relationships.

OpenUSD provides a robust mechanism for varying attributes across instances while maintaining the efficiency of instancing. For visual attributes like color, the standard approach is to use primvars. When a primvar, such as primvar:displayColor, is authored directly on an instance prim (which instanceProxy allows you to target effectively), it provides a per-instance override for that attribute. This means each instance can have a unique color without breaking the instancing, as the underlying geometry and material definition from the prototype remain shared.

Why other options are incorrect:

• A: Directly modifying the instance's geometry properties: Directly modifying geometry properties (like an attribute that defines the mesh's color) on an instance prim would typically either affect all instances (if applied to the prototype) or break the instancing for that specific instance by making it unique. Per-instance variations are specifically handled via primvars.
• C: Creating a relationship targeting the mesh's color attribute: While relationships are crucial in USD for various connections (e.g., material binding), they are not the direct mechanism for authoring per-instance data values like color. Primvars are designed for this purpose.
• D: Replacing the entire instance with a new mesh that has the desired color: This approach would completely defeat the purpose of instancing. If you replace an instance with a new, unique mesh, you lose all the memory and performance benefits of instancing. The goal is to keep the prim instanced while varying its color.