When raytracing, you sample each lights, giving a dot free result right? But when sampling for ambient occlusion, the shadows have dots like in a path tracer and takes a long time to converge. How do you fix that so it appears smooth?
The "dots" are called noise or variance and appear when you want to numerically integrate a function by random sampling it. One way to reduce it is to render it into a buffer and blur it. But I have no idea what the state-of-art approach for AO currently is.
Sounds like a good idea! thanks Roel
hmmm, easier said than done! Any ideas or links to papers on how to blur a map?
That's very basic, it's all over the internet. You can find that yourself. And it is in the directx sdk (or at least, it used to be last time I checked).
By the way, this is state of the art SSAO according to my rss reader:
Blurring ambient occlusion is wrong! Well you can do with some bilateral stuff (or gaussian filters - which are a lot better, but too slow for real time), but you'll lose micro-details in ambient occlusion, it just won't look okay.
So what's best to do - simply performing true ambient occlusion with enough samples (I think jittered 32 samples is enough for nice low-frequency ambient occlusion), let's assume we can go with half screen size ambient occlusion buffer. So let's do the math - we have to do (at 720p) 230 400 * 32 samples per frame - totalling 7 372 800 local rays/s. And we need at least some decent 30 fps - thats totally 221 184 000 rays/s (221 MRays/s) ... this is not far from impossible.
At ompf.org mpeterson states, that "on dual sandy (3.06ghz) around 290mrays/s with ray length of 0.25 \ scene-diag" (Fairy forest scene) which actually seems enough (note that 0.25 \ scene-diag is quite large radius for AO and you'll most likely use much smaller one). Not mentioning that you can actually run ray tracing on GPU. Also the less radius, the more Mrays/s you will get - so you can get quite nice correct local AO at decent framerate
I've noticed that. I made a MakeGaussianKernel function and used that to blur the AO map but it looked like crap. I get nice results on random rays but it take so long! I'll try what you suggested, thanks!
Things like screen space ambient occlusion are always wrong anyway. But since Vilem Otte mentions ompf, are you talking about AO in rasterisation or in ray-tracing, Alienizer? In ray-tracing you get AO-effects for free, they simply emerge. In rasterisation, AO is---unless pre-computed---an "effect" based on true AO.
Pre calculating AO and storing in your meshes gives the best results IMHO.
The screen space stuff is good, but not available on some platforms (you need render to texture which doesn't exist on a lot of mobile platforms)
But of course the drawback of pre-calculation is that it is valid only for the geometry for which it is calculated - so you have static geometry with nice AO.
yeah, I ran into that problem :wacko:
It's a pain. A hell of a lot of things I used to do as "standard" are no longer available to me because some \ was limp wristed when writing the standards.
Now render to texture is "optional" and only supported by opengl extensions, which of course means "not available" to anyone who has to write for multiple platforms.
Our engine creates a single binary that can run on all supported platforms, but we still have to have run time flags and platform dependant code to handle stuff that should have been a requirement rather than an optional feature.
At ompf.org mpeterson states, that ...
What happened to ompf.org anyway? They were up for so long, I can't beleive they shut down!
In fact nobody knows what actually happened to ompf.org - anyway Jacco Bikker revived it at http://igad2.nhtv.nl/ompf2/ some time ago. The shame is, that the database was lost (well something is still available from google cache, and I read that some archived version from 2009 is also on TheWaybackMachine).
who cares if its noisy, ao looks awesome anyway even with the noise.