# SSAO using GLSL

Hello,
I came across the following page that describes a SSAO implementation using GLSL, but am having difficulty getting to work right.

http://rgba.scenesp.org/iq/computer/articles/ssao/ssao.htm

Did anyone ever get it to run correctly?

do a search on SSAO in the prevous months : http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=search

I was looking for something in the line of
http://www.gamedev.net/community/forums/topic.asp?topic_id=463075&whichpage=2&#3198107

Yeah, initial implementation done by Leadwerks forgot the part that reduces the occlusion when the depth difference increases, so this degenerated to a glorified outline shader.

But this version should be ok :

As described in the original article by Iñigo Quilez :

"Now the most tricky part of the algorithm comes. Unlike in shadow mapping where a simple comparison yields a binary value, in this case we have to be more careful bacause we have to account for occlusion, and occlusion factor are distance dependant while shadows are not. For example, a surface element that is far from the point under consideration will occlude less that point than if it was closer, with a cuadratic attenuation (have a look here). So this means it should be a bit like a step() curve so that for negative values it does not occlude, but it should then slowly attenuate back to zero also. The attenuation factor, again, depends on the scale of the scene and aesthetical factors. I call this function “blocking or occlusion function”. The idea is then to accumulate the occlusion factor, like:

``````    float zd = 50.0*max( se.z-sz.x, 0.0 );
bl += 1.0/(1.0+zd*zd);              // occlusion = 1/( 1 + 2500*max{dist,0)^2 )
``````

"

IMHO it still looks like a glorified outline shader.

The Crytek method using a texture to do random lookups, rotated per pixel, looks much more natural. Also, I think the radius used to lookup neighboring pixels should be depth-dependent.

SSAO IS a glorified outline shader!