SSAO Compositor

[kajjjak]

Great work Null, your the man. I got some interesting results on Lenovo T61 having NVIDIA Quadro NVS 140M.
My system ran Null´s first SSOA implementation without any problem.
First I could not run this new demo (it crashed when compiling the compositor). But changing the default values (FSAA=1, texture count=1, texture res=32) I could get it to run (but did not look good). Then I switched over to D3D and used the original settings and got a smother frame rates (looking GREATE).
Thanks for contributing this Null.

[nullsquared]

Yes, the original demo didn't even run on OpenGL.

I'm not quite sure what the issue with OpenGL is... I really haven't had much luck with it at all. Even in Portalized, we have nothing but trouble with OpenGL on ATI.

[jjp]

Maybe the cg compiler doesn't produce code ATI cards like?

[nullsquared]

Maybe the cg compiler doesn't produce code ATI cards like?

Perhaps, but I've hand-written a GLSL port and that didn't work, either

[artn3r]

I got another problem, now it is concerning hdrlib,
maybe someone has an idea?

HDRLIB + SSAO OFF - Everything ok



HDRLIB + SSAO ON - looks strange



Should i create new threads for such problems or discuss it here?

Thanks for helping,
Christian

[nullsquared]

Hm. Have you tried enabling the SSAO compositor before/after HDRLib? I think it should be run after HDRLib, or it might be messing up HDRLib's lighting calculations.

Also, keep playing with the shader. It still looks a bit wrong, more of ghosting rather than actual SSAO.

[artn3r]

It works, thank you =)
The ssao has to be enabled after hdr!

Thanks,
Regards Christian

[nullsquared]

It works, thank you =)
The ssao has to be enabled after hdr!

Thanks,
Regards Christian

Cool . Can I see a screenshot? I'm just as interested in this as you are, I love to see stuff used in other projects . I still think you need to adjust the geometry scaling (see my previous posts), though.

[artn3r]

Here they are =)




Yes, the problem of the overall scaling is still present, i have to adjust this
in the ogremax exporter and my physx engine.

in the screenshots, i use the "modified reynolds operator" of hdrlib,
but something goes wrong, because my whole scene is getting colorless...
maybe this is because i use ldr textures except on the teapot...
my problem is that i do not know how to create this awsome textures of the hdrlib demo,
but i still want this "glow" effect on my objects in the sun =)

Regards,
Christian

[Captain_Deathbeard]

Hey null, good work with your awesome graphical doodads you've been making available.

I tried to get some ssao on my terrain, probably a bit ambitious really because I think its designed more for indoor scenes, but I gave it a try anyway. Didd'nt work out too well unfortunately, i tried adjusting the COEF a bit, found 0.01 to get best result, my scene is 10units=1m and its miles of open terrain.
These screens with lighting disabled to show ssao better. As you can see it looks awesome at a certain range, but then just vanishes. Also even when it looks good, it goes a bit crazy when the camera moves, and seems to add a specular sheen too. Could be that I'm still doing something wrong somewhere.





Low framerate, but its on a geforce 7800.

[nullsquared]

The thing about SSAO is that it's very local. For large terrains, it's better to precompute an ambient occlusion map within a modeling application.

[kajjjak]

I finally got some time to implement this into my project but encountered some problems. I have spent a lot of time to understand what is going on and appreciate any help on the subject.
The image bellow displays a big box and a small box. where the big is located on the "floor". The problem is twofold. One is the jagged shadow edges and the second is the shadow projection. The projection should start from the corner of the box but does not, resulting in the illusion that the box is "hovering".



Implementation part was easy where I simply took initShadows and initSSAO passing scene manager and viewport as pointers and assigning the accompanying materials to my objects.

I have been looking around for solution and this problem resembles some of the issues on thread "Ogre Soft Shadows Demo".
My objects has are scaled 1 m = 1 unit (the small box). I scaled down the root but got exactly the same result.

[nullsquared]

