SSAO featured PG example error "*trying to reuse a post process not defined as reusable"

Dears,

This is both what I believe to be a bug and also next, a question/request for help on:
‘Using SSAO with multiple cameras’

The bug:
In this only featured PG example in the doc for #SSAO:

Babylon.js Playground

Description: Press 1,2,3 then press 1 again and see the error thrown (eventually multiple times) saying we are attempting to reuse a post process (this one or may be the related DoF from the default pipeline?)

The question/issue
As reproduced in this PG, with the adding of a second cam, I tried different methods for detaching/attaching the camera/pipeline or even dispose of it (also with ‘true’) to deactivate the DoF (which according to doc is said to be used for SSAO). You can try play along with my PG. It mostly shows that SSAO is rendered with the camera which I believe is ‘in use’ BEFORE the error is thrown. I also suppose that, once the error occurs, any further instruction like the switch of the scene active camera will be ignored, correct?

https://playground.babylonjs.com/#N96NXC#47

Could yours please look into this and let me know?
Thanks a lot,

Adding @CraigFeldspar who created the SSAO post processes.

Hi @mawa,

Is your targeted platform webgl2 capable ? I would first try the SSAO2RenderingPipeline which is way more performant and may solve your problem.

Here is the PG Example :
https://playground.babylonjs.com/#7D2QDD#0

Cheers,

Thanks for your quick answer and suggestion,
I believe I could use or add this. But then, the same error is still displayed with SSAO2 in your PG.
Can I use SSAO/*2 with multiple cameras (switching camera)? Should I disregard this error (I’d rather not if possible)?

Actually the PG example is probably a bit outdated.
It seems like if you enable an effect that is already enabled (with attachCameraToRenderPipeline), this error pops (under the hood, enableEffectInPipeline attaches a post-process to a camera, like attachCameraToRenderPipeline).

If you want to make things in a cleaner way, you need to keep track of the enable/disabled status of the effect like in this PG : https://playground.babylonjs.com/#7D2QDD#28

That said, the error is also followed by a return statement, which cancels the postprocess attachment, so it can be ignored (even though I agree it ain’t pretty :smile: )

1 Like

Thank you, I guess I got this part and will also try to use the ‘cleaner way’:wink:
The values are quite different from SSAO, especially with radius and min- & maxZ and also ‘base’. I’m actually having a hard time setting appropriate values for my scene. Any advise for a larger scene (2500x2500) where you can zoom out or in a max. When I zoom in closer either I loose the effect, or the other way round, when I zoom out I start getting unwanted results, depending on the parameters I set. In this aspect I found SSAO easier to manage (or it could be just me). Discovering…

SSAO could be indeed a lot improved, maybe for a further version ? @Deltakosh @sebavan ?

1 Like

Yes, well, in terms of ‘design’ (or FX) I didn’t find SSAO/*2 very convincing.
I’m still happy to have found how to use them with multiple cams and isolate my skybox and cloud layers. This part works now (and without error;) all thanks to your input.
So, Thanks A LOT for taking the time and have a great day :smiley:

1 Like

Happy to help :slight_smile:

Here is a last one to close the case on my side:

I found SSAO (the original;):

  1. easier to use than ssao2
  2. providing better results (from a distance)
  3. unable to work with multicam !? At least, not in the same manner as SSAO2. At least, I didn’t succeed… will you?:wink:

Now, below is a dirty (sry;) and simplified PG illustrating my case with SSAO vs SSAO2.

https://playground.babylonjs.com/#N96NXC#61

Using the same approach, I tried switching cameras with SSAO and SSAO 2.
The result: SSAO seems to always use the first camera (declared or attached), where SSAO2 allows you to instantly detach (camera and combine?! and attach new (or in other words, switch camera).

Last question: Should I abandon the idea of using SSAO with multicam or is there a way (different from SSAO 2)? The point is, if I strictly apply the SSAO2 switch camera/render method to SSAO, I eventually end with a black a screen and a warning on a buffer/texture (which I believe is for my ‘snow accumulation’ textures for which I have slightly ignored;) the ‘recommendations’ for alpha blending and depth;) Though, I believe this result shouldn’t end up with a black screen, again in my opinion only. And it doesn’t with SSAO2.
I’ll let you Guys figure the big thing… Just wanted to share my personal experience of this part.
Keep’up with the great work and have an awesome day,