Omniverse Cad To Simready

NVIDIAOfficialCreated by OmniverseDistributed by NVIDIA

Skill
Workflow
Software development
Apache-2.0
Medium risk
Has scripts

From the author

Coordinate the end-to-end CAD/source-asset to SimReady workflow. Use for broad requests such as CAD to SimReady, source asset to simulation-ready USD, or prop packaging that require conversion, material/physics assignment, SimReady conformance, validation, and optional package creation; deploy or verify Content Agents services first when property assignment is enabled; route single-stage work through nested references.

— the description by Omniverse

AutoGineer summary

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

This skill acts as an orchestrator for the CAD to SimReady pipeline, coordinating a series of specialized stages including asset conversion, material and physics assignment via Content Agents, validation, and final packaging. It is designed to manage the flow between discrete tools rather than replacing them, ensuring that assets meet specific simulation requirements through a structured, documentation-driven process.

What it does

Coordinates end-to-end conversion from source CAD or mesh assets to SimReady USD.
Manages property assignment for materials and physics using Content Agents.
Performs multi-stage validation gates to ensure asset viability and conformance.
Automates the assembly of deliverable packages including thumbnails and USD dependencies.
Provides consolidated reporting on workflow status, validation findings, and stage outputs.
Supports flexible execution modes including conversion-only and validation-only paths.

When to use it

When you need to transform raw CAD or source assets into simulation-ready USD files.
When you require automated material and physics assignment for 3D assets.
When you need to validate assets against SimReady conformance profiles.
When you are preparing assets for packaging and distribution in a simulation environment.

Advantages

Provides a structured, repeatable pipeline for complex asset preparation.
Integrates multiple specialized stages into a cohesive workflow.
Ensures consistent validation and conformance across the asset lifecycle.
Supports modular execution by allowing specific stages to be skipped or isolated.

Usage examples

“Convert my CAD file at /path/to/model.step to a SimReady asset.”: The agent will initiate the preflight check, convert the file to USD, apply material and physics properties, validate the result, and output a report.
“Validate this existing USD file for SimReady conformance.”: The agent will run the validation-only workflow, checking the provided USD against SimReady profiles and reporting any findings.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/nvidia/omniverse-cad-to-simready/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip omniverse-cad-to-simready.zip -d .agents/skills

Documentation by Omniverse

CAD to SimReady

When to Use

Use this workflow skill for an end-to-end pipeline from a source asset to a SimReady asset or package. It coordinates existing conversion, authoring, validation, conformance, rendering, and packaging references directly; do not replace it with a single monolithic runner command.

This skill is documentation-driven and does not ship scripts/run.py; it must not depend on a repository checkout. Shell is declared because this workflow invokes installed stage reference scripts directly, from each reference's installed directory, and it still must not grow a monolithic runner.

Prerequisites

Prefer preflight first for deterministic setup: it installs/verifies local upstream checkouts, writes a cad-to-simready-preflight.json manifest, and exports PHYSICAL_AI_PREFLIGHT_MANIFEST plus PHYSICAL_AI_REQUIRE_PREFLIGHT=1 for downstream references.
Python 3.12 and uv (per repo README.md).
A Content Agents model provider key when local deployment will run, or explicit endpoint variables plus usage tokens for already-running endpoints; see references/preflight/README.md for the full list.
Docker, NVIDIA Container Toolkit, and an NVIDIA GPU for Content Agents and OVRTX stages.
Local upstream checkouts under ${OMNIVERSE_CAD_TO_SIMREADY_UPSTREAM_ROOT:-$HOME/.omniverse-cad-to-simready/upstreams} when a stage needs upstream scripts or specs.

First Action

For any broad CAD/source-asset to SimReady request, assume property_assignment_intent=run unless the user explicitly asks for conversion-only, validation-only, or no material/physics assignment. For conversion-only requests, set property_assignment_intent=skip, do not deploy Content Agents, run convert-to-usd, then run validate-usd-minimum on the generated USD if conversion succeeds. For validation-only requests, set property_assignment_intent=skip and validate the USD the user provided without rerunning conversion.

Run preflight (or verify an existing PHYSICAL_AI_PREFLIGHT_MANIFEST) before any converter, validation, Content Agents, OVRTX, packaging, or FET step; treat it as dependency bootstrap, not workflow routing. Use --skip-content-agents for conversion-only/validation-only requests.

