I've currently left the file and function names as "jitter", "pmj", etc. But this feels a little odd now that it's not PMJ anymore. I'm happy to change them in this patch as well, but want to double check what good names would be. Maybe "tabulated_sobol" or "tab_sobol"?

Maybe name it tabulated_sobol_burley and sample/tabulated_sobol_burley.h?

This isn't really Sobol-Burley, though. The sampling pattern is equivalent (they're both Owen-scrambled/shuffled Sobol), but it's not generated using Burley's approach.

Maybe sobol_helmer, since it uses the technique from Helmer et al's paper to generate the samples...? (Although I suppose it is using Burley's approach just for the shuffling at render time.)

Since these are now the same pattern, we should also make the sampling pattern purely a debugging option that's not visible by default in the UI. Similar to for example the CYCLES_RENDER_PT_sampling_path_guiding_debug panel.

Yeah, that's a good idea. I'll add that to this patch.

Any particular reason the order is (time, lens_x, lens_y) and (light_u, light_v, light_pick)? I don't know if and how the order affects the quality of the (lens_x, lens_y) and (light_u, light_v) 2D patterns, but I'd expect these two cases to be ordered the same.

In my testing in Psychopath, using the first dimensions for time made a more noticeable quality difference than for DoF.

For light selection, I'm just going off the intuition that in many cases the light samples in a localized area will primarily be directed towards a single light source (particularly after light trees land), so having better stratification for light sampling probably makes a bigger difference than better stratification for light selection. But that's just a hunch, and I could totally end up being wrong. I can change it to (light_pick, light_u, light_v) if you prefer.

In D16443#447848, @Nathan Vegdahl (cessen) wrote:

This isn't really Sobol-Burley, though. The sampling pattern is equivalent (they're both Owen-scrambled/shuffled Sobol), but it's not generated using Burley's approach.

Maybe sobol_helmer, since it uses the technique from Helmer et al's paper to generate the samples...? (Although I suppose it is using Burley's approach just for the shuffling at render time.)

Maybe just tabulated_sobol as your original suggestion then.

In my testing in Psychopath, using the first dimensions for time made a more noticeable quality difference than for DoF.

For light selection, I'm just going off the intuition that in many cases the light samples in a localized area will primarily be directed towards a single light source (particularly after light trees land), so having better stratification for light sampling probably makes a bigger difference than better stratification for light selection. But that's just a hunch, and I could totally end up being wrong. I can change it to (light_pick, light_u, light_v) if you prefer.

Ok, the reasoning makes sense to me then, it's fine to keep it as is. We can compare the two options with many lights sampling at some point.

Unless you have any other notes, then I think once we test this with many lights sampling it's good to go.

Great! Will D16561 also be merged into master, or should I just rebase directly on D16561 and then this patch will effectively get both into master?

I merged D16561 into master just now (everything from blender-v3.4-release gets merged).

Awesome. I'll work on rebasing today.

@Brecht Van Lommel (brecht): I've updated the patch to latest master.

Also, here's a comparison for DoF + motion blur:

2d sampling (old)	3d sampling (this patch)

In the upper left is an object that is motion blurred and another object that is out of focus. As expected, there isn't much difference there since they at most use 2 dimensions. But in the upper right is an object that is both motion blurred and out of focus, and this patch significantly reduces the noise there because it stratifies the time and lens dimensions.

Ah! Yeah, that's an oversight. Thanks for the catch!

It still works with tabulated Sobol. Although in general, I feel like scrambling distance is a misfeature. The small performance improvement you get from the improved cache utilization is, I strongly suspect, not enough to make up for the poorer convergence rate and just generally poor render quality. So I wonder if we shouldn't just remove it entirely.

Edit: Remove since the comment is off topic