Alternatives to multisample anti-aliasing (eg: FXAA)

[MirceaKitsune]

I remember briefly discussing this on Discord, wanted to bring it here for broader discussion. With all the fantastic improvements made recently I felt that before the next release, we should look into the possibility of supporting alternate implementations for anti-aliasing over the classic MSAA.

The reason this is important to discuss is performance. Multi-sampling based AA is very expensive: Even 4x, which is the minimal amount needed to properly get rid of jagged edges, is considerably GPU intensive. In older engines that use lightmaps this may not make a noticeable difference. With our realistic lighting system, we still need to squeeze out every bit of performance that we can. MSAA is a notable performance impactor... of course none of us want sharp pixelated edges so we don't want to get rid of it entirely, a faster replacement is thus desirable.

The most common alternative available today is FXAA. I understand that like MSAA, it's supposed to be supported by the video driver and the engine just needs to tell the card to enable it. It's a shader / post-processing based solution which achieves nearly the same result but at times faster performance. If it's this simple to support it, could we get a menu option to use FXAA instead of MSAA please, so those of us who feel there's a performance benefit can rely on this alternative?

Edited June 11, 2021 by MirceaKitsune
Pressed enter by mistake and posted early

[MirceaKitsune]

Here are some useful resources on the matter, sharing in case they make this easier to accomplish.

https://catlikecoding.com/unity/tutorials/custom-srp/fxaa
https://catlikecoding.com/unity/tutorials/advanced-rendering/fxaa
http://blog.simonrodriguez.fr/articles/30-07-2016_implementing_fxaa.html

https://iryoku.com/smaa
https://www.geeks3d.com/20111101/smaa-enhanced-subpixel-morphological-antialiasing

[cabalistic]

I've written this before, but personally I'm not a fan of FXAA. Due to its purely post-processing nature, it has no actual extra information to resolve aliasing artefacts, so all it can do is blur the image. Sure, it is a "smart" blur filter in that it's looking for edges in the picture, but still. This is (in my opinion) not true anti-aliasing.
Given that you can usually enable FXAA in the graphics driver for any game you want, integrating it directly into TDM feels like a waste of development effort to me. Although I'll concede it would be more convenient to have it as an ingame option.

In my opinion, the only real challenger to MSAA is TAA, but unfortunately that one's the most difficult to implement, by far. Especially if you want to achieve actually good results. But we don't even have some of the prerequisites in place in the engine, so we can't work on this in the foreseeable future even if we wanted to.

[stgatilov]

I think FXAA should be much worse in TDM than even the lowest levels of multisampling.

Regarding the geometry, there are two opposite sides of the spectrum:

1. blocky geometry with long straight edges (vertical/horizontal) and large triangles
2. curved surfaces with many small triangles and no apparent directions

FXAA probably helps with case 2 well, but case 1 is much harder.
I had such case on my daily job, where buildings without any details were rendered without textures and with single color (very blocky style). Even the latest FXAA on highest quality did not help: the long vertical edges still looked awful when moving. And multisampling was mutually incompatible with SSAO due to shitty WebGL

Perhaps FXAA and other alternatives are newer, but multisampling is the "correct" approach, while FXAA is not. It matters a lot what information is used by antialiasing method: multisampling saves the real coverage information, which makes it converge to perfect image as you increase number of samples. FXAA does not use any additional information, so it is pure guesswork and hacking. Temporal antialiasing uses information about velocity, and I think this information allows it to achieve good quality: it knows how current frame relates to the previous/next ones, so it blurs in such a way that pixels don't jump back and forth as you move.

 

[nbohr1more]

FXAA is useful for one case that MSAA isn't: alpha-textures

The other inexpensive way to achieve AA on alpha-textures is "Alpha to Coverage" :

http://www.humus.name/index.php?page=3D&ID=61

but it seems to be broken on recent drivers...

 

[cabalistic]

5 hours ago, stgatilov said:

Temporal antialiasing uses information about velocity, and I think this information allows it to achieve good quality: it knows how current frame relates to the previous/next ones, so it blurs in such a way that pixels don't jump back and forth as you move.

In addition, TAA employs a sub-pixel jitter to the projection matrix. So each frame, the projection is slightly offset in such a way that you are looking at a different "subpixel", if that makes sense. So when combining the current and previous frames, it actually has some indirect access to subpixel resolution even in cases where MSAA does not (like edges in lighting). It does still blur the final image, but that can actually be counteracted with the CAS filter pretty well, and the anti-aliasing effect is very good - *if* the velocity buffer and frame reprojection are implemented well.

[MirceaKitsune]

Yes, FXAA isn't the only method: There are a few other alternatives to MSAA, which are all worth exploring and testing to see which gives the best results at the best performance with our engine. I believe most are shader based but use different passes to achieve the effect, which IMO is the right way of going about it.

I agree that in theory MSAA is the correct way of doing this. Its problem is that it requires multiple samples per pixel which is a great way of wasting GPU power. If we could have everything running in the most accurate way, our dream of a lighting system based on realtime raytracing would come true... on existing hardware that would run at 1 frame per minute. Point being that sometimes it's better to use estimations, especially when they can offer roughly the same result as the more realistic method.

