Screen Space Ambient Occlusion

#61 Lorne -

You got it right on the first hit! I made the change and now everything looks great. I'd like to say this is a great resource, This really pushes the quality of the rendering up a couple notches, I'm really impressed. If anyone is reading this that hasn't made the jump yet, DO IT!

Jaimi

PS - Apparatus did the rocks - They're from one of his packs, but I can't recall which one. (I bought them all - he does great work)

#62 Cool! I think I may have to update the Install Guide at that part. It seems like it's easy to go wrong there.

Thanks for the praise Jaimi!

#63 Hi Lorne,

I've finally got the time to play more with SSAO.

On a scene (terrain, character, gui, looking at the character from above) where the original FPS was 138.4, with SSAO on it all dropped to 61.4. This is what profiler gave me:

%%NSTime  %% Time  Invoke #  Name
 51.067  51.067    67048 setVertexShaderConstF
 20.261  20.261      260 SwapBuffers

I am using an Intel C2D iMac with Windows on it. The videocard is an ATI Radeon X1600. This is happening in 1024x768 windowed. I've added the changes of the latest version of the SSAO kit as well.

Can you please help me find why the card is coughing on SSAO? It seems to me that SSAO should not cause such a framerate drop, if only because other games do not have such a huge fps drop with SSAO on.

#64 Hey Konrad,

There are a couple new profiler tags in the SSAO kit:
- RenderDepthMgr_render
- RenderSSAOMgr_render

Try looking for those in the profiler. Together they represent basically everything the SSAO Kit does.

I'm surprised to see setVertexShaderConstF at 51%... what was it at before you installed the kit?

For improving performance you might try the 2 suggestions I made earlier in this thread:
1) Reuse depth map for eliminating overdraw
2) Reduce samples from 16 to 8

Lorne

#65 Lorne, thanks for the quick reply.

I'm gonna be home soon, and run a new profiler check and look for those tags. The weird thing is that if I use ALT-O to turn SSAO off, both setVertexShaderConstF and SwapBuffers fall back to a value somewhere between 0.2 and 3. Other times, with SSAO on, viewing a full scene, SwapBuffers tops at around 81% (!).

I've seen people with Radeon cards and similar problems, I just don't know what a possible workaround could be.

Maybe someone else here with a Radeon card could do profiler checks? I'd be very grateful, as it would certainly help narrowing the problem down a bit.

I don't believe this is a problem with the SSAO kit, but ATI cards, or at least some of them instead.

Thanks for the suggestions! I'll give them a try once I get home.

#66 Hi again,

As you said, all things profiled in SSAO take only a small fraction of the resources. I've managed to create a test scene where SwapBuffers and setVertexShaderConstF were high regardless of SSAO being on or off. So finally I was able to confirm that this is not related to SSAO. (Which is a bummer - seems like I'm in for a long night... :)

Thanks for your help, and forgive me for bugging you with something completely unrelated to SSAO.

#67 @Konrad:

Is there any difference if you turn off Full Screen Anti Aliasing?

#68 @Jaimi:

Thanks for the idea. Give me a day or so to check, my options panel is totally torn out and apart.

#69 We're experiencing issues with SSAO messing up Glowing Materials that have Specular in a 2nd pass. It would seem that this is probably a case where SSAO won't work properly?

SSAO + Glow = fine (no ssao since its glow)
SSAO + Spec = fine

SSAO + Glow + Spec (white overlay on textures)

i287.photobucket.com/albums/ll136/byteasc/test.jpg

If what I suspect which that Glow and Spec isn't compatible with SSAO, then need to add some way to check what pass you're in, then verify there isn't a conflicting option in an earlier pass, like Glow...

#70 Hey Jeremiah,

I'll take a look at this. I *thought* the SSAO was turned off for all glowing materials, regardless of anything else... but I could be (and apparently am!) mistaken.

Lorne

#71 Well, it looks like it is handled by "Stages" and if the stage has glow or emissive or translucency, then it wouldn't have the feature, but with multi-pass materials (Glow on pass 0, bump/diffuse/spec on pass 1), this breaks as it still gets SSAO added to that stage.

The fix for right now for me was to change the ShaderFeature check to add the feature or not

