Generated banner for Omniverse Realtime Viewer
Generated logo for Omniverse Realtime Viewer

Omniverse Realtime Viewer

NVIDIAOfficialCreated by NVIDIA Omniverse

  • Skill
  • Tool integration
  • Software development
  • Apache-2.0
  • Medium risk

From the author

Use as the top-level router for Omniverse Realtime Viewer USD apps, XR delivery, SPG GPU processing, stylized rendering, and focused viewer reference documents.
— the description by NVIDIA Omniverse

AutoGineer summary

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

The Omniverse Realtime Viewer skill acts as a central routing and architectural framework for developing USD-based 3D viewer applications. It provides a structured approach to composing rendering, scene state, and delivery mechanisms, ensuring that developers can integrate OVRTX rendering, OVStage scene management, and various UI or streaming adapters effectively. The skill emphasizes a modular architecture where the viewer runtime, UI/input adapters, and delivery systems are decoupled, allowing for consistent behavior across local and streamed environments.

What it does

  • Provides a routing architecture for USD viewer apps, XR delivery, and GPU-accelerated rendering.
  • Defines the separation of concerns between viewer runtime, UI adapters, and delivery systems.
  • Offers guidance on integrating OVRTX for high-fidelity 3D rendering.
  • Establishes conventions for camera interaction, scene state management, and input handling.
  • Supports the implementation of specialized features like stylized rendering and CAE/CFD visualization.
  • Provides protocols for agent-to-UI communication and scene control.

When to use it

  • When starting the development of a new USD-based realtime viewer application.
  • When integrating advanced rendering features like stylized visualization or AOV switching.
  • When building XR or spatial editing capabilities into an existing Omniverse application.
  • When you need to standardize the architecture for local and streamed viewer deployments.
  • When implementing chat-driven scene control or agent-based inspection of a 3D scene.

Advantages

  • Promotes a clean, modular architecture that separates rendering logic from UI and transport.
  • Ensures consistent behavior across different delivery methods, such as local windows or WebRTC streaming.
  • Provides clear paths for extending functionality without disrupting the core viewer runtime.
  • Facilitates the integration of complex simulation and visualization data into the viewer.
  • Standardizes conventions for scene state, selection, and camera control.

Usage examples

“How do I set up a basic USD viewer application using the Omniverse Realtime Viewer architecture?”
The agent will guide you to start with the viewer app reference, resolve dependencies, and implement the core runtime owner to manage the OVStage and OVRTX renderer.
“I need to add stylized rendering to my existing viewer. Where should I start?”
The agent will direct you to the stylized visualization references to implement the required USD/Lua/CUDA nodes within your existing runtime owner.
“How can I enable an AI agent to control the viewer scene?”
The agent will point to the A2UI Scene Copilot reference to implement an operation interface that allows the agent to send commands through the existing runtime owner.
“How do I switch between different render outputs like beauty and depth in my viewer?”
The agent will explain how to use the AOV switching reference to map RenderVars and update the RenderProduct's orderedVars through the runtime owner.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/nvidia/omniverse-realtime-viewer/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip omniverse-realtime-viewer.zip -d .agents/skills

Documentation by NVIDIA Omniverse

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

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

Omniverse Realtime Viewer

Build responsive USD viewers by composing OVRTX rendering, OVStage scene state, and the delivery/UI libraries appropriate to the app. Use this package for viewer architecture and interaction; use each selected SDK's upstream guidance for installation and exact release-specific APIs.

Start With The App

  1. When delivery is explicit, select its recipe through references/routing.md and follow its current phase. Otherwise start with references/usd-viewer-app/README.md. For an existing app, keep its architecture and read only the references for the requested change. Broad app, conventions and UI catalogs are lookups as needed.

  2. Resolve the selected libraries through references/dependencies/README.md. Preserve the project's manifest unless an upgrade is requested.

  3. Build a working frame and camera interaction in the chosen shell, then add the requested capabilities. Read references/conventions.md for shared input, camera, selection, and protocol conventions.

  4. Use references/viewer-ux-workflow/README.md for broader interface design. Loading, selection feedback, errors, and input responsiveness belong in the first working app, alongside rendering.

  5. Validate the actual delivery path with references/validation.md. A browser screenshot does not validate a native window or a different transport.

Architecture

OwnerResponsibility
Viewer runtimeOwn the live OVStage, publication clock, OVRTX renderer, scene changes, and render stepping.
UI and input adapterDisplay frames and copied app state; send user intent to the runtime owner.
Storage/query/simulation workersPerform their assigned work and return results through the selected integration boundary.
Delivery adapterPresent locally or stream through ovstream; respect frame ownership and backpressure.

