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 :doc:`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: :doc:`../api/core/omni.kit.app` 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-app.json`` (or the same using python) or just ``kit.exe my-app.json`` If no app config specified Kit will load default: ``apps/omni.app.dev.kit``, which will start default Kit app. 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 app config might look: .. code:: { "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 :doc:`../../source/extensions/index` for documentation about bundled extensions. Different Modes Example ************************* CLI utility ============ .. mermaid:: 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: .. code:: "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 ================== .. mermaid:: 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.