Add support for contrast-adaptive sharpening in 3D (3.x, GLES3 only)

[Calinou]

3.x version of #47401.

This is an older, easier to implement variant of CAS as a pure fragment shader. It doesn't support upscaling, but we won't make use of it (at least for now).

The sharpening intensity can be adjusted on a per-Viewport basis. For the root viewport, it can be adjusted in the Project Settings.

Since textureLodOffset() isn't available in GLES2, there is no way to support contrast-adaptive sharpening in GLES2.

Preview

FXAA is enabled on both screenshots.

Slider comparison

Sharpening disabled

Sharpening enabled (intensity 1.0)

[Calinou]

This PR likely suffers from the same HDR issue as the Vulkan version, so I'll mark it as a draft until we find a way to fix it.

Edit: Fixed by #47401 (review), thanks @fire 🙂

[lawnjelly]

To me this looks fine. I can't comment on the method but if it is pretty standard then that seems safe to try out, and it seems to get removed from the shader when set to 0.0 so that is good.

If it were me I might be tempted to enclose the apply_cas in the shader with #ifdef but that's because I don't trust shader compilers. And the other functions aren't doing this I guess lol.

I don't know if @clayjohn has any preferences before trying it out.

[clayjohn]

As before, I think the code looks fine, but we absolutely need a test scene that utilizes CAS properly to verify that it is working correctly. We can't merge graphics features without testing them.

A proper test scene for CAS is one that has textures with high frequency detail that get blurred out by FXAA. Upon turning CAS on it should restore some of the high-frequency detail while maintaining the edge antialiasing. A test scene with untextured blocks only shows that CAS adds some amount of aliasing to edges. We need a test scene that shows that this implementation of CAS sharpens high-frequency textures more than it aliases edges.

edit Ah, so sorry, my finger slipped. I did not mean to close this. I support the PR and I think it is likely ready to merge, but it needs to be tested before we do so.

[Calinou]

@clayjohn I made a test project for the master version of this PR: https://github.com/Calinou/test_contrast_adaptive_sharpening

[clayjohn]

I think CAS needs to run in its own pass after tonemapping for 2 reasons:

1. It needs to read the output after FXAA is applied (currently only the central pixel "e" uses the FXAA colour)
2. It needs the input to be linear and 0-1 range otherwise we will get ringing artifacts.

For the Vulkan version you can avoid the extra pass by writing out the results to local memory and placing a barrier after tonemapping. For GLES3, you will need to break it into 2 passes. First pass should run as normal, but write to an intermediate buffer, then the second pass should apply CAS by itself.

For a more detailed explanation of the above, the notes in the original implementation are really helpful

[Calinou]

@clayjohn Thanks for the insight! Unfortunately, I don't know how to use local memory and barriers (I have no actual Vulkan experience).

As for running CAS in a second pass in GLES3, wouldn't that decrease performance noticeably? It also doesn't sound easy to introduce multi-pass post-processing shaders in Godot right now. Having that knowledge would be useful for implementing SMAA, so I'm all for it 😛

Due to this, I'll need to have someone else finish this feature if we want it to be merged in a reasonable timeframe – unless we're OK with merging this PR in its current state. I think it certainly works right now, even though it's not ideal. Ringing artifacts will generally not be as noticeable with intensities around 0.5.

[akien-mga]

There are some style issues to fix, and docs to sync. Otherwise is this ready to merge / get tested for 3.4?

[Calinou]

I rebased and added documentation for the newly exposed properties/methods.

[akien-mga]

Thanks!

[akien-mga]

I might have merged a bit fast since I'm not sure @clayjohn's feedback was addressed. But since this is opt in, I guess we can get it tested and bugfix/adapt the implementation based on user reports in 3.4 betas?

[Calinou]

I might have merged a bit fast since I'm not sure @clayjohn's feedback was addressed. But since this is opt in, I guess we can get it tested and bugfix/adapt the implementation based on user reports in 3.4 betas?

clayjohn's feedback doesn't seem to be essential to get working CAS (even with FXAA enabled), but it would look more correct in certain situations. From my testing, CAS looked good enough already, so I would wait and see if anyone has problems with the current implementation.

[Calinou]

For future reference, I pushed a 3.x-compatible version of the testing project: https://github.com/Calinou/test_contrast_adaptive_sharpening/tree/3.x