Hell yeahh!

I love how realistic this looks.

Thanks! - You are one of those guys who are working with different engines and next-gen stuff - do you have have any suggestions and remarks?

Actually no, it looks perfect. As long as you make it adjustable it will be fine.
Some engines offer quality settings or range. Here are some SSAO settings I can adjust in one of these engines:

radius, sample count, occlusion intensity, blur, downsampling, occlusion attenuation, Min Z, random texture

You are talking about Unity, right? Ok, Occlusion radius is no problem; will be added.

Number of ambient occlusion samples is currently hardwired to one pass (8 samples) and can be changed in the shader file easily - I will see if I can reorganize the shader so that it is used in an accumulated fashion, so that the sample count is constant per pass, but dynamically chainable so that arbitrary passes are allowed --> I simply don't want a conditional loop. The shader is so big, it is making it all worse then.

Intensity of ambient occlusion is already adjustable through two parameters: ssaoConvexHighlight (brightnes of edges) and ssaoConcaveDarkness (darkness of ambient occlusion).

Amount of blur to apply to ambient occlusion will be possibly, maybe - I am tinkering with that stage soon to make it faster.

At what resolution calculations should be performed is now hardcoded to 1:2 (half of the screen). I already wrote on my todo-list that I try to make that dynamic for all postprocessing shaders so that you can vary this; but mainly I wanted to experiment with blurring in a resolution one step smaller than the AO stage so, we both meet here, hehe

Occlusion Attenuation is commented on the Unity page with "how fast occlusion should attenuate with distance". What does this mean?

MinZ - "Try increasing this value if there are artifacts": same here, what does this actually do??

--> I see what I can do and I'll add such parameters into the GUIs of all demos for you to play a bit with them

[EDIT]: what is meant with "random texture"? The one that determines the random rotation vectors?

Sorry, I dont know the technical details about MinZ. The random texture is a noisy looking 64x64px 24 bit colored texture called "RandomVectors". So I think you guessed it right

I forgot to reply to the attenuation question:

Generally attenuation in 3d graphics is how something decreases when objects are farer away. For a light it is how brightness decreases over distance. So it probably will fade occlusion off over distance. Maybe the translation of attenuate helps a bit:
http://dict.leo.org/ende?lp=ende&lan...earch=attenuate

Time passes by and after four months or so of no news about my SSAO solution you may wonder what happened. At the time of the last release (January), I was asked to add GPU and decal sprite support, as you might have heared, JCL implemented new features for this concern for me and after some beta iterations, they are now stable and ready to go. Inbetween I had much trouble with my work, written tests, a research paper and social issues, so, everything slowed down but now it seems that I have more free time and I am ready to go!

Here is an extract from my changelog in the order of implementation, which documents, that I am working on it :

• surface flags begin now with "SSAO_TYPE"; new surface flag: SSAO_TYPE_IGNORE for clipping e.g. decal objects
• all object shaders automatically detect and support now gpu animations (A8 only)
• Scene rendering has been splitted into two passes, once for depth map(s) and once for normal- & soft alpha map(s). Rendering the scene twice is cheap, though, the additional costs of this overhead are outperformed through the optimizations concluded through this, as follows:
• In addition to the depth- and normal maps which have been generated as before, counterparts get generated which include those depth/normal values of objects which were clipped (like softalpha objects). These maps can then be processed in later, complex shader chains, attached to the SSAO solution (like DOF) without rendering again the scene!
• Render targets consume now (including the additional two new maps, s.a.) 19% less memory due to the usage of 16- instead of 32bit FP targets and 888- instead of 8888 targets (-> faster, less memory)
• Since depthmaps are now generated again with absolute floating point values, the 8888 32bit -> 16bit FP target encoding / decoding scheme is abandoned (-> faster)
• If a view is registered as post-SSAO stage via ssaoSetContext, a new rendertarget is created in which the final image (diffuse * ao) is rendered into. Though, you can still access this image simply via TargetMap in staged views, for instance in simple PP effects like with pp_sepia.fx
• You can gain access to all screen-sized maps (clipped/full depth/normal-map, softalpha map, diffuse and combine* map with a set of getter-functions (*: only if a post-SSAO view is defined, s.a.)
• With registerSsaoResolutionEvent and registerSsaoTargetRecreationEvent you can now register external events, which are called at the end of the SSAO process. If they are called, they indicate either a (re-)creation of at least one render target and/or a general screen resolution change. Useful, if you want to adapt automatically render targets of other attached complex shader effects without checking yourself if something happened!

I am working together with Pietro Nifosi, who is generously contributing his Wasteland Remake assets for a new demo I am working on which should serve as proof of concept for integrating my stuff in complex game environments with more than just SSAO as shader effect.

I recognized some people which asked for a connection to Shade-C (Pietro Nifosi -> Boc_Havoc) or a linkage with other effects (Slin, SSAO->DOF, for Zapans game). So, I decided to put much more effort in making it customizable, but still yet powerful and complete on its own. In contrast to Shade-C I follow the strategy, that a whole shader solution is designed as a component, which is complete on its own, easily integratable, open for pre- and post-shader chains and that it, if seriously programmed, can substitute redundant things to reduce memory consumption and overhead (like serving the depthmap for other shaders, so that they don't need to render it).

So, if you failed to integrate it in your project, because your project is too complex or it is too hard for you, please tell me!

Further features planned for the 0.6 release are:

• ingame slider panel for adjusting artistic SSAO properties
• possibility of shader injection for custom Vertex Shaders, like for foliage/grass-waving scenarios
• when disabling and post-SSAO effects are needing depth/normals, these will be still sampled

I hope, there are still people interested in this and like these new news. Any news are good news ^^

Best regards,
-Christian

SSAO is always inteesting! Once I saw SSAO applied to my own levels, i can not imagine them anymore without!

Yes please continue with your project, I for one greatly appreciate your efforts
and the amount of time you have put into the A8 SSAO.

When I can spare some money I will defenitaly make a donation.