The results of yet more thievery; this time I filched some of Mael's MegaPOV
code to get access to a low-discrepancy sequence of numbers (Halton series).
This reduced the noise for a given number of samples, although at present
I'm unable to quantify by how much. I also applied a minor modification so
that the user can control the maximum angle between the normal and the
direction of sample rays.

The images shown before correspond to a maximum angle of 90 degrees, so that
rays are shot into a hemisphere. Reducing the angle tightens the shading,
enhances the contrast (because surfaces close to the local horizon are
sampled less or not at all) and potentially allows you to reduce the number
of samples while keeping the same noise level in the hemispherical case; or
to reduce the noise for the same number of samples.

The attached image was rendered using Mael's samples with a maximum angle of
90 degrees, like the previous images. It took about 80 seconds to render at
800x600 (I cropped it). The same scene with one light and basic diffuse
finish renders in about 2-5 seconds, so although it's impossible to
estimate speed in absolute terms, you can see that the occlusion is
certainly very weighty compared to lambert. It will only get slower with
increased geometry. I chose a simple box as the shadow underneath will
clearly show the effect of changing the max sampling angle.

Post a reply to this message

Attachments:
Download 'variangle_90deg.jpg' (22 KB)

Preview of image 'variangle_90deg.jpg'

An image at the other extreme; the max sampling angle was set to 5 degrees,
so that surfaces consider themselves occluded only by things almost
directly in front of them (note that the ground is an infinite plane, so
the box's vertical sides always see it even at this narrow angle). Both
this and the previous image used 128 samples.

Post a reply to this message

Attachments:
Download 'variangle_5deg.jpg' (15 KB)

Preview of image 'variangle_5deg.jpg'

A warning ahead: I have no clue about the algorithms involved so if the
following is plain stupidity i apologize :-)

"Tom York" <alp### [at] zubenelgenubi34spcom> wrote:
> 2) I knew that it would certainly be a lot slower than a radiosity approach
> in rendering...

I'm pretty much surprised that you say that. As you obviously dealt with
both algorithms I'm pretty much sure you're right but from my native point
of view i always thought AO would be faster than GI.
First of all AO only uses a gray scale color space so it should already be
faster than radiosity which needs to calculate the brightness
for every color component seperately and secondly AO only needs to calculate
intersections. Neither lights nor surface attributes of the intersected
objects are taken into account during the calculations.
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?

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

Regards Roman

Post a reply to this message

That's a nice effect. You say it's noisy and can get slower for complex 
scenes. Sunflow has fast and clean AO, you should check out the source and 
see if you can get some ideas.

Also, Blender's AO is very slow if you have a large object (like a large 
quad for a floor), but you can speed it up by a factor of 2 or 3 if the 
octree is larger. You probably know this already, but I thought I'd mention 
it.

Post a reply to this message

"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

"Anthony D'Agostino" <gam### [at] contastnet> wrote:
> That's a nice effect. You say it's noisy and can get slower for complex
> scenes. Sunflow has fast and clean AO, you should check out the source and
> see if you can get some ideas.

I would need to do comparisons for speed and quality (and download the JDK),
something I can't really do at the moment on this laptop. In a week I'll be
rid of it and be able to take up your suggestion. Thanks for drawing my
attention to sunflow, though, it looks really nice. Another good one
(although it's not open source) is Kerkythea. I haven't used it myself it
but it seems to have global illumination methods for almost every occasion.

> Also, Blender's AO is very slow if you have a large object (like a large
> quad for a floor), but you can speed it up by a factor of 2 or 3 if the
> octree is larger. You probably know this already, but I thought I'd mention
> it.

I'm afraid I'm using the intersection finding system as a black box at the
moment. I might look at intersection issues once I'm sure I'm taking the
"best" samples possible, but the intersection code in POV is probably not
improvable, at least by me. I *think* the size issue might be negated for
some shapes by POV's bounding slabs, but I know little about it.

I'm wary of looking at blender too closely, because of the license and
because I haven't seen nice AO results from blender yet, their example
images all seem really tiny.

Post a reply to this message

web.46894aed94b24855869b4c780@news.povray.org...

> 1) Ambient occlusion is so specific that you can almost say it has only 
> one
> or two uses. It's not flexible. I might never use it very much. Can't
> really say the same about radiosity, which I use a lot.

In my experience, AO can be used in a stand alone fashion as a replacement 
for radiosity and it can actually be good enough in some circumstances, but 
usually it's too unrealistic and can have bizarre side effects. As you said, 
it is very specific.

However, I find AO to be extremely handy and it would be a welcome addition 
to the POV-Ray toolset. Particularly, AO is extremely useful when used with 
radiosity. Typically, radiosity requires high sampling values to get 
detailed shadows in corners: it's hard to fine tune and can be very slow 
and/or memory consuming. When AO and radiosity are used together, AO can 
work its magic in the corners so that it becomes possible to lower the 
radiosity sampling = faster rendering. For instance, FinalRender has AO both 
as a standalone shader and as a part of its GI system, where it's used as an 
add-on to increase GI quality.

AO can be also used to create interesting texture effects, provided it can 
be set per object with the abiliy to drive other 
textures/materials/channels/shaders. One obvious use is cheap patinas. 
Another creative use I've seen was the following : to create a fuzzy darker 
stain on a surface without the hassle of defining a new texture layer or 
editing a bitmap, just create a new polygon object of the desired shape, 
make it invisible to anything but AO, and make it float above the surface to 
generate the stain...

G.

Post a reply to this message

I admit I hadn't considered AO as being useful in many of the contexts you
mention. At present it's implemented as a finish option, but the only
reason for that was familiarity with finish code; the goal and intent is an
ambient occlusion pattern type. Having thought about it more there would
actually be some fairly strange and interesting things you could do with an
AO pattern type, I agree.

Apart from cleverer image-space sampling, damn them, I notice that many
other AO implementations allow you to set a maximum search distance beyond
which an AO object will not respond to other objects. Do you use this
feature? I was thinking about some sort of occlusion_group system similar
to the existing light_group system instead, a max search distance seems a
bit arbitrary to me.

Low contrast is often mentioned as a problem with radiosity, but I wonder if
the improved flexibility of sampling in MegaPOV can help get around that. If
you hand it a custom sample set that is very concentrated in the normal
direction rather than being spread evenly over the full hemisphere, it
should work very much like the same as the angle parameter in AO.

Post a reply to this message

> Radiosity must be turned on or off globally for the whole picture.
> - From what I understand of Tom's posts, he implemented AO as a
> pigment feature that can be turned on or off on a per object basis.
> This could offer some very interesting possibilities...

Try no_radiosity  (MegaPov?)

Post a reply to this message

web.468ea5ce94b248557d55e4a40@news.povray.org...

> Apart from cleverer image-space sampling, damn them, I notice that many
> other AO implementations allow you to set a maximum search distance beyond
> which an AO object will not respond to other objects. Do you use this
> feature?

Definitely. There are other AO features to consider, basically those that 
help to control the spread (linear, exponential...) and contrast of the 
"shadowing". Again, keep in mind that when one uses AO as a (per object) 
shader, these features are quite mandatory. For instance, AO with a small 
spread and search distance (and low sampling) will be used on small objects 
(like a door handle) to give them a patina/dirt effect while AO with a 
larger spread and search distance will be used for walls to get proper 
corner shadowing and smooth/hide the radiosity artefacts that tend to crop 
up in corners.

G.

Post a reply to this message