Omniverse Usd Performance Tuning
NVIDIAOfficialCreated by NVIDIA Omniverse
- Skill
- Workflow
- Software development
- Apache-2.0
- Medium risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a structured workflow for diagnosing and optimizing USD stages. It focuses on improving performance metrics like load times, memory footprint, and frame rates by identifying and optimizing unique asset definitions, reusing shared definitions, and pruning unnecessary data. The process emphasizes preserving original asset boundaries, animation, and interface requirements, ensuring that downstream applications remain functional after optimization.
What it does
- Inspects USD stages to identify performance bottlenecks and structural inefficiencies.
- Classifies assets into atomic, package, or aggregate structures to guide optimization.
- Performs native USD optimization operations on disjoint scopes.
- Publishes semantic libraries to enable efficient asset reuse.
- Validates composition, ownership, and interface accessibility of the optimized output.
- Profiles the final output against the original baseline to report measured improvements.
When to use it
- When a USD stage suffers from slow loading times or high memory consumption.
- When rendering performance (FPS) needs improvement in a production environment.
- Before finalizing a USD assembly for downstream consumption.
- When you need to standardize asset structures according to factory-level guidelines.
Advantages
- Maintains asset boundaries and critical metadata during optimization.
- Reduces scene complexity through intelligent reuse of shared definitions.
- Provides verifiable reports on performance gains and composition integrity.
- Supports large-scale scene optimization by processing independent definition scopes.
Usage examples
- “Inspect the USD stage at /data/factory.usdc for performance issues and prepare a review workspace.”
- The agent initializes the workspace, runs the inspection script, and provides a summary of candidates for optimization.
- “Submit the optimization decisions for the factory stage based on the generated JSON.”
- The agent processes the boundary decisions, executes the optimization operations, and generates the final optimized USD assembly.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/nvidia/omniverse-usd-performance-tuning/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip omniverse-usd-performance-tuning.zip -d .agents/skills
Documentation by NVIDIA Omniverse
Omniverse USD Performance Tuning
Purpose
Improve loading, memory use or rendering for the requested workload. Preserve the prim paths, appearance, placement and behavior required by downstream applications. Follow the component/subcomponent model in NVIDIA's Factory-Level USD Structuring guide. Apply the relevant parts of that model; a static asset does not need new animation or physics.
Inputs
Required: the source USD stage. When no workload is specified, use factory layout planning and visualization and record that assumption in the request/report. Explicit workload and preservation requirements take precedence. Optional: an output workspace, preservation requirements, physical error budget, existing library indexes and recorded runtime evidence. Use values from the current user request; reuse recorded values only while they remain applicable. Follow setup when no output path is supplied.
Prerequisites
Verify the selected runtime and required capabilities using setup. Keep its preflight record with the run; installation and remote access are conditional steps described there.
Instructions
Inspect. Establish the workload, preservation requirements and output workspace. Set up progress and dashboard access before assessment. Verify setup and inspect the selected source configuration.
Judge boundaries. Review equipment, service-system sections and architectural elements in the selected configuration, including animation and interiors. Record owners, editable interfaces, equipment categories and optional families using boundary guidance.
Classify and author. Classify accepted assets children before parents. Capture or reuse the original profile before authoring. Prepare reusable definitions, materials and occurrence opinions using asset authoring.
Optimize unique definitions. Run supported native operations concurrently on disjoint scopes with the recorded physical budget.
Publish semantic libraries. Use one writer per category layer and remap consumer references.
Check composition. Check authored ownership, references, bindings, placement, animation and interface accessibility through the written-output checks.
Profile and report. Compare the final consumer with the original baseline under comparable conditions and report measured benefits, completion and operations by asset definition.
sequenceDiagram
participant A as Agent
participant T as USD tools
participant W as Definition workers
participant L as Library publisher
participant D as Read-only progress dashboard
Note over A,L: One compact progress state also renders text progress
T-->>D: Recorded phase, assessment rounds, counters and decision reasons
A->>T: Inspect original selected configuration
T->>T: Collect cached child-to-parent summaries and repetition nominations
T->>T: Load supplied indexes once and batch authored product clues
T-->>A: Product review groups, member context, animation and reuse evidence
loop Until boundaries and interiors are reviewed
A->>A: Select asset boundaries, then identify required internal prims and properties
A->>T: Submit boundary decisions with reviewed scope, required edits, category and optional family
T->>T: Reuse unchanged source evidence, recompute boundary-dependent results
opt Geometry ownership requires reconstruction
T->>T: Regroup or native split, remap paths and reassess affected regions
end
T-->>A: Remaining candidates and member exceptions
end
T->>T: Classify selected child assets before parent assets, confirm reuse
T->>T: Capture or reuse original baseline profile
T->>T: Confirm accepted product identities from source and supplied indexes; reconcile complete parent-child groups
T->>T: Skip worker inputs for confirmed groups; author remaining materials, editable prims and occurrence overrides
T->>T: Determine merge groups on prepared interiors; preserve selected child assets and required prims
T->>W: Read-only input USD layers for existing-library matching
par Independent preparation jobs
W->>W: Confirm remaining product, exact source or authorized normalized reuse; preserve occurrence placement
W->>W: Consolidate accepted product or compatible exact/normalized leaf inputs; retain every occurrence
end
W-->>T: Confirmed library hits and definitions requiring optimization
T->>W: Owned geometry prim paths in read-only input layers
par Independent definition scopes
W->>W: Remove small meshes when authorized; apply asset representation: reserve merge inputs or fit analytic prims; reduce, merge (native clustering if required), prune, flatten, prune
end
W->>L: Geometry outputs and assembly authoring outcomes
L->>L: Share eligible static whole definitions within current category publication
L->>L: Share remaining whole meshes; write USD reuse metadata and compact index
L->>T: Output USD stage with rewritten references and dependencies
T->>T: Check authored composition, ownership, animation and interfaces
T->>T: Profile final output USD stage and report results by asset definition
T-->>A: Measured changes, coverage and unresolved work
T-->>D: Final verdict and report/library pathsUse the provided tools for traversal, native operations, authoring and checks; the agent supplies engineering judgments. Preserve current variant selections, authored animation, required materials and interfaces. Trust supported USD Optimize operations with valid settings and scopes. Deep geometric comparisons and whole-scene edit trials belong in development tests, not ordinary execution.
Complete when every unique definition has an executed or evidenced unchanged outcome, every asset has justified ownership and structure, and the written consumer passes composition checks. Retain native failures, unresolved judgments and missing required capabilities as incomplete work. Repeat only affected work when evidence changes.
Scope and authorization
Diagnosis and validation requests remain read-only. An optimization request authorizes work in a separate output workspace within its stated preservation limits.
Never overwrite source layers or inherited libraries without explicit authorization.
Reuse authorization already given. Ask only for a missing decision that changes identity, required appearance or a loss budget; explain the affected component and consequence.
Report only observed changes. Measure rendering before claiming higher FPS or lower GPU use.
Load only the relevant guidance
| Request | Read |
|---|---|
| Validation only | Setup, then the validation section of operations |
| Approved operation chain | Setup, operations, verification |
| Existing or persistent asset library | Add the library index requirements to the assessment |
| Missing standalone runtime | Installation |
| Remote stage | Remote access before the first open |
| Report from completed evidence | Verification |
Use upstream package guidance for selected operation mechanics and proxy workflows. Keep large logs on disk as specified in setup.
Limitations
Convert CAD input with the source converter's workflow and NVIDIA's CAD conversion guidance. Render profiling requires NVIDIA/omniperf or the user's available profiler; USD open and traversal timings alone do not establish rendering improvements.
Troubleshooting
For unavailable imports, operations or remote assets, follow setup. For incomplete execution or failed composition checks, follow verification; retain the failed artifacts and report the missing capability or failed check.
Examples
After runtime preflight, use the verified Python interpreter from setup to inspect a stage:
python scripts/successor_assessment.py inspect --source /data/factory.usdc --workspace /data/factory-reviewReview the generated candidates using boundary guidance, fill the generated decision template, then submit it:
python scripts/successor_assessment.py decide --workspace /data/factory-review --decisions /data/factory-review/decisions.jsonThese commands perform assessment; continue through the instructions above only when review is complete. Run from the skill directory; generated data stays in the workspace.
Output Format
Maintain live progress and editable steering throughout execution.
For end-to-end optimization, provide the written USD assembly, validated report JSON, and generated Markdown and HTML reports. State the runtime, operations actually executed, preservation and coverage results, measured changes, source-write status, and artifact paths. Diagnosis-only work may return a findings summary stating that no optimized stage was written.
Files
- ATTRIBUTION.mdAdded by AutoGineer964 B
- BENCHMARK.md12.0 KiB
- CHANGELOG.md2.4 KiB
- LICENSELicence file added by AutoGineer11.2 KiB
- SKILL.md10.2 KiB
- agents/openai.yaml375 B
- assets/progress-dashboard/app.jsScript9.8 KiB
- assets/progress-dashboard/index.html2.4 KiB
- assets/progress-dashboard/styles.css3.8 KiB
- config/skillspector-baseline.yaml7.3 KiB
- evals/README.md1.8 KiB
- evals/evals.json12.4 KiB
- evals/files/completed-run/after.usda399 B
- evals/files/completed-run/before.usda399 B
- evals/files/completed-run/evidence.json745 B
- evals/files/factory/cases/factory.usda13.6 KiB
- evals/files/factory/materials.usda1.8 KiB
- references/asset-authoring.md10.1 KiB
- references/component_scope.pyScript18.0 KiB
- references/geometry_tolerance.pyScript2.1 KiB
- references/install-standalone.md2.4 KiB
- references/library-reuse.md7.6 KiB
- references/operations.md22.4 KiB
- references/operations/README.md7.9 KiB
- references/operations/operations.json52.4 KiB
- references/operations/registry-args.json2.1 KiB
- references/operations/scripts/operations.schema.json6.2 KiB
- references/optimization-report/scripts/apply_palette.pyScript13.3 KiB
- references/optimization-report/scripts/asset_results.pyScript5.9 KiB
- references/optimization-report/scripts/definition_verification.pyScript7.1 KiB
- references/optimization-report/scripts/descent_convergence_common.pyScript9.0 KiB
- references/optimization-report/scripts/optimization-report.schema.json39.4 KiB
- references/optimization-report/scripts/structure_conformance.pyScript15.2 KiB
- references/optimization-report/scripts/validate_report.pyScript55.2 KiB
- references/remote-assets.md1.6 KiB
- references/report-templates/optimization-report.html.template14.9 KiB
- references/report-templates/optimization-report.md.template6.2 KiB
- references/report-templates/render_preview.pyScript17.9 KiB
- references/report-templates/theme.css711 B
- references/setup-usd-performance-tuning/scripts/probe-snapshot.schema.json1.7 KiB
- references/setup-usd-performance-tuning/scripts/setup-preflight.schema.json6.4 KiB
- references/setup.md3.3 KiB
- references/structure.md20.8 KiB
- references/upstreams/usd-optimize.md6.3 KiB
- references/usd-optimize-run-operations/scripts/asset_authoring.pyScript54.9 KiB
- references/usd-optimize-run-operations/scripts/batch-plan.schema.json7.5 KiB
- references/usd-optimize-run-operations/scripts/category_publication.pyScript6.3 KiB
- references/usd-optimize-run-operations/scripts/current_run_reuse.pyScript11.6 KiB
- references/usd-optimize-run-operations/scripts/material_optimization.pyScript4.9 KiB
- references/usd-optimize-run-operations/scripts/material_publication.pyScript9.5 KiB
- references/usd-optimize-run-operations/scripts/native_reconstruction.pyScript7.9 KiB
- references/usd-optimize-run-operations/scripts/native_worker.pyScript68.4 KiB
- references/usd-optimize-run-operations/scripts/pack_definitions.pyScript1.6 KiB
- references/usd-optimize-run-operations/scripts/persistent_library.pyScript20.3 KiB
- references/usd-optimize-run-operations/scripts/persistent_reuse.pyScript31.1 KiB
- references/usd-optimize-run-operations/scripts/prim_regroup.pyScript14.9 KiB
- references/usd-optimize-run-operations/scripts/run_batch.pyScript32.5 KiB
- references/usd-optimize-run-operations/scripts/semantic_library.pyScript48.2 KiB
- references/usd-optimize-run-operations/scripts/shared_geometry.pyScript25.5 KiB
- references/usd-optimize-run-operations/scripts/status.schema.json7.9 KiB
- references/usd-structure-assessment/references/apply-restructure/scripts/apply-restructure-manifest.schema.json35.3 KiB
- references/usd-structure-assessment/references/usd-hierarchy-dedupe-candidates/scripts/instance_candidate_finder.pyScript12.7 KiB
- references/usd-structure-assessment/references/usd-mesh-fragmentation-candidates/scripts/mesh_fragmentation_finder.pyScript13.8 KiB
- references/usd-structure-assessment/scripts/atomic_placement.pyScript4.9 KiB
- references/usd-structure-assessment/scripts/audit-report.schema.json2.3 KiB
- references/usd-structure-assessment/scripts/boundary_reasoning.pyScript36.0 KiB
- references/usd-structure-assessment/scripts/discovery_preview.pyScript8.6 KiB
- references/usd-structure-assessment/scripts/optimization-plan.schema.json1.5 KiB
- references/usd-structure-assessment/scripts/structure_assessment.pyScript112.2 KiB
- references/usd-structure-assessment/scripts/usd-structure-assessment-report.schema.json14.0 KiB
- references/usd-validation-runner/references/validator-concepts.json35.8 KiB
- references/usd-validation-runner/scripts/usd_validation_executor.pyScript37.4 KiB
- references/usd-validation-runner/scripts/validation-report.schema.json3.5 KiB
- references/usd-validation-runner/scripts/validation-scope-note.schema.json2.6 KiB
- references/usd-validation-runner/scripts/validator-concepts.schema.json3.8 KiB
- references/verification.md11.9 KiB
- scripts/animation_context.pyScript6.8 KiB
- scripts/composition_verification.pyScript16.9 KiB
- scripts/failure_reporting.pyScript2.7 KiB
- scripts/product_clues.pyScript6.2 KiB
- scripts/progress_dashboard.pyScript12.6 KiB
- scripts/stage_profile.pyScript15.7 KiB
- scripts/successor_assessment.pyScript34.1 KiB
- scripts/successor_execution.pyScript15.7 KiB
- scripts/successor_progress.pyScript22.3 KiB
- scripts/successor_reconstruction.pyScript19.6 KiB
- scripts/successor_workflow.pyScript55.0 KiB
- scripts/usd_tuning.pyScript24.7 KiB
- skill-card.md5.5 KiB
- skill.oms.sig26.5 KiB
references/structure.md
Discover asset boundaries
Use the intended workload to decide what must remain independently placeable, replaceable, configurable or movable. Factory-scale use is the default when no other workload is specified. The factory structuring guide provides the equipment, assembly and editable-interface model.
Inspect and select asset boundaries
Open the selected configuration with payloads loaded. Include hidden geometry; visibility can change with animation. Record missing dependencies as incomplete inspection. Do not enumerate alternate variants. Preserve the source layers and the variant selections recorded at the start of the run.
Tools summarize relevant prims children before parents, including referenced and instanced interiors. Reuse cached summaries for shared definitions while retaining occurrence context. Use schema, topology and valid bounds to narrow expensive comparisons. Missing bounds are unknown, not evidence that geometry is absent.
Boundary decision checklist
An asset boundary selects a prim whose assigned content will be extracted into a
separately referenceable asset definition. Set disposition: "retain" to select
that boundary; this does not preserve its internal hierarchy unchanged. Set
disposition: "internal" to include the region within its enclosing asset.
Preserving an editable prim or property does not itself select an asset boundary.
Use the candidate summary to answer this checklist. Record one boundary decision and concise reason per reviewed subtree or group; do not write an explanation for each mesh. Missing optional metadata does not prevent a decision.
| Question | Evidence to use | Decision |
|---|---|---|
| Which equipment, service-system section or architectural element is used as a unit? | Prim name/path, displayName, assetInfo, specific CAD/BIM attributes and assembly context | Select its root as an asset boundary when the workload calls for independent placement, replacement or configuration. Keep the complete equipment boundary when selecting its internal mechanical bodies as child assets. Use existing meaningful service sections for factory visualization. |
| Which internal mechanical bodies need separate boundaries? | Joint body targets, animated relative motion and descriptive mechanical hierarchy identifying particular robot links, sliding rails or other bodies, including static poses | Keep complete equipment as a reusable asset. Select its meaningful rigid bodies as child assets, including static source poses. Both equipment assemblies and their bodies can share definitions; each occurrence preserves its own body placements. Merge compatible static geometry within each body. A suggestive part name, arbitrary CAD grouping or repeated meshes alone does not establish a mechanical body. |
| Which additional internal prims or properties must remain available? | The exact path and its workload-required placement, visibility or identification use | For additional edits inside a selected body, record the exact prim/property path and explicitly requested or directly implied workload use in required_occurrence_edits. Child-asset occurrence roots already provide placement; do not duplicate declarations solely to preserve their positions. Preserve an internal frame when the requested control belongs within a body. Identification requires a stated selection or lookup use. Part names alone do not require extra controls. |
| Does this asset contain the intended geometry? | Assigned geometry count, selected child assets, unassigned geometry and flagged misplaced/combined parts | Keep adequate subtrees. Request regrouping or native splitting only for an identified ownership problem. |
| Does its geometry call for fitting before merging, or consolidation of its static interior? | Pipe/conduit or other simple-shape geometry, equipment context and workload requirements | Apply the representation decision and record geometry_representation; being static or atomic does not settle this choice. |
| What repeats, and what differs? | product_review_groups with authored identification clues and complete member paths; member labels and child summaries; confirmed comparison results | Review a product group together and submit common boundary decisions through source_prim_paths; separate exceptions. Review corresponding interiors once when accepted product identity or content confirmation establishes correspondence. Ask which cited model, part or configuration values distinguish the interchangeable product; name those values in the existing reason for product_identity. Descriptions echoed in exporter metadata remain one clue. Use content confirmation when product identity is unresolved; see persistent reuse. |
| Which equipment category should this asset be published in? | Prim names, displayName, assetInfo, named CAD/BIM attributes and assembly context | Choose the most specific supported equipment category. An unknown model does not require a general category. |
| Is an equipment family already supported by explicit evidence? | Product/model identifiers or explicit copy relationships | Optionally record equipment_family; otherwise omit it. Explain the basis in the existing reason. Family membership neither creates a boundary nor confirms geometry reuse. |
| Does this asset contain child assets selected by boundary decisions, and does it also own geometry outside those child assets? | Selected child-asset IDs and assigned geometry | Let tools derive the atomic, package or aggregate structure. Resolve contradictions or incomplete ownership. Child prims alone are not child assets. |
Review parents before children. Select the complete equipment, meaningful
service-system section or architectural element with retain. Use
decision_scope: "prim" when internal child boundaries remain undecided and review
them next; use subtree when interior review is complete. Record required internal
edits in the same decision. If children were reviewed first, use
evidence.enclosing_boundaries to select the complete equipment root before
completing assessment. Select that root using the equipment evidence in the
checklist and its required use as a unit; enclosing organizational Xforms do not
become assets merely because they contain selected children. An asset without child assets is atomic. Atomic means no child assets,
not one mesh or one physical part. Use internal/prim to continue through an
organizational prim when a meaningful asset boundary has not yet been found.
Do not automatically descend to individually named parts. Tools classify child
assets before parents and handle placement, transform baking and geometry comparisons.
Interpret German and English CAD labels, including compounds and umlaut spellings
(Tuer, Schraenke), using assembly context. Keep original product identifiers,
dimensions and handedness significant; manufacturer and copy labels nominate
related equipment, not identical geometry.
Combine labels with hierarchy context: opaque children beneath a product-labelled ancestor may be ordinary internal geometry; related product-labelled siblings may be separate occurrences. A level or discipline label does not establish equipment. Similar dimensions nominate repetition but do not prove matching geometry. Compare asset-local dimensions with the same units, purposes and USD time code, separately from world-space position. Rotated copies can have different world-axis-aligned bounds. Missing bounds mean unknown; do not demand a geometry scan to fill every row.
In candidates.json, evidence.product_review_groups batches members with shared
product IDs, authored labels or alphanumeric label tokens. Page it with
successor_assessment.py show --workspace OUTPUT --candidate ID --field evidence.product_review_groups.
Use each group’s source_prim_paths for a common decision when its member evidence
supports the same conclusion. Groups may overlap; submit each prim once and split
exceptions into separate decisions. Interpret station and occurrence tokens from
the observed naming convention while preserving model, dimensions, cut length,
revision and handedness. Scripts keep complete labels and do not strip suffixes.
evidence.members supplies the member context and children; repetition_nominations
and confirmed_reuse distinguish candidates from confirmed matches. Schema-based review groups are explicitly marked
review_batch_only_not_equivalence. Read each member's labels and exceptions;
a representative's counts or children do not describe every member. Early reuse
nominations are not confirmed matches. Fingerprints validate evidence freshness;
they are not explanations of duplication. Request specific property values or
spatial facts only when they could change a decision. Visual inspection is not
required or available to the target agent.
For example, a factory-visualization workload could use this hierarchy. Labels describe structural type, not USD model kind:
Building - aggregate
└─ Level 01 - aggregate, if independently loaded or delivered
├─ Chiller - package
│ ├─ Pump assembly - atomic
│ └─ Internal geometry
├─ Complete robot - aggregate
│ ├─ Base link - atomic
│ └─ Moving links - atomic
├─ Piping section - atomic
│ └─ Static pipe and fitting geometry
├─ Electrical conduit system - aggregate
│ ├─ South service zone - atomic
│ └─ North service zone - atomic
├─ Wall section - atomic
├─ Floor section - atomic
└─ Ceiling section - atomicA complete robot with geometry outside its selected child assets is a package.
Use existing meaningful service-system and architectural sections for factory visualization. Static pipes and fittings within a section are internal geometry unless the workload establishes a separate asset requirement. If a section also contains a valve selected as a child asset for required independent configuration, that section becomes a package. Apply the same criteria to conduit and duct sections. Do not invent partitions or regroup adequate subtrees to match the example. A level, discipline or product-family label alone does not establish an asset boundary; assess what its subtree represents in the workload.
For each selected asset boundary, record its independent use, supporting prim or property paths and a concise reason. Distinguish observed facts, user requirements and domain inference. Account for each service-system section and architectural element under its meaningful owner; do not collect unrelated infrastructure into one package merely because it shares a building ancestor.
Tools collect authored animation and addressed relationship/connection targets. Review unresolved semantic questions using the identified parts and their assembly context; record additional requirements by exact prim/property path and use. Use the boundary checklist to select mechanical bodies, including static poses. Authored animation remains preserved by the existing tools regardless of additional editability decisions. An internal attachment frame or required identification prim remains within its asset; geometry beneath it may be optimized while that prim stays addressable. Record an unresolved requirement when a required use cannot be satisfied. Asset authoring owns structural type, USD model kind and preservation behavior. Tools handle placement and animation preservation.
Reconstruct ownership
Keep the existing hierarchy when it already represents the chosen owners. Regrouping is not a prerequisite for optimization or library publication. Request reconstruction only when source organization prevents the intended geometry ownership:
| Source condition | Action |
|---|---|
| A subtree already represents the asset | Keep it |
| Its geometry is scattered under unrelated parents | Regroup the prims under the accepted owner |
| One mesh contains geometry belonging to different assets | Use a supported native splitMeshes mode, then assign the resulting pieces |
For misplaced parts, inspect attachment relationships, assembly metadata and mounting context before spatial evidence. Bounds shortlist possible owners; proximity alone does not settle ownership. A fastener connecting two bodies has one geometry owner and can retain relationships to both bodies.
For regrouping, owner_prim_path names the physical owner. When that owner is
missing, set create_owner: true in the reconstruction proposal to create one
Xform immediately beneath an existing defined, editable parent. This does not
create missing ancestor chains or overwrite a prim. Leave the flag absent for an
existing owner. The tools preserve placement and inherited state, reject cycles
and namespace collisions, then return the new owner for explicit boundary and
structural classification. Creating an Xform alone does not establish an asset.
After submitting reconstruction decisions, run
scripts/successor_reconstruction.py --workspace OUTPUT.
The controller batches disjoint regroup requests into one authored output.
Overlapping or dependent requests remain sequential; each request retains its
outcome. It invokes native splitting
or prim regrouping and returns
a new assessment workspace. The regroup adapter calls
regroup(source_layer, output_layer, memberships, create_owners=...), where
memberships maps disjoint source prim roots to destination owner paths. It copies
the local layer stack into an isolated output, retains references and payloads,
and moves subtrees with Usd.NamespaceEditor; it does not flatten the composed
stage. The result contains status, input/output paths, root_path_map and
created_owner_paths. The controller translates the agent's proposals into these
arguments; agents do not maintain descendant-by-descendant mappings. Continue in that returned
workspace; the previous one is superseded. It retains the original source and
ordered root-path mappings for profiling and remapping required interfaces.
Regroup preservation is tested in development; execution does not produce or
replay per-property preservation checks. Later phases check operation records and
written composition as described in verification.
Read the returned output paths and operation results. Do not assume native
output names or use mesh-count reduction to judge a split. Disconnected pieces
and material subsets do not automatically become separate assets.
In decision JSON, use operation: "splitMeshes" with parameters: {"splitOn": 0}
for disconnected vertices, or parameters: {"splitOn": 1} for material GeomSubsets.
The controller derives the prim paths from source_prim_paths.
It operates on editable polygon meshes and preserves ancestor animation. Animated
mesh data, subdivision surfaces, nested meshes and unresolved relationship remapping
remain unsupported. Another native mode needs its own preservation checks; do not
write a custom face-cutting algorithm.
If the available modes cannot separate the intended parts, record the precise
unsupported case after testing applicable options. Reinspect changed regions and
remap required properties before proceeding. A failed reconstruction leaves its
dependent work incomplete while independent regions can continue.
Confirm reuse
When persistent_indexes are supplied, inspect persistent_nominations beside
candidate evidence. Each row names the source prim, matching product/model
identifier and published layer/prim entrypoint. A child's nomination applies to
that child, not its containing equipment. These are unconfirmed clues; retain
independent boundaries and required edits. Record accepted product identity with exact source facts and a substitution reason when supported; otherwise preparation confirms published source identity regardless of category; see persistent reuse. If the workload explicitly permits small constant-colour rounding substitutions, set allow_constant_colour_rounding: true; preparation records the accepted difference and preserves occurrence placement. For source-content matching without that authorization, effective appearance must match exactly.
Authored clues nominate candidates. Accepted product identity authorizes representation substitution, not a claim of identical source geometry or corresponding internal mesh paths. Content-based reuse follows the existing source-identity checks and explicitly authorized enclosing-child normalization. See persistent reuse for confirmation requirements.
Resolve reuse of child assets selected by boundary decisions before merging the remaining interior geometry. Repeated meshes alone do not establish asset boundaries or exclude geometry from merging. Internal references and instances can remain inside an atomic asset.
Record decisions
Select the stage entry point as the root asset boundary. For a factory or building layout,
record structural_type: "aggregate" with the layout reason: the root composes
equipment and building assets without owning geometry. A spatial subset of a
layout, such as one floor, roof or site zone, is still a layout. Assign its geometry
to the physical owners selected above; do not change the layout root to a package
just to absorb that geometry. An equipment-only
source can instead have an atomic or package root according to its interior.
Organizational children need no separate asset boundary. Record regrouping or splitting for misplaced geometry
before marking its terminal wrapper internal.
Use internal for an organizational prim and retain for an asset. With
decision_scope: "prim" (the default), its interior remains unresolved: review continues through its child groups.
Use decision_scope: "subtree" with retain to select an asset and complete its
interior review together, or with internal to complete a region inside its owner. Record the evidence and reason for that scope;
do not use it to skip units whose independent use is still undecided.
source_prim_paths can group disjoint subtrees with the same reviewed conclusion.
Selected asset boundaries and protected interfaces still receive their own
review. Required editable prims remain authored even when their boundary decision
is internal. Terminal geometry wrappers require no separate mesh decisions.
Run scripts/successor_assessment.py inspect --source INPUT --workspace OUTPUT --request REQUEST_JSON. REQUEST_JSON is a JSON file containing the workload and operation policy.
Record the workload and physical geometry budget,
including any user override or explicit exact-geometry requirement. The tool selects
the successor policy and writes the current source context, inventory, grouped boundary
reviews, definitions, occurrences and unresolved decisions.
The CLI returns counts and artifact paths; complete evidence remains in candidates.json. List candidate groups with scripts/successor_assessment.py show --workspace OUTPUT --offset 0 --limit 10. Use show --workspace OUTPUT --candidate ID to list its fields, then --field evidence.all_members for its summary or --field evidence.members --offset 0 --limit 10 for members. Follow next_offset to inspect the remaining members; a page is not evidence for unreviewed members. Dot-separated fields can select nested evidence, including a member index.
Submit decisions with scripts/successor_assessment.py decide --workspace OUTPUT --decisions DECISIONS.
Use decision-help.json to fill decision-template.json under decision-schema.json.
Copy current source context and candidate fingerprints, then judge reviewed members;
the template supplies no boundary answers. Submit a separate file to survive template
regeneration. The adapter validates current evidence/configuration and
preserves earlier decisions. During boundary review, unchanged source evidence is reused;
current decisions and required edits are evaluated again. Progress reports the assessment
pass, stage scan counts, and evidence reuse separately from boundary review.
Tools own membership and generated paths. Agent records supply disposition,
independent use, reason, evidence paths, semantic category or unknown, and
required occurrence edits, geometry_representation for the selected operation order (omission uses merged_meshes), optional product_identity for accepted interchangeable products (key, reason, asset-root frame and exact evidence; format in decision-help.json), plus optional equipment_family when assigned using the
checklist above. Unreviewed members stay pending. Source or configuration changes
invalidate corresponding evidence.
Continue with asset authoring when ownership and interior review are complete. Classification cannot substitute for reviewing the contents.
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs Python, Needs Node.js
The author says: Requires a verified standalone Usd Optimize/OpenUSD runtime for operations, usd-validation-nvidia for supported checks, and a writable output workspace. Remote assets require a working resolver. Render profiling is an external handoff.
Security
What our scanner noticed· Medium risk
- Large base64-encoded blobs
- Scripts that your agent may run
This skill includes scripts that your agent may run. Read them before you use it.
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- NVIDIA Omniverse
- Publisher
- NVIDIA (Official)
- Source
- NVIDIA/skills · skills/omniverse-usd-performance-tuning · commit fce3cca
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE-APACHE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by NVIDIA Omniverse or NVIDIA.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download omniverse-usd-performance-tuning.zip