Render Settings

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, 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

Render Mode Selection

Real-Time Path-Tracing Settings (rtpt:)

Sampling and Caching

Ray Bounces and Shading

Firefly Filter

Gaussian Splatting

Path Tracing Settings (pt:)

Path Tracing

Denoising

Sampling and Caching

Firefly Filter

Spectral Rendering

Non-Uniform Volumes

Multi-GPU

Global Volumetric Effects

Anti-Aliasing

View Lighting Mode (Camera Light)

View Lighting Mode replaces all scene lights with a single camera light. By default the camera light is a distant headlight aligned with the view direction; it can be switched to a spot light positioned at the camera. The spot-only settings (radius, cone angle, cone softness) have no effect when the light type is "distant"; the angle setting has no effect when the light type is "spot".

Source: tests/docs/python/test_base.py snippet doc-set-view-lighting

Note: Minimal mode and SDG simple-shading outputs always render the camera light as its distant variant, so the light type and the spot-only settings have no effect there. Camera lights never cast shadows (the light is collocated with the camera, so it is effectively shadowless).

DomeLight MDL Material Baking

When a DomeLight's image source is an MDL material rather than a texture, RTX bakes the material into a lat-long map once and derives importance sampling data from it. These settings control that bake. They are authored per RenderProduct but consumed per scene, as the scoping note below explains.

Both integers are raised to 1 if authored lower, so 0 cannot produce a degenerate bake. Neither has a renderer-side ceiling: the baked texture is capped at 8192 texels after omni:rtx:domeLight:resolutionFactor is applied, so how large an omni:rtx:lights:dome:baking:resolution is usable depends on that factor.

Changing any of the three re-triggers the bake for every affected dome light.

Important: a baked dome light is a scene-level resource, not a per-view one. RTX resolves these three settings from the scene's reference view (its first view), so when several RenderProducts share a scene only the reference view's opinion is used and the others are silently ignored. Author the same values on every product that shares a dome light. This mirrors how the rest of MDL material baking already behaves.

Denoising trades transient GPU memory for a much lower spp. It is worth enabling whenever the MDL material is procedural and noisy; leaving spp high instead makes the bake proportionally slower.

Note: omni:rtx:domeLight:baking:spp lives on OmniRtxDebugSettingsAPI_1, while the other two live on OmniRtxSettingsCommonAdvancedAPI_1. A RenderProduct must apply the debug API to author the sample count.

Minimal Settings

Minimal mode is optimized for speed-of-light rendering performance and stability. It only respects the first DistantLight found in the scene, and shadows from that light are hard shadows. Other light types, including DomeLight, are ignored for Minimal mode lighting; if no DistantLight exists, Minimal mode uses a single camera light instead. For improved visibility, use the ambient light attributes documented in docs/sensors/cameras/render_modes/minimal.rst, or disable shadows with omni:rtx:minimal:castShadows.

Troubleshooting

• Render settings are attributes on the RenderProduct prim, not on a separate RenderSettings prim. Write them to the same prim path you pass to step() (e.g., /Render/Camera).
• The dtype must match the schema type exactly. Most integer settings above are uint, so write np.uint32 -- omni:rtx:rtpt:maxBounces is uint32, not int32 or int64. Settings typed token (such as omni:rtx:rendermode and omni:rtx:pt:pixelFilter:filter) are written as interned token IDs, not integers; see writing-attributes for the full USD-type-to-dtype table.
• After changing a setting, call reset() and run warm-up frames before capturing output. The renderer needs time to reconverge.
• Settings use the omni:rtx: namespace prefix, with subsystem prefixes like rtpt: (real-time path tracing), post: (post-processing), etc.

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.