Tom York nous apporta ses lumieres en ce 2007/06/30 20:34:
> I implemented a basic sort of ambient occlusion using the MegaPOV 1.2.1
> source as a base. The idea behind ambient occlusion is outlined here, if
> you've not heard of it before:
> 
> http://www-viz.tamu.edu/students/bmoyer/617/ambocc/
> 
> The example on that page pretty much sums up my use case: a shader that will
> produce an occlusion image that I can layer over a direct illumination pass
> to suggest more realistic shading. There are alternative ways in povray to
> get the ambient occlusion effect, and alternative ways to fulfill the use
> case as well, but I liked the simplicity of the ambient occlusion idea, and
> after experimenting with a method based on the proximity pattern I decided
> that source modification was probably the cleanest and fastest route to go.
> 
> At the moment the effect samples entire hemispheres (I thieved the
> hemispherical sample set that standard radiosity uses, I'm afraid), so you
> need a lot of samples to reduce the noise. Because the sampling surface is
> so extensive, objects also react quite strongly to each other and the
> occlusion effect is very visible. Narrowing the sampling surface would
> concentrate the effect (and require fewer samples to reach the same noise
> level). I've heard (here?) that altering the sampling surface can alter the
> perception of scale the effect produces.
> 
> The attached image shows a simple scene using 128 AO samples, consisting of
> a sphere and a few cylinders, with some cylinders CSG differenced. It took
> 22 minutes to render on a laptop with a Pentium 4-M 1.8GHz processor,
> although I was listening to banging tunes and using the information
> superhighway at the same time. It was rendered with antialiasing settings:
> A0.3 and AM2. I hope it isn't too unbalanced, brightness-wise, as this
> laptop's screen is absolutely horrible.
> 
> This is quite a simple scene and the method can be expected to slow down
> considerably as scene complexity increases. Having said that, it's not as
> slow as I thought it might be despite the number of samples I'm using.
> After introducing the ability to change the size of the sampling
> hemisphere, which should allow me to reduce the number of samples used, I
> plan to think about the best way to integrate this into POV's materials
> system. At the moment it basically acts the same way as the finish term
> ambient does. Also, full occlusion is always black and zero occlusion is
> always white, whereas most apps allow the user to choose.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
Do you realise that's what we call "radiosity" in POV-Ray? And that those so 
caled "ambient oclusion" are automaticaly generated using by that radiosity 
algorythm? It just need dome tweaking of the available parameters.

-- 
Alain
-------------------------------------------------
Never underestimate the power of stupid people in large groups.

Post a reply to this message

Tom York nous apporta ses lumieres en ce 2007/06/30 20:34:
> I implemented a basic sort of ambient occlusion using the MegaPOV 1.2.1
> source as a base. The idea behind ambient occlusion is outlined here, if
> you've not heard of it before:
> 
> http://www-viz.tamu.edu/students/bmoyer/617/ambocc/
> 
If I remember correctly, that reference page was mentioned in this group some 
years ago, and generated about the same comment I just gave you.

-- 
Alain
-------------------------------------------------
   I knew a girl so ugly that she was known as a two-bagger. That's When you put 
a bag over your head in case the bag over her head comes Off.
	Rodney Dangerfield

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> Do you realise that's what we call "radiosity" in POV-Ray? And that those so
> caled "ambient oclusion" are automaticaly generated using by that radiosity
> algorythm?

I'm very aware of the similarities (and the differences). As I mentioned in
my first post, there are alternative ways to fulfill the use case I had;
clearly radiosity is one of them.

I had my own reasons for not going straight to radiosity, and a lot of spare
time. I have been constructing scenes using radiosity for a very long time.
I'm aware of what it can do.

Tom

Post a reply to this message

Alain wrote:
> Do you realise that's what we call "radiosity" in POV-Ray? And that 
> those so caled "ambient oclusion" are automaticaly generated using by 
> that radiosity algorythm? It just need dome tweaking of the available 
> parameters.

POV-Ray's current radiosity implementation doesn't allow you to use the 
result as a so-called "dirt map" - which would be useful for dirt in 
corners, chips on edges, etc.

~Sam

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alain wrote:
> Do you realise that's what we call "radiosity" in POV-Ray? And that
> those so caled "ambient oclusion" are automaticaly generated using by
> that radiosity algorythm? It just need dome tweaking of the available
> parameters.
> 
	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...

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGh/iMd0kWM4JG3k8RAlBYAJ9jCRGhPPRfdZ0wVa4OnMd6WKP6RwCggkP5
4efl2phjMb+1+U47q4uVOBk=
=l8gh
-----END PGP SIGNATURE-----

Post a reply to this message

"Tom York" <alp### [at] zubenelgenubi34spcom> wrote:
> I had my own reasons for not going straight to radiosity, and a lot of spare
> time. I have been constructing scenes using radiosity for a very long time.
> I'm aware of what it can do.

What are the relative advantages and disadvantages of each technique?

Post a reply to this message

"Cousin Ricky" <ric### [at] yahoocom> wrote:
> "Tom York" <alp### [at] zubenelgenubi34spcom> wrote:
> > I had my own reasons for not going straight to radiosity, and a lot of spare
> > time. I have been constructing scenes using radiosity for a very long time.
> > I'm aware of what it can do.
>
> What are the relative advantages and disadvantages of each technique?

Radiosity is a powerful method for computing indirect illumination - it's a
proper global illumination system. Ambient occlusion just isn't, it's
nothing but a simple trick to get you dirt shading or to liven up an
existing direct illumination image. Radiosity *can* fulfill my original
requirement, because it does everything ambient occlusion can do and a lot
more besides. So these techniques are not really comparable except in a
very limited area.

My reasons for choosing to implement ambient occlusion instead of using
radiosity to meet my requirements were these:

1) Despite its simplicity, ambient occlusion could do the job. The idea of
having only two parameters to fiddle with was very attractive, especially
since I knew exactly how they related to visual results and quality. I
would be faced with a much larger parameter space with radiosity. Perhaps
what I'd lose in final rendering time, I'd more gain in preview and
adjustment time. This place is littered with threads in which people spend
a long time trying to find acceptable radiosity solutions and get rid of
stubborn artefacts. I just wanted something I could point at a problem,
makes some reasonable guesses, let it go, and come back later to find a
result I found acceptable, reliably.