MSAA should always remain an option... only wishing that other alternatives could be available for those who need the performance benefit. Ideally they can all be put under one slider or drop-down menu, so you have a list that looks like "FXAA, 2x TAA, 4x TAA, 2x MSAA, 4x MSAA, 8x MSAA, 16x MSAA" (prolly a silly example but you get the idea).

Something I forgot to add: I took inspiration for this suggestion from Red Eclipse, the latest version of which uses Tesseract engine (previously Cube). It has all sorts of AntiAliasing options available in the menu, from FXAA to Temporal AA to one I think they created just for that engine. I played with them and FXAA seemed to give the best results, whereas enabling all others at the same time still didn't affect performance as much as enabling MSAA alone.

Edited June 12, 2021 by MirceaKitsune

[OrbWeaver]

Interesting to learn that TAA applies a jitter. Reading about TAA and its focus on motion I could never understand why TAA looks so good in Elder Scrolls Online even when I wasn't moving, but I guessed it must be doing some kind of "simulated motion" when the player is standing still. At work I implemented a basic jitter-based antialiasing for our spline rendering years ago (four samples for every frame in a fixed pattern), but never really thought of it as "TAA" — perhaps we should advertise it as such.

Personally I wouldn't choose to use FXAA but I have no objection to it being available for people with lower-end video cards, if someone wants to implement it.

[MirceaKitsune]

I'm down with TAA or any option. I think the decision should be based on three criteria: How much it reduces aliasing and thus looks as good as MSAA, how much performance it gains us compared to it, and how easy it is for the developers to integrate into the engine so this improvement can hopefully catch the next release.

On FXAA I can only say I noticed a few FOSS games started using it recently, which means it's probably the most popular alternative. The latest version of 0ad has it as a menu option, Red Eclipse I already mentioned, and I recently noticed that even Xonotic (darkplaces engine) implemented it as a hidden setting which I now enabled.

[HMart]

What about SMAA? Invented by Crytek and some Spanish university, can't confirm but some sources say it looks better than FXAA.

 

Edited June 12, 2021 by HMart

[MirceaKitsune]

3 hours ago, HMart said:

What about SMAA? Invented by Crytek and some Spanish university, can't confirm but some sources say it looks better than FXAA.

 

Is it also as fast? Also, regarding FXAA, on what Cabalistic mentioned earlier and in the initial chat: FXAA is supported by the video driver, however it's not an option you enable at runtime, I looked for a system parameter and couldn't find a way. The engine probably needs a flag to call OpenGL with this feature. If that's the case and I understood correctly, supporting it would be a matter of just implementing a menu option linked to a renderer initialization call. Don't know for certain if that's the case, just what I'm gathering so far.

[Xolvix]

I generally dislike TAA/temporal antialiasing because so many games implement it badly. It does do its job pretty well but as mentioned before, it creates a subtle ghosting effect during motion that plays badly with my eyes. In many cases if another antialiasing method isn't available I'd rather go WITHOUT antialiasing than suffer with TAA.

That said, implementation is key. Deus Ex: Mankind Divided has temporal antialiasing that seems to be reasonably well done and doesn't bother me as much as some other implementations. I suspect it also has a lot to do with the scenery. Far Cry 5 has TAA as an option and it blurs the shit out of grass/foliage in motion and really gets distracting. DXMD doesn't have much in the way of grass and fine scenery and has more suburban, lived-in architecture, so maybe that helps. TDM would be closer to rendering more of the latter so it could be tolerable, but please if you ever do it, keep the classic MSAA that's already there (which I use at 4x with no real problems).

[cabalistic]

7 hours ago, MirceaKitsune said:

Is it also as fast? Also, regarding FXAA, on what Cabalistic mentioned earlier and in the initial chat: FXAA is supported by the video driver, however it's not an option you enable at runtime, I looked for a system parameter and couldn't find a way. The engine probably needs a flag to call OpenGL with this feature. If that's the case and I understood correctly, supporting it would be a matter of just implementing a menu option linked to a renderer initialization call. Don't know for certain if that's the case, just what I'm gathering so far.

No, there is no such option or flag for OpenGL. You can literally enable it in the NVIDIA graphics panel for any game. The Radeon software has a "morphological anti-aliasing" option that you can enable, although I'm not entirely sure which implementation it is.

[HMart]

6 hours ago, MirceaKitsune said:

Is it also as fast? Also, regarding FXAA, on what Cabalistic mentioned earlier and in the initial chat: FXAA is supported by the video driver, however it's not an option you enable at runtime, I looked for a system parameter and couldn't find a way. The engine probably needs a flag to call OpenGL with this feature. If that's the case and I understood correctly, supporting it would be a matter of just implementing a menu option linked to a renderer initialization call. Don't know for certain if that's the case, just what I'm gathering so far.

Based on what I read, it is a tad slower than FXAA but is obviously way faster than MSAA or SSAA. 

