Enable FXAA by default for better visuals out of the box

[Calinou]

• Related to Improve Default 3D Lighting & World Environment #348.

Describe the project you are working on

The Godot editor 🙂

Describe the problem or limitation you are having in your project

A common complaint about out-of-the-box visuals in Godot's 3D renderer is the lack of any form of antialiasing. This, combined with the lack of anisotropic filtering by default, gives the renderer an amateurish image until you tweak it to give better results.

This issue creeps up even in official development blog articles, which shows that it's something that should be resolved somehow 😉

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Note: This change only affects 3D projects, not 2D, as FXAA only operates on 3D rendering.

Enable FXAA by default. This will lead to higher-quality visuals out of the box, which will also be visible on screenshots and videos taken by Godot users.

This proposal suggests enabling FXAA on both desktop and mobile, but we can also choose to enable it only on desktop platforms using feature tags.

While this change targets Godot 4.0, this change can also be backported to new projects in Godot 3.x by changing the generated project.godot file's contents. This only occurs when the project manager is used to create a new projects, so existing projects wouldn't be affected by this change.

FXAA has many attractive traits for use as a default antialiasing mode in Godot:

• FXAA has a very low cost on the GPU compared to other antialiasing solutions. For games with complex 3D visuals, it's generally the only AA solution that is viable on mobile and integrated graphics. When targeting 1440p or 4K, FXAA may be all you need, especially on higher DPI displays.
• FXAA smooths out the edges of alpha-tested materials, which are often used in foliage.
• FXAA helps hide dithering patterns, such as the one visible in shadow rendering. Taken from the screenshots below:

No FXAA	With FXAA

The main downside of FXAA is the blurriness it adds, which is especially noticeable at lower resolutions. This can be alleviated in several ways, such as #4657 or #1519. If we end up accepting either of those proposals, the former could help reduce the added blurriness out of the box (while sharpening is something that should be enabled by the user manually).

---

Question: Why not enable multisample antialiasing (MSAA) instead?

MSAA is a good solution for edge antialiasing, but it has several downsides:

• MSAA is very expensive on the GPU in modern renderers, especially at higher resolutions. We could only realistically consider using 2× MSAA, which isn't that good on its own. (2× MSAA is pretty alright if you use FXAA or TAA on top, but it becomes even more demanding.)
• MSAA doesn't affect alpha-tested surfaces and doesn't reduce specular aliasing in any way. While FXAA doesn't resolve specular aliasing, it does alleviate specular aliasing a little in some scenarios.
• MSAA doesn't reduce the shadow dithering pattern's visibility like FXAA or TAA can do.

---

Question: Why not enable temporal antialiasing (TAA) instead?

TAA is a good solution in some cases, but has several caveats:

• Due to its temporal nature, TAA leaves visible disocclusion and ghosting artifacts which can be distracting. This happens even if proper motion vectors are generated. People may think that these are engine bugs (and some will file issues as a result¹), while these are actually limitations of any TAA solution in any engine.
• Not everything in Godot will generate proper motion vectors for TAA yet (such as UV scrolling, skeletons, soft bodies, etc). This results in visible ghosting trails when one of those objects moves.
• TAA is more demanding than FXAA, even if Unexpectedly low performance of temporal antialiasing due to high GPU cost godot#61905 is resolved.

---

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I have a branch implementing this change: https://github.com/Calinou/godot/tree/viewport-default-fxaa

Here are some comparison screenshots in scenes with the default environment settings:

1152×648

New proposed default window size.

Basic scene, VoxelGI

No FXAA	With FXAA

Textured Octavus, SDFGI

No FXAA	With FXAA

1920×1080

Typical fullscreen resolution.

Basic scene, VoxelGI

No FXAA	With FXAA

Textured Octavus, SDFGI

No FXAA	With FXAA

If this enhancement will not be used often, can it be worked around with a few lines of script?

No.

Is there a reason why this should be core and not an add-on in the asset library?

This is about changing a default setting to improve the out-of-the-box experience with Godot's 3D renderer.

Footnotes

1. We regularly get issues opened about ghosting trails left behind moving sprites in 2D, while it's actually due to an hardware issue (monitor ghosting/slow display response times). ↩

[jcostello]

FXAA has some problem with lines. The AA looks weird and also as it well know, it blurs textures

[clayjohn]

I agree with jcostello, I don't think FXAA should be on by default. It can cause significant blurriness in textures and makes a mess out of lines.

[Calinou]

