AutoGineer
Generated banner for Omniverse Usd Performance Tuning
Generated logo for Omniverse Usd Performance Tuning

Omniverse Usd Performance Tuning

OpenAIOfficialCreated by NVIDIA OmniverseDistributed by OpenAI

  • Skill
  • Workflow
  • Software development
  • Apache-2.0
  • Medium risk
  • Has scripts
Download ZIP

From the author

Top-level workflow skill for USD performance diagnosis and optimization. Use for slow loading, high memory, low FPS, or 'optimize my scene' requests; delegates auth/runtime setup to Phase 0 owners.
— the description by NVIDIA Omniverse

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The omniverse-usd-performance-tuning skill provides a structured, end-to-end procedure for addressing performance bottlenecks in USD assets. It manages the lifecycle of performance tuning, from initial runtime context setup and baseline profiling to composition auditing, validation, and targeted scene optimization. The skill enforces a rigorous milestone-based approach, ensuring that all destructive operations are planned and approved, and that performance improvements are verified through comparative profiling and standardized reporting.

What it does

  • Orchestrates the end-to-end USD performance tuning lifecycle.
  • Validates runtime environments and handles authentication for remote assets.
  • Conducts composition audits and structural assessments of USD stages.
  • Executes validated optimization operations using Scene Optimizer.
  • Generates structured optimization reports comparing baseline and post-optimization metrics.
  • Enforces safety gates for destructive operations and mutation.

When to use it

  • When a USD scene exhibits slow loading times or low frame rates.
  • When memory usage is excessively high or GPU crashes occur.
  • When you need to optimize a scene for better interactivity or performance.
  • When you need to diagnose CAD conversion quality issues.
  • When you need to validate a scene before and after applying optimizations.

Advantages

  • Ensures consistent performance diagnosis through a standardized workflow.
  • Prevents accidental data loss by requiring approval for destructive operations.
  • Provides clear, evidence-based reporting on performance improvements.
  • Integrates seamlessly with existing Omniverse validation and optimization tools.
  • Maintains strict separation between diagnosis, planning, and execution phases.

Usage examples

“This USD scene loads very slowly; please triage what I should check first.”
The agent will initiate the runtime context gate, perform a composition audit, and provide a structured plan to identify the source of the slow load time.
“Optimize my CAD scene for better performance.”
The agent will verify the runtime, assess the CAD conversion quality, and propose a milestone-based optimization plan including validation and profiling.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/openai/omniverse-usd-performance-tuning/download

  2. Unzip 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

<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->

<!-- SPDX-License-Identifier: Apache-2.0 -->

When to Use

Use this workflow for broad performance asks such as slow loading, high memory, low FPS, GPU crashes, conversion-quality triage, or generic requests to optimize a USD scene.

Instructions

  1. Start from the mandatory runtime context gate before producing tuning output, unless the prompt is only asking for a static classification test.

  2. Classify broad optimization requests as ready_to_plan; reserve approval_required for prompts that explicitly name a destructive operation to execute before planning.

  3. Plan the full canonical chain through optimization-report, preserving the structured milestone order and the profile-stage:baseline / profile-stage:after labels when listing milestones.

  4. Invoke downstream skill bodies only when their phase is reached, and keep raw runtime artifacts on disk while reading compact summaries.

Frontmatter keeps version and tools at top level for agentskills.io runtime compatibility. NVCARPS discoverability fields live under metadata.

Output Format

Return a plan or status summary that names the selected entry skill, uses ready_to_plan for generic optimization requests, includes the full milestone chain through optimization-report, and labels profile phases as profile-stage:baseline and profile-stage:after. For structured outputs, the broad-optimization milestone subsequence is omniverse-usd-performance-tuning -> profile-stage:baseline -> usd-structure-assessment -> usd-validation-runner -> restructure-decision -> apply-restructure -> so-run-validators -> so-interpret-validators -> so-run-operations -> profile-stage:after -> compare-profiles -> optimization-report. End-to-end execution should produce an optimized stage when mutation runs and a report conforming to the optimization-report reference's schema (scripts/optimization-report.schema.json within that reference).