Are you sure that you call sceneManager->setShadowCasterRenderBackFaces(false) (or whatever it was called)? The demo doesn't have this issue, so I'm not sure what to go with here...

[kajjjak]

Yes, I am calling
sceneMgr->setShadowCasterRenderBackFaces(false);
getting the described "error".
But when only running your CG scripts (the material files) and disabling the calls initShadows(...) and initSSAO (...) the projection of the shadows onto the "floor" material is correct (see image bellow)?

[kajjjak]

Ok, after playing around with the values (in diffuse.cg)

vsmEpsilon = 0.0001;
radius=0.001;
1024*2 sized shadow texture

I got this result



Seems there is some kind of scaling issue with regards to my scene after all
Thanks for creating this example Null

[osknoes]

Hi guys!

I've a little problem with the ssao. When I compute it, seems that there is some texCoord error that produces a strange artifact. As you can see in the image looks like there's a little offset between the original image and the ssao. I'm using my own ssao, but it's almost base on nullsquared source (I moved my questions/problems to the new thread )
I read that a way to prevent a skybox effect (no z info), there's a way to clean the buffer (0,0,0,10000). The point is I'm using mrt, where one is phong shading and the other one is for normal+depth data. If I clean the viewport, this will be done to both targets or only in one of them. There's a way to clean both ?



So, any advice ?

[Oogst]

Really cool effect! I am quite fond of the cleverness and simpleness of screen space ambient occlusion. I understood the idea within one sentence, but they person who came up with it (I think someone at Crytech?) was just really smart.

The framerate is rather low on my Geforce 9650 M. What kind of optimisations could be done to improve it? Less samples? Lower resolution ssao and smartly blur that for the final result? Did you try any optimisations?

[nullsquared]

Hi guys!

I've a little problem with the ssao. When I compute it, seems that there is some texCoord error that produces a strange artifact. As you can see in the image looks like there's a little offset between the original image and the ssao. I'm using my own ssao, but it's almost base on nullsquared source (I moved my questions/problems to the new thread )
I read that a way to prevent a skybox effect (no z info), there's a way to clean the buffer (0,0,0,10000). The point is I'm using mrt, where one is phong shading and the other one is for normal+depth data. If I clean the viewport, this will be done to both targets or only in one of them. There's a way to clean both ?



So, any advice ?

How are you "applying" the SSAO result to the final scene?

[nullsquared]

Really cool effect! I am quite fond of the cleverness and simpleness of screen space ambient occlusion. I understood the idea within one sentence, but they person who came up with it (I think someone at Crytech?) was just really smart.

I believe it was someone before Crytek; they were just the first ones to really show it off with Crysis.

The framerate is rather low on my Geforce 9650 M. What kind of optimisations could be done to improve it? Less samples? Lower resolution ssao and smartly blur that for the final result? Did you try any optimisations?

First of all, press "F" to disable the initial flashlight. The lighting calculations use variance shadow mapping, so you want to first make sure it's not the shadowing that's slow.

Second, the demo does use quite a few optimizations. There are only 6 samples taken per pixel, it's done at half-resolution, it's blurred, and so on.

Something else to try is to go to data/ssao.cg, find ssaoBlurX_ps and ssaoBlurY_ps, and uncomment the fist commented-out return statement in both of them. This will basically disable the blur, which does a lot of texture fetches - this way we can see if it's possibly not so much the SSAO that's slow, but the texture-hungry blur. If it's not this, then just comment out those two lines and the blur will be back.

One last thing to try: go to data/config.ini, and make sure FSAA = 0 and maybe lower width and height. Also, try "D3D" as the renderer instead of "OGL", might be faster.

And if it's still very slow, then ... hm. I'll just blame it on the slowness of SSAO in general, then .

[Oogst]

Hmm, I played around with it a bit and it turns out that FSAA, D3D and blur all had a part in decreasing the framerate. The blur is the strongest, though. I also tried decreasing the number of blur samples and decreasing the number of SSAO samples. I think in a 'real' application that uses SSAO, if the textures contain enough detail, the blur can be set to significantly lower numbers of samples, thus giving an acceptable framerate. Nevertheless, the effect is for the moment probably still so expensive, that it should only be used if it is very important for the graphical style of the game, or if the game is to be released some time from now.

