Bits and pieces I found useful

• SSAO can be generated at a smaller resolution than screen, with depth+normals aware upsample/blur step.
• If random offset vector points away from surface normal, flip it. This makes random vectors be in the upper hemisphere, which reduces false occlusion on flat surfaces. Of course this requires having surface normals.
• When generating random vectors for your AO kernel:
  • Generate vectors inside unit sphere (not on unit sphere).
  • Use energy minimization to distribute your samples better, especially at low sample counts. See malmer.ru blog post.
• In your AO blurring/upsampling step: no need to sample each pixel for blur. Just skip some of them, i.e. make kernel offsets larger. See below.

Strided blur for AO

Normally you’d blur AO term using some sort of standard blur, for example separable Gaussian: horizontal blur, followed by vertical blur. How one can imagine horizontal blur kernel:

Here’s how Rune taught me how to blur better:

Rune:

The other thing is the blur. I tried to make the blur 4 times stronger, and it looks much better IMO without any artifacts I could see. I could even use 4x downsampling with that blur amount and still get acceptable results.

Aras:

how did you make it 4x stronger? (I was going to say that blur step is already quite expensive, and I don’t want to add more samples to make it even more expensive, yadda yadda)

Rune:

m_SSAOMaterial.SetVector (“_TexelOffsetScale”, m_IsOpenGL ?
  new Vector4 (4,0,1.0f/m_Downsampling,0) :
  new Vector4 (4.0f/source.width,0,0,0));
And similar for vertical.

Aras:

hmm. that’s strange :)

Rune:

I have no idea what I’m doing of course but it looks good.

Aras:

so this way it does not do Gaussian on 9×9 pixels, but instead only takes each 4th pixel. Wider area, but… it should not work! :)

Rune:

It creates a very fine pattern at pixel level but it’s way more subtle than the noise you get otherwise.

Aras:

ok (hides in the corner and weeps)

So yeah. The blur kernel can be “spread” to skip some pixels, effectively resulting in a larger blur radius for the same sample count:

Or even this:

Yes, it’s not correct blur. But that’s okay, we’re not building nuclear reactors that depend on SSAO blur being accurate. If you are, SSAO is probably a wrong approach anyway, I’ve heard it’s not that useful for nuclear stuff.

I’m not sure how this blur should be called. Strided blur? Interleaved blur? Interlaced blur? Or maybe everyone is doing that already and it has a well established name? Let me know.

Some images of blur in action. Raw AO term (very low – 8 – sample count and increased contrast on purpose):

Regular 9×9 blur (does not blur over depth+normals discontinuities):

Blur that goes in 2 pixel stride (effectively 17×17):

It does create a fine interleaved pattern because it skips pixels. But you get wider blur!

Blur that goes in 3 pixel stride (effectively 25×25):

At 3 pixel stride the artifacts are becoming apparent. But hey, this is very
low AO sample count, increased contrast and no textures in the scene.

For sake of completeness, the same raw AO term, but computed at 2×2 smaller resolution (still using low sample count etc.):

Now, 2×2 smaller AO, blurred with 3 pixels stride:

Happy blurring!

Here it is.

Is it insane or the only sane thing to do? It’s insane amount of work, but it looks like they know what they’re doing. STL is broken in many ways, especially on memory limited systems… Now they could release it as open source with a decent license!

That required tiny 700 lines of hacky C++ code in the engine; but in exchange there’s no longer a need to write state restoring passes by hand. Maybe such effect usage scheme would even be useable in RealWorld!

Too bad I didn’t think it up a couple of months ago. My ShaderX4 article about this subject would have been much better…

Ok, still got to test this stuff on real world data (i.e. trying it on our demos) ]]> http://aras-p.info/blog/2005/09/27/state-management-in-d3dx-effects-2/feed/ 0 http://aras-p.info/blog/2005/09/24/state-management-in-d3dx-effects/ http://aras-p.info/blog/2005/09/24/state-management-in-d3dx-effects/#comments Sat, 24 Sep 2005 15:45:00 +0000 Aras Pranckevičius http://aras-p.info/blog/?p=68 In my projects I’ve been using D3DX Effects with no device state saving/restoring. Instead, each effect contained a dummy “last pass” that restores “needed” state (see here; more lengthy article coming in ShaderX4).

I always wrote this “state restore” by hand. This is obviously very error-prone; it’s ok if I’m the only one writing effects but would be unusable in any real world scenario.

I think I could automatically generate the “state restore” pass. Somehow the engine knows which states need to be restored; which must be set in every effect etc. (this could be read from some file). It first loads each effect file and examines what states it touches. This can be done by supplying a custom ID3DXEffectStateManager and “executing” the effect – the state manager then would remember all states (left-hand sides of state assignments) touched by the effect.

Then the engine generates the “state restore” pass and loads the effect again. I’d image it would do it like this: each effect has to contain a macro RESTORE_PASS:

technique Foo {
 pass P1 { ... }
 pass P2 { ... }
 RESTORE_PASS
}

Which would be empty during first load and which would expand to the generated restore pass on the second load (you can supply generated macro definitions when loading the effect). The engine can check whether the generated pass exists after second load (if it doesn’t then RESTORE_PASS is missing from the effect – an error).

The downside of this scheme is that each effect file has to be loaded twice – first time for examining its state assignments and second time for actually loading it with the generated restore pass. It’s not a problem for me, I guess, because effect loading doesn’t take much time anyway… And if it would become really slow, all this stuff can be done as a preprocess (e.g. during a build).

There are many upsides of this scheme, I think: the whole system is robust and error-proof again (no longer depends on the effect writer to remember all the details about states). And as far as I can see, no performance would be lost at all (performance was the main point why I’m using this “restore pass”).

Gotta go and implement all this!

Right now – finishing my ShaderX4 article and preparing for Japan.

One totally insane 64 kilobyte intro: 195/95/256 by rgba. Of course, first you have to see the original 195/95 demo by Plastic. The 64k intro copies the (party version) of the demo almost perfectly, while squeezing everything in less than 64 kilobytes. Ok, the music sucks, the loading time is nearly infinite and it has lots of bugs/glitches, but I must say that rgba guys are insane anyway.

Texture Montage: looks cool. Just made me realize how primitive the “usual” texturing tools are… It makes me want to create some texturing tool…

LDPRT and Local PRT are steps in the needed direction for precomputed radiance transfer. Though Ignacio says that CPCA compression of SH is patented my M$… Bah!

Relational Debugging for the Graphics Pipeline is like NVPerfHud on steroids!

Reading on…

Like with most similar books, half of this one is old, well known or pretty basic stuff. At a first glance, Generating Shaders from HLSL Fragments by Shawn Hargreaves is really good; Dean Calver’s stuff (Accessing and Modifying Topology on the GPU and Deferred Lighting on PS3.0 with HDR) also looks very cool. Probably these alone are worth the book; much like Kozlov’s article on PSMs in GPU Gems was. My own articles – oh well; one (Shaderey…) is really useless; the other (Fake Soft Shadows…) is maybe ‘interesting’, but of unknown practical purpose :)

Ok, back to reading…