TL;DR:
I’m evaluating ovrtx for lighting-design software that needs incident irradiance in documented physical units, independent of camera exposure and tone mapping. I couldn’t find a documented irradiance output; a test Irradiance RenderVar returns an empty buffer. Is this exposed another way, or planned?
Context:
I’m a lighting designer building analysis software on top of photoreal rendering. My prior workflows used Iray for 3ds Max, where irradiance render elements support photometric calculations (illuminance in lux, luminance in cd/m²) alongside tone-mapped beauty output. My goal with ovrtx is one ovstage scene serving three outputs:
- Photoreal beauty renders
- Luminance across visible surfaces
- Illuminance across visible surfaces AND user-placed calculation points/planes — ideally on invisible, non-participating geometry (probes that don’t cast shadows or affect indirect light)
I understand ovrtx is prerelease and oriented toward camera/lidar/radar sensor simulation, so photometric outputs may simply not be exposed yet — if so, I’d love to know whether they’re on the roadmap.
Environment:
ovrtx 0.4.0 (pip wheel), ovstage 0.1.0.346039
Windows 11 24H2 (build 26100), NVIDIA RTX 5000 Ada Generation Laptop GPU, driver 596.58
Python 3.13.2
PathTracing render mode
What I tried:
I searched the docs and the repo’s skills/ references and found no irradiance AOV. As a test I requested:
def RenderVar "Irradiance"
{
string sourceName = "Irradiance"
}
The frame contained an Irradiance entry, but mapping it returned an empty buffer:
dtype=uint8
shape=(0,)
Control case:
The same code path maps HdrColor correctly (float16, shape (64, 64, 4), linear RGBA with plausible values), so I believe my mapping code is sound and Irradiance is simply not a recognized sourceName.
Prior art I’m aware of:
Kit’s RTX renderer exposes path-traced annotators including PtDirectIllumination (per-channel illumination values), and Iray / RTX Accurate in Omniverse had an irradiance AOV — though placeable irradiance probes were noted as a gap even there. My questions are essentially whether ovrtx exposes (or plans to expose) an equivalent of that annotator set, and whether the probe gap is being addressed in the new library.
Questions:
-
Does ovrtx expose incident irradiance through another RenderVar, sensor type, or API? For lighting calculations it would need documented physical units, independence from camera exposure/tone mapping, and inclusion of both direct and indirect illumination.
-
Can irradiance be evaluated on invisible, non-participating calculation geometry or virtual probes, so measurement points don’t alter shadows, reflections, or indirect illumination? (In other renderers this is a “matte/invisible-to-rays” flag or a dedicated probe primitive.)
-
If supported: what are the output units and channel encoding? And architecturally — in Iray, analysis (irradiance) rendering initializes as a separate mode from photoreal rendering but shares the same scene, and that model works fine for me. Is the intended ovrtx pattern similar — one live ovstage driving separate beauty and calculation passes without forked layers or per-pass scene edits? (If a single invocation can emit beauty plus physical AOVs together, even better, but separate passes are acceptable.)
Minimal repro attached as ovrtx-0.4-irradiance-repro.zip: ovrtx-0.4-irradiance-repro.zip (1.8 KB)
irradiance_test.py — short driver following the shipped 0.4 attached-stage workflow; requests and maps both RenderVars
irradiance_test.usda — self-contained scene with a plane, DistantLight, camera, and HdrColor plus Irradiance RenderVars
If there’s a preferred way to file a feature request for physical AOVs, I’m glad to follow it. Thanks for any guidance — and thanks for shipping ovrtx as an open prerelease; the standalone Python model is exactly the integration shape I was hoping for.
(Related thread: [ovrtx 0.4.0] Absolute-candela IES (LM-63) photometry — is PhysicalIlluminantAPI supported? )