A very fast technique to render clouds as imposters which are only updated when the viewport has changed enough to make a visible error. Here’s the abstract from the paper:

“This paper presents a method for realistic real-time rendering of clouds for flight simulators and games. It describes a cloud illumination algorithm that approximates multiple forward scattering in a preprocess, and first order anisotropic scattering at runtime. Impostors are used to accelerate cloud rendering by exploiting frame-to-frame coherence in an interactive flight simulation. Impostors are particularly well suited to clouds, even in circumstances under which they cannot be applied to the rendering of polygonal geometry. The method allows hundreds of clouds with hundreds of thousands of particles to be rendered at high frame rates, and improves interaction with clouds by reducing artifacts introduced by direct particle rendering.”

Link to a webpage with much more information about this technique:
http://www.markmark.net/clouds/

Link to the paper:
http://www.markmark.net/PDFs/RTCloudsForGames_HarrisGDC2002.pdf

These are two types of regression test that might be good to do when working on a renderer and you want to be sure that the new code won’t break something else. When doing refactoring, these tests are very important too.

The easy way to do testing is to make some test scenes and manually run them all and look for errors after each change. But this will be cumbersome so more automation is needed.

Regression testing (functionality)

Create a couple of tests with scenes that contains all that should be tested. Run them and manually control so they are working. When running, the test should save a screen shot of the perfect rendered scene for later comparison.

Then a new feature has been added, the test scenes should be automatically run again and new screen shots should be rendered and compared against the original ones. Some sources suggests that the comparison can be a simple bit to bit comparison and that any difference should be noted and reported as a failure.

Regression testing (performance)

Save the fps for all performance tests and whenever a feature has been added. It should automatically run all tests again and report if any performance has changed. It’s most important if performance has decreased, but increased performance might be good to know too if your working on optimizations.

Information about how Unity does testing of their graphics code
http://aras-p.info/blog/2007/07/31/testing-graphics-code/

Some info about how to compare images in these kinds of tests:
http://www.tilander.org/aurora/2008/03/comparing-images.html

A link to information about all kinds of automated testing in games:
http://www.gamasutra.com/features/20050329/roken_pfv.htm

These developers uses a “monkey” to test their code, which seems to work good for them:
http://powerof2games.com/node/25

Some info about what regression testing is and why it is needed:
http://en.wikipedia.org/wiki/Regression_testing

How to take the samples is a big concern as it will impact what will occlude and how much. The currently best implementations takes random samples in a hemisphere in the direction of the normal. This limits the amount of self occlusion. Another problem is that if you only take the depth into consideration then a flat surface might occlude itself because of the perspective. By also comparing the normal when calculating the AO, this problem will go away.

One of the hard parts of implementing SSAO is to choose the correct smoothing technique. Because of the big cost of taking occlusion samples you want to take as few samples as possible but this will give much noise in the SSAO so the result needs smoothing. Just doing a simple gaussian blur will not be good as the blur will make the SSAO bleed. Instead a blur that considers the depth and/or normals is needed. One of those is the bilateral filter which often is used in combination with SSAO.

The steps of a simple SSAO implementation:

1. Render the scene. Save the linear depth in a texture. Save the normals in eye space in a texture.
2. Render a full screen quad with the SSAO shader. Save the result to a texture.
3. Blur the result in X
4. Blur the result in Y
5. Blend the blurred SSAO texture with the scene, or use it directly when rendering the scene.

An optimization is to render the SSAO in a lower resolution than the screen and upsample it when blurring. Another optimization is to store both the normals and the depth in a single texture.

SSAO in the NVIDIA SDK

Probably one of the best implementations of SSAO is this one by NVIDIA (although it’ rather slow). The SDK 10 has a paper about the technique and also source code!
http://developer.download.nvidia.com/SDK/10.5/direct3d/samples.html

And here’s three papers/presentations from NVIDIA describing their SSAO in detail:
http://developer.download.nvidia.com/presentations/2008/GDC/GDC08_Ambient_Occlusion.pdf
http://developer.download.nvidia.com/presentations/2008/SIGGRAPH/HBAO_SIG08b.pdf
http://developer.download.nvidia.com/SDK/10.5/direct3d/Source/ScreenSpaceAO/doc/ScreenSpace AO.pdf

SSAO in Starcraft II

Some information of how Starcraft II will use SSAO is included in this paper ( see chapter 5.5 ):
http://ati.amd.com/developer/SIGGRAPH08/Chapter05-Filion-StarCraftII.pdf

SSAO in Two Worlds

A link to a description of the SSAO implementation in the game Two Worlds:
http://www.drobot.org/pub/GCDC_SSAO_RP_29_08.pdf

SSAO in Crysis

The paper and game that started it all (look in the chapter 8.5.4.3):
http://delivery.acm.org/10.1145/1290000/1281671/p97-mittring.pdf?key1=1281671&key2=9942678811&coll=ACM&dl=ACM&CFID=15151515&CFTOKEN=6184618

Hardware Accelerated Ambient Occlusion

One of the papers that probably inspired the Crysis team:
http://perumaal.googlepages.com/

Kindernoiser SSAO

A simple but smart SSAO implementation, here with well commented shader source code:
http://rgba.scenesp.org/iq/computer/articles/ssao/ssao.htm

A gamedev.net thread with lots of discussion about SSAO
http://www.gamedev.net/community/forums/topic.asp?topic_id=463075

A different approach to deferred lighting in which the lights are rendered before the actual geometry is rendered. Here’s the abstract from the paper describing this technique: