SSAO using line integrals

Started by
15 comments, last by PixelSmasher 11 years, 9 months ago
I see your point but I have to disagree.

Let's imagine this book completely open (the angle between the pages is Pi).
If we fold it slightly, the depth difference would mainly benefit to the volume of the sample furthest from the shading point... multiplied by the lowest weight.

If we reach a smaller angle (let's say Pi/2), the contribution of the furthest sample would have reached its maximum value and a sample closer to the shading point would start its real contribution, weighted with a higher value.

This behaviour is not linear and I feel it mimics the contribution of the projected solid angle.

----------------------------

I tried some low value detection on the occlusion coefficients and obtained this image
It is not a satisfactory result as a lot of subtle details are lost.
wagcc.png
Advertisement
Is the 'weight' the vertical volume in that slice?
If so, you're still approximating AO with spherical obstruction (albeit sample based)...

------

I think you have to take into account normals to compensate for those bands.

Pretend you're looking at only the depth buffer. You have no way to differentiate between a hard edge and a smooth edge, as the smooth edge appears hard in the depth buffer. The interpolated shading normal is where you get the 'oh it's a smooth edge' information.

Also if you discard, don't forget to scale the resulting stuff (total volume is no longer volume of a sphere)

Is the 'weight' the vertical volume in that slice?
If so, you're still approximating AO with spherical obstruction (albeit sample based)...

Yes it is, and I have to agree with you wink.png.

I eventually tried some smooth-edge detection based on normal difference. The results are not that great, the GPU bandwidth has exploded and the slightest idea of performance is dead on the battlefield
(Yeah I know it should be painless in a proper deferred pipeline, but I have to integrate this code in an odd, bloated and insulting pipeline where outputting normals in the G-Buffer is prohibited).

I'm still working on it.
After another day of math tips and tricks, here is the latest version of my SSAO (after a bilateral blur pass).
With good per-scene adjustements, I think this one will do.

has6Y.png
Looks excellent. What's the performance of this method (just roughly?)
I get good results on PC (5 ms with an unoptimized version).

On console, which is the release target, I get disastrous perf (8 ms on a 720p resolution), mainly due to a low texture cache.
I'm currently working on aggressive optimizations and will update this post when I'll get a shippable implementation.
Hi again and sorry for the late answer.
After several optimizations, loop unrolling and code vectorization, I get awesome results with the same image produced in 2.36ms for a 720p resolution !

  • AO computation pass : 1.5 ms
  • Horizontal bilateral blur : 0.43 ms
  • Vertical bilateral blur : 0.43 ms

Hints :
- The GL_AMD_texture_texture4 extension (allowing to quickly fetch 4 adjacent pixels) was available on the target console. Always use it (or fetch4 or textureGather or whatever with the same behaviour) and smile while looking at your perf counter.
- Kill loops with fire ! They are horridly slow ! (Look at the code generated by your shader compiler to see if they were not unrolled at compil time)

This topic is closed to new replies.

Advertisement