Jump to content
  • Advertisement
Sign in to follow this  
hmmcoffee

question regarding ssao

This topic is 3485 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

After reading the Starcraft 2 paper about ssao, I got a bit confused about how they check the occlusion. Here's what confuses me : they said
Quote:
At any visible point on a surface on the screen, multiple samples (8 to 32) are taken from neighboring points in the scene. These samples are offset in 3D space from the current point being computed; they are then projected back to screen space to sample the depth at the sample location.
And then the illustration picture : Image Hosted by ImageShack.us I don't understand what they mean by "These samples are offset in 3D space from the current point being computed". In the illustration they have rays pointing out from a point. So are they actually casting rays, searching where the rays intersect the depth map? Not just simply take samples around the given point? Thank You

Share this post


Link to post
Share on other sites
Advertisement
Those vectors are displacement directions from the original point and it just means adding the vectors (which are directions) to the original 3D position of each fragment. You are sampling on a sphere around the original point to get a ratio of samples in front to behind.

A really raw algorithm:

- For each pixel:
--- find its depth from the depth map which can give you its 3D position (original point)
--- for number of samples (more samples = better quality)
------- find a new 3D position by offsetting the origin by a vector
---------- this is just adding the vector to the original point.
------- project this new point in to screen space and find the depth again
------- if new_depth < original_depth then it is occluded
--- next
--- average over all samples to get an occlusion / darkening factor
- next pixel

You will probably want to change the number of samples taken and the size of the sampling sphere based on the depth of the original point. You can change the size of the sampling sphere by multiplying the offset vectors by a scaling value.

You should randomize the offset vectors you use to avoid aliasing. This can be done by reflecting the vectors accross a random plane through the original point. The random planes can be stored in a texture map as the GPU cant do random numbers itself.

EDIT: Don't just sample on the surface of the sphere, you want random samples inside the sphere or you may get some strange artifacts. This means you dont want all your vector directions to be normalized.


HTH

[Edited by - jrmcv on January 27, 2009 12:36:35 PM]

Share this post


Link to post
Share on other sites
You can take a look at the SSAO chapter in our D3D10 book (see link in my signature) for more explanations.
Quote:
Original post by Leafteaner
You also only want to sample the hemisphere about the normal, or you will get incorrect results.
That is only true if you don't take into account how you are sampling. Technically speaking, SSAO isn't physically correct anyways so you aren't really going after correctness.

With that said, I am planning to amend the SSAO chapter to include both forms of sampling kernels - one with a spherical sampling volume and one with a hemi-spherical sampling volume. There are advantages and disadvantages to each, and I plan to discuss the topic at length...

Anyhow, I hope this info helps the OP.

Share this post


Link to post
Share on other sites
Quote:
Original post by Jason Z
That is only true if you don't take into account how you are sampling.

How do you handle the "self occlusion" problem while sampling in a full sphere? Here's an example of what I mean (before blurring):

Full sphere:


Hemisphere:



Quote:
Original post by Jason Z
With that said, I am planning to amend the SSAO chapter to include both forms of sampling kernels...

That online book is already a great resource. Definitely appreciate what you guys have done :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Leafteaner
Quote:
Original post by Jason Z
That is only true if you don't take into account how you are sampling.

How do you handle the "self occlusion" problem while sampling in a full sphere?
I basically use an upper bound on the occlusion factor that is equivalent to the occlusion of a flat plane. The advantage here is you don't need to transform the kernel to do the test. The disadvantage is ~50% of the samples end up not really contributing to the occlusion value...
Quote:
Quote:
Original post by Jason Z
With that said, I am planning to amend the SSAO chapter to include both forms of sampling kernels...
That online book is already a great resource. Definitely appreciate what you guys have done :)

Quote:
Original post by jrmcv
Yeah thanks for that online book, Its going to be really useful :-)

I'm glad you have found it useful! If you have any suggestions feel free to PM me!

Share this post


Link to post
Share on other sites
In Starcraft II paper they had ability to fetch normal at current pixel and flip sampling vector if dot product of normal and sample is negative. This way all samples will contribute to occlusion, but you need to have a special normal map to do this. I'm currently using same approach, benefit is a "clean" result but self occlusion is not that bad if you have a good function to estimate occlusion and your content will have mostly dark shades, as in Crysis.

Share this post


Link to post
Share on other sites
We was doing some performance test and I get quite bad results on 7xxx and 8xxx cards. My suspision is it's because of the floating point texture that containes depth and need to be fetched at least 8 times for single pixel.
Jason, did you tryed to implement it with 8bit render targets?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!