/update-0-4-to-0-5

# 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-4-to-0-5
description: >
  Upgrade an existing Python or C/C++ application from ovrtx 0.4.x to 0.5.x.
  Use when porting application code, authored sensor USD, RenderVar output
  handling, DLPack interoperability, Windows renderer configuration, or an
  attached ovstage 0.1 workflow to the ovrtx 0.5 release train.
license: LicenseRef-NvidiaProprietary
author: NVIDIA ovrtx
tags:
  - ovrtx
  - upgrade
  - "0.5"
  - ovstage
  - migration
tools:
  - Read
  - Grep
  - Edit

Update OVRTX 0.4 to 0.5

Port an existing application with the minimum changes required by the 0.5 public contract. Do not adopt unrelated 0.5 features or rewrite working code.

When to Use

Use this skill when upgrading an existing Python, C, or C++ application from OVRTX 0.4.x to 0.5.x. It also covers authored sensor USD and attached-mode applications that must upgrade from OVStage 0.1.x to the matching 0.2.x release.

Do not use it for applications starting on OVRTX 0.3.x or earlier; apply the corresponding earlier-version migration skill first.

Inputs

Resolve these before editing:

• The exact source and target OVRTX versions and package locations.
• Whether the application uses Python, C/C++, authored USD, or a combination.
• Whether it uses attached OVStage and directly consumes OVStage data.
• The source, build, deployment, and generated-asset files in migration scope.
• Whether 0.4-equivalent rendered output must be preserved.

Prerequisites

• Access to the application's current source, package pins, build configuration,

authored USD, and accepted output baselines when visual compatibility matters.

• Matching OVRTX 0.5.x and OVStage 0.2.x packages from the same release train for

attached mode.

• Read the authoritative sources below before changing APIs or data contracts.
• Runtime validation requires the GPU, driver, network, and unsandboxed execution

prerequisites documented in [`../../AGENTS.md`](../../AGENTS.md).

Scope

• Source: OVRTX 0.4.x, including 0.4.1, with optional OVStage 0.1.x.
• Target: OVRTX 0.5.x and, when attached mode is used, the matching OVStage

0.2.x package from the same release train.

• Languages: Python, C, C++, and authored USD used by those applications.
• Preserve application behavior unless the user explicitly wants the new 0.5

defaults.

This skill includes only changes that can require user source, build, deployment, or authored-USD changes. Renderer bug fixes, performance work, tests, CI, packaging reductions, documentation-only work, and optional new features are not migration steps.

Authoritative Sources

Before editing, read:

1. The `[0.5.0]` migration bullets in [`../../CHANGELOG.md`](../../CHANGELOG.md). 2. The installed 0.5 headers and Python signatures. They override release-note drafts and internal inventories. 3. [`../../include/ovrtx/ovrtx_types.h`](../../include/ovrtx/ovrtx_types.h), [`../../include/ovrtx/ovrtx_config.h`](../../include/ovrtx/ovrtx_config.h), and [`../reading-render-output/SKILL.md`](../reading-render-output/SKILL.md) when output or tensor APIs are present. 4. [`../../../../ovstage/public/CHANGELOG.md`](../../../../ovstage/public/CHANGELOG.md) when the application uses attached OVStage, OVStage population, or direct OVStage reads/writes.

Do not infer a migration from a ticket title alone. Confirm that the change is present in the target package and absent from 0.4.

Migration-Relevant Inventory

| Area | Inventory evidence | Applies when | |---|---|---| | Full RenderVar path identity | OMPE-94127 | The app fetches, indexes, logs, or compares render outputs. | | Python DLPack surface | OMPE-102110, OMPE-104349, OMPE-105119, OMPE-105460 | The app imports `ManagedDLTensor`, uses `.tensor`, passes raw `DLTensor`, or inspects mapping metadata/lifetimes. | | Vulkan-only Windows package | OMPE-103728 | The app selects DX12/Vulkan, has DX12 interop, or ships a pre-0.5 C binary. | | Sensor schema/model versioning | OMPE-74104, OMPE-94528 through OMPE-94535 | The app authors acoustic, IDS, lidar, or radar sensors. | | GenericModelOutput removal | OMPE-107766 | USD requests `sourceName = "GenericModelOutput"` or code imports the bundled GMO decoder. | | Schema registration order | OMPE-94125, OMPE-103596 | OVRTX and OVStage or another OpenUSD runtime share a process. | | One renderer per attached stage | OMPE-105429 | The app attaches one OVStage instance to more than one live OVRTX renderer. | | Reset-stack Boolean dtype | OMPE-103960 | Low-level code reads/writes `omni:resetXformStack` and assumes `kDLUInt`. | | OVStage population layouts | OMPE-102552 | Attached applications directly consume assets, path expressions, extents, or affected semantics. | | OVStage loader packaging | OMPE-106739 | A C/C++ app manually links or deploys OVStage rather than using its package CMake config. | | Other OVStage 0.2 public breaks | Paired-package changelog; not fully represented in the OVRTX Jira inventory | Attached applications use OVStage metadata, raw reads/maps, Python resource objects, physics schema fallbacks, or permissive 0.1 argument coercions. | | Changed image defaults | OMPE-102343, OMPE-103674, OMPE-105838 | The app requires output equivalent to 0.4 and relied on an omitted setting. |

Instructions

1. **Establish the real baseline.** Locate OVRTX and OVStage version pins, package roots, copied headers/libraries, lock files, and generated USD.