When property_assignment_intent=run, verify or deploy Content Agents services immediately after confirming the source path and resolving intent, before asset-context inspection, converter dependency checks, conversion, validation, conformance, rendering, packaging, or upstream source builds. Treat explicitly provided healthy endpoints as user-owned; otherwise run deploy-content-agents, which deploys the shared standalone OVRTX renderer, then Material, Physics, and optional Texture service containers in order.

Instructions

Confirm the source asset path exists, resolve output_root, and classify the request as end-to-end, conversion-only, validation-only, or packaging.
Resolve property_assignment_intent before running any asset inspection, converter probe, conversion, validation, conformance, rendering, or packaging step.
Run preflight for the selected workflow targets, unless a ready PHYSICAL_AI_PREFLIGHT_MANIFEST is already configured. Source the generated env file before running downstream scripts. Treat preflight as dependency setup only: it may use a provided --source-asset, --source-format, or --conversion-tools value to scope dependency checks, but convert-to-usd and the upstream converter references still decide actual conversion support.
Verify or deploy Content Agents services first when property_assignment_intent=run; block on missing authentication or unhealthy services instead of continuing.
Read references/workflow.md and references/commands.md, then run only the stage references needed for the current request.
Run identify-asset-context on the original source asset when web search is available or property assignment will run.
Route the source through convert-to-usd, or skip conversion for existing USD input and treat the source path as the current USD path.
Run validate-usd-minimum before expensive downstream work. Treat this as a viability gate only: record unit/profile issues such as metersPerUnit != 1.0, but do not run simready-conform-profile, FET001, or any other FET repair before Content Agents assignment when property assignment will run.
Run Content Agents material, physics, and optional texture assignment on the converted/minimum-valid USD when requested or required.
Run simready-conform-profile on the latest simulation USD path after property assignment and preserve every selected FET repair report.
Run validation gates in order: omni-asset-validate, omni-asset-validate-geometry, omni-asset-validate-physics, and simready-validate.
Rerun simready-conform-profile when simready-validate reports a repairable requirement, then rerun profile validation on the newest authored USD.
Run ovrtx-render-service when preview, thumbnail, or inspection images are requested. When package outputs are requested, run assemble-package-source next to create the clean deliverable/ package source from the final USD and thumbnail, then run nv-core-package-sample and nv-core-package-sample-validation on that deliverable folder only.
Emit the consolidated workflow report with the final USD path, all stage reports, validation findings, rerun reasons, and next work.

Output Format

Emit a consolidated workflow report in Markdown, and include JSON when the workflow writes structured artifacts. Report overall status as passed, blocked, failed, or needs_rerun. See references/workflow.md for the required Markdown and JSON report fields.

Detailed References

Read only the references needed for the current request:

references/preflight/README.md: deterministic local setup, manifest/env contract, wrappers, deployment opt-out, and guardrail behavior.
references/workflow.md: inputs, source routing, detailed workflow, validation policy, output report fields, and next steps.
references/commands.md: concrete portable script command patterns.
references/assemble-package-source/README.md: two-zone package source assembly, root USD naming, thumbnail placement, and deliverable checks.
references/troubleshooting.md: symptom/cause/fix table plus FET (GSP.001/RB.MB.001) repair-routing detail.
references/publishing-layout.md: frontmatter compatibility-field notes and layout rationale for this skill's own file tree.

Publishing Layout Notes

Use skills/omniverse-cad-to-simready/ as the source of truth for this product repo's skill. The .agents/skills symlink is a compatibility alias for local agentskills.io-style discovery, and the nested references/ tree is intentional. See references/publishing-layout.md for the alias list, frontmatter field placement, and flattening rules.

Limitations

This workflow coordinates existing conversion, property assignment, conformance, validation, rendering, and packaging skills; it does not replace them with a single monolithic runner command.

Troubleshooting

Read references/troubleshooting.md only when a specific stage or validation gate is failing; it owns the symptom/cause/fix table and FET repair routing.

Hard Rules

