Screen Space Ambient Occlusion




When lighting a scene in a way that is similar to real life you want to know how much light can get to a point in space, this is important for small corners and crevices where light photons have a hard time getting to. Ambient Occlusion algorithms are ways to approximate how much light can reach such points, and in this particular implementation I will be focusing on a view space (Screen Space) algorithm.

The algorithm runs in a single fragment shader where it samples a random kernel around every fragment for depth values to calculate an occlusion factor, this result is later used in a lighting pass to lower the ambient component by this factor. I don't want to make this post too long since the technique itself is quite old by now and there are tons of resources already on implementing it.

Now some for some things I personally encountered while implementing this technique. From what I read at first the algorithm does not play nice with normals calculated from a normal map but it turned out that it does not matter in my case since I store these normals in a separate texture as part of the G-buffer. This means the normals are read and stored per fragment, still enabling normal mapping and avoiding SSAO noise.

Most implementations I found had a per-fragment position texture calculated for view space or reconstructed the view position vector from depth. My renderer follows the Unreal principle of calculating everything in world space for best performance, but this meant I had to convert the world space position to view space for every SSAO shader fragment, which could decrease performance.

Lastly I did not really notice the effect at first, and found that the occlusion factor would brighten the entire scene. This happens when the factor  is > 1.0 thus increasing the ambient component in my HDR lighting pass, so don't forget to clamp!



Comments

Post a Comment

Popular posts from this blog

Ray Tracing in One Weekend - OpenGL Compute

Image
Executable Below! As an exercise for learning ray tracing I have implemented most of Ray Tracing in One Weekend, one of the most beloved ray tracing introduction books, in an OpenGL compute shader. The idea is to create an application that shoots multiple rays per pixel and checks for intersections with spheres. This way we procedurally generate a frame, avoiding traditional triangle rendering. I have built up quite a nice C++ framework over time for creating new OpenGL applications, loading shaders etc. so I could focus on the actual GLSL ray tracing program and only need a bit of C++ for dynamically adding, removing and altering the rendered objects.    Rasterization Traditional rendering is called rasterization: It is the process of taking vertices (points in 3D space, called 'vectors' in math) that make up a triangle and converting it to monitor pixels. We take the triangle and project it flat onto the scree...
Read more

Shadows

Image
For the past couple months I've been working on a small project that allows users to integrate ray traced shadows in an OpenGL C++ application through Vulkan. It generates a screen space shadow texture that's exported to OpenGL using external memory handles (for now Windows only, though I do believe that Vulkan has enums for Linux memory export). Having implemented basic shadow mapping and CSM in other personal projects I wanted to do this short write-up to share my thoughts and findings on old and new shadow techniques. We'll only be looking at single directional light techniques, so no local lights. Don't worry if you don't understand everything in this post, it's meant to show the disadvantages of shadow mapping compared to ray tracing and rant about my implementation, not a tutorial.  Shadow Mapping I think that a single shadow map's biggest benefit is ease of setup in a rasterized renderer: Rendered depth from the lights' point of view You render th...
Read more