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?