Warmup
When to Use
Use this skill when the user asks about warmup frames, image quality, texture streaming, path tracing convergence, or why renders look noisy/incomplete.
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++, or both.
- Application lifecycle stage: renderer creation, scene loading, stepping, warmup, output readback, or cleanup.
- 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.
- For code changes, preserve renderer lifecycle ordering and cleanup semantics for the selected language.
Instructions
- Identify the requested language and lifecycle stage before choosing an example.
- Read the referenced snippet that matches the requested stage and language.
- Preserve the normal ovrtx order: create or initialize the renderer, load or compose USD, step or wait for work, read outputs when needed, then release C resources explicitly.
- Apply the async, status-query, error-handling, and warmup skills when the workflow crosses those concerns.
- When changing code, run the narrow example or docs test that owns the 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
After loading a scene or changing render settings in Real-Time Path-Tracing (rtpt, the default render mode), the first few rendered frames will not be production quality. There are two independent reasons for this:
- Texture streaming -- ovrtx streams textures on demand. The first frames use low-resolution mip levels while higher-resolution data loads in the background. This typically takes 10-30 frames depending on scene complexity.
- Path tracing convergence -- The real-time path tracer accumulates samples over successive frames. Early frames are noisy; quality improves as more samples are gathered.
To get a good quality image in RT2 mode, step the renderer for a number of warmup frames before capturing output. 40 frames is a good default that handles both texture streaming and basic convergence.
PathTracing (pt) mode does not need warmup
When omni:rtx:rendermode = "PathTracing" is set on the RenderProduct, the reference path tracer accumulates omni:rtx:pt:samplesPerPixel samples within a single step and returns a converged frame. You don't need to run warmup frames for PT-mode output — step once (after textures are in place if you need a particular mip level) and read the result. The test_path_tracing_mode test demonstrates this.
When to warm up (RT2 mode)
- After
open_usd() / open_usd_from_string() or add_usd_reference*() -- new textures need to stream in.
- After
reset() -- accumulated path tracing samples are discarded.
- After changing render settings that invalidate the accumulation buffer (e.g., bounce counts).
Python
Source: tests/docs/python/test_base.py snippet doc-warmup
C
Source: tests/docs/c/test_base.cpp snippet doc-warmup-c
Troubleshooting
- Warmup frames still produce
RenderProductSetOutputs. You can safely ignore the results (Python garbage-collects them; in C you must call ovrtx_destroy_results() for each step).
- The number of warmup frames needed depends on scene complexity. 40 is a conservative default; simple scenes may converge faster, while scenes with many high-resolution textures or complex lighting may need more.
- After
reset(), both texture streaming and path tracing restart. After reset_stage() + open_usd() or open_usd_from_string(), the scene is fully reloaded and warmup is essential.
- Applies to RT2 mode only. PathTracing (
pt) mode converges within a single step; don't warm up for it.
References
- Use the
> **Source:** directives in this skill to locate tested snippets before reusing API patterns.
- Keep related skills, docs, and snippets synchronized when changing the workflow.
1---2name: warmup3description: Warming up the renderer before capturing output. Use when user asks about warmup frames, image quality, texture streaming, path tracing convergence, or why renders look noisy/incomplete.4license: LicenseRef-NvidiaProprietary5---67# Warmup89## When to Use1011Use this skill when the user asks about warmup frames, image quality, texture streaming, path tracing convergence, or why renders look noisy/incomplete.1213## Inputs1415Resolve inputs in this order: existing repository files and referenced snippets, explicit user request, then broader agent context.1617- Target API surface: Python, C/C++, or both.18- Application lifecycle stage: renderer creation, scene loading, stepping, warmup, output readback, or cleanup.19- Repository source snippets referenced below. Treat these snippets as the API source of truth.2021## Prerequisites2223- Use an ovrtx checkout that contains the referenced examples and docs tests.24- Read the relevant `> **Source:**` snippet before writing or explaining API usage.25- For code changes, preserve renderer lifecycle ordering and cleanup semantics for the selected language.2627## Instructions28291. Identify the requested language and lifecycle stage before choosing an example.302. Read the referenced snippet that matches the requested stage and language.313. Preserve the normal ovrtx order: create or initialize the renderer, load or compose USD, step or wait for work, read outputs when needed, then release C resources explicitly.324. Apply the async, status-query, error-handling, and warmup skills when the workflow crosses those concerns.335. When changing code, run the narrow example or docs test that owns the snippet whenever practical.3435## Output Format3637- For explanations, cite the relevant API names, source snippets, and caveats.38- For code changes, summarize the files changed, snippets affected, and validation run.3940## Scripts4142This skill has no scripts.4344## Limitations4546- The referenced snippets remain the source of truth; update or add tested snippets before documenting new API usage.4748## Overview4950After loading a scene or changing render settings in **Real-Time Path-Tracing** (`rtpt`, the default render mode), the first few rendered frames will not be production quality. There are two independent reasons for this:51521. **Texture streaming** -- ovrtx streams textures on demand. The first frames use low-resolution mip levels while higher-resolution data loads in the background. This typically takes 10-30 frames depending on scene complexity.532. **Path tracing convergence** -- The real-time path tracer accumulates samples over successive frames. Early frames are noisy; quality improves as more samples are gathered.5455To get a good quality image in RT2 mode, step the renderer for a number of warmup frames before capturing output. 40 frames is a good default that handles both texture streaming and basic convergence.5657### PathTracing (`pt`) mode does not need warmup5859When `omni:rtx:rendermode = "PathTracing"` is set on the RenderProduct, the reference path tracer accumulates `omni:rtx:pt:samplesPerPixel` samples within a **single** step and returns a converged frame. You don't need to run warmup frames for PT-mode output — step once (after textures are in place if you need a particular mip level) and read the result. The `test_path_tracing_mode` test demonstrates this.6061## When to warm up (RT2 mode)6263- After `open_usd()` / `open_usd_from_string()` or `add_usd_reference*()` -- new textures need to stream in.64- After `reset()` -- accumulated path tracing samples are discarded.65- After changing render settings that invalidate the accumulation buffer (e.g., bounce counts).6667## Python6869> **Source:** `tests/docs/python/test_base.py` snippet `doc-warmup`7071## C7273> **Source:** `tests/docs/c/test_base.cpp` snippet `doc-warmup-c`7475## Troubleshooting7677- Warmup frames still produce `RenderProductSetOutputs`. You can safely ignore the results (Python garbage-collects them; in C you must call `ovrtx_destroy_results()` for each step).78- The number of warmup frames needed depends on scene complexity. 40 is a conservative default; simple scenes may converge faster, while scenes with many high-resolution textures or complex lighting may need more.79- After `reset()`, both texture streaming and path tracing restart. After `reset_stage()` + `open_usd()` or `open_usd_from_string()`, the scene is fully reloaded and warmup is essential.80- Applies to RT2 mode only. PathTracing (`pt`) mode converges within a single step; don't warm up for it.8182## References8384- Use the `> **Source:**` directives in this skill to locate tested snippets before reusing API patterns.85- Keep related skills, docs, and snippets synchronized when changing the workflow.