I agree with jcostello, I don't think FXAA should be on by default. It can cause significant blurriness in textures and makes a mess out of lines.

Do you have any other solution in mind? I'd prefer to have some kind of AA enabled by default in 3D, as screenshots/video screencasts will look bad by default otherwise.

• We can't enable TAA by default yet as it's still lacking motion vectors in some situations, and some people are averse to the ghosting artifacts it can create. I've seen reports of TAA causing motion sickness, but I don't know how much this applies to games targeting 60 FPS (as opposed to 30 FPS).
• SMAA handles thin lines better and doesn't blur the image nearly as much as FXAA, but it's not implemented in Godot yet. I'd have proposed that otherwise 🙂
• If we find a way to reduce MSAA's cost, perhaps 2× MSAA will be fast enough on dedicated GPUs. We'd still need to add an .integrated feature tag or similar to automatically disable it on integrated graphics.

What do other engines do here?

[Jamsers]

What do other engines do here?

Unity has no antialiasing by default, Unreal defaults to TAA

MSAA 2x is the most "lossless" default option IMHO, but cost is too heavy.

I agree that if SMAA were implemented into Godot, it'd make for an excellent middle ground default.

[xxSeys1]

Maybe we could have a checkbox when creating a project called something like 2x MSAA or Anti-Aliasing that is ticked by default with a warning that this may cause performance problems.

This could of course also be done with FXAA (+ a warning of maybe causing blurry textures/ lines etc) or TAA (+ a warning that this may cause noticeable ghosting).

[Calinou]

Maybe we could have a checkbox when creating a project called something like 2x MSAA or Anti-Aliasing that is ticked by default with a warning that this may cause performance problems.

This could of course also be done with FXAA (+ a warning of maybe causing blurry textures/ lines etc) or TAA (+ a warning that this may cause noticeable ghosting).

Having project templates is planned at some point, but I don't think it should be as granular as providing antialiasing settings directly in the project creation dialog. It could however automatically enable antialiasing if you choose a 3D template focused on high-end visuals (most likely TAA).

[thygrrr]

Absolutely against. FXAA is PS3 era quality and incompatible with a variety of modern rendering techniques.

I would suggest MSAA 4x as the default for desktop instead, and 2x on Mobile.

TAA is completely overrated and Godot's Implementation is problematic. MSAA is where it's at.

[Jamsers]

I agree that FXAA as a default in the year of our lord 2023 is terrible, not to mention Godot's FXAA implementation is quite low quality and has issues.

That being said, MSAA is still unfortunately a no go. MSAA is great and is about as "lossless" as it gets, but for lower end systems (think Intel iGPUs) even the lowest 2x setting is too heavy to enable by default.

If we can get SMAA implemented it could serve as a good default, or better yet CMAA2, which is even more "lossless" than SMAA and performs better, although at the cost of more aliasing.

[thygrrr]

AFAIK, MSAA 2x is considered "free" even on most mobile GPUs these days. On PC, it is generally considered that 4x still is a low impact measure. I'm rather sure it also applies to Iris graphics. I'll try to find a few test devices.

In fact, even Intel themselves work on implementations of Morphological AA that are designed to be COMBINED with MSAA, 2x and 4x MSAA is considered that much of a given default these days.

https://www.intel.com/content/www/us/en/developer/articles/technical/conservative-morphological-anti-aliasing-20.html

MSAA is not SSAA.

[Calinou]

On PC, it is generally considered that 4x still is a low impact measure.

This isn't the case in modern renderers for 2 reasons:

• Modern Forward+ rendering techniques make MSAA quite expensive, due to shader complexity. The overhead of MSAA isn't the same as it was in the late 2000s.

  • Be happy Godot isn't using deferred rendering, as MSAA with deferred rendering is even more expensive 🙂

