Omniverse Kit

Omniverse Kit is the SDK for building Omniverse applications like Create and View. It can also be used to develop your own Omniverse applications.

It brings together a few major components:

  • USD/Hydra (see also omni.usd)

  • Omniverse (via Omniverse client library)

  • Carbonite

  • Omniverse RTX Renderer

  • Scripting

  • a UI Toolkit (omni.ui)

As a developer you can use any combination of those to build your own application or just extend or modify what’s already there.


USD is the primary Scene Description used by Kit, both for in-memory/authoring/runtime use, and as the serialisation format.

USD can be accessed directly via an external shared library. If your plugin uses USD through C++ it must link to this library. You can also use USD from python using USD’s own python bindings, which cover the whole USD API (but not all of it’s dependencies like Tf, SDF etc). We generated reference documentation for it, see pxr package.

Hydra allows USD to stream it’s content to any Renderer which has a Hydra Scene Delegate - these include Pixar’s HDStorm (currently shipped with the USD package shipped as part of Kit) as well as the Omniverse RTX Renderer and IRay (both of which ship with Kit)


Omni.USD (See :doc: `../source/extensions/omni.usd/docs/`for API docs) is an API written in C++ which sits on top of USD, Kit’s core, and the OmniClient library, and provides application-related services such as: - Events/Listeners - Selection handling - Access to the Omniverse USD Audio subsystem - Access to the Omniverse Client Library, and handling of Omniverse Assets/URIs - USD Layer handling - A USDContext which provides convenient access to the main USDStage and it’s layers, as well as various Hydra, Renderer and Viewport related services - MDL support - Python bindings to all of the above, using Python 3 async API in most cases

Omniverse Client Library

This is the library that Omniverse clients such as Kit use to communicate with both Omniverse servers and with local filesystems when loading and saving Assets (such as USD, MDL and textures). It contains: - a USD AssetResolver for parsing omniverse:// URIs - some SDF FileFormat plugins to support specialised use cases, including Omniverse’s Live Edit mode - an API for read/write/copy of data/files and filesystem-like queries on Omniverse Nucleus servers - Support for managing connections with Omniverse servers - Python bindings to all of the above, using Python 3 async API in most cases


The Carbonite SDK provides the core functionality of all Omniverse apps. This is a C++ based SDK that provides features such as plugin management, input, file access, persistent settings management, audio, asset loading and management, thread and task management, image loading, localization, synchronization, and basic windowing. All of this is provided with a single platform independent API.


Carbonite Plugins are basically shared libraries with C-style interfaces, which can be dynamically loaded and unloaded. Interfaces are semantically versioned and backward compatibility is supported. More details on that can be found in the Carbonite documentation. Extending Kit is C++ means writing your own Carbonite plugin. That allows you to use Carbonite Framework to access all other interfaces. Plugin is a crucial low-level building block.

Most plugin interfaces have python bindings, i.e they are accessible from python. The pybind11 library is used. For your own plugins you can also write python bindings and make them directly accessible from python.

Omniverse RTX Renderer

As mentioned above, Pixar’s Hydra is used to interface between USD and RTX. This is an area of high architectural complexity, as Kit is required to support a large number of Renderers, multiple custom Scene delegates, multiple Hydra Engines (to support GL, Vulkan, DX12) and a host of other requirements, providing a Viewport inside Kit Applications with Gizmos and other controls, all rendering asynchronously at high frame rates


Kit comes with a version of python (currently 3.6) . You can run arbitrary python scripts in Kit based apps which can:

  • access all plugins exposed via python bindings

  • access the USD python API

  • access Kit python-only modules

  • load and access your C++ Carbonite plugins

Currently there are 3 ways to run scripts:

  • at app startup time by passing cmd arguments. E.g.: kit.exe --exec "some_script.py"

  • using the Console window

  • using the Script Editor Window


Building on top of scripting and Carbonite Plugins there is the highest-level and probably most crucial building block: Kit Extensions. You can think of Extensions as versioned packages with runtime enable/disable state.


Omni.ui, our UI framework, is built on top of Dear Imgui.) and written in C++, but exposes only a Python API.