 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A question for Nathan, or anyone else who knows...
I thought that radiosity works a bit like blurred reflection, shooting
out X samples in random directions to gather environmental information,
but I've been experimenting some more today and it seems like this may
not be the case.
So how *does* it work, exactly? And if it is like blurring, wouldn't an
option to shoot out rays which are evenly spaced over an area instead of
randomly-aimed produce smoother and more accurate results, assuming a
decently-large (say, at least a hundred) number of samples?
-Xplo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sorry, I can't answer to your question. However, I have a suggestion..
Why not organise a "radiosity roundtable" ? Let me explain : when
radiosity appeared in POV-Ray, the availiable computers made it very
slow, and thus difficult to master. Slowly, people started to
understand how it sould be used to give good results, and realised
that the "right way" was quite different from what the docs said.
At one point, when our favorite sport was "rad without light source",
Nathan decided to modify the core code. It worked ten times better
than before, but, still, people started making interesting discoveries
(you, TonyB, Gilles, and others), which again showed that the engine
was better than what the programmers tought !! So, my suggestion is to
do some "comferences", where concerned people could publicly exchange
their views about how it works, how it acts, how it could work...
A detailed answer to your question could be a good starting point.
Of course, if it happens, it would be after the release of
POV-Ray 3.5...
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Xplo Eristotle <inq### [at] unforgettable com> wrote:
: I thought that radiosity works a bit like blurred reflection, shooting
: out X samples in random directions to gather environmental information,
: but I've been experimenting some more today and it seems like this may
: not be the case.
Yes, it basically works like this.
However, if it only did this, the rendering of any simple scene with
radiosity would take ages (eg. with 100 samples and recursion level 4 it
would take 4^100 times longer, ie. about 10^62 times longer; which means
that the Sun would die before the rendering is ready).
I have to go to class right now but I'll explain a little bit more when
I return and nobody else has already done it.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
As far as I have understood, the algorithm goes approximately this way
(Nathan, please correct me if I say anything wrong):
The lighting values of the radiosity calculations are stored in a spatial
tree.
When the lighting of a certain point is calculated povray first looks if
the point is close enough to a point in that spatial tree. If it is, then
it just takes some closest points in the tree (I think that the number
is specified with 'nearest_count') and calculates a weighted average of
their illumination values.
If there isn't any point close enough, then it shoots lots of rays
in every direction (well, not in every direction but only through the
hemisphere which is defined by the surface normal vector). If the recursion
level is 1, then it just takes those values the rays hit. If the recursion
level is higher than 1, then it performs this same algorithm for each
intersection point.
At the beginning the spatial tree is empty and thus the first rays will
take pretty long to calculate, but as the tree gets filled of values, less
samples have to be taken and more old sample values can be used.
This is why even a deep recursion level will not explode the render time.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabien Mosen wrote:
>
> Sorry, I can't answer to your question. However, I have a suggestion..
> Why not organise a "radiosity roundtable" ? Let me explain : when
> radiosity appeared in POV-Ray, the availiable computers made it very
> slow, and thus difficult to master. Slowly, people started to
> understand how it sould be used to give good results, and realised
> that the "right way" was quite different from what the docs said.
> At one point, when our favorite sport was "rad without light source",
> Nathan decided to modify the core code. It worked ten times better
> than before, but, still, people started making interesting discoveries
> (you, TonyB, Gilles, and others), which again showed that the engine
> was better than what the programmers tought !! So, my suggestion is to
> do some "comferences", where concerned people could publicly exchange
> their views about how it works, how it acts, how it could work...
I was actually in the midst of putting together some webbable material
on low-error radiosity when it occurred to me to ask this question.
Won't be done for a while, though; I'm still making a demo scene, and
that takes a while to render (and eats more RAM than I can really give
it; low-error is pretty RAM-intensive).
-Xplo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> As far as I have understood, the algorithm goes approximately this way
> (Nathan, please correct me if I say anything wrong):
>
> The lighting values of the radiosity calculations are stored in a spatial
> tree.
> When the lighting of a certain point is calculated povray first looks if
> the point is close enough to a point in that spatial tree. If it is, then
> it just takes some closest points in the tree (I think that the number
> is specified with 'nearest_count') and calculates a weighted average of
> their illumination values.
> If there isn't any point close enough, then it shoots lots of rays
> in every direction (well, not in every direction but only through the
> hemisphere which is defined by the surface normal vector). If the recursion
> level is 1, then it just takes those values the rays hit. If the recursion
> level is higher than 1, then it performs this same algorithm for each
> intersection point.
Okay, that sounds about right.
Here's what's bothering me, though: I have a small room with no
traditional lighting and a rad source (1/8th of a three foot radius
sphere with ambient 8 or so) in one corner, and the light it shines on
the far wall is decidedly splotchy, even with the nearest_count pumped
to 20 (the max) and the count cranked up to 600 (I really don't want to
go higher, as it's already slow enough, and *shouldn't* have to).
It occurs to me that if the radiosity algorithm is shooting out random
rays, then although they should average out, they may not be doing a
very good job of it, and I wonder if it would work better with some kind
of even distribution pattern.
It might be worth looking into other ways to tweak the algorithm as
well, but for now that sort of thing would be over my head.
-Xplo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Xplo Eristotle wrote:
> It occurs to me that if the radiosity algorithm is shooting out random
> rays, then although they should average out, they may not be doing a
> very good job of it, and I wonder if it would work better with some kind
> of even distribution pattern.
Someone did that :
http://perso.wanadoo.fr/albedo/patchedpov.html
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> would take 4^100 times longer, ie. about 10^62 times longer; which means
Wouldn't this be 100^4, ie 10^8? Quite a bit different of a number...
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Xplo Eristotle <inq### [at] unforgettablecom> wrote:
: Here's what's bothering me, though: I have a small room with no
: traditional lighting and a rad source (1/8th of a three foot radius
: sphere with ambient 8 or so) in one corner, and the light it shines on
: the far wall is decidedly splotchy, even with the nearest_count pumped
: to 20 (the max) and the count cranked up to 600 (I really don't want to
: go higher, as it's already slow enough, and *shouldn't* have to).
The problem is that since your bright object is small, the rays sent
from each intersection point will hit it only rarely. This means that only
few of these points will be illuminated by that bright object while the
others are dark. This is what causes the splotchiness.
You'll get a lot better result if you make that bright object shadowless
and add a light_source (possibly an area_light) in the middle of it.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Fontaine <dav### [at] faricynet> wrote:
: Wouldn't this be 100^4, ie 10^8? Quite a bit different of a number...
Oops, your are right... :)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
