Omniverse Kit 108 Migration Guide#

This guide details the steps and considerations necessary for migrating extensions and applications to Omniverse Kit 108. It incorporates essential updates, dependency changes and known issues, ensuring a clear and structured approach to facilitate a upgrading from previous releases.

The Omniverse Kit 108 release includes the following note-worthy dependencies, amongst others:

Component	Reference
OpenUSD 25.02	Changelog
Python 3.12	Release Notes

Preparing for Migration#

Before starting any update process, please ensure that you have the following prerequisites in order to minimize disruptions during migration:

Ensure you have access to the latest Omniverse Kit SDK.
You are familiar with your application’s architecture, and existing dependencies.
You have a backup of your current project, to prevent any potential data loss during migration.
A process in place to confirm all functionalities of your application and extensions behave as expected after upgrading.
- This process can vary depending on your organization, but typically includes elements such as automated builds, unit or integration tests, documentation about your feature’s behavior, reviewing log information, etc.

Carbonite#

Required Code Updates#

carb::extras::Path#

We removed implicit conversion from Path to std::string. Beginning with Kit 108, converting a Path object to a std::string requires explicitly calling the getString() member function:

Before (Stops working in Kit 108)	After (Compatible with Kit 107 & Kit 108)
`Path p = ... string s = p;`	`Path p = ... string s = p.getString();`

Also, as part of the effort to remove null-terminated strings, the following functions now accept carb::cpp::string_view only: getPathParent, getPathExtension, getPathStem and getPathRelative (all from carb::extra namespace).

If you’re using those functions, you’ll have to replace them using the following table (consider the variable p to be a char* representing a null-terminated string)

Before (Stops working in Kit 108)	After (Compatible with Kit 107 & Kit 108)
`char* p = ...; auto r = getPathParent(p);`	`char* p = ...; auto r = Path(p).getParent();`
`char* p = ...; auto r = getPathExtension(p);`	`char* p = ...; auto r = Path(p).getExtension();`
`char* p = ...; auto r = getPathStem(p);`	`char* p = ...; auto r = Path(p).getStem();`
`char* p = ...; auto r = getPathRelative(p1, p2)`	`char* p = ...; auto r = Path(p1).getRelative(p2);`

If your char* is obtained by calling the method .c_str() from a std::string or an omni::string, the solution is just to remove .c_str():

Before (Stops working in Kit 108)	After (Compatible with Kit 107 & Kit 108)
`string s = ...; r = getPathParent(s.c_str());`	`string s = ...; r = getPathParent(s);`

Library.h#

Library.h doesn’t provide the functions getDefaultLibraryPrefix and getDefaultLibraryExtension anymore. They should be replaced with the defines CARB_LIBRARY_PREFIX and CARB_LIBRARY_EXTENSION respectively.

Other Breaking Changes#

omni::string#

The class omni::string no longer treats construction from nullptr as an error, it will create a valid empty string. This doesn’t require changes to the code.

carb.crashreporter-breakpad.plugin#

Changed the default setting of /crashreporter/compressDumpFiles to true since most products have always enabled that.

omni.structuredlog.plugin#

Changed the default for the /telemetry/enableAnonymousData setting to true. By default, all emitted and transmitted structured log messages will now be sent using an anonymous user ID and the open endpoint (unless configured otherwise). The setting can still be disabled on the command line or in a config file if needed. It can also be overridden with the OMNI_TELEMETRY_DISABLE_ANONYMOUS_DATA environment variable.

Assert macros moved to Assert.h#

include/carb/Defines.h no longer provides CARB_ASSERT and other assert macros. These are now in a new header file: include/carb/Assert.h.

OpenUSD Update#

We updated from OpenUSD 24.05 and Python 3.11 to OpenUSD 25.02 and Python 3.12. This requires any C++ extension to be rebuilt.

Breaking Changes and Migration Requirements#

GfMatrix Lossy Overloads
- OpenUSD deprecated precision-losing GfMatrix4d methods. Update your code to use explicit precision methods.
- See: Deprecating precision-losing GfMatrix4d methods
Documentation Field Changes
- The way documentation metadata is handled has changed. You now need to consult prim definitions for tooltip information instead of relying on previous methods.
- See: The purpose of UsdObject’s Documentation metadata
Boost Python Fork
- OpenUSD now uses a fork of Boost Python. This may affect extensions that directly interact with Python bindings.
- Ensure your C++ extensions are compatible with the new Boost Python fork implementation.
NDR Deprecation
- The Node Definition Registry (NDR) is being removed from OpenUSD. If your extensions rely on NDR functionality, you’ll need to migrate to alternative approaches.
- See: Deprecation of pxr.usd.ndr
Scalar Translate and Scale xformOps
- OpenUSD now supports scalar transform operations. Tooling that interacts with xformOps directly should consider scalar translate and scale operations (e.g., xformOp:translateX) in addition to vector operations (e.g., xformOp:translateXYZ).
- Update your transform handling code to account for both scalar and vector xformOps.