Use this workflow for broad performance asks such as slow loading, low FPS, high memory, GPU crashes, conversion quality, or "optimize my scene."

Entry skill rule

This skill is the named entry point for broad performance work whenever the agent has any verified way to do that work. Runtime probing details live in setup-usd-performance-tuning; this rule only decides which skill owns the user-facing performance request.

  • If the setup probe shows any verified runtime path - Kit, standalone, or even a partial stack such as Asset Validator only - enter here. If the user's requested tool is missing, return the specific blocked_code (blocked_missing_scene_optimizer, blocked_missing_so_operation, etc.) instead of substituting another workflow.

  • Enter at setup-usd-performance-tuning only when no runtime path is verified and runtime choice/setup is the first unresolved problem.

  • For omniverse:// assets, enter at omniverse-authentication first. Authentication precedes setup and triage for remote assets.

The decision is about ownership, not order. Setup, authentication, and triage all run in their normal phase order; this rule only fixes which skill the agent names as the entry skill in its response.

Runtime context — session-start gate (mandatory)

Before any other tuning output, follow the mandatory session-start gate in skills/omniverse-usd-performance-tuning/references/setup-usd-performance-tuning/references/runtime-context-header.md. That reference owns output_path, the canonical setup-preflight.json location, Format A/Format B, and the "do not improvise a silent probe" anti-pattern.

Required outcomes:

  • Missing or unreadable preflight: invoke setup-usd-performance-tuning.

  • Present preflight: print Format A and wait for the user to choose Continue, Change Kit, Switch to standalone, or Re-run probe.

  • Confirmed runtime in the same session: use compact Format B for follow-up status.

[Kit: {runtime_context.kit.application} {runtime_context.kit.version}  |  SO: {runtime_context.sceneOptimizer.version}  |  AV: {runtime_context.assetValidator.version}]

Runtime artifact token budget

Before reading Kit logs, Asset Validator CSVs, Scene Optimizer logs, Tracy CSVs, or other runtime output, follow references/runtime-artifact-token-budget.md. Keep raw artifacts on disk, read summary JSON first, and use bounded log snapshots instead of full dumps or live streams.

Plan-time vs execution-time approval

approval_required at planning time is reserved for requests that explicitly name a destructive operation. Use the following rule when deciding between ready_to_plan and approval_required:

  • approval_required at planning time — the user's request itself names a destructive operation: "flatten this stage", "decimate the meshes", "merge prototypes", "delete unused prims", or any specific named mutation that cannot be undone within the same workflow. In this case the agent's first response must be an approval prompt that names the operation, before the agent commits to a plan that executes it.

  • ready_to_plan at planning time — the user's request is general: "optimize this scene", "make it load faster", "reduce GPU memory", "improve interactivity". The agent lays out the full plan, including any destructive operations the plan would invoke (for example so-run-operations with mergeMaterials), without withholding the plan itself. Approval for each destructive operation is requested alongside plan approval.

The distinction is between authorising a plan and authorising a destructive action. A general optimisation request authorises planning; it does not authorise execution of specific destructive operations.

For structured runtime-test responses and similar planning summaries:

  • A future restructure-decision prompt is a planned user-decision gate, not a reason to set the top-level response decision to approval_required for a generic optimization request.

  • For a generic optimization request, set decision: "ready_to_plan" and include the full intended chain in both committed_milestones and planned_phases, through optimization-report.

  • It is valid for gates_observed to include asks_user_for_restructure_decision while the top-level decision remains ready_to_plan.

  • Whenever a chain names profile phases, use the exact labels profile-stage:baseline and profile-stage:after; do not emit the ambiguous bare profile-stage token.

  • Start structured milestone lists with omniverse-usd-performance-tuning as the owning entry skill. Include setup-usd-performance-tuning only as additional Phase 0 context, not as a replacement for the entry skill milestone.

  • For broad optimization requests, preserve the milestone subsequence from Output Format above exactly, with optional extra analysis steps inserted only where they do not reorder it.

  • Do not list so-run-validators or so-interpret-validators before restructure-decision in broad optimization milestone summaries. Phase-aware validator routing still happens through usd-validation-runner; the SO validator executor/interpreter milestones appear after the restructure decision path in the structured plan contract.

