Screen space effects + 16× MSAA cause blurry screen

[everythingandnothingdev]

Godot version

3.3.2.stable

System information

Windows 10, Vulkan, RTX 2080

Issue description

MSAA appears to mistakenly cause blurry screen when screen space effects are enabled. FXAA does not have the same problem.

MSAA 16x, SSAO OFF, SS Reflections OFF

MSAA 16x, SSAO ON, SS Reflections OFF

MSAA 16x, SSAO OFF, SS Reflections ON

Steps to reproduce

1. Enable MSAA to 16x in project settings
2. Add a WorldEnvironment node to scene
3. Either enable Ssao or Ss Reflections

Minimal reproduction project

No response

[Calinou]

Due to how it's implemented as a combination of 4× MSAA and 4× SSAA by the graphics driver, 16× MSAA causes various issues and will likely be removed. This leaves 8× MSAA as the highest supported option, which is very demanding already (given the overall higher requirements of the Vulkan renderer compared to Godot 3.x's GLES3 and GLES2). It's surprising that the editor doesn't freeze completely on your end :slightly_smiling_face:

For performing offline rendering (e.g. for promotional media), it's a better idea to use 8× MSAA, render at a higher resolution then downscale the image/video manually. This is effectively a form of supersampling, and will also smooth out transparency/specular aliasing in a way that MSAA doesn't.

[everythingandnothingdev]

This bug is for 3.3.2, not Vulkan.

[SirQuartz]

This bug is for 3.3.2, not Vulkan.

The outcome is the same regardless of whether or not you use Vulkan, GLES3, DirectX, or any 3D rendering API. Because of how 16x MSAA works, it's extremely excessive and expensive to render in real-time, not to mention it causes a lot of issues. MSAA is a method of supersampling, which by its very nature, is expensive. 16x MSAA should definitely be removed as an option altogether, it's basically redundant anyway. With 16x MSAA you're effectively rendering at 16x the resolution in some parts of the image, so if your game is at a 1080p resolution of 1920x1080, and you're using 16x MSAA you're actually effectively rendering at 30720x17280 in some parts of the image, which is just ridiculous.

I think there are other options for anti-aliasing that the engine could add like TAA, which is in almost every game out there these days. It's a more modern implementation of anti-aliasing and uses a fraction of the rendering power that MSAA does while also providing near-identical quality in parts of the picture with no motion. SMAA would also be a nice addition.

[Calinou]

With 16x MSAA you're effectively rendering at 16x the resolution in some parts of the image, so if your game is at a 1080p resolution of 1920x1080, and you're using 16x MSAA you're actually effectively rendering at 30720x17280 in some parts of the image, which is just ridiculous.

16× MSAA is internally 4× SSAA + 4× MSAA in most graphics drivers, so it would internally render at 3840×2160 (+ 4× MSAA on top), not 30720x17280.

Some graphics drivers allow choosing 2× SSAA + 8× MSAA as a cheaper alternative, but it's never the default when using "16× MSAA" in an application in my experience.

I think there are other options for anti-aliasing that the engine could add like TAA, which is in almost every game out there these days. It's a more modern implementation of anti-aliasing and uses a fraction of the rendering power that MSAA does while also providing near-identical quality in parts of the picture with no motion. SMAA would also be a nice addition.

See https://github.com/godotengine/godot-proposals/issues/2779. TAA is planned in a future 4.x release, but not 4.0 as it requires significant changes to the renderer to expose motion vectors.

Edit: TAA was added in 4.0 by https://github.com/godotengine/godot/pull/61319.

[Calinou]

@everythingandnothingdev Can you reproduce this when using 8× MSAA instead of 16× MSAA?

[everythingandnothingdev]

No, like you said it only happens on 16x