That is all fine, but the real improvement came when I used energy minimization on my sampling sphere. Instead of just settling with random spherical coordinates I put my sphere through a energy minimization routine, and the difference is staggering. I’ll let the pictures speak for themselves:

SSAO without energy minimization
Notice how noisy and high contrast this looks.

SSAO with energy minimization
Much less noise with the same number of samples, and more realistic contrast.

So how does one do this? It is quite simple. Just generate your sample sphere with normalized vectors. Then iterate through them and apply some force between each point until they reach and equilibrium. About 100 iterations should be more than enough, and since this is done in a pre-process stage it really doesn’t matter how long it takes.

Here is some code:

// Energy minimization
int iter = 100;
while( iter– )
{
for( int i = 0; i < samples; i++ )
{
Point3 force;
Point3 res = Point3( 0.0f, 0.0f, 0.0f );
Point3 vec;
float fac;

vec = sampleSphere[ i ];
// Minimize with other samples
for( int j = 0; j < samples; j++ )
{
force = vec – sampleSphere[ j ];

fac = DotProd( force, force );
if( fac != 0.0f )
{
fac = 1.0f / fac;
res.x += fac * force.x;
res.y += fac * force.y;
res.z += fac * force.z;
}
}

res = res * 0.5f;
sampleSphere[ i ] += res;
sampleSphere[ i ] = Normalize( sampleSphere[ i ] );
}
}

After this we can randomize sphere radius lenghts…

// Randomize sphere radiuses
for( int i = 0; i < samples; i++ )
{
sampleSphere[ i ] *= random.Rand01() * radius;
}

Read on for the actual code.

Input:

x
Screen space x-coordinate (unit: pixels).
y
Screen space y-coordinate (unit: pixels).
zbuffer
Depth buffer with pixel z coordinates in camera space.
normalbuffer
Buffer with pixel normals in camera space.
samples
Constant with number of samples
radius
Radius of sample sphere. Very scene scale dependant.
coneAngle
The cosine of the cone angle of the occlusion.
coneAngle = cos( angle / 2 * DEG_TO_RAD )
where angle around 150 is a good value.
strength
Multiplier that can be used to tweak the strength of the occlusion.

The code:

for each pixel(x, y)
{
	// Get current pixel depth
	float z = zbuffer[ x, y ];

	// Do nothing with pixels that are the background
	if( z <= -1.0e30f || z == 0.0f )
		continue;

	// Set initial variables
	float occlusion = 0.0f;
	int actualSamples = 0;

	// Map screen pixel to camera space point
	Ray cameraRay = MapScreenToCamRay( x, y );
	cameraRay.dir = Normalize( cameraRay.dir );
	Point3 p = -z * cameraRay.dir;
	Point3 normal = normalbuffer[ x, y ];

	for( int i = 0; i < samples; i++ )
	{
		// Calculate a random position within the radius.
		// The distribution below gives a good random sampling
		// This should be pre-calculated
		float rad = random01() * radius;
		float a = random01() * TWOPI;
		float b = random01() * TWOPI;
		Point3 vector;
		vector.x = rad * Sin( a ) * Cos( b );
		vector.y = rad * Sin( a ) * Sin( b );
		vector.z = rad * Cos( a );

		// Get sample point, in camera space
		Point3 samplePoint = p + vector;

		// Get screen coordinate of the sample point
		Point2 screenSamplePoint = MapCamToScreen( samplePoint );
		int sx = int( screenSamplePoint.x + 0.5f );
		int sy = int( screenSamplePoint.y + 0.5f );

		// If sample point is outside the bitmap then ignore it.
		// This code could potentially be skipped in a realtime scenario
		if( sx < 0 || sy < 0 || sx >= w || sy >= h )
			continue;

		// Get z-buffer depth at sample point
		float sampleZ = zBuffer[ sx, sy ];
		// Do nothing with samples that are the background
		if( sampleZ <= -1.0E30f || sampleZ == 0.0f )
			return;

		// Get the difference of the depth at the sample and the depth at p
		float zd = sampleZ - z;

		// Ignore samples with a depth outside the radius or further away than p
		if( zd < radius )
		{
			// Calculate difference in distance to sample point and the z depth at that point
			// Optimized by using squared, ok due to the nature of how we will use it
			// One could probably use samplePoint.z instead of length though.
			float zd2 = LengthSquared( samplePoint ) - sampleZ*sampleZ;

			// Check that the sample point is in front of the z-buffer depth at that point
			if( zd2 > 0.0f )
			{
				// Now get a new point that is samplePoint, but with an adjusted z depth
				Point3 p2 = Normalize( samplePoint ) * -sampleZ;

				// Get cosine of angle between the normal in p and a vector from p to p2
				float dp = DotProd( -normal, Normalize( p2 - p ) );
				// Check that the angle is inside the cone angle
				if( dp > coneAngle )
					occlusion += 1.0f;
			}
		}
		actualSamples++;
	}

	// Calculate final occlusion.
	// Multiply by 2 since we roughly lose quite a lot of samples with the normal check
	occlusion *= 2.0f * strength / float( actualSamples );
	LimitValue( occlusion, 0.0f, 1.0f );
}

I implemented it in 3ds max as a render effect using the fine article written by Iñigo Quilez, and with a little help from a render element I managed to get it to only modify the ambient channel. Well, I didn’t actually implement it. I reimplemented it. because this and every text I’ve read about it on the web has some artifacts that are unacceptable in a vfx scenario, and can actually be avoided without any major performance penalties (if any).

In a later post I will detail what modifications I did to remove these artifacts, but in the mean time here are some screenshots. These are rendered in 3dsmax, but I’ve lowered the number of samples to 32 (which is what real-time engines should be able to handle) and I’ve turned off anti-aliasing. I’ve also, for clarity made the SSAO affect all channels, the way most game engines will do it, instead of just the ambient channel. Usually I also apply gamma to the render to make it more realistic, but I’ve removed that aswell so we get the pure linear pixel experience.

In other words, this is an image that a 3d engine should be able to produce without any problems.

Naturally, if you want to use these few samples you probably should do some blurring of it before presenting it, but this is a better reference for real-time scenarios. In software renders using 500 samples is fast and gives very smooth results.

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

So this is how it starts. Well, I plan to not update this blog too often, I might as well say that from the beginning. I will, however, try to post things that are more than what I ate for breakfast.

Topics will probably be things relating to programming and stuff I bump into at work. So expect lots of posts about frustrating things in the 3ds max sdk, but also some things about 3d programming in general. Oh, and I really like my xbox 360, so some post might come from that aswell.

Until then, take care!