Live Streaming#

When upgrading from Kit 107 to Kit 108, several important changes were made to the livestream extensions as part of the “Livestream 2.0” restructuring. This section outlines the required changes for existing applications.

Extension Dependencies#

New Required Extensions:

In Kit 108, livestream functionality has been split into multiple focused extensions. You now need to explicitly enable the appropriate extensions based on your use case:

[dependencies]
# For application framebuffer streaming
"omni.kit.livestream.app" = {}

# For specific AOV streaming (if needed)
"omni.kit.livestream.aov" = {}

# Core streaming infrastructure (automatically included as dependency)
"omni.kit.livestream.core" = {}

# Session management (if using REST endpoints)
"omni.services.livestream.session" = {}

What Changed:

omni.kit.livestream.core no longer provides direct streaming functionality
Application streaming moved to omni.kit.livestream.app
AOV streaming moved to omni.kit.livestream.aov
Session management requires omni.services.livestream.session instead of the legacy omni.services.livestream.nvcf

Settings Migration#

Legacy Settings (Kit 107 and earlier):

[settings]
# DEPRECATED - These settings are now legacy
app.livestream.port = 49100
app.livestream.fixedHostPort = 47998
app.livestream.publicEndpointPort = 47998
app.livestream.publicEndpointAddress = "192.168.1.100"
app.livestream.allowDynamicResize = false
app.livestream.webrtcEtli = true

New Settings (Kit 108+):

[settings]
# Primary application stream settings
exts."omni.kit.livestream.app".primaryStream.signalPort = 49100
exts."omni.kit.livestream.app".primaryStream.streamPort = 47998
exts."omni.kit.livestream.app".primaryStream.publicIp = "192.168.1.100"
exts."omni.kit.livestream.app".primaryStream.allowDynamicResize = false
exts."omni.kit.livestream.app".primaryStream.enableEventTracing = true
exts."omni.kit.livestream.app".primaryStream.streamType = "webrtc"

Setting Mapping:

Legacy Setting	New Setting	Notes
`app.livestream.port`	`exts."omni.kit.livestream.app".primaryStream.signalPort`	TCP port for connection negotiation
`app.livestream.fixedHostPort`	`exts."omni.kit.livestream.app".primaryStream.streamPort`	UDP port for media transport
`app.livestream.publicEndpointPort`	`exts."omni.kit.livestream.app".primaryStream.streamPort`	UDP port for media transport (legacy if `app.livestream.publicEndpointAddress` was set, now `streamPort` always used`)
`app.livestream.publicEndpointAddress`	`exts."omni.kit.livestream.app".primaryStream.publicIp`	Public IP for NAT traversal
`app.livestream.allowDynamicResize`	`exts."omni.kit.livestream.app".primaryStream.allowDynamicResize`	Dynamic resize capability
`app.livestream.webrtcEtli`	`exts."omni.kit.livestream.app".primaryStream.enableEventTracing`	Event trace logging

Automatic Legacy Support#

The system provides automatic migration for legacy settings:

Legacy settings under /app/livestream are automatically detected
Values are migrated to corresponding primary stream settings
Warning messages are logged encouraging migration to new settings
Both legacy and new settings can coexist temporarily during migration

Command Line Migration#

Kit 107 Command Line:

./kit/kit your_app.kit \
  --/app/livestream/port=49100 \
  --/app/livestream/fixedHostPort=47998

Kit 108 Command Line:

./kit/kit your_app.kit \
  --/exts/omni.kit.livestream.app/primaryStream/signalPort=49100 \
  --/exts/omni.kit.livestream.app/primaryStream/streamPort=47998

Breaking Changes#

Extension Structure: The monolithic omni.kit.livestream.core has been split into focused extensions
Setting Paths: All primary stream settings moved from /app/livestream to /exts/omni.kit.livestream.app/primaryStream
Explicit Dependencies: Applications must now explicitly depend on omni.kit.livestream.app for application streaming
AOV Streaming: Moved to separate omni.kit.livestream.aov extension with its own configuration structure

Recommended Migration Steps#

Update Dependencies: Add explicit dependencies on required livestream extensions
Update Settings: Replace legacy /app/livestream settings with new /exts/omni.kit.livestream.app/primaryStream settings
Test Configuration: Verify streaming functionality works with new settings
Remove Legacy Settings: Once confirmed working, remove deprecated settings
Update Documentation: Update any internal documentation or deployment scripts

Validation#

To verify successful migration:

Check application starts without deprecation warnings in logs
Confirm streaming functionality works as expected
Verify all required extensions are properly loaded
Test both primary and spectator streams if applicable

For applications using AOV streaming, additional migration may be required for the omni.kit.livestream.aov extension configuration.