Document sub-pixel morphological antialiasing (SMAA)

[MJacred]

• For Godot 4.5, depends on merging Add SMAA 1x to screenspace AA options godot#102330

[tetrapod00]

The demo for generating the images is https://github.com/Calinou/godot-antialiasing-comparison, see this comment on the page:

godot-docs/tutorials/3d/3d_antialiasing.rst

Lines 6 to 8 in f8ce2c9

	.. Images on this page were generated using the project below
	.. (except for `antialiasing_none_scaled.webp`):
	.. https://github.com/Calinou/godot-antialiasing-comparison

[tetrapod00]

I'm not sure if this should be a footnote in the table. It's the kind of relatively small difference that IMO should be made in the section about SMAA earlier in the page. SMAA and FXAA both have a "low" performance cost by the standards of this table.

I do understand the desire to differentiate between the two postprocessing techniques, but I think if we start adding footnotes for every comparison the table loses it's value as a succinct summary. I'd like to hear what other maintainers think though.

[MJacred]

I fully understand your concern.

Perhaps it is agreeable to introduce new adjectives instead of the footnote; proposals:

• Added blur: Light / Less / Lowest / Minimal / Minimum / Reduced
• Performance cost: Low-Medium / Mild

Or use "Low" for "Performance cost" of SMAA and change cost value for FXAA to "Very Low".

NOTE: my personal preference highlighted in bold

[tetrapod00]

I approve of "very low" and "low" for the performance cost FXAA and SMAA. I'd prefer adding more distinctions at the "very low" and "very high" levels rather than the "low-medium" or "medium-high" levels for clarity's sake.

However, can you (at least briefly/casually) test the performance difference between FXAA and SMAA, and verify that the performance difference is actually big enough to justify using both "very low" and "low"? If the difference is very minimal, I think it would be more appropriate to keep using "low" for both.

For added blur, I approve of adding at least one more descriptor. I would avoid "lowest" IMO because the lowest amount is "none" 🙂. For blur, I think I would personally go with one of these (preference is bolded):

• "none", "less", "some", "more"
• "none", "minimal", "some", "high"
• "none", "low", "some", "high"

The "more" or "high" category might not be needed.

This would require re-evaluating the blurriness of the existing options to categorize them in the new system (most should remain as "some"). There should be enough information in the page to do so, I mostly used the info already on the page when I added the table.

[MJacred]

I would avoid "lowest" IMO because the lowest amount is "none" 🙂

that… makes sense

---

For blur, your preferred counter-suggestion makes sense to me.

---

However, can you (at least briefly/casually) test the performance difference between FXAA and SMAA […]

I used Calinou's project for testing the performance, but FXAA does not appear in the visual profile, SMAA appeared (I turned off the viewport 1 which shows the same w/o antialiasing), and SMAA had most of the time 0.09 ms GPU, and randomly spikes to ~1.25 ms. FXAA cannot be tracked.

Afterwards, I tested the FPS demo (pressed "Play" so it was the actual game), and when using FXAA, the max FPS on my computer is 49/50 FPS. For SMAA, I get 47/48 FPS.
Funny (sarcasm) fact: I reset the 3D scaling mode from FSR 2 to default Bilinear, and it still appeared as "FSR2" in the visual profiler, consuming GPU and CPU. Though I didn't see it in the other project (see screenshots below).

Here some screenshots of the stats from Calinou's project: first FXAA, then SMAA

[tetrapod00]

Afterwards, I tested the FPS demo (pressed "Play" so it was the actual game), and when using FXAA, the max FPS on my computer is 49/50 FPS. For SMAA, I get 47/48 FPS.

I know FPS comparisons are not that robust, but IMO this seems close enough that we could still call both SMAA and FXAA "Low" performance cost for the purposes of the table. But, calling FXAA "very low" also seems reasonable, so I'm happy with the current state of the PR.

I'm going to leave this conversation unresolved in case anyone else wants to see the context when this gets further review.

[tetrapod00]

Looks good for docs formatting, and matches my casual understanding of the performance of SMAA. Still waiting on a merge of the engine PR, and will need another round of review at that time.