i
DATAIST
News · 2026-08-31

Nvidia unbundles Omniverse into three embeddable libraries

@neuronium_ai @neuronium_ai

Nvidia has taken Omniverse apart. At GTC 2026 the company put three of the platform's core components — RTX rendering, PhysX simulation and data storage pipelines — into standalone C libraries with C++ and Python bindings, named ovrtx, ovphysx and ovstorage. They are in early access now on GitHub and NGC, with a production release carrying a stable API and long-term support planned for later this year. The practical effect is that a robotics or CAD team no longer has to adopt the full containerized Omniverse runtime to put physically accurate simulation inside its own product.

Cover: Nvidia unbundles Omniverse into three embeddable libraries

Nvidia has taken Omniverse apart. At GTC 2026 the company put three of the platform's core components — RTX rendering, PhysX simulation and data storage pipelines — into standalone C libraries with C++ and Python bindings, named ovrtx, ovphysx and ovstorage. They are in early access now on GitHub and NGC, with a production release carrying a stable API and long-term support planned for later this year. The practical effect is that a robotics or CAD team no longer has to adopt the full containerized Omniverse runtime to put physically accurate simulation inside its own product.

Physical AI is Nvidia's term for systems that perceive an environment, reason about it and act inside physically plausible simulation — the loop that lets a robot or an industrial line be designed and checked before anything is built on the factory floor. Nvidia named it one of the key directions for robotics and digital twins at this GTC, and the mechanism it is selling is policy training in environments that account for the physical properties of objects.

The constraint being addressed here is mundane and real. In large robotics and industrial projects, monolithic environments make it hard to scale simulations out, to run without a graphical interface, and to sit inside continuous integration and delivery systems. The libraries let a team call Omniverse APIs from inside its own processes rather than hosting everything in a single runtime, and they still reach the existing pieces: OpenUSD scene description, SimReady assets prepared for simulation, and the Omniverse Kit Framework.

Nvidia Omniverse modular libraries let developers integrate real-time digital twin capabilities into existing applications

Nvidia Omniverse modular libraries let developers integrate real-time digital twin capabilities into existing applications

Source: developer.nvidia.com

The strongest evidence that this is more than repackaging is that Nvidia rebuilt its own framework on it. Isaac Lab, the high-performance environment for robotics simulation and reinforcement learning, moved its base layer off monolithic Kit and onto a modular architecture of several subsystems in Isaac Lab 3.0 Beta. General availability is set for the end of this year. With the platform service layer removed, the framework can use tensorized data exchange and read simulation state straight out of GPU buffers — positions and velocities arrive as PyTorch tensors with no copy back to the host. For anyone running reinforcement learning at scale, that single change is the whole argument.

Nvidia is also using the libraries internally for the next generation of its physical AI toolkits and development tools, validating them first on high-performance internal computing systems and industrial deployments before the general release.

Six software companies are attached to the announcement: ABB Robotics, Adobe, Cadence, PTC, Siemens and Synopsys, all drawn by the same capability — core RTX rendering, physically accurate PhysX and built-in OpenUSD support without rebuilding their software architecture. Three of them have a described integration. ABB Robotics is embedding Omniverse into RobotStudio alongside its industry-proven virtual controller, offline programming tools and commissioning workflows, to train and validate industrial robots at scale. PTC connects Onshape directly to Isaac Sim for designing, testing and deploying robots in the cloud. Siemens is wiring in the libraries to build industrial digital twins at scale. Adobe, Cadence and Synopsys appear as names against a generic capability statement — which is the usual shape of a list assembled to look like momentum.

ovrtx and ovphysx do not depend on the Omniverse Kit runtime at all. Both ship thin Python bindings over the C API. DLPack support means zero-copy data exchange with NumPy, PyTorch and Warp.

ovrtx gives lightweight access to hardware-accelerated RTX rendering: load a scene, render a frame, write it to PNG with NumPy, in ten lines of code. Its Python bindings go through ctypes and need no dependency beyond the C library itself, on Python 3.10 or newer.

The rendered robot.usda scene saved as a PNG

The rendered robot.usda scene saved as a PNG

Source: developer.nvidia.com

ovphysx handles the other half, binding the PhysX core SDK to USD environments and tensor data. Running a physics simulation takes five asynchronous steps through the base API. Both repositories are on GitHub.

ovstorage is the least glamorous and probably the most consequential. It acts as a single storage layer, connecting PLM systems and existing repositories to the Omniverse ecosystem through one API — which removes the separate synchronization jobs and expensive data migrations that normally gate this kind of adoption, and lets USD workflows run without moving files. It is built for headless deployment on Kubernetes, with microservices that scale independently. Nvidia calls the current feature set an initial one and says it will expand; materials are on NGC.

An example ovstorage implementation architecture

An example ovstorage implementation architecture

Source: developer.nvidia.com

There is a second track here aimed at agents rather than engineers. Omniverse now exposes its capabilities through Model Context Protocol servers that describe operations in a machine-readable schema — loading USD scenes, editing primitives, stepping the simulation forward — so tools like Claude and Cursor can call them safely. Each MCP server runs locally via Docker or Python, and Nvidia documents USD Code MCP, Kit MCP and OmniUI MCP separately. Embedding and reranking run as cloud-hosted Nvidia services reached by API key, with no local GPU required. Scaling this is handed to NemoClaw, a new infrastructure stack for the OpenClaw community, built to run secure always-on autonomous agents in isolated sandboxes under policy-based limits. Because the MCP servers absorb the low-level remote procedure calls into Omniverse, a developer describes agent behavior and safety rules instead of wiring up every simulation API call by hand.

The more interesting question is what the library split says about the past several years of Omniverse. Nvidia sold it as a place to work: a runtime, a container, an environment you moved into. The pitch now is the inverse — keep your architecture, take the three pieces you want. That reads like an acknowledgement that industrial software vendors were never going to rebuild around someone else's platform, and that the parts Nvidia genuinely owns, RTX and PhysX, are worth more distributed than bundled. Kit stays on the menu for teams building entirely new, feature-heavy applications; the standalone libraries are for everyone with working code and no appetite to rewrite it.

A decision guide for choosing between the Omniverse libraries and the Omniverse Kit Framework

A decision guide for choosing between the Omniverse libraries and the Omniverse Kit Framework

Source: developer.nvidia.com

Notably absent from the announcement is anything about pricing or licensing for the libraries, and any commitment to API stability before the production release. Nvidia states plainly that the APIs may change between versions and that it will publish migration instructions and collect feedback on GitHub and the Omniverse Discord. That is the honest thing to say during early access. It is also the thing that keeps a cautious engineering manager from shipping on them this quarter, which makes the later-this-year production release the real launch and this one a call for testers.

What Nvidia is actually distributing is the dependency. A team that calls ovrtx from its own renderer, or pulls PhysX state directly into PyTorch without a copy, has not adopted a platform — it has written a GPU requirement into the layer of its stack it is least likely to ever touch again.