Ssao 2 has different results each time i add it to the scene ( video showing it )

HI All

So im using some SSAO2 and im seen some weird behaiour in that it does not always display the same?

Please look at the video to see what i mean and if possible test the site clicking the same button I was clicking and see if it is happening on your end ( if you want the scene to look the same for you just click “preset 2” in the side nav



Something to note , im only using 1 sample , this is because after much testing , when it does display right it gives the most tight corner radius compared to when you have more samples

this is the function used to toggle the effct :

> function setSSAO2(state) {
>   if (state === true) {
>     if (SSAO2RenderingPipeline.IsSupported) {
>       // Create SSAO and configure all properties (for the example)
>       var ssaoRatio = {
>         ssaoRatio: 1, // Ratio of the SSAO post-process, in a lower resolution
>         blurRatio: 0.5, // Ratio of the combine post-process (combines the SSAO and the scene)
>         combineRatio: 1,
>       };
>       SSAOPipeline = new SSAO2RenderingPipeline("ssao", scene, ssaoRatio);
>       SSAOPipeline.radius = 1;
>       SSAOPipeline.totalStrength = 1;
>       SSAOPipeline.base = 0.2;>       
>       SSAOPipeline.samples = 1;
>       SSAOPipeline.maxZ = 250;
>       SSAOPipeline.minZAspect = 0.02;>       
>       scene.postProcessRenderPipelineManager.attachCamerasToRenderPipeline(
>         "ssao",
>         camera
>       );
>       scene.postProcessRenderPipelineManager.enableEffectInPipeline(
>         "ssao",
>         SSAOPipeline.SSAOCombineRenderEffect,
>         camera
>       );> 
>       //fix for ssao affecting transparent objects
>       scene.enableGeometryBufferRenderer().renderTransparentMeshes = false;
>     }
>   } else {
>     if (SSAOPipeline !== null && SSAOPipeline !== undefined) {
>       SSAOPipeline.dispose();
>     }
>   }
> }

Could you repro on a playground as debugging from your app is not as convenient for the community ?

@CraigFeldspar any idea what it could be ?

yes i understand , let me create a playground for you

well here is a PG and im adding the same default pipeline and ssao and glow layer but never mind the glitch … I cant even make it show a single thing?? ( well very lightly )

1 Like

ok playground is set up with as much code doing as i was doing in my app , click listener on window to toggle , played around for a minute or so and it happened : next click back to normal , took about anothe 30 clicks or so to happen again , but not as strong , so incosistent bug , and I did mange to do it another time again with about the same amount of on and offs.

(I know you could think , no one will click to switch it on and off that many times in production but here is the issue, because sometimes when my app loads, this is the state of the SSAO without the removing and adding )

1 Like

Looks like a depth precision issue, try to play with your camera minZ and maxZ.

Also tweaking SSAOPipeline.maxZ can help

My app and this camera in the playground have nothing in common, also it’s inconsistent which is an issue itself

Im so over flooded with work , I have to jump onto another 3d modelling project for the next week. I m behind on both and I’m due for surgery in three weeks , so I’m really honest when I say I can’t spend time tweaking knobs and crossing my fingers so to speak. I need to know what exactly I’m doing wrong or else it is a engine bug

(EDIT: didnt mean to come across as rude or self important , sorry , just under heavy workload stress currently)

Thanks anyway :blush:

SSAO won’t really work with a number of samples = 1 as you set in the PG.

The bug occurs when the sample generated by the SSAO class has a very low Z component.

For eg, setting explicitely a (0.707, 0.707, 0) value (see line 64):

Setting more samples will improve things. For eg, with 15 samples (and changing a bit the SSAO properties so that the effect is visible):

However, generating low Z components can still happen for some samples, and even if the artefacts are less visible because of the number of samples I’m not sure it is what we should expect.

Looking at this code in the SSAO2RenderingPipeline class:

private _hemisphereSample_uniform(u: number, v: number): Vector3 {
    const phi = v * 2.0 * Math.PI;
    // rejecting samples that are close to tangent plane to avoid z-fighting artifacts
    const cosTheta = 1.0 - (u * 0.85 + 0.15);
    const sinTheta = Math.sqrt(1.0 - cosTheta * cosTheta);
    return new Vector3(Math.cos(phi) * sinTheta, Math.sin(phi) * sinTheta, cosTheta);

Given the comment in the code and my findings above, I would compute cosTheta as cosTheta = 1.0 - u * 0.85 instead, to avoid being too close to 0.

@CraigFeldspar what do you think?

1 Like

yeah that totally makes more sense



So how do updates work with using npm modules? How do I know which module this update belongs to ?

cc @RaananW for the process

thanks, i am a still a build tools noob so if possible just tell me the npm command I need to run as a explanation about what to do might still be beyond my understanding.

I know modules and version numbers are in the package json , when running a command it makes changes to this document , which is how npm install understands the state of all modules , this is mine currently :

 "dependencies": {
    "@babylonjs/gui": "^5.23.0",
    "@babylonjs/gui-editor": "^5.23.0",
    "@babylonjs/materials": "^5.17.1",
    "@babylonjs/post-processes": "^5.17.1",
    "@babylonjs/serializers": "^5.23.0",
    "@popperjs/core": "^2.11.6",
    "axios": "^0.26.1",
    "bootstrap": "^5.1.3",
    "bootstrap-vue": "^2.21.2",
    "bootstrap-vue-3": "^0.1.10",
    "core-js": "^3.8.3",
    "gsap": "^3.10.3",
    "latest-version": "^6.0.0",
    "pinia": "^2.0.13",
    "vue": "^3.2.39",
    "vue-router": "^4.0.14",
    "vue-screen": "^2.1.0-beta.1"    

It is a part of this package: “@babylonjs/post-processes”: “^5.17.1”,

And if you run npm update tomorrow you will get the latest released version, which will include the fix

1 Like

Sorry gents , I ran npm update this evening and ssao still has these bugs when messing around with the sliders a bit , also when doing the dispose and add of the process , it is still inconsistent.

I know i might be doing this incorrectly , sorry if that is the case.

I noticed the playgrounds evengi created to show the error are also still producing the error , maybe its not updated yet?

I think I also experienced some other behaviour that was not there previously , now when I have the inspector open and i dispose and add back again … the inspector seems to loose reference because it doesnt update the values and changing anything has no effect after that. if I close it and open it again then it works. This was not like that before , well i dont think so. That doesnt affect my app but thought I should mention it.

Yes, depending on the values of the properties, you can make it look bad. I don’t think there’s a way around it, you need to tweak the values so the result is ok for you.

The samples property is important in this regard.

For eg, one test with samples=8 (with the new PR in):

Same with samples=15:

One problem with the inspector is that the samples slider is limited to 8. This PR is setting the limit to 64:

The first PG I created will always show the error because I put a hard value into SSAOPipeline._sampleSphere, something you shouldn’t/can’t do normally. With the new PR, such values can’t happen.

It seems it’s also doing this in 4.2.1 => can you check to verify it’s not a regression?

1 Like