<p>It's common to precompute some of the sampling. The most modern approach is probably to use a blue noise pattern. Have a read through here (I belive it also has some precomputed patterns and source code you can use):</p>
<p><a href="https://belcour.github.io/blog/research/publication/2019/06/17/sampling-bluenoise.html" rel="nofollow noreferrer">https://belcour.github.io/blog/research/publication/2019/06/17/sampling-bluenoise.html</a></p>
<p>This gives you which &quot;subpixel&quot; to sample from but I think you still want to apply some randomness within that subpixel.</p>
<p>EDIT: As lightxbulb points out, what I shared precomputes for a tile of 128x128 pixels. You don't want neightbouring pixels to be exactly the same or you will notice it when rendering.</p>

CC BY-SA 4.0
2022-04-05T12:13:31.447Z
The above is tiled over the screen. The sampling sequences are not reused within neighbouring pixels. I believe the tiles provided in the code above were $128\times 128$. Also it was quite limited in terms of dimensions.
lightxbulb
CC BY-SA 4.0
2022-04-05T15:18:36.910Z
Yes that's a good point it is not the same pattern for neighbouring pixels. The dimensions are fine, you just loop back around.
Peter
CC BY-SA 4.0
2022-04-05T15:37:48.967Z
"The dimensions are fine, you just loop back around." - that's not fine.
lightxbulb
CC BY-SA 4.0
2022-04-05T17:48:22.183Z
You will have to take it up with the authors then because this is what they do in the sample code: "sampleDimension = sampleDimension & 255;" ;)
Peter
CC BY-SA 4.0
2022-04-05T17:50:59.340Z
Sure, and what they do is wrong. I am quite familiar with the paper and code. It may produce passable results in specific scenarios, but it is wrong - you get a biased estimator with correlation between dimensions.
lightxbulb
CC BY-SA 4.0
2022-04-06T05:11:25.543Z
And, what if **all** the pixels patterns are precomputed? That is the pattern is different for each pixel, but constant in each frame (in time)
user18228
CC BY-SA 4.0
2022-04-06T09:23:43.393Z
@user18228 Then you get a showerdoor effect. One way to deal with it is to toroidally shift those in screen space at each frame. And you don't need it for all pixels, a sufficiently large tile is sufficient.
lightxbulb
CC BY-SA 4.0
2022-04-05T10:47:29.587Z
2022-04-05T15:19:57.717Z
2022-04-05T15:19:57.717Z
Peter
<p>This <a href="https://en.wikipedia.org/wiki/Supersampling#Supersampling_patterns" rel="nofollow noreferrer">wikipedia</a> page explains the principle of patterning in Supersampling.</p>
<p>However, I have a question: should the pattern be constant for every pixel?</p>
<p>Of course, the pattern will be constant for a &quot;grid algorithm&quot; but for the &quot;random algorithm&quot;, should the randomness pattern be the same across all pixels?</p>
<p>I think about it because it could be an optimization, pre-computing the sub-pixel positions instead of calculating it in each pixel. However I don't know if it's an acceptable technique.</p>
<p>To illustrate this: Here for example a 2x2 image, with random pattern, on the left the same pattern is repeated (it is random, but the same across all pixels so can be cached). On the right the pattern is re-computed for each pixel.</p>
<p><a href="https://i.sstatic.net/TOMq7.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/TOMq7.png" alt="enter image description here" /></a></p>
<p>My question is: <strong>it is visually acceptable to cache the pattern?</strong></p>

CC BY-SA 4.0
2022-04-05T08:46:50.260Z
It's not good to reuse it - you get correlation of the error between pixels. Precomputed sequences have been used though, e.g. optimised Sobol sequences.
lightxbulb
<raytracing><antialiasing><supersampling>
Ray tracing Supersampling patterns : pre-computing them?
user18228
# Ray tracing Supersampling patterns : pre-computing them?

(Asked by: username_0 on 2022-04-05)

This [wikipedia](https://en.wikipedia.org/wiki/Supersampling#Supersampling_patterns) page explains the principle of patterning in Supersampling.

However, I have a question: should the pattern be constant for every pixel?

Of course, the pattern will be constant for a "grid algorithm" but for the "random algorithm", should the randomness pattern be the same across all pixels?

I think about it because it could be an optimization, pre-computing the sub-pixel positions instead of calculating it in each pixel. However I don't know if it's an acceptable technique.

To illustrate this: Here for example a 2x2 image, with random pattern, on the left the same pattern is repeated (it is random, but the same across all pixels so can be cached). On the right the pattern is re-computed for each pixel.

[![enter image description here](https://i.sstatic.net/TOMq7.png)](https://i.sstatic.net/TOMq7.png)

My question is: **it is visually acceptable to cache the pattern?**

**Tags:** raytracing, antialiasing, supersampling

> **Comments:**
> **username_1**: It's not good to reuse it - you get correlation of the error between pixels. Precomputed sequences have been used though, e.g. optimised Sobol sequences.  

---

## 1 answers

### Answer by username_2 on 2022-04-05. Score: 1

It's common to precompute some of the sampling. The most modern approach is probably to use a blue noise pattern. Have a read through here (I belive it also has some precomputed patterns and source code you can use):

<https://belcour.github.io/blog/research/publication/2019/06/17/sampling-bluenoise.html>

This gives you which "subpixel" to sample from but I think you still want to apply some randomness within that subpixel.

EDIT: As username_1 points out, what I shared precomputes for a tile of 128x128 pixels. You don't want neightbouring pixels to be exactly the same or you will notice it when rendering.

> **Comments:**
> **username_1**: The above is tiled over the screen. The sampling sequences are not reused within neighbouring pixels. I believe the tiles provided in the code above were $128\times 128$. Also it was quite limited in terms of dimensions.  
> **username_2**: Yes that's a good point it is not the same pattern for neighbouring pixels. The dimensions are fine, you just loop back around.  
> **username_1**: "The dimensions are fine, you just loop back around." - that's not fine.  
> **username_2**: You will have to take it up with the authors then because this is what they do in the sample code: "sampleDimension = sampleDimension & 255;" ;)  
> **username_1**: Sure, and what they do is wrong. I am quite familiar with the paper and code. It may produce passable results in specific scenarios, but it is wrong - you get a biased estimator with correlation between dimensions.  
> **username_0**: And, what if **all** the pixels patterns are precomputed? That is the pattern is different for each pixel, but constant in each frame (in time)  
> **username_1**: @username_0 Then you get a showerdoor effect. One way to deal with it is to toroidally shift those in screen space at each frame. And you don't need it for all pixels, a sufficiently large tile is sufficient.  

---