Use OVRTX for USD/3D rendering. Browser apps display its WebRTC video; local apps present its output through their native shell. A missing GPU means rendering is unverified, not a reason to substitute a browser 3D renderer.

Keep viewer cameras, settings, effects, and transient edits in app-owned session or runtime state so the source USD stays intact. Serialize scene mutation and render stepping through the runtime owner. Read references/ovstage-ovrtx-integration/README.md for that loop, then the population or data-plane references when implementing scene loading or attribute writes.

Keep expensive loading and metadata work off the UI and render threads. Keep transport details behind a delivery adapter so camera, selection, properties, and loading state can be reused across local and streamed shells.

Add Capabilities As Needed

Use references/routing.md to select camera/picking, scene management, render settings, cloud assets, simulation, editor tools, deployment, or CAE/CFD visualization. Read the selected capability's implementation flow and its linked contract; the full reference catalog is not a prerequisite for a first frame.

For simulation, use the routing reference's Simulation Ecosystem section plus references/realtime-sim-integration/README.md. For UI-driven forces or control, add references/interaction-round-trip/README.md.

For example scenes, use references/usd-sample-data/README.md. When a runtime failure needs diagnosis, use references/troubleshooting/README.md and the selected SDK's matching release guidance before changing the architecture.

Solid Modeling: Upstream First

For usd-brep, exact BRep, solid modeling, kernel failures, CAD topology, or BrepArray questions, first read references/dependencies/README.md → USD BRep. Follow the owning repository's current agent guidance, skills, operation docs, and package API before selecting local integration references. Discover the upstream router rather than assuming skill names or directory layouts remain fixed. Upstream owns modeling semantics, schema rules, tuning, and diagnostics; this package owns OVRTX display, worker handoff, selection mapping, and publication timing.

GPU Processing And Stylized Viewers

For custom GPU processing, chained outputs and lens sampling, read references/spg-processing/README.md. For toon, ink, technical/X-Ray styles, geometry strokes or full wireframe, continue to references/stylized-visualization/implementation.md. Its USD/Lua/CUDA starting node and geometry/depth/composite build sequence work with the selected viewer recipe; use references/stylized-visualization/style-recipes.md for the preset math and references/stylized-visualization/README.md for supporting contracts. Implement the result inside the existing OVRTX/runtime owner and deliver the published processed output. These instructions do not require a sample checkout or a prior stylized-rendering implementation.

For an optional usd-brep geometry source, first read references/dependencies/README.md → USD BRep and the owning repository's current agent guidance, skills, and operation docs; then read references/stylized-visualization/usd-brep-source.md for the display boundary.

XR Viewers

For headsets, immersive viewers, or spatial editors, start with references/xr-viewer-recipe/README.md. Resolve SDK setup and contracts through references/dependencies/ovxr.md; the library owns OpenXR lifecycle and frame submission. For controllers, hands, navigation, or scene tools, add references/xr-spatial-input/README.md and references/ovxr-python-interactions/README.md. For projection-integrated UI, read references/ovxr-composition-ui/README.md and references/ovxr-composition-ui-validation/README.md.

Files

references/dependencies/nvidia-runtime.md

NVIDIA Runtime Dependencies

Use this reference to find the libraries selected for the viewer. Package metadata and the corresponding upstream release guidance own compatibility and installation; the viewer references own application integration.

Select A Compatible Set

For an existing app, start from its manifest/lockfile. For a new app or requested upgrade, resolve the current public supported package set for its OS, architecture, Python/native runtime and delivery path from upstream release and package metadata. Do not select an older cohort just because its examples are easier; report an unavailable or incompatible current set rather than silently downgrading. Resolve OVRTX and OVStage together. Add UI, transport, storage, or simulation packages only when the app uses them.

Check the selected release's metadata, migration notes, and relevant upstream examples before implementation. Record resolved versions in the generated app's manifest. A successful import or experimental ABI probe does not establish a vendor-supported combination.

Package And Documentation Sources

LibraryPackage sourceUpstream guidance
OVRTXPyPIOVRTX: renderer configuration, outputs, picking, native API, release notes
OVStagePyPIOVStage: population, schemas, data plane, publication, attachment
ovstreamPyPIovstream: server/client skills, native artifacts, frame submission, examples
ovuiPyPIovui: supported Python/platforms, companion packages, widgets and presentation
ovstoragePyPIovstorage: AGENTS.md, skills, storage adapters, authentication, resolver/cache integration
OVPhysXPyPIOVPhysX: supported OVStage pair, schemas, attachment, simulation and tensor APIs
ovnewtonPyPISelected wheel's metadata and examples: bridge compatibility, lifecycle and output types
NewtonPyPINewton and documentation: model building, importers, solvers and its agent skills
OVXRPyPI for Python; matching native SDK through ovxr.mdOVXR: README, library skills, release manifest, headers, bindings and minimal examples
CloudXR runtime SDKSeparately supplied runtime SDKCloudXR: service hosting and opaque-channel contracts; see ovxr.md for the runtime-adapter route
Warpwarp-lang Python packageWarp: arrays, CUDA streams, DLPack and kernels