Output expectation

End-to-end optimization work should produce both an optimized USD stage, when mutation is executed, and a structured optimization report conforming to the optimization-report reference's scripts/optimization-report.schema.json. The HTML report must be rendered from references/report-templates/optimization-report.html.template via render_preview.py — never hand-write HTML. Diagnosis-only work should still end with a report or summary that states no optimized stage was written.

Purpose

Route digital twin USD performance requests into the right diagnostic and optimization workflow while preserving evidence before mutation.

Prerequisites

  • Stage path or enough context to identify the target asset.

  • User goal: diagnosis only, validation, profiling, or processor execution.

  • Runtime availability status from setup-usd-performance-tuning when not already known.

  • Permission status for in-place mutation vs writing a separate optimized output.

Examples

  • "This USD loads slowly; triage what to check first."

  • "Route a low-FPS CAD scene through the performance workflow."

Triage order

  1. Runtime gate. Follow the mandatory session-start gate above before validation, profiling, or optimization. Do not scan, probe, install, or pick Kit/standalone runtimes directly in this skill; setup-usd-performance-tuning owns probe/chooser/install dispatch and writes the preflight consumed here.

  2. Identify the target problem:

    • Load time.

    • FPS or interactivity.

    • GPU or system memory.

    • Crash or device lost.

    • CAD conversion quality.

    • Validation failure.

  3. Gather minimum context:

    • Stage path and size.

    • Whether the stage is local, mounted, or omniverse:// remote. For remote assets, route through omniverse-authentication before first open.

    • Kit or USD runtime.

    • Whether the workload is CAD, VFI, AIF, Isaac, or generic OpenUSD.

    • Whether in-place mutation is allowed.

    • Whether the user wants diagnosis only or processor execution.

  4. Route:

    • USD composition questions: usd-structure-assessment (composition is now part of the SA umbrella; deeper detail in skills/omniverse-usd-performance-tuning/references/usd-structure-assessment/references/composition-audit.md).

    • Validation and content issues: usd-validation-runner (master router; routes to validate-* family or so-run-validators based on intent).

    • Edit/output decisions: usd-edit-target-planner (also owns variant/payload gates).

    • Repeated copied hierarchy or high mesh count with no instancing: usd-hierarchy-dedupe-candidates.

    • Restructure decision (monolithic stage, asset boundary materialization): restructure-decision.

    • CAD converter settings: read references/cad-conversion/README.md (niche pre-USD concern; see reference for details).

    • Scene Optimizer: so-run-validators, so-interpret-validators, so-run-operations.

Optimization ordering

Follow the canonical ordering in workflow.md § Operation ordering invariants. The high-level rule: prototypes first → per-asset validation → stage-level operations last. The workflow reference owns the full invariant list (meshCleanup before decimateMeshes, deduplication before decimation, never merge if instanced, etc.) and the analysis-only ops catalogue.

Rules

  • Always run composition audit before mutation.

  • Always validate before and after processor execution.

  • Optimize prototypes before per-asset validation.

  • Do not run whole-stage mesh deduplication on very large CAD scenes before checking for hierarchy-level reuse.

  • Do not recommend a fixed optimization stack without bottleneck evidence.

  • Do not invent numeric thresholds or expected percentage wins.

  • Prefer canonical SO ops over specialty / documentary ones. The op curation in references/operations/_curation.json classifies every op as canonical, specialty, analysis, documentary, or deprecated. When more than one op could resolve the same finding, recommend the canonical one first and only reach for a specialty op when the user explicitly asks or the rationale warrants it. Specifically:

    • For vertex welding, prefer canonical meshCleanup with explicit flags over the standalone mergeVertices op. The standalone op is a legacy/specialty surface; use upstream usd-optimize for the operation mechanics and local approval policy before mutating.

    • For hierarchy dedupe, recommend usd-hierarchy-dedupe-candidates + apply-restructure (the USD-authored rewrite path).

    • For per-mesh dedupe, recommend deduplicateGeometry (canonical) over findCoincidingGeometry (analysis — produces a report, not a change).

    • Do not recommend documentary-status ops (e.g., boxClip, deletePrims, removeAttributes, removeUntypedPrims, merge outside its narrow non-instanced case) without an explicit user request. Documentary ops survive in the per-op references/operations/<key>.md routing stubs for completeness but are excluded from agent-initiated recommendations.

    • Specialty ≠ documentary. Ops classified as specialty in _curation.json either (a) have validator-finding evidence that wires them into the so-interpret-validators chain (e.g. sparseMeshes, optimizePrimvars), or (b) are load-bearing escape hatches needed for specific downstream contexts (e.g. primitivesToMeshes when output must be UsdGeomMesh, utilityFunction for instancing toggles and material rebinding, pythonScript for so-create-proxy recipes). Recommend specialty ops when their validator fires OR when their downstream context applies — the suppression above only targets documentary ops.

