/render-settings

# 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: render-settings
description: >
  Writing render settings to control rendering behavior. Use when user asks to change
  render settings, set max bounces, configure path tracing, change render quality,
  enable DLSS frame generation, or modify RTX settings on a RenderProduct.
license: LicenseRef-NvidiaProprietary
author: NVIDIA ovrtx
tags:
  - ovrtx
  - rendering
  - settings
tools:
  - Read
  - Grep

Render Settings

When to Use

Use this skill when the user asks to change render settings, set max bounces, configure path tracing, change render quality, enable DLSS frame generation, or modify RTX settings on a RenderProduct.

Inputs

Resolve inputs in this order: existing repository files and referenced snippets, explicit user request, then broader agent context.

• Target API surface: Python, C/C++, USD, or a combination.
• RenderProduct prim path and the exact `omni:rtx:*` setting attribute to author or update.
• Desired setting value, USD type, runtime/write timing, and whether reset/warmup behavior matters.
• Existing scene or snippet that already owns related RenderProduct settings.
• Repository source snippets referenced below. Treat these snippets as the API source of truth.

Prerequisites

• Use an ovrtx checkout that contains the referenced examples and docs tests.
• Read the relevant `> **Source:**` snippet before writing or explaining API usage.
• Confirm the setting belongs on the RenderProduct prim, not on a Camera, RenderVar, or renderer creation option.
• Use `writing-attributes` when the setting is changed through runtime APIs.

Instructions

1. Identify the RenderProduct path and the exact RTX setting attribute to change. 2. Write settings on the RenderProduct prim, not on the Camera or RenderVar prim. 3. Match the value type to the USD attribute schema and preserve existing authored settings that are unrelated to the request. 4. Apply the writing-attributes skill when setting values through runtime APIs rather than static USD. 5. When changing code, run the render-settings docs test that owns the setting snippet whenever practical.

Output Format

• For explanations, cite the relevant API names, source snippets, and caveats.
• For code changes, summarize the files changed, snippets affected, and validation run.

Scripts

This skill has no scripts.

Limitations

• The referenced snippets remain the source of truth; update or add tested snippets before documenting new API usage.

Overview

Render settings in ovrtx are written as attributes on the **RenderProduct** prim. To change a setting, use `write_attribute()` in Python or `ovrtx_write_attribute()` in C, targeting the RenderProduct prim path (e.g., `/Render/Camera`) with the setting's attribute name.

Settings use the `omni:rtx:` namespace prefix. For example, to set the maximum number of path tracing bounces, write `omni:rtx:rtpt:maxBounces` as a `uint32` attribute.

After changing a render setting, call `reset()` and run warm-up frames to allow the renderer to converge with the new setting.

Python

Set a render setting on a RenderProduct

> **Source:** `tests/docs/python/test_base.py` snippet `doc-set-render-setting`

C

Set a render setting on a RenderProduct

> **Source:** `tests/docs/c/test_base.cpp` snippet `doc-set-render-setting-c`

Key Types / Functions

| Python | C | |--------|---| | `renderer.write_attribute(prim_paths=["/Render/Camera"], attribute_name="omni:rtx:rtpt:maxBounces", tensor=np.array([value], dtype=np.uint32))` | `ovrtx_write_attribute(renderer, &binding, &buffer, OVRTX_DATA_ACCESS_SYNC)` with `uint32` DLTensor |

Render Mode Selection

| Setting | Type | Default | Description | |---------|------|---------|-------------| | `omni:rtx:rendermode` | `token` | `"RealTimePathTracing"` | Render mode: `"RealTimePathTracing"`, `"PathTracing"`, or `"MinimalRendering"` |

DLSS Frame Generation (`dlss:`)

DLSS Frame Generation inserts interpolated frames between rendered ones. It is off by default and is enabled per RenderProduct, like any other render setting.

> **Source:** `examples/c/vulkan-interop/src/main.cpp` snippet `enable-dlssg`

| Setting | Type | Default | Description | |---------|------|---------|-------------| | `omni:rtx:dlss:frameGeneration` | `bool` | `false` | Enable frame generation | | `omni:rtx:dlss:frameGenerationInterpolatedFrameCount` | `int` | `0` | Interpolated frames per rendered frame; `0` lets the renderer pick. Clamped to the hardware maximum (1 on Ada, 3 on Blackwell) |

Enabling frame generation changes the shape of the step results: one step returns `output_frame_count == N + 1` output frames instead of 1, ordered with the interpolated frames first and the real rendered frame last. Each frame exposes the same single color render var, and only the last frame carries a meaningful accumulation status. Consumers that assume `output_frames[0]` is the frame to display or inspect need to be updated before turning this on.

The renderer declines frame generation without failing the step, in which case a step keeps returning a single frame. It requires an Ada or newer GPU that drives the display, the `RealTimePathTracing` render mode, `LdrColor` or `HdrColor` as the only render outputs, and a render resolution of at least 126 pixels per side.

Real-Time Path-Tracing Settings (`rtpt:`)

Sampling and Caching

| Setting | Type | Default | |---------|------|---------| | `omni:rtx