if ( i == GFXShaderFeatureData::SSAO &&
	       !mMaterial->emissive[stageNum] &&
		   !mMaterial->translucent &&
		   !mMaterial->glow[stageNum] &&
		   stageNum == 0 )
		   {

This will only add SSAO on Stage 0 which is also where Glow normally would reside, so it keeps it from being added in a later Stage where Glow isn't, but SSAO could be.

I'm not sure if SSAO needs to be applied to all stages or it is sufficent to be blended with stage 0

#72 I'm not totally sure on this one.

Is there a reason you're doing Glow on stage 0, and bump/diffuse/spec on stage 1? I'm not a material expert, so I'm likely wrong here, but this seems like it's backwards to me. I've tried as you say, but until I reverse them the object "vanishes".

Could you share your material definition? I should also ask what SDK version you're using...

Regardless, I think you're right. It probably doesn't make much sense to apply SSAO on more than one stage, so something similar to your fix is probably in order.

Lorne

#73 Not a problem!

As for the definition, the Glow pass is basically just using a texture which is "ran thru" the glowbuffer (modulated, if i recall). So if it was put on Stage 1, it would traditionally cause the diffuse/spec to be overridden, since it is coming up last in the stack. Where as, having it as Stage 0, assures that the pass gets thrown in with the glowbuffer, but then allows diffuse/spec to work properly as they come off last.

new Material(Ind_Floor2L_1)
{
	mapTo = Ind_Floor2L_1;

	baseTex[0] = "./GlowMaps/Ind_Floor2L_1_g";
	emissive[0] = true;
	glow[0] = true;

	baseTex[1] = "Ind_Floor2L_1";
	bumpTex[1] = "./NormalMaps/Ind_Floor2L_1_n";

	pixelSpecular[1] = true;
	specular[1] = "1.0 1.0 1.0 0.1";
	specularPower[1] = 32.0;
};

That is one of our definitions, nothing fancy, but it works great without SSAO.. and is also working fine with my changes. We're using TGEA 1.7.1 as our base SDK.

#74 Lorne, Looking at that tree issue in your screenshot, couldn't you be baking a normal map as well? (As in normals of each pixel that you have the depth for) that way you can tell what direction each depth pixel is facing and eliminate a bunch of weird artifacts? I'm just throwing that out there... maybe I'm wrong but I thought that's what Crysis did.

#75 Hi Helk,

You're right... with per-pixel normal data SSAO can be improved. Nvidia has a neat paper about it.

I've had some time to study their technique, (and although I haven't tried it), i think it's performance would be significantly worse that our method. Their shaders are huge, but the results are beautiful, and I'm sure as hardware improves that method will be the future.

From reading the presentations published by the Crytek team, it sounds like they don't use normals for SSAO either - only depth is mentioned.

EDIT: and I should add that that tree is just a bad example. You can set a variable that changes how much depth difference is required for occlusion. It was simply turned up too high in that screenshot.

Lorne

#76 Well I bought the pack anyway, great job dude it really improves things and hopefully I'll be able to hack the depth production up for some cool stuff. Keep up the good work.

#77 OK, this is in relation to the known issue of: large resolutions/screen sizes hurt performance.

This is in and works great, had very little impact on performance *when working normally*

We've seen a situation come up which is easy to reproduce, looking for a solution.

If we start up the app in windowed mode (800x600, 1024x768) it will stay nice and fast, 60fps.
If we maximize the window (still windowed, just maximized), FPS stays nice and fast, maybe a 1fps drop.
If we exit out and come back in so that the app STARTS in windowed mode, the FPS drops and usability drops to not usable. While in this state, restoring the window to 1024x768 does not speed up the app. The app needs to START UP in a windowed mode to be performant!

So it looks like starting the window in a maximized window state really hurts things. My question is: why, and how can this be addressed. If there is some startup condition, can it be exposed to script so we can fix it?

TGEA version is 1.03, using the 1.03 version of the latest SSAO download.

#78 Hi Dave,

I'm trying to reproduce this... Can I assume you meant, "If we exit out and come back in so that the app STARTS in [maximized] windowed mode, the FPS drops and usability drops to not usable."?

Call me dumb, but I can't get Torque to start maximized. Is there a trick here?

EDIT: actually, I can't get 1.0.3 to maximize at all... double-clicking the title bar does nothing.

Lorne

#79 OK, you're right, stock 1.03 doesn't have the window resize controls. We are creating the canvas window with standard window resize capabilities. This would make it tough to reproduce in a stock codebase. Is this not a problem at all in a later codebase which does use the window resize controls? 1.7+ It seems like an analogous problem.

#80 What resolution is TGEA setting the "Default" to, when you maximize?

I've seen a few cases where, despite the desktop resolution being one thing, maximizing an application would fail to set the resolution to "that" value, so it would be a bit off or sized unusually which would throw some things into disarray