Use the upstream guidance matching the package being installed. Read its agent instructions and relevant skills when available; fetch only the API/build detail needed for the chosen integration. Reuse a known matching local checkout rather than cloning the same dependency for every feature.

OVRTX And OVStage

Create the renderer and attached stage with a compatible release pair and register required schemas before population. Follow references/ovstage-ovrtx-integration/README.md for the viewer-owned loop and references/ovstage-population/README.md for loading and schema handling.

For native apps, match headers and libraries to the selected SDK. Keep USD metadata/query workers isolated unless the selected in-process OpenUSD import path is supported; choose the worker's USD package from its own requirements.

For an existing OVRTX application upgrade, discover the selected release's upstream migration skills, including the 0.5-to-0.6 source/data upgrade guide when that transition applies. Use the matching tag/package guidance and its linked OVStage contracts; upstream owns callback ABI, sensor, and raw-data migrations. Review renderer-setting changes separately.

ovstream

Use the selected release's Python installation path for Python producers and its native SDK for C/C++/Rust consumers. Build native readers against matching headers and runtime libraries. Refer to ovstream.md for the viewer's transport and frame ownership contract; upstream owns packaging and loader setup.

ov-web-rtc client

For a browser connected directly to a standalone ovstream server, use @nvidia/ov-web-rtc and the compatible client version identified by the upstream WebRTC client example. Use the package's supported registry configuration:

registry=https://registry.npmjs.org/
@nvidia:registry=https://edge.urm.nvidia.com/artifactory/api/npm/omniverse-client-npm/

Resolve and lock the client dependency in the generated app. After orchestration provides an endpoint, the client uses the standalone server's Direct connection configuration. For NVCF self-hosted deployment, read references/cloud-deployment/nvcf-self-hosted.md before selecting the connection model.

ovui

Choose the Python interpreter and companion UI packages from the selected ovui release's supported platform set before creating the environment. If no matching wheel is available, check Python, OS, architecture, and companion package requirements before changing application UI code. Follow local-openusd-gpu.md and the chosen native delivery reference for viewer integration.

For a new app, begin at the upstream ovui repository. Read its current AGENTS.md and discover the application, widget, UI API, and styling skills it routes to. Consult the latest public release and package metadata to resolve a supported set for the chosen platform. Use documentation matching that resolved set when implementing; development-branch APIs may not be present in published packages.

Resolve the UI, widget, and adapter distributions as one compatible set using upstream dependency constraints. Check current public package indexes and release assets for availability. Record the resolved set in the generated app's manifest and verify it with python -m pip check.

The application and provider packages currently use ovui-widgets-* and ovui-data-adapters-* distribution names, with ovui_widgets and ovui_data_adapters Python namespaces; core UI imports use omni.ui and omni.ui_scene. Confirm names, extras, supported interpreters, and provider requirements in current upstream metadata before installing. For an OpenUSD editor, use the provider's supported OpenUSD runtime and choose its standalone extra only when that runtime is not already supplied. Resolve OVRTX compatibility from that provider's contract. Resolve the native OVStage provider's runtime cohort separately; support for one provider does not establish the other's ABI compatibility. Follow the selected provider's bootstrap and import order.

Discover bundled agent guidance through the installed package's documented skill entry points when available. Before adding panels or editing features, run the upstream minimal application with a real USD scene and capture a nonblank OVRTX frame through the intended delivery path.

For native C++ UI integration, discover the selected package's SDK contents, build manifests, and CMake exports through the upstream native SDK documentation. Confirm header/library identity, compiler and Python development requirements, and ImGui ABI before linking. Preserve the documented package layout. Continue using the OVRTX SDK for USD rendering and the viewer runtime for stage ownership.

ovstorage

Follow its upstream AGENTS.md and selected storage skills for connection, authentication, plugins, resolver behavior, and transfers. The viewer-side contract is in references/cloud-assets/README.md: background preparation, cache identity/freshness, progress, and handoff to the runtime owner. Storage provider installation and SDK source builds belong to their upstream projects.

ovxr

Begin at NVIDIA-Omniverse/ovxr and follow the OVXR library route for its current README, skill index, release artifacts, examples and manifest. Resolve OVXR together with its matching OVRTX and OVStage packages. Use matching distributed headers, bindings and native artifacts, record build identity, and prove native, runtime and client readiness separately. For Python, use the public ovxr PyPI package and honor its declared OVRTX/OVStage requirements instead of upgrading those libraries independently. Select supported Python/platform tags from the current wheel metadata. CloudXR is a separately licensed OpenXR runtime.

