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/troubleshooting/README.md

Troubleshooting

Triggers

Use this skill for troubleshoot, debug Omniverse Realtime Viewer, server won't start, no video, data channel not working, wrong colors, black frame, scene won't load, camera doesn't move, picking broken, or WebRTC internals.

Use this when an Omniverse Realtime Viewer fails during startup, streaming, scene loading, rendering, input, selection, or UI state sync. Start by classifying the first broken boundary instead of chasing downstream symptoms.

Triage Flowchart

Server process does not start
  -> Server startup diagnostics
Server starts but browser cannot connect
  -> WebRTC signaling and port diagnostics
Browser connects but video is blank or frozen
  -> Video streaming and renderer step diagnostics
Embedded host hides media capabilities or connection does not decode a frame
  -> Embedded-host H264 preflight and decoded-frame diagnostics
Electron SHM viewer opens but viewport is black, disconnected, or stutters
  -> Electron SHM Viewer diagnostics
Tauri or desktop WebView drag loses release, sticks, or selects after a drag
  -> Desktop WebView Pointer Lifecycle in viewer-input-routing
Video streams but colors/materials/frame are wrong
  -> Render var, BGRA conversion, camera, MDL diagnostics
UI connects but buttons/tree/settings do nothing
  -> Data-channel diagnostics
Stage open fails or loads as empty
  -> Scene loading and asset path diagnostics
Scene loads but camera does not move
  -> Input callback and live camera write diagnostics
Camera works but click selection is wrong or empty
  -> Picking, coordinate, and segmentation diagnostics
Selection works but highlight/info/tree is stale
  -> Derived state reset and message routing diagnostics
Physics or runtime transforms crash, no-op, or desynchronize
  -> OVStage/OVPhysX boundary diagnostics
Scene switch crashes or hangs
  -> Renderer ownership and stage reset diagnostics

Fast Rules

  • Debug one boundary at a time: process startup, WebRTC connection, rendered frame, JSON message, USD query, then feature state.

  • Keep one render thread as the owner of renderer.step(), reset_stage(), open_usd(), open_usd_from_string(), reference mutation, native pick queries, selection outline writes, and live write_attribute() calls.

  • In OVStage-backed apps, the parent viewer runtime also owns stage lifetime, ordinals, write floors, renderer attachment, and publication.

  • Keep pxr queries and OVPhysX USD population in workers unless the exact ABI/import path is verified. A failed PhysX.attach_ovstage(stage, read_ordinal=...) bridge must not fall back to parent-process OVPhysX population.

  • In WebRTC streaming apps, mouse, wheel, keyboard, and touch input normally arrive through NVST/ovstream InputEvent callbacks; app state commands use the JSON data channel. If the data channel works but an explicit viewport test produces no native callback, use the documented mutually exclusive browser mouseInput fallback.

  • A frontend "loading forever" state is usually either a missing openStageResult, a missed proactive state push, or a message-name mismatch.

  • For an Electron app with a Python sidecar on Windows, first run the App-Local Desktop Preflight in windows-native-setup; then diagnose the process and SHM lifecycle through electron-shm-viewer.

  • A local Omniverse Realtime Viewer skips WebRTC entirely. If the same renderer and scene code works locally but not in a browser, focus on ovstream, frame conversion, and the standalone ovstream Direct AppStreamer config.

Scenario Playbooks

Detailed startup, streaming, scene, input, selection, hierarchy, and recovery playbooks live in scenario-playbooks.md.

Common Error Map

