 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
Attachments:
Download 'ambientocclusiondemo.jpg' (59 KB)
Preview of image 'ambientocclusiondemo.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A simpler image. Here I placed some boxes over an infinite plane, with
everything having the ambient occlusion material. Again, 128 samples were
used although like before it isn't enough to get rid of all the noise. This
took 216 seconds to render.
Post a reply to this message
Attachments:
Download 'ambientocclusionboxes.jpg' (32 KB)
Preview of image 'ambientocclusionboxes.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom York wrote:
> A simpler image. Here I placed some boxes over an infinite plane, with
> everything having the ambient occlusion material. Again, 128 samples were
> used although like before it isn't enough to get rid of all the noise. This
> took 216 seconds to render.
>
>
> ------------------------------------------------------------------------
I think you're doing good. Even with the noise, this would be a useful
pigment to have.
~Sam
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/
>
> 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] netscape net> 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
|
|
| |
| |
|
|
|
|
| |
|
|