Prefer the preflight manifest for local upstream roots, converter executables, SimReady validation runtime, OVRTX endpoint, and Content Agents service URLs. When PHYSICAL_AI_REQUIRE_PREFLIGHT=1 is set, do not bypass the manifest with direct upstream discovery.
Do not run asset inspection, converter probes, local upstream builds, conversion, validation, conformance, rendering, or packaging before Content Agents readiness when property assignment will run.
Use stage-specific installed reference scripts directly. Do not add or call a single omniverse-cad-to-simready runner command.
For source conversion, delegate to the convert-to-usd reference; do not substitute another converter for CAD or mesh formats.
For property assignment, use Content Agents references as separate atomic steps: material first, then physics, then texture only when requested.
When property assignment will run, do not run simready-conform-profile or any FET helper before Content Agents. Validate minimum USD first, then run Content Agents on that converted/minimum-valid USD, then apply FET repairs to the latest service-authored USD.
When property assignment will run, do not run simready-validate or any SimReady profile validation before Content Agents. The only validation gate allowed before service calls is validate-usd-minimum, which is a basic USD viability check.
Stop at the first failing deployment, conversion, property-assignment, or conformance authoring gate unless the user explicitly asks for best-effort continuation.
Do not stop at validation findings after a meaningful USD artifact exists. Continue remaining diagnostic gates and mark the result needs_rerun.
Do not leave a GSP.001 profile failure as an unclassified final finding. Route it to upstream simready-foundation-conform-fet-005-simulate-grasp-physics; if the current agent cannot inspect renders or no explicit grasp points are available, report a blocked FET005 repair with the visual evidence path or missing input reason.
Preserve every stage report and pass the concrete output USD path from each report into the next stage.

Files

references/deploy-content-agents/README.md

Deploy Content Agents

When to Use

Use this reference when the user asks to deploy, start, configure, or troubleshoot NVIDIA Omniverse Content Agents services. This repo does not ship a deployment runner or duplicate service runbooks; it selects the target, resolves the upstream checkout, enforces repo-local readiness policy, and hands off to the upstream deployment skills.

This reference is documentation-driven, does not ship scripts/run.py, and should not depend on this repository checkout.

Prerequisites

A provider API key for the selected Content Agents VLM/LLM backend. Use NVIDIA_API_KEY from https://build.nvidia.com for NVIDIA-hosted defaults; other hosted provider keys include OPENAI_API_KEY, ANTHROPIC_API_KEY, GOOGLE_API_KEY, and GEMINI_API_KEY.
Docker, Docker Compose v2, NVIDIA Container Toolkit, an NVIDIA driver, and an NVIDIA GPU on the deployment host.
A normalized upstream checkout of https://github.com/nvidia-omniverse/content-agents at the exact ref in upstream-versions.lock.json (currently v0.5.2).

Upstream Reference

Use the NVIDIA Omniverse Content Agents deployment skills at the tested manifest pin as the source of truth:

Target	Upstream skill
Material Agent	`https://github.com/nvidia-omniverse/content-agents/blob/v0.5.2/.codex/skills/deploy-material-agent-docker/SKILL.md`
Physics Agent	`https://github.com/nvidia-omniverse/content-agents/blob/v0.5.2/.codex/skills/deploy-physics-agent-docker/SKILL.md`
Texture Agent	`https://github.com/nvidia-omniverse/content-agents/blob/v0.5.2/.codex/skills/deploy-texture-agent-docker/SKILL.md`
OVRTX renderer	`https://github.com/nvidia-omniverse/content-agents/blob/v0.5.2/.codex/skills/deploy-ovrtx-docker/SKILL.md`

Repository: https://github.com/nvidia-omniverse/content-agents, ref v0.5.2

If browser or raw-file fetches are blocked, use a local clone checked out to the exact manifest ref and read .codex/skills/<skill-name>/SKILL.md from that checkout. Resolve it from CONTENT_AGENTS_UPSTREAM_ROOT, then $OMNIVERSE_CAD_TO_SIMREADY_UPSTREAM_ROOT/content-agents, then $HOME/.omniverse-cad-to-simready/upstreams/content-agents. Do not scan broad developer workspaces.

Do not duplicate full upstream deployment runbooks here.

Inputs

Collect:

Input	Requirement
`target_service`	`material`, `physics`, `texture`, or `ovrtx`.
`content_agents_root`	Optional explicit upstream checkout path.
`deployment_mode`	Local container deployment or reuse of healthy existing services.
`render_endpoint`	Required for render-dependent agent services.
`env_keys`	Provider/API keys required by the upstream skill. Never print or commit secrets.
`vlm_backend` / `vlm_model`	Optional deployment-time VLM selection, for example `openai` / `gpt-5.5`.
`llm_backend` / `llm_model`	Optional deployment-time LLM selection, for example `openai` / `gpt-5.5`.

