Disabling SSAO2 breaks FXAA

PG: Babylon.js Playground
If you press 2 to disable SSAO2 you will see a strange effect if you move the camera.
This happens only with babylon.js 5.0 (not with 4.2) and only if FXAA is enabled.

It seems there’s no framebuffer clearing when disabling the effect.

Pinging @CraigFeldspar as it is linked to the pre-pass renderer (when forcing the geometry buffer by setting the 5th parameter of the SSAO2RenderingPipeline constructor to true it does work).

Opened a PR for that issue adding autoclear to PP when unlinking prepassRT by CraigFeldspar · Pull Request #10676 · BabylonJS/Babylon.js · GitHub. It was indeed the autoclearing of the postprocess that got disabled by the prepass, and not re-enabled when disabling the prepass.

Waiting for the PR to be merged, you can fix your playground by adding :

     tFXAA.autoClear = true;

Just like in this PG :
https://playground.babylonjs.com/#QFXII0#2

3 Likes

You rock !!! I ll make a nightly ASAP.

The Fix works but i noticed another problem. You can see it in this PG if you press 2 to disable SSAO2: https://playground.babylonjs.com/#QFXII0#3

After disabling SSAO the drawing order is messed up. Just like if depth testing is disabled.
Again this happens only if FXAA is enabled.
It seems thats its currently important to create the FXAA instance before the SSAO instance. If you create it after SSAO you will get this problem. Is this a bug?

It sounds normal that order is quite important as the creation order will be the run order.

The problem i have is that there is no direct way to enable or disable a postprocess. I have to detach it from the camera and if i attach it later again the order has changed. I have several postprocesses that i want to enable and disable dynamically very frequently.

I just saw that my playground works with version 4.2. Only version 5.0 has this problem.

@CraigFeldspar might have an idea?

One more thing: If you dispose the SSAO2 postprocess instead of detaching it you will get the same problem. Disposing something should not have such side effects i would say.

@Kesshi nope, it should definitely not :slight_smile: @CraigFeldspar will have a look soon nw.

1 Like

I found the problem, we have a condition when generating DepthBuffers for post processes which is shown on that capture :

Turns out all of these null postprocesses are messing with us.
@sebavan do you remember why we are setting the postprocess reference to null when disposing/detaching in the camera postProcess list instead of just performing splice ? I’m thinking about cleaning all of these null but maybe there is an underlying reason (keeping the order when removing/adding ?)

No reason, feel free to drop them :slight_smile:

@CraigFeldspar Some news about this issue? ( sorry for being impatient :slightly_smiling_face: )

@Kesshi holidays went through :slightly_smiling_face: but I’m back now, having a look this afternoon, PR should come shortly after

PR is here https://github.com/BabylonJS/Babylon.js/pull/10887, should be merged soon and you should be good to go with the next alpha build

2 Likes

The PR looks like it’s merged.