alienizer at April 18th, 2012 12:48 — #1
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?
roel at April 18th, 2012 13:57 — #2
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.
alienizer at April 18th, 2012 14:24 — #3
Sounds like a good idea! thanks Roel
alienizer at April 18th, 2012 16:43 — #4
hmmm, easier said than done! Any ideas or links to papers on how to blur a map?
roel at April 18th, 2012 17:27 — #5
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:
alienizer at April 18th, 2012 17:35 — #6
vilem_otte at April 18th, 2012 18:29 — #7
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
alienizer at April 18th, 2012 19:54 — #8
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!
roel at April 19th, 2012 03:19 — #9
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.
stainless at April 19th, 2012 05:21 — #10
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)
alienizer at April 19th, 2012 07:48 — #11
roel at April 19th, 2012 17:03 — #12
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.
alienizer at April 19th, 2012 19:26 — #13
yeah, I ran into that problem :wacko:
stainless at April 20th, 2012 05:16 — #14
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.
alienizer at April 23rd, 2012 19:57 — #15
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!
vilem_otte at April 25th, 2012 08:32 — #16
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).
jlippo at May 9th, 2012 14:08 — #17
rouncer at May 10th, 2012 02:38 — #18
who cares if its noisy, ao looks awesome anyway even with the noise.