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

AO is sounding really really good, especially as a per-object pattern 
function. Dust and shadows would be a realistic use for this, but there are 
other thing that could be done with this to color the serface. It could be 
used to apply grout on tiles, or some strange effect on an alien planet. 
Keep up the good work!

"Gilles Tran" <tra### [at] inapgfr> wrote in message 
news:46961491$1@news.povray.org...

> 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

Well, this was going ok until I ran into meshes (possibly other primitives
as well), which use their own internal bounding hierarchy that the shader
can't access or know about.

The methods I've started using to allow implementation of a user-specified
search distance (and speed up the effect) involve producing a cut-down
bounding hierarchy from the scene for picking up intersections along
occlusion rays, and the mesh's internal bounding sidesteps all of that.

Since I use meshes a lot, I decided not to spend any more time on this for
now. I'm going wait for 3.7 and see what the situation is then. From the
sound of it a lot of the code will have been cleaned up.

Attached is the last attempt, with the occlusion pigment providing the
surface colour (ranging from very dark blue to white), diffuse shading
only. Three lights were used, two of them shadowless. Render time (with
non-exclusive use of the processor) was 55 minutes for 128 occlusion sample
rays and +A0.3 +AM2 +r1, on a 2.4GHz P4. You can get a reasonable preview
quality image in about 7 minutes with between 8-32 sample rays.

Tom

Post a reply to this message

Attachments:
Download 'ao_54min.jpg' (142 KB)

Preview of image 'ao_54min.jpg'

"Tom York" <alp### [at] zubenelgenubi34spcom> wrote:
> Well, this was going ok until I ran into meshes (possibly other primitives
> as well), which use their own internal bounding hierarchy that the shader
> can't access or know about.
>
> The methods I've started using to allow implementation of a user-specified
> search distance (and speed up the effect) involve producing a cut-down
> bounding hierarchy from the scene for picking up intersections along
> occlusion rays, and the mesh's internal bounding sidesteps all of that.
>
> Since I use meshes a lot, I decided not to spend any more time on this for
> now. I'm going wait for 3.7 and see what the situation is then. From the
> sound of it a lot of the code will have been cleaned up.
>
> Attached is the last attempt, with the occlusion pigment providing the
> surface colour (ranging from very dark blue to white), diffuse shading
> only. Three lights were used, two of them shadowless. Render time (with
> non-exclusive use of the processor) was 55 minutes for 128 occlusion sample
> rays and +A0.3 +AM2 +r1, on a 2.4GHz P4. You can get a reasonable preview
> quality image in about 7 minutes with between 8-32 sample rays.
>
> Tom

Fell on this discussion by accident, I try bumping this up to show interest does
exist: Is this an abandonned project now? or is there an alternative solution in
3.8 through aoi pattern or other "new" features?

Post a reply to this message