Implements an initial version of GTAO for 3.x

[drcd1]

An initial implementation of what was proposed here:
godotengine/godot-proposals#3223

GTAO can now be used by enabling SSAOand changing the property Type to GTAO

Here we can see a comparison between the default 3.x SSAO and GTAO:

SSAO (3.x) (with a finetuned combination of both radius and intensity parameters:

GTAO:

It still has a few problems, some of which are documented with //TODO: ... in drivers/gles3/ssao.glsl. Namely:

• The parameters thickness_attenuation_blending_parameter and 'distance_attenuation_start' (as well as the flags for enabling thickness_attenuation and distance_attenuation) are not exposed to the user.
• SSAO parameters which are not relevant for GTAO (intensity, radius2, intensity2) shouldn't be visible when GTAO is used.
• Distance attenuation should be done with respect to view space, not screen space (this should be a simple fix, but I want to test it with different scenes).
• Sampling should be improved (by sampling mipmaps and/or doing interleaved sampling (not sure if this requires a constant screenspace radius? ).

[Calinou]

Distance attenuation should be done with respect to view space, not screen space (this should be a simple fix, but I want to test it with different scenes).

@drcd1 Do you need someone to create a few scenes for testing? If so, I can do that.

[EzraT]

Thanks!

[atirut-w]

Is this PR still alive? I'd love to see this in 3.x but it's been so long since the last update

[Calinou]

Is this PR still alive? I'd love to see this in 3.x but it's been so long since the last update

See godotengine/godot-proposals#3720 (comment).

Temporal antialiasing won't be implemented in Godot 3.x, so I don't think this PR can be merged.

[SenhorPatolino]

4.0 has TAA, any chance this gets implemented? ( I haven't looked at the files yet so I wouldn't be surprised if this was not compatible with 4.0 anymore )

[Calinou]

4.0 has TAA, any chance this gets implemented? ( I haven't looked at the files yet so I wouldn't be surprised if this was not compatible with 4.0 anymore )

4.0.beta has ASSAO, which is a fast SSAO implementation that can be tweaked to look very good. It works well with or without TAA, although we don't jitter samples based on time when TAA is enabled yet. Doing so will allow making ASSAO look even better without increasing its performance cost.

I don't think implementing GTAO makes much sense when you already have ASSAO available.

[SenhorPatolino]

I hate to give out an opinion based on "what's best for what I see", but im not familiar with the "technical differences" between each so, I'll just say that on my experience with both SSAO and GTAO, GTAO has far better visuals than SSAO, it looks correct and I find it extremely difficult to find the screen-space issues ( I can tell with SSAO where the AO starts at the edge of objects or the screen corner ), I have also tested the performance of both before and I can still confirm that GTAO is extremely expensive.

Again, my bias towards it is based on what I saw comparing the two, I would like for an option in the project settings for either ASSAO ( cheap and average AO ) or GTAO ( expensive but the highest quality )

[Calinou]

@SenhorPatolino Note that "SSAO" is a generic term, as there are many SSAO algorithms out there:

• SAO (the one used in Godot 3.x)
• HBAO (and HBAO+, which is the same but at full resolution). This one is common in AAA games starting from the Direct3D 11 era.
• ASSAO (the current one in Godot 4)
• MSSAO (was attempted for Godot 4, but dropped in favor of ASSAO)
• CACAO (was attempted for Godot 4, but dropped in favor of ASSAO)
• GTAO (this PR)
• RTAO (raytraced ambient occlusion)
• …

As a result, when a game displays a SSAO option, you cannot use its name to infer what technique it's using behind the scenes. Usually, only HBAO and RTAO are referred directly with their original names in the game's options.

You also have to consider that shipping 2 SSAO implementations has a maintenance cost, along with a cost in the binary size itself (not huge in this case, but it's there). Both implementations need to be tested and have their bugs fixed, yet we only have so many rendering contributors available.

Also, GTAO still can't perform ambient occlusion with what is located outside the camera. For that, you need overscan, which can be used with any screen-space technique. Overscan cannot cater for every situation though; raytraced ambient occlusion would be the most accurate option, but it's the most expensive one. At this point, it begs the question whether we should bother with GTAO at all and go straight for raytraced ambient occlusion, since both are going to be expensive options that require TAA to look good anyway. Raytraced ambient occlusion works even with fully off-screen objects and occluded objects (something overscan can't do).

Lastly, with the PC GPU market and economy being in a dire situation, I wouldn't rush to add more high-end graphics features just yet 🙂

[SenhorPatolino]

Apologies for not being more specific, by SSAO I meant SAO and ASSAO ( usually SAO is labeled as SSAO in games so I misunderstood that, also I can clearly see the difference between SAO and ASSAO and needless to say it is a major improvement ), im aware that GTAO doesn't perform on whats outside the camera view, but I found it to be so good at handling it that it feels like its actually raytraced ( still expensive but im sure not as expensive as RTAO ). I have not considered the maintenance part so my bad at that, as for the performance cost, while much higher than ASSAO I wouldn't consider it being unviable for any mid-low GPU to handle. I love how GTAO looks but with ASSAO being the new default one I think no one would miss it much, whenever I find out how to merge this pull request into a fork ( Github newbie talking ) I will definitively be comparing both