Game Development Community

Screen Space Ambient Occlusion

by Lorne McIntosh · in Torque Game Engine Advanced · 09/09/2008 (7:08 pm) · 114 replies

Hey everyone,

I've developed a Screen Space Ambient Occlusion shader pack for TGEA. It will apply real time ambient occlusion onto any dif, dts, or animating dts in your scene. Check out the video on my website. I'm selling the shader pack through my site to anyone who wants to have great looking ambient occlusion in their levels! Enjoy.

www.ubiqvisuals.com/index.php?option=com_content&view=article&id=46%C2%A0

www.ubiqvisuals.com/images/ssao_sample.jpg

About the author

Ubiq Visuals is a software and creative content developer for the entertainment industry. Our vision is to provide inspiration and the tools for soon-to-be game designers and creative minds of all ages.

#81
10/20/2008 (7:09 pm)
Hmm, I think I see what's happening here. SSAO for 1.0.3 isn't really managing the textures properly. The render-targets get "stuck" in whatever resolution you start at - doh!

I'll need to release a patch. However, I suspect the low FPS you get when it starts maximized is the "real" FPS you should be getting at that resolution. By starting at a smaller resolution and then increasing it, you're essentially taking advantage of the aforementioned bug (you're keeping the render-targets smaller than the screen resolution).

To keep your FPS higher (even at those larger resolutions, but at the cost of some quality) you may want to sort of "keep the bug" either by:
1) using 1/2-size render targets, or
2) capping the render targets at some maximum like 1024x768

I'll let you know how the patch goes,
Lorne
#82
10/21/2008 (1:03 am)
Hey dave,

I've emailed you a patch to try (email address from your profile).

Lorne
#83
10/21/2008 (4:13 am)
I bought this pack too and it looks great IMO.

www.windmillgames.com/artwork/mog_newlogin.jpg
#84
10/21/2008 (10:03 am)
@Kiyaku:

Wow, looks really nice! Can you post a picture with SSAO off for comparison?
#85
10/21/2008 (10:05 am)
Lorne may have handled this, but you should be able to sign up for a tex manager callback, and have the SSAO target get re-created in the callback.

You can also check the target size against the window size before render.
#86
10/21/2008 (12:24 pm)
@Lorne -

I've seen some speed hits as well on lower end cards (such as the 8600GT) - Will you have the half-size render targets as an option in your patch?
#87
10/22/2008 (3:30 pm)
@ Kiyaku: Amazing work! I can't wait to play it, whatever it is :)

@ Jaimi: Yes, the next SSAO update will include a couple performance-tuning options. Performance seems to be everyone's biggest problem/concern so we're serious about addressing it.

@ Jeremiah: I haven't forgotten about you... I think the update will have proper materials.cs support.

I haven't fully investigated this, but my plan is: you'll be able to turn SSAO on/off in each stage as you wish (like glow). It will default on in stage 0 (so you don't need a materials.cs for *everything* just to have SSAO), and default off in the other stages. This way, you can also disable SSAO on a specific material if you don't want it.

Lorne
#88
10/22/2008 (3:35 pm)
Quote:This way, you can also disable SSAO on a specific material if you don't want it.

Excellent news - I like it enabled on everything except the player in 3rd person view. Basically this will give me the ability to turn it on/off by switching materials, right?
#89
10/22/2008 (4:28 pm)
Awesome :)

I haven't been concerned at all, since we fixed up alot of the calls out to the SSAO to not clutter up the shaders, and implemented the stage0 check for glow.