Btw you can try it on x86/D3D games with this injector but based on the link bellow, it can be implemented in OpenGL.

Here is a example implementation for OpenGL 

[HMart]

13 minutes ago, cabalistic said:

No, there is no such option or flag for OpenGL. You can literally enable it in the NVIDIA graphics panel for any game. The Radeon software has a "morphological anti-aliasing" option that you can enable, although I'm not entirely sure which implementation it is.

AMD driver forced MLAA, unfortunately is only for D3D9/10/11 games, it does a nice job at removing jaggies, unfortunately has the bad biproduct of making text in GUI's distorted but that imo, is because of being forced and not directly implemented in the game. I seem to recall at lest of one game that came with MLAA in the options, I think it was Dishonored 2 but I'm not sure, where that text distortion doesn't happen. 

Edited June 13, 2021 by HMart

[HMart]

In the topic of SMAA, not sure if true but this link says this about it.

Quote

SMAA was introduced to rectify the shortcomings of both FXAA (too much blurring) and MLAA (limited coverage), and it works well in most scenarios. It works by leveraging edge-detection based on color-specific luma, and searching the edges at the top and left of every pixel while retrieving the other two from neighboring pixels.

 

[MirceaKitsune]

So far the consensus seems to be that SMAA and TAA would be the better options. They're both popular implementations and the screenshots I'm finding suggest they're pretty good. From what I'm seeing SMAA appears to look best, but this could mean it's also slower as some articles indicate, so TAA may be the ideal middle option.

Is the engine presently in a position to make at least SMAA easier to attempt implementing so far, or any of the other options available to us? Based on how our available render passes and shaders and other core components are set up to work, in hopes that major changes aren't necessary to support either of them.

[cabalistic]

14 minutes ago, MirceaKitsune said:

From what I'm seeing SMAA appears to look best, but this could mean it's also slower as some articles indicate, so TAA may be the ideal middle option.

It's not that simple. There are different sources of aliasing. TAA, as the name implies, specifically targets *temporal* aliasing artefacts, which happen when objects or the camera move. Neither FXAA nor SMAA (in its purely post-processing form) do anything against those artefacts, but you won't see those in a still image. They become really apparent for e.g. small objects in the distance when you move the camera - you'll notice a very obvious edge shimmering, even if in a still image it might look fine. A good example would be Skyrim when looking at some trees in the distance - here the difference between FXAA and TAA becomes very obvious when moving the camera around.

In its basic form, SMAA is just another purely post-processing effect like FXAA, so the same restrictions and caveats apply. It might do a better job at detecting edges to blur than FXAA, but it doesn't magically have access to any more information than is already in the rendered image, so it's still just blurring edges. It is almost certainly cheaper than TAA and easier to implement, but it also does nothing against temporal aliasing, so it will not stabilize images in motion. SMAA can be combined with MSAA or TAA, though, although at that point it obviously becomes a lot more expensive...

[MirceaKitsune]

51 minutes ago, cabalistic said:

It's not that simple. There are different sources of aliasing. TAA, as the name implies, specifically targets *temporal* aliasing artefacts, which happen when objects or the camera move. Neither FXAA nor SMAA (in its purely post-processing form) do anything against those artefacts, but you won't see those in a still image. They become really apparent for e.g. small objects in the distance when you move the camera - you'll notice a very obvious edge shimmering, even if in a still image it might look fine. A good example would be Skyrim when looking at some trees in the distance - here the difference between FXAA and TAA becomes very obvious when moving the camera around.

In its basic form, SMAA is just another purely post-processing effect like FXAA, so the same restrictions and caveats apply. It might do a better job at detecting edges to blur than FXAA, but it doesn't magically have access to any more information than is already in the rendered image, so it's still just blurring edges. It is almost certainly cheaper than TAA and easier to implement, but it also does nothing against temporal aliasing, so it will not stabilize images in motion. SMAA can be combined with MSAA or TAA, though, although at that point it obviously becomes a lot more expensive...

Thanks for clarifying. Temporal AA might be unneeded then, I've never seen movement artifacts. I only use AA to get rid of jagged edges in both still and moving frames.

Considering all this then, I'd honestly be very happy if FXAA and / or SMAA could be implemented for the time being please. I know it's just a targeted blur filter which might seem useless from a developer's perspective, yet what it achieves makes it worth it: It gets the job done for most edges, is very fast at it, popular in many engines, easy to implement as it requires no special passes, and on top of that it also fixes sharp edges in alpha textures not just geometry which is a bonus the others don't offer.

It doesn't need to be on by default as far as I'm concerned. If you're uncertain about it, I'm fine with adding it as just a hidden cvar for now... if it helps I can test it before we decide if it should be in the menu at all; I'd even be happy with it as a hidden setting one can enable from the console. I'm hoping to maximize performance on my 144 Hz screen this way (run at >= 144 FPS) which would help a lot on top of all the new optimizations. Hope you can consider it till other options become easier to implement.

Edited June 13, 2021 by MirceaKitsune