• Integrated graphics constantly run into memory bandwidth constraints. In the 3D platformer demo, enabling 2× MSAA has a gigantic performance impact on Intel UHD 770 IGPs, for instance. Framerate is easily halved just by enabling 2× MSAA. (Most people's Intel IGPs are slower than this one, even though I tested on a desktop IGP which is slower than modern mobile IGPs.)

  • Most demos currently default to 4× MSAA, but I've considered changing this at some point. If we have a pc_low_end_gpu feature tag that is automatically enabled on integrated graphics, this won't be so much of an issue as we can disable MSAA on that feature tag.

Most AAA developers moved away from MSAA for these reasons, including its inability to counteract specular aliasing. Godot has alpha-to-coverage support to handle alpha-tested materials, but its roughness limiter barely does anything against specular aliasing.

In recent times, we're even starting to see mobile/Switch games starting to adopt TAA, despite these platforms not being ideal fits for it.

[Jamsers]

we're even starting to see mobile/Switch games starting to adopt TAA, despite these platforms not being ideal fits for it.

No Man's Sky's custom FSR 2 implementation on Switch is a revelation 😔🙏

Anyway yeah I am noticing more and more high end mobile games moving away from MSAA - Genshin Impact notoriously only has TAA on mobile, for example. I wonder if the old "MSAA is free on mobile" adage doesn't hold up anymore for games pushing the cutting edge of graphics on mobile? Although when I last worked in mobile a year ago MSAA was still the standard for the simple hypercasual games we were making on Unity.

[thygrrr]

On PC, it is generally considered that 4x still is a low impact measure.

This isn't the case in modern renderers for 2 reasons:

I am indeed happy Godot doesn't use deferred shading, because I'd much rather use my (non-IGPU) Hardware's ability to anti-alias cleanly in properly subdivided fragments of depth, stencil, and framebuffer for practically free; than have cheaper point lights, more expensive directional lights, and much, much more expensive anti aliasing costs, with the added overheads of sampling depth normals, motion vectors, past framebuffers, etc. (or whatever modern TAA samples)

I suppose modern Übershaders do add more cost to MSAA indeed. I can't imagine how that is cheaper with TAA, though. (which possibly disqualifies me from this discussion)

According to Wikipedia at least, unless it's very extravagant, TAA is conceptually simpler, but the added memory and final blend requirement for every past frame sounds really prohibitive. I also can't see any options how many frames deep the AA operates with most TAA solutions, or whether I'd like to conflate 2 or 3 frames into one frame to tighten the response. The added intra-polygon blur and the fact that mipmap biases are silently adjusted by Godot doesn't bode well for memory bandwidth and anything that depends on precise selection of mipmaps, either.

(my projects may be more impacted because I work a bunch with custom mipmaps)

But I can always choose MSAA, this discussion is about a default.

In recent times, we're even starting to see mobile/Switch games starting to adopt TAA, despite these platforms not being ideal fits for it.

I'm not a huge fan of TAA; but I admit this is a personal and very subjective preference. I consider its visual stability even in the best of the best AAA games (e.g. RDR2, Battlefield 1, Cyberpunk 2077) leaves much to be desired. I always run these with 8x MSAA, even if intra-texture and transparency antialiasing isn't always the best.

Thank you for explaining. I can accept that if you need to ensure support for integrated low-end graphics from a pre-2018 generation, then yes, MSAA by default is out of the question.

FXAA is incompatible with many types of renderers as well, though.

[Jamsers]

I consider its visual stability even in the best of the best AAA games (e.g. RDR2, Battlefield 1, Cyberpunk 2077) leaves much to be desired.

Funnily enough, the "best of the best AAA games" tend to also have some of the worst implementations of TAA in the industry: RDR2 is kinda famous for its utterly unsalvageable image quality at 1080p due to its horrendous TAA, and Cyberpunk has some of the smeariest TAA in the industry.

I too am glad Godot still provides options to make your game look good without having to rely on TAA. TAA is a nice tool to have in your arsenal but I hate it when it's the only tool and you're forced to use it.

[jams3223]

we're even starting to see mobile/Switch games starting to adopt TAA, despite these platforms not being ideal fits for it.

No Man's Sky's custom FSR 2 implementation on Switch is a revelation 😔🙏

Anyway yeah I am noticing more and more high end mobile games moving away from MSAA - Genshin Impact notoriously only has TAA on mobile, for example. I wonder if the old "MSAA is free on mobile" adage doesn't hold up anymore for games pushing the cutting edge of graphics on mobile? Although when I last worked in mobile a year ago MSAA was still the standard for the simple hypercasual games we were making on Unity.

Yes, I've analyzed their FSR 2 implementation, and I am baffled by how well they implemented it. I am praying for Godot to also improve upon it so it can look better than the other implementations.

[Calinou]

Closing, as we clearly need a project template system where you can choose between predefined settings (this was discussed with reduz a while ago). A blanket default option won't be able to address all use cases without significant downsides in some scenarios.

[xxSeys1]

This isn't the place to ask for help, for that see the godot discord:
https://discord.com/invite/zH7NUgz

[felipefacundes]

Thanks! I sent it on Discord!