Screen Space Ambient Occlusion for jMonkeyEngine 3.0 |

Screen Space Ambient Occlusion for jMonkeyEngine 3.0

August 16, 2010 in Feature

ssao blog post

Everybody in the 3D computer graphics neighborhood has heard about SSAO, but what is really hiding behind those four letters?

If you want to know, this paper is for you. This is a quick abstract on the technique, with a focus on how it has been implemented for JME3.

What is ambient occlusion?

Ambient occlusion refers to the shadows that nearby objects cast on each other under an ambient lighting. It‘s an approximation of how light would radiate in a real life scene.

It usually entails casting rays from each point of a surface in random directions; lighten the point if the ray reached the background, darken it if the ray reached an object.

As you might have guessed, this method put a heavy burden on the CPU, and is not yet exploitable in real time 3D.

However in 2007 Perumaal Shanmugam and Okan Arikan released a paper on a hardware accelerated implementation available here.

What about the “Screen Space” thing?

First time SSAO acronym popped out was in this paper by Crytek in 2007 (chapter 8.5.4.3)

They explain how they managed to implement ambient occlusion in the Cry Engine 2 for the game Crysis, by comparing depth for each pixel 3D position neighborhood in a full screen quad pass. This is a credible alternative to the “real” AO implementation that makes it usable in real time 3D graphics.

What about jMonkey Engine 3.0?

Since then, there are a lot of implementations available on the Internet (some of them available in the reference section), but a particularly clever implementation got my attention in A simple and practical approach to SSAO by José María Méndez on GameDev.net. It’s fast, simple, and gives very good results.

The idea is, for each pixel of the scene, we take a random sample of pixels around it and calculate it’s occlusion factor using the distance between samples and angular difference between the receiver´s normal and the receiver to occluder direction. For more details I suggest you read the paper.

I made a GLSL version of this implementation with little adaptations to it :

- I only use front faces as this is faster and gives sufficiently good results.

- I don’t sample a position buffer as advised by the author because it requires extra memory and an extra scene render pass. Moreover I wanted to take advantage of the fact that JME3 can sample for “free” a depth texture of the scene during the main render pass. I reconstruct the 3D position of each pixel from depth using the one frustum corner method.

- For the random sampling, instead of using a random texture, I use a random function suggested by Martin Upitis in this game-dev thread. It’s a little faster and gives a more regular repartition of the samples, thus avoiding the common “grainy” look of SSAO. It also gives a smoother result so the AO looks good on the rendered scene even without an additional blur pass. However it makes some banding artifacts, and for high quality render purpose, I will probably implement an optional blur pass for the filter.

jME3 has a SceneProcessor system that allow the addition of custom scene processing to a view-port (Shadow processing for example). I had already implemented a 2D filtering post processor (more info in this post), so I just implemented an SSAOFilter for this processor.

I had to adapt the processor in order to allow a filter to compute a pre-rendering pass (here for the normal buffer sampling).

So now SSAO can be stacked with any other 2D filter on a scene.

What will monkeys have to do to use this awesome feature?

- Create a FilterPostProcessor and add it to the view-port.

- Create a SSAOFilter and add it to the processor

- Maybe play a little with SSAO configuration parameters, but that’s more of an artist duty.

Voilà!!

By Rémy Bouquet aka nehon

References

Forum History

http://www.jmonkeyengine.com/forum/index.php?topic=14393.0

http://www.jmonkeyengine.com/forum/index.php?topic=14624.0