Message or symptomActual causeUsual fix
ModuleNotFoundError: ovstreamPython binding missing or native lib path missingInstall ovstream and set OVSTREAM_LIB_PATH
CRenderApi not foundovrtx plugin tree not resolvedSet OVRTX_BIN_PATH and plugin library path
usd-core detectedovrtx USD check found another USD packageSet OVRTX_SKIP_USD_CHECK=1 before ovrtx work
multiple debug symbol definitions for SDF_ASSETTwo USD registries loadedPut ovrtx bundled libs first or split pxr into worker
_tf import failureUSD DLL/shared library conflictFix import order or use subprocess queries
Duplicate USD registry, TfType::AddAlias, or repeated USD plugin/type aliasespxr/usd-core or another USD-populating runtime loaded beside OVRTXMove OpenUSD queries or physics USD population behind a process boundary
Default.mdl parse crashRenderer initialized after wrong USD registryFix import/construction order
PhysX.attach_ovstage(stage, read_ordinal=...) reports missing ovstage_register_consumer, ovstage_register_output_buffer, ovstage_publish, ovstage_query_changes, ovstage_read_attribute, or ovstage_write_attributeOVPhysX was built against OVStage bridge symbols unavailable in the installed OVStage wheelUse the bounded OVPhysX worker path and report the ABI mismatch
Native crash after parent-process OVPhysX populationCompeting USD population entered the process that owns OVRTX/OVStageMove OVPhysX population to a child worker and hand poses back as JSON
Magenta materialsMDL resolver path missingSet OVRTX_BIN_PATH and library path
Unable to find RenderProduct primInline/session render path missing or mismatchedCreate the render pipeline and pass the exact path
Black frame, no exceptionCamera, RenderProduct, resolution, or RenderVar invalidValidate stage-loading data and camera relation
USD parse error near RenderVar inline bracesovrtx parser rejected one-line def RenderVar "X" { ... } syntaxUse multi-line RenderVar definitions from stage-loading
RenderProductSetOutputs has no attribute getrenderer.step() output was treated as a dictUse membership checks and products[render_product_path], then map individual RenderVars
Invalid output handleRenderer-backed output was retained past its valid lifetimeReturn owned buffers copied inside each RenderVar map context
First renderer.step() exceeds normal test timeoutCold RTX shader or pipeline compilationUse a 300s+ first-run timeout and inspect ovrtx logs
Red/blue swappedRGBA submitted as BGRAConvert ovrtx LdrColor before ovstream
Scene renders but appears sidewaysCamera fit, orbit, or pan hard-coded Y-up for a Z-up stageQuery UsdGeom.GetStageUpAxis in the metadata worker, set the server camera's world_up, refit, and keep the source USD unchanged
Stage load reports success but first frame failsload operation status or RenderProduct path was not checkedwait/check load status, then step the exact RenderProduct
TypeError: a coroutine was expected from ui.runovui run loop received a callback/function instead of an awaitablePass an async render loop coroutine and yield with await asyncio.sleep(1.0 / 120.0)
VIEWPORT_CAMERA_POSE_SOURCE import failurestale data adapters installed with newer local UI packagesInstall local UI packages from the same package set
ovui widget/adapter dependency resolution failsfirst-party versions differ or an obsolete umbrella package was requestedResolve matching ovui-widgets-* and ovui-data-adapters-* distributions through references/dependencies
Native UI package requires a compiler toolchainpackage/build instructions require local toolsFollow the current ovui dependency guidance
Previous session is already runningOld WebRTC client/session still activeClose old tab, reduce reconnect storm, restart server if stuck
Could not get encoded frame with black videoDirect client codec default was unknown or unsupportedSet explicit codec: 'H264' and codecList: ['H264'] in DirectConfig
Embedded host lacks navigator.mediaCapabilitiesHost frame does not expose the optional capability APIRecord iframe/preflight state, retain explicit H264 config, and require decoded-frame validation; do not reject H264 from API absence alone
connect() resolves but no decoded video frameStartup progress was mistaken for media proofCheck video readyState, decoded-frame counter/currentTime, WebRTC internals, and host-frame policy
Connects then disconnects in 1-2 seconds before messages arriveServer did not stream fallback/idle frames while waiting for a stage commandStream a valid fallback or last-good BGRA frame every connected tick
Initial app messages never reach the serverFrontend confused startup progress, command readiness, and scene-frame readinessFollow client readiness; send after confirmed start success, then prove decoded frames
Keyboard/data-channel controls work but mouse drag, button, and wheel produce no server on_input eventsNative browser input forwarding is unavailable in this host/embedVerify viewport ownership and callback logs, then enable only the mutually exclusive mouseInput fallback in viewer-input-routing; do not process native and fallback events together
NVST_R_INVALID_OPERATION on second Server.start()ovstream.shutdown() ran in a same-process stop pathUse server.stop() and server.close() for restarts; reserve ovstream.shutdown() for process exit
Server sees messageType but no event_typeAppStreamer envelope not unwrappedParse nested data payload before dispatch
POST /sign_in returns HTTP 501For a standalone ovstream Direct deployment, frontend used a connection profile intended for a different streaming product or injected auth/session fieldsRebuild the frontend from streaming-client using @nvidia/ov-web-rtc Direct mode with only the exposed server and signalingPort
UI waits on getChildrenResponseProtocol name mismatchUse active getChildrenResult route
Picks return old primspending pick/selectable state survived scene reloadclear pick state and refresh native pickability
Highlight visible on loadnative selection outline groups not clearedwrite group 0 for stale selected paths and clear runtime selection
Textures missing only after compositioncache path or sublayer path broke relative referencespreserve cache layout and quote the original asset path correctly

Streaming And Local Omniverse Realtime Viewer Paths

Streaming path:

  • Use streaming-server for ovstream lifecycle, ports, input callbacks, and frame submission.

  • Use streaming-client for standalone ovstream Direct config, video element setup, browser diagnostics, and guarded sends.

  • Use streaming-lifecycle when the connection exists but state, messages, or reconnects are wrong.

  • Use streaming-messages to verify exact JSON event names and payload shapes.

Local Omniverse Realtime Viewer path:

  • Use local-viewer for ovui shell, image display, UI-thread rules, and coordinate mapping.

  • Use ovrtx-rendering for renderer construction, frame extraction, and live attribute writes.

  • Use stage-loading for render prim injection and RenderProduct failures.

  • Use viewer-input-routing, camera-controls, object-selection, stage-hierarchy, and prim-info-display for feature-specific debugging once the frame renders correctly.

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