Limitations

  • Does not replace downstream reference instructions; load each required reference before executing it.

  • Does not install runtimes directly; follow setup or install references when requirements are missing.

  • Does not authorize mutation when the user has not allowed writes.

Troubleshooting

  • If runtime status is unclear, run setup-usd-performance-tuning before profiling or validation.

  • If the reported problem is vague, gather stage path, workload type, and whether diagnosis or execution is requested.

  • If the workflow suggests mutation before evidence, return to baseline profiling and composition audit first.

References

Before routing, read:

  • skills/omniverse-usd-performance-tuning/references/usd-structure-assessment/references/optimization-tradeoffs.md — identify which pipeline phase the scene is in (extraction, structuring, or optimization). The right action depends on the phase.

  • skills/omniverse-usd-performance-tuning/references/usd-structure-assessment/references/factory-level-structuring.md — understand the three pillars (assets, aggregation, animation) and the seven-step structuring pattern.

If you have network access, prefer the live URLs (noted in each reference file) for the most current version.

Required execution flow

Read references/workflow.md for the canonical Phase 0-7 flow, including Kit/standalone branches, validator-stack routing, operation ordering, termination conditions, duration hints, and the optional iteration pattern. The compact root map at references/skill-map.md only routes agents into this workflow.

Do not treat downstream phase names as plain checklist labels. Before executing each step, load that phase's nested README.md reference and follow its instructions. Claude Code only exposes the public catalog skill; it does not recursively inject profile-stage, usd-structure-assessment, or other nested references.

The final deliverable must come from optimization-report: save both the structured JSON report and the generated Markdown summary. Do not substitute an ad hoc SUMMARY.md or chat-only recap for the optimization report.

For deeper subtopic guidance, consult the references:

  • skills/omniverse-usd-performance-tuning/references/usd-structure-assessment/references/composition-audit.md, skills/omniverse-usd-performance-tuning/references/usd-structure-assessment/references/layer-health.md - subtopic detail for SA's Phase 1 checklist.

  • skills/omniverse-usd-performance-tuning/references/usd-structure-assessment/references/instancing-readiness/references/instancing-tradeoffs.md - merge safety, decision tree for instancing choices.

  • skills/omniverse-usd-performance-tuning/references/usd-structure-assessment/references/usd-edit-target-planner/references/variants-payloads.md - deeper variant/payload trade-offs (gates are inline in usd-edit-target-planner).

  • references/cad-conversion/README.md - CAD converter settings.

  • references/upstreams/usd-optimize.md - upstream SO mechanics and prebuilt package resolution.

  • skills/omniverse-usd-performance-tuning/references/usd-validation-runner/references/so-run-validators/references/infrastructure.md - local handoff for SO validator infrastructure.

  • skills/omniverse-usd-performance-tuning/references/usd-validation-runner/references/validation-scoping.md - tier 1/2/3 plan + scene-aware adjustment.

  • skills/omniverse-usd-performance-tuning/references/optimization-report/references/optimization-report-template.md - the data contract every phase populates.

For full Kit runtime profiling (FPS, frame time, Hydra/RTX metrics), refer to the external profiling skills at NVIDIA/omniperf.

Files

references/usd-validation-runner/references/validate-usd-asset-validator.md

<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->

<!-- SPDX-License-Identifier: Apache-2.0 -->

Validate USD Asset Validator

Purpose

