Beyond White Noise for Real-Time Rendering 

We have some stuff cooking to try and tackle the cache coherency issues too - that other shoe dropping for super perf wise folks such as yourself Robin :)

The cache unfriendliness problem is that E.g. when you use this to choose directions to shoot shadow rays in for ambient occlusion, each pixel in small regions of pixels are shooting rays in very different directions, which mean they hit different parts of the BVH. Ray tracing is accelerated by sorting similar rays (direction and otherwise) and having them run together so they access the same things which can reside in the cache. Similar for if you use this for material blending, small regions of pixels will want to access all possible materials, which means their execution diverges and the textures they read will all be different. If you could group similar pixels somehow and run them together, that would help the cache issues. Increased predictability of random values, and increased storage needs are 2 other downsides. Those are the three I can think of. There may be more but that's all that's coming to mind right now.

@@Atrix256 It is worth pointing out that this isn't actually a bug, or a problem, it is intended behaviour and inherent to the question being asked. If you use white noise and two adjacent pixels fire rays in the same direction it is 'better' for the cache, but you are duplicating work rather than doing something useful. If you only have a few samples to play with you want them doing different things and this is inherently cache unfriendly. The fact that white noise is friendlier to the cache is a bug in it because it that is fixed by blue noise!

It's a good point, and in fact, white noise is also bad for the cache. Like you say, it isn't a bug, but it is something that can be improved in the future :) Interestingly, red noise (aka low frequency noise aka brown noise, named after robert brown) is cache friendly, but has different properties. Nearby values are similar / positively correlated.

It cannot be improved at the noise end, because it is inherent. In the limit rays from every source will hit every possible target, and access every material. It is all to all. We want to access as many diverse sources of information as possible. When we limit sampling to improve performance we still want as much information as possible, We still want to hit memory with the same distribution, just fewer samples. Bundling rays can be done no matter the source of the rays, and while blue noise is likely to use more bundles for the same number of samples, this is a reflection of it doing more with the same number of samples. One thing that certainly can be done is to have low res versions of all textures that are in use, and limit the operations that materials can do to make them play nice with pre filtered textures. High frequency information on materials is almost always lost after one bounce (reflections/refractions are the exception), so we can be much friendlier on the cache by not putting high frequency information in it. Reflections and refraction rays are going to be pretty cache friendly anyway, so we don't really need to worry about them. This actually addresses another issue that even blue noise doesn't cover. Deserves it's own post though.

Of note is that even with screen space blue noise, once the rays have bounced once and been sorted they will have a white spectrum, even if we try to do bounces with a blue noise seed. Distant rays can hit close to each other. If a wall has a small bright spot for example this may get over or under represented in the final image, irrespective of the colour of the seed noise. If there is periodic high frequency information in where the rays impact then impacting in distant locations is effectively an independent random sampling, and your spectrum is back to white. For example, if you are only firing 4 rays at a brick wall, there is a significant chance they all hit the grout. The source of the rays would think the wall is white! Importantly those 4 rays did not have to hit near each other, so blue noise is of limited help. Those 4 rays could have come from 4 nearby screen space pixels, because even with blue noise the specific material of the wall you hit is still independently random. You can get low frequency noise passed through to the image. By prefiltering out the high frequency information even 1 ray would be a reliable sampling. Even low frequency signals on materials can increase noise on later bounces, so the more we can pre-filter information for deeper diffuse bounces the better results we will get. If you are only firing 4 rays at a brick wall, there is a significant chance they all hit the grout. The source of the rays would think the wall is white! Importantly those 4 rays did not have to hit near each other, so blue noise is of limited help. Those 4 rays could have come from 4 nearby screen space pixels, because even with blue noise the specific material of the wall you hit is still independently random. You can get low frequency noise passed through to the image. By prefiltering out the high frequency information even 1 ray would be a reliable sampling. Rather than thinking of each ray as a point sample, if you think about it as a gaussian sampling of the material then it becomes clear that pre-blurring bounce textures is physically meaningful, and allows us to get much better information per sample. This isn't really a down side, but I thought you might appreciate some information on the limitations, and how to mitigate those. It is extremely helpful to think of things in terms of frequency, and how manipulating frequencies can help us. At screen space, low frequency noise is bad because we cannot differentiate it from genuine signal. Deeper in the chain our sampling rates get very low, and Nyquist shows up, so we want filter out all the information above a certain frequency to avoid it adding noise to our image. Ideally our sampling should be blue to play nicer with Nyquist, but this is generally infeasible.

Yeah, other people have said that same in response to this stuff, that the unpredictability is a feature. I'd say it's a design choice, and it's nice to be able to do either.

I think the idea of a "lucky day" is purely sentimental and adds no real value to the average user experience. A lucky day is confirmation bias, amongst hundreds or thousands of unlucky days.

Yeah. There is a lot of work on denoising. There is a little work on the noise side. If they were both optimized together, I do think better results are possible. Someone needs to get on it :)

An auto correlation of a blue noise texture shows a ripple of negative then positive correlation that almost looks like sinc. But, the radius is very small and becomes uncorrelated after a radius of 5 or so. I do think what you are saying is a way to approach it, yeah.

I think the challenge with adding blue noise or low discrepancy sequences to old software is that old software often doesn't have very many people working on it, and the people that do work on it probably don't know everything about the software. There are lots of dark corners where the person who made it doesn't work there anymore and nobody wants to touch it. So yeah, i think it is possible to add it to older software, but the usual challenges of changing older software come up. I agree with you that newer software doesn't have the same excuse, and all we can do is try to help people understand this stuff to make better implementations before the new software becomes old software and stops changing :)

For sure! Random is only fair "at the limit". Like, at infinity. Before then... who knows.

That is super cursed! 😂

There is no luck. It is random noise. A predetermined probability. A more fair assertion would be that some people are luckier than others. The more realistic take is that most people will never be lucky.

@@mito._ Luck is a favourable outcome of a random (feeling) situation, the less likely the more lucky. It's just how language works.

@@Bassalicious A favorable outcome is just a specific configuration of a system. The perception of "luck" requires perception or, as you said, a "feeling" of favorableness - which is just bias towards a specific predetermined configuration.

Ha! No, it's just me recording from my house without a very nice audio setup.