109.0 Release Highlights#
Physical Lighting#
The PhysicalIlluminantAPI, PhotometricAreaLightAPI and PhotometricDomeLightAPI applied API schema allows specifying lighting in real-world photometric units, making setting up physically accurate lighting simulations much easier.
Using the new photometric:illuminance:distance attribute to reproduce a measured illuminance value for a light in RTX#
In addition, RTX now supports the UsdLux 25.05 specification. This specification, contributed by NVIDIA, makes it possible for lighting setups to be transferred seamlessly between any compliant OpenUSD application.
The behavior of individual lights is controlled with the attribute int omni:rtx:usdluxVersion, where values 2505 and greater select the new behavior. All lights are now created with int omni:rtx:usdluxVersion = 2505` by default.
Customizable Camera ISP#
The camera sensor ISP pipeline is now parameterized, allowing customization of all stages of the ISP simulation, including CFA encoding, noise simulation, companding and more. For full details, see the camera sensor extension documentation.
Custom Projections for Projector Lights#
Projector lights now allow custom projections specified by a direction LUT texture, allowing almost any projection to be encoded. The linked documentation contains an example Python script to generate the direction texture from an OpenCV pinhole calibration.
An image projected through a RectLight using the default parameters in the projection_light_texture_generator.py script#
Rolling Shutter#
RTX now supports simulating camera sensors with rolling shutter.
A propellor rendered with rolling shutter, showing the typical distortion of the propellor blades#
Runtime Motion Raytracing Toggle#
Motion raytracing is required for motion-dependent effects in sensors such as rolling shutter in cameras, and correct returns from lidar and radar sensors, among others.
In previous versions of RTX, in order to be able to render these effects it was necessary to enable motion raytracing explicitly at application startup using the --/renderer/raytracingMotion/enabled=true setting. Motion raytracing has a significant performance overhead of roughly 40% in most scenes, which meant that applications turning that setting on at startup were paying that cost regardless of whether they were simulating motion-dependent effects or not. This was particularly problematic in container deployments like Kit App Streaming and Sensor RTX where changing application startup arguments is more difficult.
In Kit 109.0, there is a new setting, --/renderer/raytracingMotion/allowRuntimeToggle=true that allows RTX to switch to motion raytracing automatically, and only when a sensor requires it. With this setting enabled, sensors that require motion raytracing will use it, while sensors that do not will not pay the requisite performance and memory overhead.
Note that the first time an application switches to motion raytracing, shaders will need to be recompiled causing a potentially multi-minute pause (exact length depends on the host hardware, and is the same as when starting a new Kit application build for the first time). The compiled shaders are then cached meaning subsequent switches will be instant.
Note also that although non-motion-dependent sensors will not pay the performance overhead, there is still a reduction in the maximum number of instances from 16.7 million to 9.7 million when --/renderer/raytracingMotion/allowRuntimeToggle=true is set.
Improved#
Mesh lights sampling has been reworked to improve visual fidelity and reduce memory usage for scenes with a large number of mesh lights.
Sensor parameters for camera ISP, lidar, and radar models can now be modified at runtime where previously they could only be set on scene load.