2) The per-object nature of ambient occlusion interested me, although I
haven't taken advantage of it as yet.

3) I was interested to see a different kind of noise from the one associated
with radiosity. Ideally, errors in the radiosity solution appear only as low
frequency noise, but there can be sharp-edged features visible that disrupt
the effect, and that can sometimes be difficult to get rid of even as the
quality of the solution increases. Sampling errors in occlusion should show
up as high frequency noise, and increasing the number of samples should
always reduce the noise. I think it's true, as the docs say, that low
frequency noise is less visually disturbing than high frequency noise if
both contain the same power, but radiosity artefacts complicate things for
me. I just wanted to see what I thought about the results.

4) This project looked reasonably simple and doable to me. I suspected that
a great deal of existing povray code could be reused to do the job. I am
lazy, you see. I don't think I've added more than a couple of original
lines to the source, most of it's been cut-and-paste. I have some other
ideas for additions, but this one struck me as most likely to be doable in
the time I have.

5) The screen on this laptop is an utter disaster, calibration-wise. It
makes artistic results difficult to judge. So I was more in favour of
spending a given amount of time coding than adjusting visual output from
radiosity in SDL a great deal, since as soon as I get home to a proper
computer I know it's going to look bad, and all that radiosity tweaking
time might have to be redone.

I knew there'd be very severe drawbacks to the ambient occlusion approach:

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.

2) I knew that it would certainly be a lot slower than a radiosity approach
in rendering. Most of the control and code complexity of radiosity is
involved in applying its main assumption, that indirect illumination
changes slowly across surfaces. Most of the problems with it come when that
assumption breaks down, but the gains are enormously significant in speed.
Ambient occlusion *will* trace an additional NSamples (128 in my images)
rays per camera ray hitting an occlusion object. Even with POVRay's
intersection acceleration structures, that has to have a rendering time
cost and it can be very great. Radiosity's assumption about indirect
illumination gives it a huge rendering speed advantage.

3) At low counts, low frequency noise is definitely a lot less noticable
than high frequency noise. With careful tweaking, sometimes more, sometimes
not much at all, you can usually get rid of those radiosity artefacts and be
left with noise that doesn't distract at all from the image.

4) I didn't intend use in animation, but that is another drawback. For
static scenes, at least, you can partially cache radiosity data. Can't do
that with ambient occlusion, another disadvantage.

So I was after a simple, predictable method rather than a potentially very
fast but complicated one, especially since I had an idea that the
particular circumstances (darkened shading on small cracks and surface
features) would slow down the faster method. But if anyone reads this as
some sort of challenge to radiosity and posts under that delusion then I
shall ignore them, as it isn't.

I remember some comparison thread here a while back between XSI (presumably
mental ray) and povray's global illumination. IIRC, the thread author
really liked the warmth of tone in POV's radiosity and the response of
surfaces to it, if not the speed (although I'm not sure the thread starter
had optimal settings, his render times sounded really off). I completely
agree with that assessment. I use radiosity regularly. I feel it's a bit
ridiculous to have to put a disclaimer in about my attitude to radiosity
just for implementing a barely-related and rather limited feature, but
there seems to be a traditional script for this type of thread and I am
anxious to avoid wasting time on it.

Post a reply to this message

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