Omniverse Physics Developer Guide#

Introduction#

Omniverse is NVIDIA’s developer platform for 3D applications and services. Simulation is a fundamental pillar of Omniverse, and this simulation is provided by Omniverse Physics: the topic of this guide. This guide is designed for the developers of these applications and services. Power users of Omniverse applications may also benefit from the knowledge in this documentation depending on how deeply they engage with this open platform.

Because Omniverse is a flexible and powerful technology, there are also a number of foundational technologies for you to be familiar with to better understand how Physics fits with the rest of the system. While each key Omniverse component has its own developer documentation, we will provide an overview here for physics users, highlighting important topics, and providing further references.

Omniverse Simulation Architecture Overview#

The lowest level technical foundation of Omniverse is called Carbonite. Carbonite is a system to build modular executables made out of plugins and provides common cross platform services like threading or memory allocation. Carbonite plugins can be implemented in C/C++ native code and have a C API.

Omniverse Kit is an SDK on top of Carbonite that provides essential capabilities common to most applications and services. Carbonite and Kit provide the platform with Python execution capability. Kit also extends the idea of Carbonite Plugins with additional capability, which are called Kit Extensions. You are encouraged to create Extensions.

Extensions can contain a mix of native and interpreted code, and they define an interface of functions that other extensions are able to invoke. This creates dependencies between extensions. The metadata about extensions is contained in a TOML file and the high level code of extensions is typically written in Python.

Because Extensions are developed independently, a key consideration is that extensions at different versions can still reliably depend on one another. For this reason ABI compatibility of Plugins and Extensions is a critical topic found in the Carbonite documentation.

OpenUSD, a technology for describing and collaboratively authoring 3D worlds, is a key technology included with Omniverse Kit. The state of the world that Omniverse operates on is intended to be stored in USD, both when offline and during authoring and simulation. USD is therefore an on-disk format, a runtime C++ API, and Python bindings that allow you to manipulate the world database. OpenUSD also includes a system called Hydra that connects the USD database to a renderer, such as the RTX renderer integrated with Kit. OpenUSD in its full generality is not very efficient for use in high performance interactive applications. For this reason Kit includes a USD runtime cache called Fabric that stores a subset of USD data in memory that can be manipulated much faster before being written back to USD.

OpenUSD can be extended with collections of new user-defined data types created using the USD schema, which is a data definition language. Having a schema permits automatic generation of the aforementioned C++ and Python code to manipulate the data. USD Physics or the Physics schema is now the standard extension of USD for rigid body dynamics. There are more standard extensions planned, including one for deformable body physics. There are also NVIDIA-proprietary USD extensions called ‘PhysX schema’ for all simulation features supported by Omniverse.

The bundle of extensions responsible for much of the standard simulation capability in Omniverse is called omni.physx. It is called PhysX because it is a wrapper around the NVIDIA PhysX SDK, the primary simulation engine in Omniverse. The PhysX SDK is also available separately from Omniverse on GitHub.

Omni.physx is responsible for parsing data out of USD and Fabric, writing this data into PhysX, running the simulation, and writing the simulation outputs back into USD or Fabric. It can also listen for USD state changes and update a running simulation.

Physics Developer Guide Structure#

We start this guide with the Simulation Setup section that explains how you can use USD Physics to mark up a USD stage with physical quantities and objects for simulation. While we do have both automated and interactive tools to do this, this developer guide will focus on the programmatic approach for developers. Visual authoring of USD is then covered in the section “Visual Authoring and Debugging”.

Creating and operating stable simulations is often inherently difficult and benefits a great deal from experience. The Hints and FAQs section tries to convey some of this experience.

The Physics Extensions section details different simulation related extensions and the Schemas section goes into detail about the different simulation relevant USD schemas.