Per-material SSAO sounds excellent, as there are some cases where performance would be better with some sort-of pre-baked AO, instead of full dynamic
#90
10/22/2008 (6:18 pm)
Quote:
Per-material SSAO sounds excellent, as there are some cases where performance would be better with some sort-of pre-baked AO, instead of full dynamic
Well that's not entirely true. The depth buffer is still the same size, and the processing step on the depth buffer still operates on every pixel in the buffer, so it actually doesn't save any time. There are probably small savings to be gained from not rendering an object during the pre-pass, however that assumes that you are only using per-pixel depth for SSAO and not for other effects.
#91
10/22/2008 (9:29 pm)
Yeah, I'm afraid Pat's right (isn't he always?). It'll give you better visual control, but turning it off on your materials won't save any render time.

I remember reading something about stencil masks... using them to prevent shaders from processing certain pixels. But I suppose creating the mask would involve rendering all the SSAO objects again anyway... probably much worse.

Lorne
#92
10/22/2008 (10:29 pm)
@Henri, thanks. Yes i can make a shot without SSAO when i'm off from work.

@Lorne, thanks, and thanks for your great shader :) It's the login screen for my mafia online game
#93
10/23/2008 (9:28 am)
What a great pack :) - dropship is larger in the game, but reduced its size so I could fit it in the screenshot up close.

www.games4business.biz/images/dropship1.jpg
www.games4business.biz/images/dropship2.jpg
#94
10/23/2008 (10:12 am)
The stencil thing would work, but then you are turning a consistent/measurable performance hit into a variable performance hit. This isn't necessassarily a bad thing, but it's something to be aware of.

I reserve stencil bit 0 as a opaque flag. So when the pre-pass renders all the opaque objects to the depth target, it assigns '1' to the stencil buffer. This won't matter a whole lot for indoor-based games, but if you look at the screenshots by Julian, you can see how much screen space the sky-box takes up.

While rendering pre-pass:
// This assumes that this is the first bin, and that stencil is cleared
      GFX->setStencilEnable( true );
      GFX->setStencilWriteMask( 0x01 );
      GFX->setStencilMask( 0xFF );
      GFX->setStencilRef(1);
      GFX->setStencilPassOp( GFXStencilOpReplace );
      GFX->setStencilFailOp( GFXStencilOpKeep );
      GFX->setStencilZFailOp( GFXStencilOpKeep );
      GFX->setStencilFunc( GFXCmpAlways );

To test against the opaque bit:
// Set up stencil test, for great fillrate-saving-justice
   GFX->setStencilEnable( true );
   GFX->setStencilZFailOp( GFXStencilOpKeep );
   GFX->setStencilFailOp( GFXStencilOpKeep );
   GFX->setStencilMask( 0xFF );
   GFX->setStencilWriteMask( 0xFE );      // NOTE!! Don't kill the opaque stencil bit!
   GFX->setStencilRef( 0 );
   GFX->setStencilPassOp( GFXStencilOpKeep );
   GFX->setStencilFunc( GFXCmpLess );

Alter as needed. If there are issues, make sure to use PIX and take a look at the stencil surface. It will save you much headache.
#95
10/23/2008 (11:31 am)
Thanks Pat - I'll give that a whirl.
#96
10/23/2008 (2:35 pm)
Oh awesome... I'm glad I mentioned it.

Considering that neither the terrain nor the skybox is included in SSAO, the performance benefit on an outdoor scene might be huge. I'll look into it.

Lorne
#97
11/03/2008 (4:57 pm)
Hey all,

Just a quick note that SSAO Kit v1.2 has been released. It's aimed mainly at addressing performance issues:

- Renamed $pref::Video::EnableSSAO to $pref::Video::SSAOEnabled
- Added performance option $pref::Video::SSAOHighQuality (switches between 8 & 16 samples per pixel)
- Added performance option $pref::Video::SSAOMaxSize (caps the render target size)
- Texture pools are now cleared upon resolution change to free memory
- "1 pixel halo" effect minimized (but still needs work)
- SSAO is now only applied to material stage 0

The proper per-material SSAO changes will have to wait for another release. I figured it was better to get this one out the door.

Lorne
#98
11/03/2008 (4:58 pm)
Oh, also I tried the stencil technique. Pat's code works practically "out of the box" :)

On outdoor scenes it provided a modest boost. However there were some issues, so I decided to drop it:
- TGEA 1.0.3 doesn't have D24S8 (only D24X8)
- Depth target must be the same size as SSAO target
- FSAA screws up the whole thing

Lorne
#99
11/06/2008 (10:53 am)
Texels with conversely inclined face normals are not shaded.

img381.imageshack.us/my.php?image=shadedud0.jpg
#100
11/06/2008 (12:10 pm)
Ouch. Sounds like a bug, though.