<p>I'm working on a (toy-level) path/ray-tracer, currently trying to implement (and understand) improved sampling strategies.</p>

<p>The obvious next choice after uniform random sampling would be stratified/jittered sampling.
The idea itself is clear: You divide the domain to sample (let's say the unit square) into NxN sub regions/cells, place a sample into each of those and add noise to it. Afterwards you shuffle the sample array so the consumption order does not matter - at least that is my understanding for the shuffle step.</p>

<p>This procedure is explained over and over in lots of sources and literature, but what most barely touch is how you would consume those in practise.
While it is clear for a single use case, like sampling a primary ray/camera pixel or sampling the surface of an area light, my understanding (which might be wrong) is
that those stratified [0,1]^N samples act as a general source of well distributed random numbers.</p>

<p>An example, say you want to render 1024 samples for some scene with area lights with a path tracer.</p>

<p>per pixel:</p>

<ul>
<li>just generating 32 x 32 (camera ray) samples is not working out, as you will need more good 2D samples for the area lights. Generating 32x32 arrays for each occasion where you might need good 2D samples is probably not a good idea, or is it? Though, given that you know the max ray bounce number one could make a good upper limit guess for the necessary total amount of 2D samples per pixel.</li>
<li>you will also need good 1D numbers for things like rolling the russian roulette dice or picking the BRDF to sample, the amount needed is probably unknown in advance, but again, guessing a reasonable upper limit would probably work out</li>
</ul>

<p>My immediate (and probably flawed) idea would be to create stratified sample arrays per pixel (or even for the full rendering) for dimensions 1+2 which do not necessarily match the requested total sample per pixel count, e.g. 64x64 each time, no matter the samples per pixel count. You would consume those in order, after shuffling, and if used up generate them fresh. </p>

<p>Other alternatives i could think of:</p>

<ul>
<li><p>given number of pixel samples N, always generate N stratified samples on demand whenever needed</p></li>
<li><p>generate enough samples ahead of time per pixel, when running out fall back to uniform random numbers or generate new stratified samples (so eventually the same as above)</p></li>
</ul>

<p>So long story short, the actual question is probably how do i properly consume those stratified samples? Are you even supposed to use such samples outside of primary pixel or area light samples? (Re)Use unused numbers per pixel sample,  per full rendering? Or am i generally on the wrong path, in that those stratified samples are not meant as a replacement for well distributed random numbers?</p>

CC BY-SA 4.0
2019-08-03T14:33:35.367Z
The stratified sampler you describe generates point sets, not point sequences. There are many ways one could use such samples, but in your case it simply seems like you are looking for a sampler that generates point sequences.
lightxbulb
CC BY-SA 4.0
2019-08-06T17:58:46.600Z
@lightxbulb That means they're not really meant as a continuous source of well distributed random numbers, and are only appropriate where sets make sense (e.g. sampling a pixel area)? So i guess things like sobol or halton sequences would be a better bet for an endless stream of good (quasi) random numbers then?
flipflop
CC BY-SA 4.0
2019-08-06T20:27:59.117Z
I am not saying you cannot create a sequence from stratified samplers, you could use a technique known as padding for instance. It involves for example generating multiple 2d stratified pointsets and permuting the points in each, and then "attaching" them sequentially to get higher dimensional points. But yes, qmc sequences are usually better in that regard, mainly due to the better convergence under some light assumptions.
lightxbulb
<raytracing><pathtracing><sampling>
Proper way of consuming stratified samples in path/ray tracing
flipflop
# Proper way of consuming stratified samples in path/ray tracing

(Asked by: username_0 on 2019-08-02)

I'm working on a (toy-level) path/ray-tracer, currently trying to implement (and understand) improved sampling strategies.

The obvious next choice after uniform random sampling would be stratified/jittered sampling.
The idea itself is clear: You divide the domain to sample (let's say the unit square) into NxN sub regions/cells, place a sample into each of those and add noise to it. Afterwards you shuffle the sample array so the consumption order does not matter - at least that is my understanding for the shuffle step.

This procedure is explained over and over in lots of sources and literature, but what most barely touch is how you would consume those in practise.
While it is clear for a single use case, like sampling a primary ray/camera pixel or sampling the surface of an area light, my understanding (which might be wrong) is
that those stratified [0,1]^N samples act as a general source of well distributed random numbers.

An example, say you want to render 1024 samples for some scene with area lights with a path tracer.

per pixel:

* just generating 32 x 32 (camera ray) samples is not working out, as you will need more good 2D samples for the area lights. Generating 32x32 arrays for each occasion where you might need good 2D samples is probably not a good idea, or is it? Though, given that you know the max ray bounce number one could make a good upper limit guess for the necessary total amount of 2D samples per pixel.
* you will also need good 1D numbers for things like rolling the russian roulette dice or picking the BRDF to sample, the amount needed is probably unknown in advance, but again, guessing a reasonable upper limit would probably work out

My immediate (and probably flawed) idea would be to create stratified sample arrays per pixel (or even for the full rendering) for dimensions 1+2 which do not necessarily match the requested total sample per pixel count, e.g. 64x64 each time, no matter the samples per pixel count. You would consume those in order, after shuffling, and if used up generate them fresh.

Other alternatives i could think of:

* given number of pixel samples N, always generate N stratified samples on demand whenever needed
* generate enough samples ahead of time per pixel, when running out fall back to uniform random numbers or generate new stratified samples (so eventually the same as above)

So long story short, the actual question is probably how do i properly consume those stratified samples? Are you even supposed to use such samples outside of primary pixel or area light samples? (Re)Use unused numbers per pixel sample, per full rendering? Or am i generally on the wrong path, in that those stratified samples are not meant as a replacement for well distributed random numbers?

**Tags:** raytracing, pathtracing, sampling

> **Comments:**
> **username_1**: The stratified sampler you describe generates point sets, not point sequences. There are many ways one could use such samples, but in your case it simply seems like you are looking for a sampler that generates point sequences.  
> **username_0**: @username_1 That means they're not really meant as a continuous source of well distributed random numbers, and are only appropriate where sets make sense (e.g. sampling a pixel area)? So i guess things like sobol or halton sequences would be a better bet for an endless stream of good (quasi) random numbers then?  
> **username_1**: I am not saying you cannot create a sequence from stratified samplers, you could use a technique known as padding for instance. It involves for example generating multiple 2d stratified pointsets and permuting the points in each, and then "attaching" them sequentially to get higher dimensional points. But yes, qmc sequences are usually better in that regard, mainly due to the better convergence under some light assumptions.  

---

## 0 answers

