Ray differentials in a path tracer

Gaming and Visualization Technologies Visualization OptiX
1

I am looking to add support for ray differentials to a path tracer. I am working from the rayDifferentials and path_tracer sample projects in the OptiX 3.9.1 SDK.
Let me note that I am aware that the stochastic nature of path tracers prevents aliasing effects. I want to use ray differentials for lodding purposes.

Learning from example by looking at rayDifferentials, I believe to understand the structure in which the programs are set up to support ray differentials. The camera program is responsible for generating the initial directions per ray (using the helpers.h function differential_generation_direction). From that point on, the intersection programs calculate relevant differential data which is passed on to the closest hit programs for further processing and to be used for rendering.

I am currently facing a few challenges.
In the sample, the parallelogram intersection program passes on the variables dudP and dvdP, while the sphere intersection program passes on the variable dNdP. Because the sample is a ray tracer, only the reflective/refractive spheres cast new rays (in their closest hit programs). They do this by passing dNdP (the sphere’s curvature) to the helper functions differential_reflect_direction and differential_refract_direction. There is no example of reflection/refraction by a plane.
I also noted that the parallelogram intersection program is correct for rectangles in the XZ plane only.

To get ray differentials working in path_tracer I will need to find a way to support parallelograms in all possible planes. I will also need to find a way to reflect and refract from a non-spherical surface, while the existing helper functions can only be used if a dNdP is known.
I hope that someone might be able to point me to more examples out there, or to share their thoughts on how my goal might be achieved.

I’ll also be looking into Tracing Ray Differentials (Igehy, 1999).

2

Hello,

Yes, the rayDifferentials sample is very hardcoded and needs to be generalized. That is one reason it is removed in the 4.0 sdk. I hope to have time to rewrite it soon.

I do have an internal demo renderer which has a general implementation of raydiffs. The approach I took was to have all geometry intersections return dPdu/v and dNdu/v. The closest hit then propagates ray origin/direction differentials and calculates duvdx/y.

The book ‘Physically Based Rendering’ by Pharr/Humphreys is an excellent resource on the mathematics of calculating partial diff values for various geometric representations.

If you email me at optix-help@nvidia.com I could send you relevent portions of code from my renderer.

3

Hi,

Thanks for your reply. I’d be very interested to see those parts of your renderer and I’ll send you a mail.
I’ll also be sure to check my copy of Physically Based Rendering. :)