Architecture

Kit is a platform for building applications and experiences. They may or may not have much in common. Some of these may use RTX, omni.ui or other libraries to create rich applications, others may be cut-down windowless services (e.g one to process USD files offline for example). To achieve this goal, Kit aims to be extremely modular: everything is an extension.

Extensions

An Extension is a uniquely named and versioned package loaded at runtime. It can have any or all of the following properties:

  1. Contain python code.

  2. Contain shared libraries and/or Carbonite plugins.

  3. Provide a C++ API

  4. Provide a python API .

  5. Depend on other extensions

  6. Be reloadable (can be unloaded, changed and loaded again at runtime).

It is the basic building block of Kit-based Applications like Create. More info in the Extensions part of the guide.

omni.kit.app (omni::kit::IApp)

omni.kit.app is the basic interface used by Create and other Kit-based applications, and provides a minimal set of Carbonite plugins to load and set up extensions. It is the core which holds everything together.

C++: omni::kit::IApp python: omni.kit.app module

It contains:

  • Carbonite framework startup

  • Extension manager

  • Event system

  • Update loop

  • Settings

  • Python context / runtime (edited)

It can run from both executable (kit.exe) or from python.

Configuration

Kit has a default config located in config/kit-core.json relative to the Kit executable. That config contains some internal predefined settings of Kit itself and is not expected to be changed by the user. The User can specify an experience config, which is applied on top of it:

kit.exe --merge-config=my-experience.json (or the same using python) or just kit.exe my-experience.json

If no experience config specified Kit will load default: experiences/kit-default.json, which will start default Kit experience.

Use help: kit.exe -h to get more information.

The most important configuration is which extensions are to be loaded (and where to find them). Here is how a typical experience config might look:

{
    "app": {
        "extensions": {
            "enabled": [
                "my.new.extension",      // My new extension
                "omni.kit.window"   // Kit builtin extension
            ],
        },
    }
}

That doesn’t mean only 2 extensions will be loaded. If they have dependencies and their dependencies have other dependencies a large extension tree might end up being loaded.

All config values can be passed using command line arguments, using the --/ prefix:

kit.exe --/path/to/setting=2

Bundled Extensions

The Kit SDK comes with a lot of included extensions, refer to Bundled Extensions for documentation about bundled extensions.

Different Modes Example

CLI utility

graph RL usd[omni.kit.usd] -.- app(omni.kit.app) con[omni.kit.connection] -.- app user[user.tool] --> usd usd --> con user --> con user -.- app

Note

Arrows are extensions dependencies.

  1. User writes an extension user.tool, which depends only on omni.kit.usd and omni.kit.app.

  2. Runs Kit with a config:

"app": {
    "extensions": {
        "folders": ["path/to/folder_with_new_ext"],
        "enabled": [
            "user.tool"
        ],
    },
}

Notice that only one extension is specified. omni.kit.app will automatically figure out which extensions are required by resolving dependencies and will load and start them up in the correct order. user.tool can for instance parse command-line args, do some processing and then exit.

GUI CLI utility

graph RL ren[omni.kit.rendering] --> win[omni.kit.window] ui[omni.kit.ui] --> ren user[user.tool] --> usd usd[omni.kit.usd] --> con[omni.kit.connection] user --> con userui[user.tool.ui] --> ui userui --> user user -.- app(omni.kit.app) userui -.- app con -.- app ren -.- app usd -.- app win -.- app


The dependency on the UI unrolls the whole tree of required extensions.