By the way, commenting out the blur lines made the app crash, since the X blur uses "ssaoMap" instead of just "map".

I really should try this out with my Cableracer game prototype, by the way: I guess it would look great in combination with high quality depth of field blur and might also require less blurring samples in that case, since the depth of field blur also adds some blur of its own.

[nullsquared]

Hmm, I played around with it a bit and it turns out that FSAA, D3D and blur all had a part in decreasing the framerate. The blur is the strongest, though. I also tried decreasing the number of blur samples and decreasing the number of SSAO samples. I think in a 'real' application that uses SSAO, if the textures contain enough detail, the blur can be set to significantly lower numbers of samples, thus giving an acceptable framerate. Nevertheless, the effect is for the moment probably still so expensive, that it should only be used if it is very important for the graphical style of the game, or if the game is to be released some time from now.

By D3D, do you mean D3D ran faster than OGL? I usually find that the case in certain cases on my 8800GTS. FSAA would definitely sap some performance, too (especially out of a mobile card). I can see why the blur would have such an effect - it uses two texture fetches each iteration, one for the SSAO and one of the depth so that it doesn't blur across the edges. Also, I don't recommend lowering the SSAO samples. They were already at 6 (compared to the possible 14 in the array).

Just for the record, this runs very fast on my 8800GTS, so it's very possible that your mobile card also plays a role in some of the slowness.

By the way, commenting out the blur lines made the app crash, since the X blur uses "ssaoMap" instead of just "map".

Oh, they must've been left in there from too long ago

[osknoes]

I'm using this to modulate the final SSAO :

Code: Select all

return tex2D(Tex0, texCoord) * tex2D(Tex1, texCoord).r;

Btw' if I use a bigger radius during the SSAO I get the exactly same artifact, nothing is better
Now, I tried to use the modulate pass as null does, but the artifact is still there.

[Oogst]

Couldn't the blur be optimised by combining alpha and ssao in a single texture, so that they can be looked up together? This might be done by making the SSAO shader also output the depth in the alpha, so that depth is effectively copied there. This would decrease the quality of the depth, though, if the depth is in a 16 bit per pixel texture and the ssao is only a 8 bit per pixel texture. However, maybe the ssao would not be much slower if it were outputted to a floating point texture as well, since the ssao does not do any pixel blending? I would expect that that might still be much faster than doing double lookups in the blurring phase, since the blurring phase does a whopping 16 lookups per pixel!

[nullsquared]

Couldn't the blur be optimised by combining alpha and ssao in a single texture, so that they can be looked up together? This might be done by making the SSAO shader also output the depth in the alpha, so that depth is effectively copied there. This would decrease the quality of the depth, though, if the depth is in a 16 bit per pixel texture and the ssao is only a 8 bit per pixel texture. However, maybe the ssao would not be much slower if it were outputted to a floating point texture as well, since the ssao does not do any pixel blending? I would expect that that might still be much faster than doing double lookups in the blurring phase, since the blurring phase does a whopping 16 lookups per pixel!

Well, that's certainly possible. I'll see to implement that soon. Basically, I can put the occlusion value in the first 8 bits and the depth can be compressed into the next 24 bits, fitting into a standard 32-bit RGBA8 texture.

[nullsquared]

I'm using this to modulate the final SSAO :

Code: Select all

return tex2D(Tex0, texCoord) * tex2D(Tex1, texCoord).r;

Btw' if I use a bigger radius during the SSAO I get the exactly same artifact, nothing is better
Now, I tried to use the modulate pass as null does, but the artifact is still there.

Hm... There's a pixel or a half pixel offset somewhere in there that's causing the error, but I can't quite figure out where it's happening... seems to be happening in your SSAO calculation, the depth/normal map is probably slightly offset or something... Hm...