Kit Development
Developing a Omniverse Kit Application to be deployed to an Omniverse Application Streaming API instance for on-demand streaming, is largely the same as for other streaming environments.
New to Kit Application development?
If you’re new to Kit Application development, the Kit App Template Tutorial is a great starting point. It provides step-by-step instructions and various templates to help you quickly create your own applications. You’ll be guided through key processes, like enabling streaming and containerization, with the USD Viewer
template as a recommended first project.
Once you have walked through creating a container of a streamable Kit Application, come back here to dive into the specifics of creating Omniverse Kit Applications to be deployed to an Omniverse Application Streaming API instance.
Before going, read through the Overview to provide a bit of context while you are learning.
For more detailed guidance, explore the Omniverse Kit Application Development Guide, which offers comprehensive documentation to support your development journey.
Overview
We’ll start with a high-level overview of the entire process, before going into specifics.
In short, the process can be divided into two major areas:
- Creating your Kit Application
This starts with creating your application, whether from a template or a blank screen, and includes everything until you have a tested containerized streamable Kit Application.
Basic steps
Creating your Kit Application
The basic steps are:
Create your Kit Application
Enable streaming using the NVIDIA Omniverse™ Kit Application Streaming extensions.
Locally test your streamable Kit Application
Package and Containerize your Kit Application
Test your Kit Application container
Once you have confirmed that your Kit Application is containerized and streaming properly, you are ready for deployment.
- Deploying to your instance.
This involves everything required to make your containerized Kit Application available for streaming on your deployment environment, an Omniverse Application Streaming API instance in this case.
Basic steps
Deploying your Kit Application
Deploying to an Omniverse Application Streaming API instance involves the following steps:
Register your Kit Application container with an image registry accessible by your cluster, such as NVIDIA NGC™.
Register your application with your Omniverse Application Streaming API instance.
Creating your Kit Application
This guide only covers specific information required to successfully deploy a Kit Application to an Omniverse Application Streaming API instance. If you are new to Kit Application development, please review the New to Omniverse Kit Application development dropdown, above, or utilize the Kit App Template Tutorial and Omniverse Kit Application Development Guide.
Required knowledge:
Kit Application development
Kit Application Streaming
Containerizing Kit Applications
Kit Streaming requirements
There are no special requirements for creating your Kit Application to be deployed to an Omniverse Application Streaming API instance, other than ensuring it meets the basic requirements for Kit Application Streaming, in general:
omni.kit.livestream.webrtc
to enable WebRTC streaming
omni.kit.livestream.messaging
for messaging between the Kit Application and the client, if required.The application configured properly for its intended use:
Minimal UI suitable for streaming, especially if being embedded into a web-client’s interface.
Resolution no greater than 1920x1080.
Render rate set to 30fps.
Streaming specific configuration options in a [my-app].streaming.kit file.
Container requirements
There are no specific requirements, other than ensuring the kit application successfully runs and streams when containerized.
Shader Cache support
To minimize start-up latency, Omniverse Application Streaming API instances have a shared shader cache service that all of the GPU Worker Nodes can access. Shared shader caching is critical to minimizing Kit start-up latency as shader compilation can take 5-10 minutes.
Why Shared Shader Caching is important.
Shader caching is a performance optimization technique used in GPU rendering to store the results of shader compilation for reuse in future sessions. Shaders are programs that run on the GPU to handle graphical tasks like lighting, shading, and other visual effects. These shaders must be compiled from source code into executable instructions before they can be run on the GPU, and this process can be time-consuming. Shader caching addresses this issue by storing the compiled shaders, significantly reducing the need for recompilation and improving performance.
Setting the AUTO_ENABLE_DRIVER_SHADER_CACHE_WRAPPER
envar
This can occur automatically when the application’s container is started within the pod, as part of the container sidecar’s environment variable configuration. You can refer to Install Memcached Service
What do I need to do?
For Kit 105.1
you just need to ensure that the omni.hssc
kit extension is being loaded. For Kit 106+
, in most situations, nothing. As long as the AUTO_ENABLE_DRIVER_SHADER_CACHE_WRAPPER
is set automatically by the instance, shared shader caching should just work.
Alternatively, you can hard-code the AUTO_ENABLE_DRIVER_SHADER_CACHE_WRAPPER
envar in the start-up script of your Kit Application. This is not preferred as any changes will require recreating your Kit Application container.
Deploying your Kit Application
Once you have a containerized Kit Application that you have tested to ensure it streams properly, you are ready to begin the deployment process. This typically requires elevated privileges, which you may not have. A common workflow involves developers collaborating with cluster administrators for the deployment of applications. Make sure that you are clear on the deployment process for your instance and whether you have the requisite permissions.
Requisite Knowledge and permissions
Familiarity with image repositories and authorization to push images
Cluster access and the ability to modify and push Kubernetes CRDs, or:
Access to optionally exposed Application management endpoints.
Deploying a Kit Application Container
You have successfully created a container of your Kit Application and now want to deploy it to your instance. Before doing so, lets clarify one key point about your container; your container represents a “version” of your application. It isn’t your application, just one version of your application. Every container you create of your application is a “version” of it.
This is exactly the model that Omniverse Application Streaming API uses with Application
and ApplicationVersion
, the two representations you need to create and manage when deploying a Omniverse Kit Application to your instance.
Before diving deeper, lets look at the two overarching steps required to deploy your container image.
1. Register your container image
The first step is pushing your container image to an image repository, which the services and Worker Nodes have access to. Ensure you choose a clear name for your image. Also, follow best-practices when choosing your label, use semver and potentially stages when doing so. This can help when registering your container image with your instance, in the next step.
You will need the URI to the container image in the next step.
2. Adding the Image to your instance
This is the step where you inform your instance that there is a new ApplicationVersion
that can be streamed using the container image you registered. There must also be a valid ApplicationProfile
compatible with your Application
and ApplicationVersion
.
There are two methods for registering a Omniverse Kit Application with your instance. The default is to use standard methods for managing resources on a Kubernetes cluster. This requires administrative access to your cluster and familiarity with Kubernetes CRDs and Helm charts.
Deploying Omniverse Kit Applications describes how
Applications
andApplicationVersions
are managed.
Optionally, you can create and delete Application
and ApplicationVersion
by enabling management endpoints of the Application
service. This has security impications, so may not available.
Managing Applications and Versions via Endpoints discusses the security concerns and how to enable the endpoints.