Screen Space Ambient Occlusion

#1 Wow awesome stuff, how is performance ? Any chance of a video ? Would be more then willing to pay for additional shader packs/addons so long as performance is up to scratch.

Also i assume this doesnt effect terrains as your website doesnt list it ?

#2 Hi Ian,

Thanks for the positive feedback! To answer your questions:

1) Performance remains good. It's of course somewhat scene and videocard dependent, but on average you'll notice a drop of about 8 FPS.

2) Yep! There's a QuickTime video up on the website... you can see those bricks drop in real-time :)

3) Ambient Occlusion is not applied to Terrain blocks or Atlas terrains. I actually had it working on terrains originally, but it looked a little strange. The effect is much nicer without it.

Lorne

#3 Looks pretty good in the bricks, but it's clearly wrong around the tree. If I remember correctly, Crysis had a pretty complex screen-space ao shader but disabled it in the shipping build because of the blatantly wrong artifacts. Definitely a nice shader to have around, but I'm not sure it's really useful for more games unless it's turned way down.

In any case, nice work!

#4 Thanks Tom! Yeah, the technique is definitely prone to artifacts (it's an approximation after-all). However we do provide several parameters the level-designer can tweak to minimize them, including a "depth threshold" parameter. It's turned up fairly high in the video/screenshots to help make the effect super-obvious. Turning it down though prevents situations like that tree occluding the wall...

#5 Groovy! Some games would look absolutely stunning with this on, so I hope it finds its way into a few Torque games.

#6 This TDN article is quite misleading.

Quote:
Torque Game Engine Advanced also has the ability to display Screen Space Ambient Occlusion. Ambient Occlusion helps to add realism to your scene.

Before scrolling down to the bottom, it sounds like TGEA is capable of SSAO out of the box.
Great work with the shader, btw.

#7 Good stuff! Can you talk more about the technique that you used?

#8 @Stefan, thanks for clarifying the TDN article. I appreciate that.

@Pat
Sure thing. The shader is essentially my interpretation of what the Crytek team described in their article, "Finding Next Gen". In a nutshell...

An early depth pass is done and stored in a depth texture. The depth texture is fed into the SSAO shader. For each pixel the scene depth (at that pixel) is compared to that of 16 neighboring (sampled) pixels. The sample points are chosen by mirroring a set of 16 "base vectors" in a per-pixel random normal. If the pixel is a little farther (deeper into the scene) than an average of it's neighboring pixels, it's shaded darker. If the pixel is nearer, it's shaded lighter. The result is quite noisy (16 samples really isn't enough) so in a second pass an edge-respecting blur filter is applied to smooth the result. The final SSAO texture is then multiplied into the original scene.

I experimented originally with doing a Gaussian blur on the depth texture and then subtracting the original depth texture ("unsharp masking"). The result is usually nice, (and fast to compute), but near objects will occlude far objects with harsh black shadows. The larger the distance, the harsher the shadow - quite the opposite of what you want.

#9 I bought and paid for this about 14 hours ago but I have yet to receive a download link..Not very pleased.

#10 Hi Adam,

You paid via an "eCheck" which unfortunately takes time to clear. Paypal says:

"This eCheck Payment will remain "Uncleared" until the funds have cleared from the sender's account, which usually takes 4 business days. If you are shipping an item, please do not ship your item until the funds have cleared into your PayPal account."

I'll look into adding a special notice to our checkout for "eCheck" customers... I'll agree it's rather confusing at the moment.

Please email us directly with any issues like this in the future. Or post on our customer forums at www.ubiqvisuals.com. We take customer satisfaction very seriously.

Thanks!

#11 I did post in the forums, and I did email you but the email bounced for some reason. PayPal lies when it says 4 business days. The clearing time is different for Canadians, as I have had anywhere from 7 days to 15 days. Its a killer to have to wait that long.

#12 We're a Canadian company, so we know your pain... everything is slower up here. 7 to 15 days though... yikes! I think we'll have to figure out a better policy regarding these eChecks.

In the meantime, we've added the download to your account :)

#13 One quick comment, on the documentation. You should probably include a txt or html version of it. Docx is something that a lot of people don't have.

#14 Good catch J.C... I've added some .PDF files to the download and I'll look into HTML.

Thanks,
Lorne

#15 Awesome! I will buy it :)

#16 Lorne,
Awesome. I have been really caught up in some single-buffer deferred rendering stuff but now that I have depth data I'm looking for more and more stuff to do with it. Would the accuracy of the technique improve any if you had per-pixel surface normal data, and then scattered in random offsets from the actual surface normal?

#17 Hi Pat,

I'm quite certain it would... You might notice in the "SSAO only" screenshot on our product page that the shader sometimes accents low-poly geometry (for instance, look at the arches). With per-pixel normal data it's apparently possible to limit that effect using essentially the technique you describe...

Nvidia has just published a paper about it:
http://developer.download.nvidia.com/SDK/10.5/direct3d/Source/ScreenSpaceAO/doc/ScreenSpaceAO.pdf

Lorne

#18 Thanks for the link to the new paper Lorne.

We also implemented the "unsharp masking" technique and have not been that satisfied with the results. As soon as i get some time i'll try out this new nVidia technique.

#19 Lorne,
I am gathering depth and normal data into a single buffer in a pre-pass. The depth is gathered using the Crysis eye-space method, and the normals are sampled/interpolated, transformed into world space, and stored in spherical co-ordinates. The format is:

8:8:8:8
normal.theta|normal.z|depthHi|depthLo

This gives 16 bits for eye-space depth and stores normals in 16 bits with about the same % error as storing normal.xy and reconstructing z. The difference is that if you reconstruct a world-space z, you need the sign.

inline float2 cartesianToSpGPU( in float3 normalizedVec )
{
float atanYX = atan2( normalizedVec.y, normalizedVec.x );
float2 ret = float2( atanYX / PI, normalizedVec.z );

return (ret + 1.0) * 0.5;
}

inline float3 spGPUToCartesian( in float2 spGPUAngles )
{
float2 expSpGPUAngles = spGPUAngles * 2.0 - 1.0;
float2 scTheta;

sincos( expSpGPUAngles.x * PI, scTheta.x, scTheta.y );
float2 scPhi = float2( sqrt( 1.0 - expSpGPUAngles.y * expSpGPUAngles.y ), expSpGPUAngles.y );

// Renormalization not needed
return float3( scTheta.y * scPhi.x, scTheta.x * scPhi.x, scPhi.y );
}

#20 Just a quick plug:

I bought this pack and it is a breeze to install. It has instructions for integrating it with the current TGEA, and the previous 2 versions. The documentation is clear, and easy to read. The code is very well written, and uses ShaderGen and the RenderInstMgr exactly how they were intended to be used and expanded.

I integrated this into a different codebase than TGEA, and it went in very smoothly, and the results were great.

This is the light accumulation buffer without SSAO:

And this is with the Ubiq code using default settings:

Well written code kit, and well worth the $30. I recommend it.