/update-0-5-to-0-6

# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
# SPDX-License-Identifier: LicenseRef-NvidiaProprietary
#
# NVIDIA CORPORATION, its affiliates and licensors retain all intellectual
# property and proprietary rights in and to this material, related
# documentation and any modifications thereto. Any use, reproduction,
# disclosure or distribution of this material and related documentation
# without an express license agreement from NVIDIA CORPORATION or
# its affiliates is strictly prohibited.
name: update-0-5-to-0-6
description: >
  Upgrade an existing Python or C/C++ application from ovrtx 0.5.x to 0.6.x,
  including attached ovstage 0.2 to 0.3 workflows. Use when migrating logging,
  animation clocks, population and raw attribute contracts, sensor revisions
  and outputs, or SPG Lua scripts. Does not cover renderer-setting migrations.
license: LicenseRef-NvidiaProprietary
author: NVIDIA ovrtx
tags:
  - ovrtx
  - upgrade
  - "0.6"
  - ovstage
  - migration
tools:
  - Read
  - Grep
  - Edit

Update OVRTX 0.5 to 0.6

Port the application's source and data contracts with the minimum necessary changes. Apply each conditional migration only where the application uses the affected interface; do not rewrite working code or adopt unrelated features.

When to Use

Use for Python, C/C++, authored USD, and SPG Lua applications moving from OVRTX 0.5.x to 0.6.x, including attached OVStage 0.2.x to 0.3.x applications. For earlier versions, apply the corresponding earlier upgrade skill first.

Inputs

• Exact source and target package versions and locations, including build IDs.
• Application source, native bindings, authored/generated USD, SPG scripts,

dependency pins, and deployment configuration.

• Whether the application directly consumes OVStage buffers or sensor outputs.
• Accepted image/tensor baselines and animation/seek behavior to preserve.

Prerequisites

• Use matching OVRTX 0.6.x and OVStage 0.3.x packages for attached applications.

Rebuild native integrations against the target headers and runtime.

• Read target headers/signatures before editing. They override draft release

notes; confirm applicability to the application's exact 0.5 patch release.

• Runtime validation requires the GPU, driver, network, and execution conditions

in [the public agent guide](https://github.com/NVIDIA-Omniverse/ovrtx/blob/main/AGENTS.md). Static checks do not prove runtime compatibility.

Scope

This skill covers the nine source/data migrations below. Renderer settings, render-mode selection, section planes, spectral configuration, Gaussian tone mapping, and denoiser-setting migrations are outside its scope. Completing this skill is not a claim that those separate settings have been audited.

Authoritative Sources

• [OVRTX changelog](https://github.com/NVIDIA-Omniverse/ovrtx/blob/main/CHANGELOG.md) and installed headers/Python signatures.
• [OVStage changelog](https://github.com/NVIDIA-Omniverse/ovstage/blob/main/CHANGELOG.md) and

[population contract](https://github.com/NVIDIA-Omniverse/ovstage/blob/main/include/ovstage/ovstage_population.h).

• The area-specific public references linked below. Links target the published

repositories on `main`; use the matching release tag or installed distribution when checking a version-specific contract.

The comparison starts at the released OVRTX 0.5.0 source, not a pre-release approval candidate. In particular, the renderer animation-clock change is new relative to that release even if a changelog groups it under 0.5.

Instructions

1. Inventory uses of the nine interfaces below before editing. Record each as applicable, already migrated, or not used. 2. Apply only the matching source, binding, or data edits. Preserve unrelated settings and behavior. 3. Rebuild affected native consumers and regenerate application-owned bindings or assets when their layouts or types changed. 4. Validate the application's existing representative workflows: callback concurrency, playback/seek, population/replacement, raw buffer decoding, sensor outputs, SPG execution, and cleanup as applicable. Ask before adding new tests when the application's repository requires it. 5. Report completed migrations, checks actually run, and remaining blockers.

Audit Searches and Required Actions

1. C logging callbacks

Search for `ovrtx_log_severity_t`, `ovrtx_log_callback_t`, `OVRTX_LOG_INFO`, `OVRTX_LOG_WARNING`, `OVRTX_LOG_ERROR`, `OVRTX_LOG_FATAL`, and callback registration.

• Include `<ovrtx/ovrtx_logging.h>` explicitly; shared message types come from

`<ovx/logging_types.h>`.

• Replace the severity/callback types with `ovx_log_severity_t` and

`ovx_log_callback_t`, and the listed severity constants with `OVX_LOG_*`. The new severity set also includes verbose logging.

• Replace the old callback arguments (severity, floating-point timestamp,

message, user data) with `const ovx_log_message_t*` and user data.

• Read severity and text from that structure. It also supplies library/channel,

Unix and elapsed timestamps in nanoseconds, source location, process/thread IDs, and sequence number. Update timestamp conversions accordingly.

• Make callbacks fast and thread-safe: they may run concurrently on emitting

threads, rather than being serialized.

• Copy length-delimited strings before retaining them beyond the callback.

Keep callback state alive until successful replacement/disable has drained active calls, or shutdown has fully completed.

• Do not replace/register a callback from inside itself: it can deadlock.

Flushing from a callback is rejected; explicit flush timeouts use nanoseconds.

• Rebuild even though callback registration retains its function name: the

callback ABI has changed.

Read [the logging API](https://github.com/NVIDIA-Omniverse/ovrtx/blob/main/include/ovrtx/ovrtx_logging.h) and [message types](https://github.com/NVIDIA-Omniverse/ovrtx/blob/main/inc