Instructions

Resolve the upstream checkout from the normalized root policy.
Read the matching upstream deployment skill before issuing service-specific commands.
Confirm required secrets are available from local shell state or a private .env; if missing, ask the user and wait.
Treat explicit endpoints as user-owned. Probe them and block if they are unhealthy; do not deploy a replacement container for that service.
For managed local deployment, deploy missing services in deterministic order: standalone OVRTX when Material or Physics will be deployed, then Material, Physics, and optional Texture one service at a time through the upstream collection deployment helper.
Prefer a shared standalone OVRTX renderer plus independently deployed agent services for this workflow. Use bundled agent-specific renderer stacks only when the user asks for isolation or the upstream skill requires it.
Preserve upstream secret handling, build steps, image names, health checks, and service-specific environment details.
Verify the renderer and selected agent health endpoints before exporting CONTENT_AGENTS_*_BASE_URL or RENDER_ENDPOINT. For local deployments, RENDER_ENDPOINT should point the agent containers at the standalone OVRTX HTTP service; upstream may describe this as the remote renderer backend because it is reached over HTTP.
Return to the caller only after the requested service is healthy, or report the missing prerequisite as blocked.

Headless / Nested Host Notes

Use this section only as deployment-readiness guidance for nested or headless hosts. The upstream content-agents skills still own the actual Docker Compose files, commands, image names, ports inside containers, and service-specific environment variables.

Single GPU + Cloud VLM

For local evaluation, prefer one shared standalone OVRTX renderer on the local GPU plus independent Material, Physics, and Texture Agent service containers that use a hosted provider key such as NVIDIA_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY, GOOGLE_API_KEY, or GEMINI_API_KEY for provider-backed VLM/LLM calls. This topology does not require a separate local VLM GPU. Verify the OVRTX host endpoint first, then verify each agent service reports configured API keys before exporting CONTENT_AGENTS_*_BASE_URL. For managed local deployment, treat OVRTX as part of the Content Agents deployment contract when Material or Physics will be deployed: start it first, verify render health, then deploy each missing agent service individually.

For hosted providers, use the upstream collection deployment path with non-secret model overrides and keep keys in a private .env. Supported hosted backends include openai, anthropic, and gemini. GPT-style OpenAI model deployments should pin VLM/LLM temperatures to 1.0, because some GPT models only accept the default temperature:

python3 skills/omniverse-cad-to-simready/references/preflight/scripts/preflight.py \
  --content-agents-secret-env-file "$HOME/Codes/.env" \
  --content-agents-vlm-backend openai \
  --content-agents-vlm-model gpt-5.5 \
  --content-agents-llm-backend openai \
  --content-agents-llm-model gpt-5.5

For a custom OpenAI-compatible /v1 VLM endpoint, set --content-agents-vlm-backend openai, then provide --content-agents-vlm-endpoint with the model ID served by that endpoint. Use --content-agents-vlm-api-key-env when that endpoint should read a custom secret name instead of the default OPENAI_API_KEY. Anthropic and Gemini use their matching upstream key environment names. Reserve nim for actual NVIDIA NIM endpoints.

Confirm Docker Compose v2 is installed before following the upstream deployment skills; the legacy docker-compose binary is not sufficient when upstream expects docker compose.
In nested Docker environments, overlay storage can fail with invalid argument. If Docker cannot start containers, check whether the host needs a vfs storage-driver fallback before retrying the upstream deployment.
Avoid changing Docker daemon settings in a shared or user-provided SSH session until the user approves that risk; prefer a fresh disposable session for deployment experiments.
Treat the Xvfb display number as a configurable deployment input. If OVRTX exits during startup and the logs show a display conflict, choose an unused display such as :100 instead of assuming the default display is free.
Prefer distinct host endpoints for the shared renderer and each independently deployed agent service. A proven local layout is OVRTX on 8001, Material Agent on 8100, Physics Agent on 8200, and Texture Agent on 8300 when texture generation is needed; export the corresponding host URLs only after those endpoints respond healthy.
A container-internal OVRTX healthcheck can be a false negative when the externally mapped host /health endpoint is healthy. Record both the container health result and the host endpoint result before declaring the renderer blocked.