Use this validation reference when a stage or asset needs executable NVIDIA Omniverse Asset Validator coverage. This is a validation-only reference: it reports issues and recommended next steps, but does not apply fixes unless explicitly requested.

Prerequisites

  • Run setup-usd-performance-tuning first to select a Kit or standalone validation runtime.

  • Confirm the target is a USD asset path or asset directory. If basic USD viability is unknown, first perform the runner's minimum-openability check: stage opens, root/default prim is valid enough for the task, asset paths resolve, and scale/up-axis metadata is known or recorded as missing.

  • Require either a Kit runtime with omni.asset_validator.core or a standalone omniverse-asset-validator environment. Install or select a runtime before reporting blocked_missing_dependency.

  • For unknown, customer-scale, or structurally large assets, require explicit user approval before running the default full-stage Asset Validator rule set. The default path is minimum-openability plus targeted rules/categories.

Runtime Selection

First resolve the runtime with setup-usd-performance-tuning. There are two supported paths:

  • Kit path: use the selected Kit/USD Composer/Kit venv runtime and run Asset Validator through omni.asset_validator.core inside that same Kit process. Do not require uv or omni_asset_validate on PATH for this path.

  • Standalone path: use a project-managed omniverse-asset-validator environment. If that standalone environment is missing, invoke install-asset-validator-standalone.

Do not use the Scene Optimizer package's bundled validator-venv/bin/omni_asset_validate as the preferred Asset Validator runtime. That venv is package-local and has been observed without numpy, which can make validation much slower on large USD stages. Prefer a project-managed environment that can import both omniverse-asset-validator and the selected Scene Optimizer package.

Report blocked_missing_dependency only when neither path is available and the missing runtime cannot be installed or selected.

Kit Path

Use this path when setup returned ready-kit, when SO validators are needed, or when validating remote omniverse:// assets from the same authenticated Kit runtime.

Standalone is the preferred runtime. The standalone path is lighter (no Kit overhead), deterministic, and achieves the same validator coverage: SO validators auto-register via @register_rule decorators when both omniverse-asset-validator and the SO package are importable in the same Python environment. Fall back to Kit when standalone is unavailable or when render-time profiling is needed (Kit-only capability).

  1. Use the Python launcher selected by setup:

    • Classic Windows Kit: <kit>\python.bat

    • Classic Linux Kit: <kit>/python.sh or <kit>/python

    • Windows Kit venv: <venv>\Scripts\python.exe

    • Linux Kit venv: <venv>/bin/python

  2. Set OMNI_KIT_ACCEPT_EULA=yes.

  3. Start Kit with --no-window and --enable omni.asset_validator.core.

  4. Validate through omni.asset_validator.core.ValidationEngine.

Minimal Kit pattern:

import os

os.environ.setdefault("OMNI_KIT_ACCEPT_EULA", "yes")

try:
    from kit_app import KitApp
except ImportError:
    from omni.kit_app import KitApp

app = KitApp()
app.startup(["--no-window", "--enable", "omni.asset_validator.core"])

from omni.asset_validator.core import ValidationEngine

asset_abs = "/path/to/asset.usd"
engine = ValidationEngine()
engine.disable_all_rules()
engine.enable_rules("omni.asset_validator.DefaultPlugin.StageMetadataChecker")
results = engine.validate(asset_abs)
issues = results.issues() if callable(results.issues) else results.issues

print("ASSET_VALIDATOR_ISSUES", len(issues))
app.shutdown()

If Scene Optimizer performance validators are also required, use so-run-validators after setup verifies omni.scene.optimizer.core in the same Kit runtime.

Standalone Path

Use this path when the user chooses standalone validation or no Kit runtime is available. Use a project-managed omniverse-asset-validator install created or verified by install-asset-validator-standalone in the same venv where the SO package is on PYTHONPATH. SO validators auto-register via @register_rule decorators: no manual register_all() call is needed for rule discovery. For targeted or category-scoped runs, select registered rule classes with CategoryRuleRegistry and enable them with ValidationEngine(init_rules=False) plus enable_rule().

Do not use the SO bundled validator-venv — it may lack numpy and is slower on large stages.

