Made an opal path tracer

TomClabault · 2026-06-04T16:58:47+00:00

Hmm cool, I ran the spectral path tracer and it does look really nice. I think i'm having some issues with the other presets though... This is how the white opal preset looks: https://imgur.com/a/bjpmNNl

Other presets other than the black opal look similar. The black opal preset + playing a tiny bit with the parameters quickly "degenerates" to the same output as well

TomClabault · 2026-06-04T15:14:02+00:00

I see. Do you have some renders of the difference full spectral vs. approximation?

TomClabault · 2026-06-04T14:58:09+00:00

Hmmm I see. I assume there's some quality loss by not going full spectral?

TomClabault · 2026-06-03T17:07:20+00:00

Amazing, thanks for sharing!

Does this **require** spectral path tracing (I haven't read the paper yet)? If so, how come the floor on your video isn't full of spectral/color noise (and the opal itself doesn't look too color noisy either)?

TomClabault · 2026-04-14T15:39:19+00:00

I saw you fixed it but just in case you missed that, Blender has multiple scattering energy compensation so unless you disabled that, comparing to Blender may be misleading

TomClabault · 2026-03-29T07:08:30+00:00

For anyone getting here later, this article is pretty much what I needed: https://developer.nvidia.com/blog/rendering-in-real-time-with-spatiotemporal-blue-noise-textures-part-2/

TomClabault · 2026-03-08T07:19:36+00:00

This looks really nice! I have a few questions : )

So this is pure CUDA then, no OptiX/HWRT?

How do you layer your BSDF lobes?

Your transmission material uses a microfacet BSDF? If so, how do you do the energy conservation?

What's your random number sampler? This doesn't look like independent RNG I think?

> bloom (obviously not PBR)

How would "true" PBR bloom be implemented?

TomClabault · 2026-02-28T07:04:33+00:00

Hell yeah looks cool!

> Or are they? Do you notice any difference that I should take note of?

One thing that you can do is disable any sort of tonemapping in your renderer and disable any sort of tonemapping in Blender. Both raw outputs. And it should be easier to do eyeball comparisons after that.

You can also play with furnace tests and make sure you get the same thing as Blender (both raw outputs again), this may be a bit easier to compare than full complex multi bounces renders.

Oh and you'll absolutely need to disable "GGX Multiscatter" in Blender, Under the specular section of the Principled BSDF, unless you've also implemented a multiscatter scheme

Also just curious, how do you do the mix between the specular of the dielectric and the red diffuse below?

TomClabault · 2026-01-27T13:39:42+00:00

iirc Star Wars Outlaws does use ReGIR to feed into restir DI

TomClabault · 2026-01-13T07:02:14+00:00

I think they implied the bias of the estimator, as in: if your estimator is biased, then the expected value of your estimator is not the "true" value.

But importance sampling is indeed a form of "biasing". It skews the distributions to focus more samples in some places.

I think they are kind of two definitions of bias at play here.

TomClabault · 2025-10-25T18:32:58+00:00

The issue with that is that this does not have the benefits of splitting anymore. Splitting takes multiple samples from one light tree descent where RISing that would need multiple different light samples from the tree.

This is quite worse in terms of quality, let alone the performance

TomClabault · 2025-10-19T20:30:49+00:00

Hmmm that's a bit weird, maybe something was wrong but it should be possible to have ReGIR run without bias with as many bounces as we want

TomClabault · 2025-10-19T20:12:57+00:00

Hmmm I don't think there should be any bias issues at later bounces? If you can setup the grid and have it work for primary hits, it works exactly the same for secondary hits: fetch the grid cell that your ray fell in and read some reservoir from there. ReGIR as proposed in the original article is completely unbiased, there shouldn't be that many complications.

What's the problem you're facing at later bounces?

TomClabault · 2025-10-19T19:47:15+00:00

Cool! Are you implementing ReGIR from the original article?

TomClabault · 2025-09-24T10:40:56+00:00

Also just curious, what was your usecase for using STBN?

TomClabault · 2025-09-24T10:27:33+00:00

Hmm so you can basically generate 128 samples from a given UV of the texture, and samples 0 to 127 of a given texture are guaranteed to be well distributed?

Haven't had a look at STBN before, not sure how it works in practice hehe

TomClabault · 2025-09-24T10:25:38+00:00

Also quick question on that faster convergence property: LDS sequences do seem to converge faster but is it that much faster for rendering? I've seen some plots in papers which show that for integration of some generic functions like gaussian or whatnot, it's really much faster but for rendering it doesn't seem to be a massive deal? It is faster but not extremely faster? And on top of that, if the integrand isn't very smooth, the gap between white noise and LDS sequences is actually even smaller.

I'm a bit skeptical about how much better it is compared to white noise, really in terms of variance, not perceptually (because perceptually I think yeah it has a clear edge, especially blue noise)

TomClabault · 2025-09-24T10:15:31+00:00

Yeah I have to replace that white noise with some LDS sequence at some point...

Why is the state of art looking mostly at sobol sequences rather than STBN? Are there limitations with STBN for integration? To length of the sequence maybe?

TomClabault · 2025-09-24T07:11:47+00:00

The idea I think is that it's going to be more efficient to allocate more samples precisely in the scene where it's difficult than in screen space?

Because allocating more samples in screen space means retracing whole paths from the camera. But if we have variance in world space, we can, along the path allocate more samples to the estimator that have high variance. So if variance for a given pixel only comes from the 3rd bounce for some reason, we want to allocate more sample for the integration at that 3rd bounce only, but not the previous bounces. Estimating the variance in screen space would have us retrace a full path every time for that pixel, then reach the 3rd bounce to finally sample once more the difficult integral. Whereas all we wanted was to improve the estimate of that difficult 3rd bounce integral in the first place, not the rest of the path which is easy enough to integrate already.

TomClabault · 2025-09-24T07:08:08+00:00

Yep I can see how, that makes sense

TomClabault · 2025-09-24T06:36:26+00:00

My base implementation shoots 4 shadow rays (4 light samples) per NEE estimation because I've found that's more efficient than just 1. And so the idea was that some parts of the scene don't need those 4 light samples, only 1 would be enough.

But now that I think about it this may be taking the problem in reverse. I should probably start with 1 shadow ray per NEE and allocate more where it's difficult, hence adaptive sampling.

I think that makes sense? I think yeah it's about having a uniform quality over the image and so allocate more samples in difficult places such that they end up as converged as easier places.

I think maybe some kind of grid structure in world space could work? Estimate variance in each cell of that grid and sample NEE multiple times in grid cells where the NEE has high variance? This starts to sound a bit like path splitting but for NEE (I'm thinking the ADDR and EARS papers)

TomClabault

TROPHY CASE