Blocked Deployment Policy

If deployment authentication is missing, ask the user for the matching provider key and wait; if deployment cannot produce healthy services, report Content Agents readiness as blocked instead of proceeding. See ../preflight/README.md and this reference for provider-key, dotenv, and custom-endpoint detail.

Handoff Map

Target	After deployment
Material Agent	Set `CONTENT_AGENTS_MATERIAL_AGENT_BASE_URL`, then use `material-agent-client`.
Physics Agent	Set `CONTENT_AGENTS_PHYSICS_AGENT_BASE_URL`, then use `physics-agent-client`.
Texture Agent	Set `CONTENT_AGENTS_TEXTURE_AGENT_BASE_URL`, then use `texture-agent-client`.
OVRTX	Set `RENDER_ENDPOINT` or `OVRTX_RENDER_ENDPOINT` for render clients.

Limitations

This reference selects targets and readiness gates; upstream deployment skills own commands and service internals.
It does not call already-running services for asset enrichment.
It does not publish Docker Compose, docker run, port, image-name, or in-container environment recipes. Read those from upstream.

Troubleshooting

Symptom	Action
Upstream skill URL cannot be fetched	Use the local `content-agents` clone checked out to the exact ref in `upstream-versions.lock.json`.
Required API key is missing	Ask the user for the provider key matching the selected backend, such as `NVIDIA_API_KEY`, `OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, `GOOGLE_API_KEY`, or `GEMINI_API_KEY`. Usage tokens for already-running endpoints belong to the client references, not this deployment reference.
Service health is not ready	Follow the selected upstream deployment skill's health-check section.
Renderer-dependent agent cannot reach OVRTX	Use the upstream renderer and agent deployment skills together; do not patch this repo with local Docker recipes.
Nested host cannot start Docker containers	Check Docker Compose v2, GPU visibility, NVIDIA Container Toolkit, and whether the host requires the `vfs` storage-driver fallback.
OVRTX exits in a headless session	Check Xvfb logs and retry the upstream deployment with an unused display value instead of assuming `:99` is available.
Container health is unhealthy but the mapped host endpoint responds	Treat this as a healthcheck mismatch until the upstream deployment skill confirms the container-internal and host-mapped ports. Use the host endpoint only after `/health` reports renderer readiness.

Pass/Fail Policy

Report blocked rather than guessing when:

the upstream checkout is inaccessible
Docker/GPU/container prerequisites fail
required credentials are missing
the selected upstream deployment skill does not support the requested mode
health checks do not pass

Next Steps

After a service is healthy, return to content-agents or the selected service wrapper reference for the asset workflow.

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: Declares allowed tools, Needs Python

The author says: Orchestrator skill. Managed Content Agents deployment requires a configured model provider key matching the selected backend, such as NVIDIA_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY, GOOGLE_API_KEY, or GEMINI_API_KEY, Docker + NVIDIA Container Toolkit + GPU, Python 3.12, and an upstream checkout of nvidia-omniverse/content-agents at the ref pinned in upstream-versions.lock.json. Reused/provided endpoints may instead use explicit endpoint and usage-token environment variables. Linux/macOS only.

Security

What our scanner noticed· Medium risk

Large base64-encoded blobs
Instructions that use the network
Downloads piped into a shell
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

Omniverse

Publisher

NVIDIA (Official)

Distributed by

NVIDIA

Source

NVIDIA/skills · skills/omniverse-cad-to-simready · commit fce3cca

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE-APACHE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

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

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download omniverse-cad-to-simready.zip

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by Omniverse

CAD to SimReady

When to Use

Prerequisites

First Action

Instructions

Output Format

Detailed References

Publishing Layout Notes

Limitations

Troubleshooting

Hard Rules

Files

references/deploy-content-agents/README.md

Deploy Content Agents

When to Use

Prerequisites

Upstream Reference

Inputs

Instructions

Headless / Nested Host Notes

Single GPU + Cloud VLM

Blocked Deployment Policy

Handoff Map

Limitations

Troubleshooting

Pass/Fail Policy

Next Steps

Requirements and compatibility

Security

Attribution and licence

Related skills

Setup TS Deep Modules

To Spec

Improve Codebase Architecture

Domain Modeling

Codebase Design

Prototype

Download ZIP