Examples: Simplify composer setup in GTAO demo.

[Mugen87]

Related issue: #27317

Description

@Rabbid76 This PR simplifies the composer setup by not using MSAA and also rendering with the native resolution instead.

Ideally, user should not setup the render target for the composer manually. Besides, MSAA is not the best AA technique for (HDR) FX workflows. Yes, the demo does not use HDR but I suppose many users will use GTAOPass with a HDR workflow. Probably better to promote something different (like TAA or SMAA/FXAA) depending on the use case.

[Rabbid76]

@Mugen87 small change, impressive impact ���

[Mugen87]

The new demo runs at 60 FPS on my M2 Pro but on a Pixel 4a it runs with 10 FPS^^.

Lower frame rates with low/mid end mobile devices are not surprising. I just wonder if we should keep the example as it is so we have more usable results on a greater variety of devices.

[Mugen87]

I think rendering such effects in full native resolution is tricky on mobile devices. Projects have to compute the AO (and other effects) with smaller resolutions in order to avoid fragment-shader bound apps. For now, I don't add the device pixel ration for a better compromise of performance and quality.

[Rabbid76]

An AO algorithm is simply an approximation to an integral over a hemisphere. There are different algorithms, some are fast and give poor results, others are slower and give better results. GTAO belongs to the second category. None of the algorithms is ideal and all have advantages and disadvantages.

[Mugen87]

Indeed. Against this backdrop it might make sense to keep SSAO which is the fastest of SSAOPass, SAOPass and GTAOPass according to my first tests. However, it also provides the worst results.

We maybe can ditch SAOPass in the future since it is seems more expensive than GTAO and there are some quality issues in its example. It seems the effect tends to darken occluded areas too strong so they become almost black. Can't tell yet if this is okay...

[Mugen87]

@Rabbid76 If you have the opportunity, it would be great if you could test the new demo with a mobile device. I have noticed some artifacts on the loaded asset when you zoom out. It's hard to describe but it looks like black/shadowed stripes that are present on the entire asset (see screenshot). The also depend on what camera angle you look at the scene. The go away if you zoom closer into the scene.

[Rabbid76]

@Mugen87 I will have a look. The issue seems to be related to the sample distribution of the gtao and/or denoiser. Or the device resolution is simply not set correctly somewhere. Fortunately, there are still a few days until the next release.

[Mugen87]

No need to rush. 👍

The result of the pass is already impressive! Can't believe how good the AO has looked in the 5K rendering^^.

[Rabbid76]

Did some tests. Seems to be an issue with the depth buffer. AO only (no Denoise):

[Mugen87]

The depth precision of UnsignedIntType is >= 16 bits. On desktop, the value is usually higher but on mobile it could be indeed 16 bits which is too low. I think we can try this in setGBuffer():

this.depthTexture.format = DepthStencilFormat;
this.depthTexture.type = UnsignedInt248Type;

In this way, we definitely get 24 bits. That should be sufficient.

[Mugen87]

Link for testing: https://rawcdn.githack.com/Mugen87/three.js/a1fdeec4c496a306ea5f7bcfc3be009d4f52c14e/examples/webgl_postprocessing_gtao.html

Commit: Mugen87@a1fdeec

[Mugen87]

Um, that did not seem to help. Still getting the issue with a Pixel 4a.

[Rabbid76]

Yep, still the same. I will investigate this further...

[Mugen87]

Do you still get the issue with this version?

https://rawcdn.githack.com/Mugen87/three.js/6c820a3abba157edc3b98ff5066a915be525ed9e/examples/webgl_postprocessing_gtao.html

[Mugen87]

Respective PR #27320. The trick is using highp for the depth samplers.

[Rabbid76]

Solved! Thank you so much! ❤️

[Mugen87]

Awesome! BTW, with the default composer setup (without MSAA), the GTAO runs at 60 FPS on my Pixel 4a now 👍 .