Renderers: Add automatic support for roughness adjustment to alleviate specular aliasing

[gkjohnson]

Description

There have been a couple issues in the forum recently regarding issues with specular aliasing with high detail normal maps and geometry (post 1, post 2) so I wanted to make an issue to track this. It can be particularly noticeable in VR environments.

My understanding is this is caused by different subpixel details being sampled as the camera moves causing a "shimmering" effect in addition to a lack of continuity with sibling pixels.

Solution

I haven't read them in depth but there are some papers on the topic here (Square Enix 2019) and here from slide 24 (Valve 2015, accompanying video). At a high level it seems that adjusting the roughness factor based on the subpixel detail (as determined by derivatives) can help alleviate the twinkling artifacts.

Alternatives

Generating custom normal map mipmaps and an associated roughness texture (a la the old RoughnessMipmapper) may be a more ideal solution (and is referenced in the above Valve talk) but doing this automatically may pose some difficulties, though maybe the node material system will help with that?

Additional context

No response

[aaaidan]

Hi! Author of post 2 here. 👋

That Alex Vlachos VR Rendering video is 👌🎉 So much gold packed into 60 minutes. 😓

From what I can see, post 1 (Arecsu) is wrestling with the limits of geometric MSAA antialiasing. I'm focused more on solutions to specular aliasing in normal maps.

These two problems may have similarities, but it might be helpful to consider solutions to the sources of aliasing separately (geometric vs textural). I'm possibly not connecting the dots, but I'd expect these to be solved with significantly different approaches.

The Vlachos lecture even says something to that effect: "...if you have a mesh with no normal maps on it, everything i just told you [...] buys you nothing ..." (He then goes on to describe the geometric roughness compensation that ThreeJS is already doing, almost exactly.)

@gkjohnson did you have something in mind that might mean we can work on a unified approach to these two problems?

[aaaidan]

This slide from the Vlachos presentation visually explains the rendering issue I'd love to see resolved.

There are many ways to solve this. I'd love to see if it can be tackled at render time, without the need for pre-rendering or pre-processing textures (e.g. RoughnessMipmapper). I lightly explored one possible approach on the forum. Here's the main takeaway from that brief investigation.

This one-liner added to the frag shader is only a small handful of instructions (e.g. vec3 length, subtract, multiply, add), and no branching or extra texture lookups. Despite its crudeness, this seems to be able to resolve the aliasing ("speckles") in this one case, without introducing unintended rendering effects (that I could see). I haven't tested it on a wider range of scenes.

I suspect a more sophisticated (principled) calculation would get more accurate and robust results without needing a much more compute.

[gkjohnson]

From what I can see, post 1 (Arecsu) is wrestling with the limits of geometric MSAA antialiasing. I'm focused more on solutions to specular aliasing in normal maps.

There's likely more nuance to this but the way I see it these are very similar problems (sampling higher frequency data than the screen sampling rate) - normal maps are just emulating geometry detail after all. There's more data to work with when sampling normal maps by virtue of being textures, though, so there are other solutions.

I'd love to see if it can be tackled at render time

Feel free to make a PR with your suggestions. The project has many priorities and any new features or fixes will need somebody to contribute them.