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();
> }
> }
> }
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 )
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 )
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)
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.
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 :
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):
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?
Hi again, ok so here is a simple playground with two rectangles. Nothing else in the code , please follow the steps im talking about below :
first test just right clicking the rendering pipelines in the inspector and add a ssao2.
Notice that it has that buggy look right away. Surely you own default numbers via the inspector should not be setting up a users scene to look like this. ( eg , adding SSAO on sketchfabs platform to your scene never gives you a glitch result )
so anyway , changing minZ to 0,02 and sample of 16 makes it look ok.
SO keeping that minZ check this out :
you told me ssao2 doesnt work with 1 sample , yet weirdly enough other that 16 samples and above the other best option is actually 1 sample … try it. Then try samples 2-15 and notice the glitch effect is visible for all of those.
So its a case of use 1 sample or then have to jump to 16 samples … everything inbetween is useless?
oh i tested the inspector loosing reference using different versions of the engine , it seems it always looses the reference when you add and remove and add the process via code. So not regression Closing the inspector and opening it again recreates the reference.
Using several samples allow averaging the contributions, the “bad” + the “ok”. If you have a single sample, if you get a “bad” sample you are out of luck.
Notice that it has that buggy look right away. Surely you own default numbers via the inspector should not be setting up a users scene to look like this. ( eg , adding SSAO on sketchfabs platform to your scene never gives you a glitch result )
Yes, I think we should set 16 as the default number of samples…
ok noted , i understand the inconsistency thing now and why you say 1 is not a valid choice but also then why lower samples also dont yield good results.