Workflow

  1. Confirm the input is a USD asset path or an asset directory.

  2. Confirm the minimum-openability check has passed, or run it first when basic USD viability is unknown.

  3. Choose the narrowest Asset Validator scope that answers the request: targeted rule, targeted category, or explicit full-stage pass. For performance work, prefer rules/categories that can change the optimization plan; do not use a full-stage default sweep as the preliminary baseline.

  4. For large assets where full-stage coverage is too expensive but validation signal is still useful, use the Masked-Stage Spot Check Pattern below on representative prims/subtrees before escalating to a full sweep.

  5. If the chosen scope is a default full-stage pass on an unknown, customer-scale, or structurally large asset, stop and ask for approval. Name the risk plainly: long runtime, high log/report volume, and possible repeated issue rows. Offer targeted category/rule checks as the recommended alternative.

  6. Run validation with validate-usd-asset-validator.

  7. Normalize issues by severity, rule, message, location, and suggested fix when available. For high-volume findings, summarize by rule and target class rather than dumping every repeated issue into the user-facing report.

  8. If the raw Asset Validator report is large, summarize it with the Large Report Summarization policy below before reading results into context.

  9. Fail the report on Asset Validator errors or failures.

  10. Warn on Asset Validator warnings unless the active workflow profile promotes them to failures.

  11. Hand off performance-oriented findings to so-run-validators / so-interpret-validators. For external domain profiles or package conformance, route to the owning external workflow rather than adding those references here.

Timeout and Approval Policy

All validation cost-control policy (full-sweep approval gate, timeout guidance, spot-check thresholds) lives in validation-scoping.md → Full-Sweep Approval Gate and Decision Tree. Apply those rules before any full-stage invocation.

When a timeout is used, record timeout_seconds and timeout_reason. If the validator times out, report status: TIMEOUT and keep partial logs/artifacts for follow-up.

Standalone CLI Pattern

Project-managed standalone environment:

omni_asset_validate --help
omni_asset_validate asset.usda --category Geometry --csv-output geometry-report.csv

Use only the output flags advertised by the selected runtime. Some versions or wrappers also support JSON output; when they do not, CSV is the conservative standalone artifact.

Treat category-scoped CLI invocations as scoped full-stage traversals. On large or unknown-size assets, apply validation-scoping.md first: prefer masked spot checks, or run each category/rule with an explicit wall-clock budget and record any timeout.

Do not use a bare default invocation such as omni_asset_validate asset.usda --csv-output asset-validator-report.csv on a large or unknown asset until the full-sweep approval gate has passed. Do not use --fix unless the user explicitly asks for auto-repair behavior.

Standalone Python API Pattern

Use the Python API from the selected standalone environment when structured issue extraction is needed:

from omni.asset_validator import ValidationEngine

engine = ValidationEngine()
results = engine.validate("asset.usda")
issues = results.issues() if callable(results.issues) else results.issues

Masked-Stage Spot Check Pattern

Policy, sample selection rules, and implementation pattern live in validation-scoping.md → Masked-Stage Spot Checks. Use that reference for the canonical Usd.Stage.OpenMasked() pattern, mesh coverage floor (≥25%), and sample manifest fields.

Inside Kit, use omni.asset_validator.core.ValidationEngine instead of the standalone import. For a live Kit stage, pass both root and session layers:

default_prim = original_stage.GetDefaultPrim()
if default_prim:
    mask.Add(default_prim.GetPath())
masked_stage = Usd.Stage.OpenMasked(original_stage.GetRootLayer(), original_stage.GetSessionLayer(), mask)
if default_prim and not masked_stage.GetDefaultPrim().IsValid():
    raise RuntimeError(f"masked stage excluded default prim {default_prim.GetPath()}")

Large Report Summarization

Apply this policy before reading any Asset Validator JSON, CSV, stdout, or log artifact into agent context.

First inspect artifact size (wc -c on POSIX, Get-Item <path> | Select Length in PowerShell). Treat the artifact as large when it is over 5 MB, when it has more than 10,000 CSV rows, or when it was produced by a full-stage pass over an unknown or customer-scale asset. A 166 MB validation report is always a large artifact.

