SSAO, Bloom need ping-pong implementation for WebGL

[prideout]

WebGL 2.0 on Chrome and Firefox do not allow what they call "feedback loops" for depth, and there are Khronos conformance tests in existence to enforce this. For more information, see:

https://bugs.chromium.org/p/chromium/issues/detail?id=1066201

We need to provide an alternate FrameGraph for SSAO on some platforms that employs a ping-pong strategy as follows. Say the mipchain is 5 levels, you create another one that's 4 levels. You do the processing from the first(level 0) to the 2nd, (level 0) then blit the 2nd (level 0) to the first(1), repeat.

[MingweiSamuel]

Does this issue prevent SSAO from working on Chrome/Firefox?

[prideout]

Yes, last time I checked it appeared to be more than just a warning, it looked wrong.

[MingweiSamuel]

I'm wondering since I've been trying to test SSAO but haven't been able to get it to do anything. Should I be seeing the GL_INVALID_OPERATION error in the dev console? (I'm not)

For example I tried going to https://google.github.io/filament/webgl/helmet.html and running

app.view.setAmbientOcclusionOptions({
        radius: 0.3,
        power: 1.0,
        bias: 0.0005,
        resolution: 0.5,
        intensity: 1.0,
        quality: 3,
});
app.view.setAmbientOcclusion('SSAO'); // or true

But nothing happens, so I'm not sure if that is this issue or I'm doing something wrong.

[prideout]

Yes you should see INVALID_OPERATION. The correct way to enable it is view.setAmbientOcclusion(Filament.View$AmbientOcclusion.SSAO).

I recommend using our TypeScript bindings to help catch stuff like this.

[prideout]

Update: something similar to the SSAO issue also occurs for bloom, even though bloom is using color attachments rather than depth.

[prideout]

Also: bloom does not work on desktop OpenGL on two of my home machines (it floods the viewport with white and flashes), and these are the two machines in my house that happen that have Intel GPU's.

So, in addition to the WebGL problem (GL ERROR :GL_INVALID_OPERATION : glDrawElements: Source and destination textures of the draw are the same.) we might need to do this for Desktop GL, at least for Intel GPU's.

[prideout]

This is something we've gone back-and-forth on, we've implemented it then removed it, etc. :)

The bug itself is very old and I'm surprised it's still open. Closing.