Add SMAA 1x to screenspace AA options

[RGDTAB]

The quality settings used for edge detection and blending weight calculation are the defaults for SweetFX's ReShade implementation. I didn't add any way to change these settings as the very meager performance improvement between the highest and lowest settings didn't justify the visual difference between them.

• Production edit: This closes Integrate sub-pixel morphological antialiasing (SMAA) in the Vulkan renderer godot-proposals#2779.

[RGDTAB]

There is a proposal for SMAA already: godotengine/godot-proposals#2779

Right. I forgot to mention that in my first message. This is aimed at implementing that proposal.

[fire]

Are you able to run pre-commit -a and godot --doctool so tests can proceed? I'll try to get some instructions written in the future.

[RGDTAB]

Sure thing, but it looks like the only thing pre-commit wants to change is the last name of one of the authors of SMAA. Are you sure that's OK?

[tetrapod00]

It's definitely not right to misspell an authors name so the CI passes.

Looks like COPYRIGHT.txt is already skipped by codespell:

godot/pyproject.toml

Line 58 in eee39f0

"COPYRIGHT.txt",

But since the author name is in multiple files, the right fix might be to add "Masia" to the ignored word list:

godot/pyproject.toml

Line 66 in eee39f0

ignore-words-list = [

[RGDTAB]

Thanks for the clarification. It should be fixed now.

[Calinou]

Tested locally on macOS with Metal, it works as expected.

Testing project: test_pr_89582.zip
This uses the approach described in #89582 (comment) for testing.

Click to view at full size.

No AA	FXAA master	FXAA #89582	SMAA

SMAA does a better job at preserving detail compared to FXAA, while having slightly better edge coverage.

SMAA is not affected by #83089 either:

No AA	FXAA master	SMAA

[mrjustaguy]

While I know were in the beta stage as is right now and that's a feature freeze, I personally don't see much harm in getting this in 4.4 if it's ready, given there's practically no compat breakage, and our current screen space aa is bad (until FXAA 3.11 gets merged if it gets merged in the future which will break compatibility given significantly different behavior and performance of it compared to our current FXAA) and there are cases where only Screen Space AA is usable

Example: when using https://github.com/TokisanGames/Terrain3D breaking TAA/FSR2 due to Motion Vector issues (FSR2's somewhat usable, TAA however is not) and MSAA isn't an option due to Vulkan Synchronization issues in Godot when used with other effects like in #102646

Though do keep in mind Compositor SMAA (https://github.com/RGDTAB/Godot-SMAA) is also an option, though it's much harder to work with it, making a setting to turn it off/on

[DeeJayLSP]

Testing on the TPS demo (Native resolution, SMAA enabled, other AAs disabled). Edge detection seems a bit broken.

This also happened in Godot-SMAA back then

[mrjustaguy]

No, this is the SMAA settings.. the edge detection threshold needs to get really really low to catch some of the aliasing, and some of the aliasing just is due to a lack of samples, that SMAA and FXAA cannot help with.

[RGDTAB]

I think you're right that WebP would shrink the binary size, just maybe not by as much as you reported.
The WebP file you provided didn't have color information on pixels where the alpha value is zero. I've done a little testing with cwebp and found that if we preserve the colors with full transparency the raw WebP file is still about 4.5KB smaller than the PNG file. That would translate to about 6KB of savings when encoded to base64.

As for loading the WebP at runtime, we could try waiting until we actually try to apply the effect. By then all the modules should be loaded. We should probably be doing that even with PNG so that the texture doesn't take up room in the VRAM if SMAA isn't in use. WebP only supports RGB and RGBA, so it would have to be converted to RG or LA after loading so it doesn't take up more memory than needed.

The ultimate downside for using WebP for compression is that it would force a dependency on an optional module. We could either try and find a workaround to re-encode to PNG if WebP is disabled, or we could just issue a warning if someone tries to enable SMAA if WebP is disabled. If the binary size matters more than the header size then we could try skipping the Base64 encoding. That might shave off about 10KB from the binary. Maybe we could just store the PNG or WebP file in the repository, and then convert it to a header file when building.

[Calinou]

Maybe we could just store the PNG or WebP file in the repository, and then convert it to a header file when building.

I agree this would be the way to go. This is traditionally what we do for things like icons, while we haven't relied on Base64 encoding too much.

[Calinou]

Tested again, it works as expected on Forward+ only.

In Mobile, there's an issue where having SMAA enabled in the project settings has no effect in the running project (you need to change it at runtime for it to work). It will also be visible in the editor. In Forward+, it works on startup correctly. FXAA is also affected by this issue.

In Compatibility, there's now an error message printed when you try to enable either SMAA or FXAA (which is expected as neither is implemented there yet). We should probably harmonize these messages to turn them into warnings, but this can be done in a separate PR as there's many of them right now.

In the editor, a capitalization for smaa to SMAA should be added to this list in alphabetical order (as the SMAA Edge Detection Threshold project setting would then make use of it):

godot/editor/editor_property_name_processor.cpp

Line 138 in 80a3d20

EditorPropertyNameProcessor::EditorPropertyNameProcessor() {

Also, I found a slight binary size optimization using oxipng:

❯ oxipng -Zso6 AreaTex.png SearchTex.png 
Processing: AreaTex.png
Processing: SearchTex.png
120 bytes (11.76% smaller): SearchTex.png
27091 bytes (7.48% smaller): AreaTex.png

You can integrate the textures from this ZIP to the PR: smaa_textures.zip

I made sure fully transparent pixels are not affected this time (oxipng doesn't touch them by default).

Note

These figures take the above optimization I made into account.

Binary size comparison for a Linux release export template:

• master: 70,647,752 bytes
• This PR: 70,713,320 bytes

Binary size comparison for a web release export template:

• master: 37,222,703 bytes
• This PR: 37,225,000 bytes

It's only a 3 KB difference, but the web platform only includes the Compatibility rendering method, so this is expected.

[RGDTAB]

I'll get to work investigating what's happening with the Mobile renderer.
For now I've integrated the oxipng textures and your other suggestions, and fixed some merge conflicts.

[RGDTAB]

As @mrjustaguy has noted, the issue also exists outside of this PR with FXAA. There wasn't any check for screen space AA, so the mobile renderer will just run the tonemapper as a subpass for performance purposes if there aren't any other post processing effects enabled such as glow or DOF.
We can either fix it with this PR or I could open up another one, I'm cool with either.

[BlueCube3310]

As @mrjustaguy has noted, the issue also exists outside of this PR with FXAA. There wasn't any check for screen space AA, so the mobile renderer will just run the tonemapper as a subpass for performance purposes if there aren't any other post processing effects enabled such as glow or DOF. We can either fix it with this PR or I could open up another one, I'm cool with either.

Sorry for not reading this before, I only saw this comment now. That got fixed by #106631

[RGDTAB]

Sorry for not reading this before, I only saw this comment now. That got fixed by #106631

No problem! You got around to fixing it faster than I would have anyhow. Just updated this PR to make sure that the full post-processing pass occurs with SMAA also, so we should be all good now.

[BlueCube3310]

Tested again, it works as expected in both Mobile and Forward+

[Jamsers]

here are some comparisons from the latest build artifacts

no aa:

fxaa:

smaa:

[Calinou]

Tested locally, it works as expected in all rendering methods (in Compatibility, an error is displayed as intended).

I've also tested it in combination with TAA/FSR2 and it helps further reduce aliasing there, particularly in fast-moving scenes or just after a camera cut (the impact is more noticeable at lower FPS). Since SMAA doesn't blur the rendering as much as FXAA, it's more viable for this use case.

[Repiteo]

Thanks! Congratulations on your first merged contribution! 🎉

[akien-mga]

I notice now that this added some textures in thirdparty/smaa/. What's the source for those textures?

[Jamsers]

These are most likely the precomputed area textures that encode the location of edges, coverage areas, and precomputed areas for blending (SMAA paper)

Can be found here in the original SMAA repository. Generated with these scripts.