"Roman Reiner" <lim### [at] gmxde> wrote:
> So if you just take the ordinary radiosity algorithm and cut it down to that
> it should be faster, shouldn't it? Can you point out the error in my
> reasoning here?

I think what's missing is the number of rays that must be shot in AO vs.
radiosity. It's true that tracing AO sample rays is going to be cheaper
than tracing radiosity sample rays, as you say, although by how much is
scene and shader dependent. The question is, can it make up for the fact
that AO will be tracing many more of those rays?

In both cases, when a sample is taken a number of rays are traced out into
the environment. These can be set the same in both systems; the above AO
images were casting the same number of extra rays per sample as radiosity
with the "count" value set to 128. However, AO *always* samples. Every ray
that hits an surface with ambient occlusion turned on will spawn 128 extra
rays. Without antialiasing, this means *every* pixel whose centre covers an
object with AO will suffer this cost, and it will only get worse with
antialiasing.

As described in the documentation, radiosity avoids this cost (which would
be ruinous with multiple bounces allowed plus fancy shading) by making the
approximation that indirect illumination changes relatively slowly across
the image. It tries to take extra samples only where it looks like the
indirect illumination would be changing rapidly enough to make the cost of
sampling worthwhile (what "worthwhile" is depends on your radiosity
settings). So radiosity will almost certainly trace far fewer rays than AO.

Let's say that to trace an AO sampling ray is X times faster than tracing a
radiosity ray. If both trace the same number of extra rays per sample, and
antialiasing is off, then radiosity only starts slowing down to AO's level
when it takes a sample every X pixels or fewer. Even if you can trace 10 AO
sampling rays in the time it takes to trace one radiosity sampling ray
(which would be surprisingly fast), radiosity just has to take samples
spaced on the average more than 10 pixels apart and it will still take less
time than AO, if the AO object fills the screen.

> Secondly: Have you thought about using an iterative method to determine in
> which direction new rays are being shot? Should save some samples too.

Do you mean an adaptive system that traces extra random rays for a sample if
the error is "too large", or one that traces rays towards geometry whose
visibility is changing rapidly as seen from the sample point (sort of
importance sampling, I guess)?

The adaptive version should be easy to do, but the importance version would
probably require generating new directions on the fly, which would be
expensive. I hadn't really thought about it yet. I want to keep AO as
simple as possible so I spend less time tweaking it, and taking a fixed
number of samples does have the advantage that you can roughly guess the
effect on render time of increasing the number of samples.

Post a reply to this message