For large artifacts, keep the raw report on disk and create or use a compact summary first:

  • If a packaged summarizer exists for the selected runtime, run it and read only its compact JSON output.

  • If no summarizer exists, create a temporary stdlib-only script beside the artifact (for example <artifact_dir>/_summarize_asset_validator_report.py). The script is a run artifact, not repository content, unless the user explicitly asks to add tooling.

  • For CSV reports, stream rows with Python's csv.DictReader; do not load the whole file or print raw rows.

  • For JSON reports, parse in the helper process and emit compact counts. It is acceptable for the helper process to load JSON if the runtime has enough memory, because the raw JSON still never enters agent context. If the JSON is too large or the shape is unknown, emit top-level keys and an error summary, then ask for a CSV export or narrower rule/category run.

The compact summary should include:

  • report_path and report_bytes

  • issue_counts by severity

  • top rules/categories by issue count

  • grouped failures by (rule, severity, message, suggestion)

  • up to 10 example locations per group

  • truncated: true|false

  • parse errors or skipped records, if any

Read only that compact summary into context. The final user-facing validation report may include capped examples and artifact paths, but it must not include the full raw issues list when the raw report is large.

Categories

Common categories include:

  • Basic

  • Geometry

  • Layer

  • Layout

  • Material

  • Physics

  • Other

Output Report

Reports should include:

  • asset_path

  • validator_skill

  • validator_tool

  • passed

  • categories

  • rules

  • issue_counts

  • issues

  • timeout_seconds

  • timeout_reason

  • warnings

  • errors

  • next_step

Pass/Fail Policy

Fail when:

  • the Asset Validator dependency is missing

  • the asset cannot be opened by Asset Validator

  • any issue has severity ERROR or FAILURE

Warn when:

  • issues have severity WARNING

  • the selected category or rule set is narrower than the requested validation goal

  • auto-fix suggestions exist but were not applied

Limitations

  • This validation reference reports Asset Validator results only; it does not apply --fix or repair USD content unless the user explicitly asks for auto-repair behavior.

  • Rule coverage depends on the selected Kit or standalone Asset Validator version and installed categories.

  • Scene Optimizer performance validators are separate and should run through so-run-validators when setup verifies omni.scene.optimizer.core.

  • Remote omniverse:// targets require an authenticated Kit runtime; standalone validation is for local paths.

  • Masked-stage spot checks are optimization evidence, not a substitute for a full conformance pass when the user asks for formal validation coverage.

Payload Loading Behavior

The Asset Validator discards StageLoadRules and re-opens with LoadAll — all payloads are loaded regardless of caller configuration. StagePopulationMask IS preserved (OpenMasked works for scoping). Do not rely on LoadNone for validation scoping; use OpenMasked or validate standalone files.

See validation-scoping.md §"LoadRules Behavior With the Asset Validator" for full consequences and workarounds.

Troubleshooting

  • If neither runtime path is available, run setup-usd-performance-tuning again or use install-asset-validator-standalone to create a project-managed standalone validator.

  • If the SO bundled validator venv is missing dependencies such as numpy, select the Kit path or project-managed standalone path and record any fallback limitation.

  • If validation times out on a large stage, keep the partial report/log, narrow the scope, or ask the user for an explicit larger time budget.

  • If Asset Validator passes but external profile/package conformance is still needed, hand off to that owning external workflow and keep this package's report focused on USD/Asset Validator evidence.

Next Steps

Use this handoff:

Asset intentNext skill
Performance validation neededso-run-validators
Findings need operation recommendationsso-interpret-validators
External profile/package conformance neededOwning external validation workflow

Requirements and compatibility

Written for: OpenAI Codex

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

The author says: Orchestrator skill. Downstream phases may require Kit, Scene Optimizer, Asset Validator, USD Python, writable output paths, and omniverse:// authentication selected by setup-usd-performance-tuning.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs
  • Instructions that use the network
  • 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
OpenAI (Official)
Distributed by
OpenAI
Source
openai/plugins · plugins/nvidia/skills/omniverse-usd-performance-tuning · commit d420d13
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (written by AutoGineer)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA Omniverse or OpenAI.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download omniverse-usd-performance-tuning.zip