ovphysx

Read the selected release's upstream AGENTS.md, SKILLS.md, and basic workflow. For Python first-run setup, install both physx-usd-schemas and newton-usd-schemas from public PyPI alongside OVPhysX, as required by the upstream basic workflow:

python -m pip install ovphysx physx-usd-schemas newton-usd-schemas

The OVPhysX wheel and SDK do not bundle these schema resources. Follow upstream Physics Schemas for metadata-based resource discovery, native provisioning, and registration of both PhysX and deformable resource directories before the first population or export. Avoid importing the provider's stock-USD bindings in the viewer process. The upstream hello_world sample always calls ovphysx.newton_schema_root(), so it needs the Newton provider even when the application scene has no newton:* attributes. After resolving the compatible package set, run:

python -m ovphysx.samples.python_samples.hello_world

Require successful simulation stepping and cleanup. For application code, include Newton resources in the same registration call when the scene authors newton:*; installing the provider alone does not register it. Record the resolved provider versions with the app's runtime packages; resource discovery alone does not establish semantic compatibility.

For an existing application, inspect the selected release's migration guide before reusing lifecycle, session, configuration, or joint-authoring code. Rebuild native consumers against the matching headers and SDK.

Resolve OVPhysX against its declared OVStage requirements. For in-process shared stages, confirm the supported attachment and schema initialization sequence from the selected release before attaching either consumer. If the required package sets cannot share a process, use the explicit worker architecture in references/physics-simulation/README.md, with independent environments and copied pose/state messages. An ABI error is a compatibility problem to diagnose, not a reason to guess another population API in the renderer process.

ovnewton and Newton

Newton owns simulation; ovnewton bridges model state into OVStage. Begin with its current support guide and using-ovnewton skill, then use the selected wheel's metadata and bundled examples. Resolve the bridge's OVStage requirement and the examples' OVRTX requirements together with the app's other consumers. Include the selected example's extras, schema providers, and assets; account for USD dependencies introduced by optional Newton importers when choosing process boundaries.

Recheck public releases before declaring the bridge unavailable for a runtime cohort. If no compatible set exists, keep simulation controls unavailable and explain the missing bridge; do not bypass requirements with --no-deps or widen them locally. A thread does not isolate native dependencies. A worker with a copied-state adapter needs its own implementation and validation.

Run the selected release's bounded simulation example, then validate an OVRTX frame and the intended viewer interactions separately. Package compatibility or a CPU-only simulation does not qualify GPU, viewer, or XR behavior. Use references/newton-physics/README.md and references/realtime-sim-integration/README.md for the viewer-owned simulation clock, publication, and interaction path.

Warp and CUDA compatibility

Resolve two separate constraints: the packages must accept each other's versions, and each GPU library build must support the host GPU and NVIDIA driver. A successful dependency resolution or import establishes neither GPU execution nor cross-library interoperability.

Distinguish the host driver, a locally installed CUDA Toolkit, and the CUDA runtime/toolkit used to build each wheel or SDK. The CUDA version displayed by nvidia-smi describes driver capability; it does not identify the installed Toolkit or the build used by Warp. Prebuilt GPU packages can bring their own runtime libraries, so installing another local Toolkit does not repair an unsupported wheel/driver combination. Follow each selected library's upstream compatibility requirements; matching every CUDA version string is not a policy.

Select a Warp build compatible with the GPU and driver as well as every selected package's declared version constraints. The default PyPI build can require a newer CUDA driver than OVPhysX itself. Use the selected Warp release's compatibility guidance for supported CUDA builds. Resolve optional extras and test tools with the app's constraints; do not bypass incompatible bounds or add another USD runtime to the viewer process. Record package/build identities and the driver in app evidence.

Verify CUDA device discovery, an allocation and small kernel with synchronization, then the app's actual consumer path, such as physics reads or streaming buffer conversion. Keep readiness evidence for renderer, simulation, and transport separate. A passing CPU simulation or successful import does not validate GPU execution, and a Warp kernel alone does not validate shared buffers or streams.

Verify Setup

Run the selected upstream minimal example, then render a real frame through the app's intended delivery path before adding features. Capture exact versions and build identities in the app's validation evidence. See environment-validation.md for environment checks and diagnostics.

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: Orchestrator skill. Downstream focused references may require NVIDIA GPUs, ovrtx, ovstream, ovui, OpenUSD, Python, Node/React, Tauri, Electron, C++, or cloud GPU deployment access depending on the selected viewer path.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs
  • Instructions that use the network

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-realtime-viewer · 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-realtime-viewer.zip