How does POV-Ray's radiosity system actually work? Does it actually sit 
there and perform forward ray calculations like photon mapping does? Or 
does it just modify the normal reverse ray calculations to shoot some 
extra says to try to simulate diffuse reflections?

Andrew.

Post a reply to this message

Andrew the Orchid <voi### [at] devnull> wrote:
> How does POV-Ray's radiosity system actually work? Does it actually sit
> there and perform forward ray calculations like photon mapping does? Or
> does it just modify the normal reverse ray calculations to shoot some
> extra says to try to simulate diffuse reflections?
>
> Andrew.


Hi Andrew,

    POV-Ray uses hemisphere sampling combined with irradiance caching for
its "radiosity" system. The total illuminance at a point (which is what you
see) equals the direct illuminance + the indirect illuminance at that
point.

The direct illumination is computed using backward (AKA Whitted) raytracing.
The indirect illumination is gathered by shooting many rays through the
hemisphere over that point, and averaging the total illuminances of where
those rays intersect with objects in the scene.

     As you may guess, this is a recursive process because the illuminance
gathered by each hemisphere ray consists of the total (direct+indirect)
illuminance for the point where it intersected. This happens recursively
until the recursion_limit is reached. When the recursion bottoms out, a
constant ambient term is used for the indirect illuminance.

     Alone this method would be unworkable due to the combinatorial
explosion of rays that would need to be traced. However, the irradiance
cache provides a way out of this dilemma. After an illuminance sample is
gathered, its location is recorded into a data structure called an octree.
This is the irradiance cache. The next time POV-Ray needs to gather
indirect illuminance data it first checks this cache. If there are enough
samples nearby that have already been gathered the hard way, it averages
those and avoids gathering altogether. As tracing the scene progresses, the
cache fills up with values and makes gathering the hard way less and less
necessary. This makes the algorithm workable and avoids that combinatorial
explosion of rays!

Also see "A Ray Tracing Solution to Diffuse Interreflection" by Ward,
Rubenstein, and Clear.

Hope this helps,
George

Post a reply to this message

OK, so... it works by tracing backwards like normal, but with extra rays 
being spawned for diffuse illumination, approximately? (Just like 
specular reflection and refraction require additional rays.)

Well, that answers the main question.

Just to clarify... Are rays fired evenly in all directions? Completely 
at random? Are they set up to "avoid" the object under consideration? 
Are their directions in any way related to the direction of the ray that 
hit this surface in the first place? Does the total computed intensity 
take into account the different angles the light is illuminating the 
surface from?

You say the process traces backwards according to the max trace limit. 
(In fact, I think there might even be a parameter to change it for the 
radiosity system so it's different to the main trace.) Does POV-Ray only 
save the final intensities, or does it cache all the intermediate values 
too?

Andrew.

PS. Some graphical diagram in the help file would be really useful here. 
I /think/ I understand the overall principle now, but for a long time I 
was very confused by this feature.

Post a reply to this message

In article <41b629b3@news.povray.org> , Andrew the Orchid <voi### [at] devnull> 
wrote:

> Just to clarify... Are rays fired evenly in all directions? Completely
> at random? Are they set up to "avoid" the object under consideration?
> Are their directions in any way related to the direction of the ray that
> hit this surface in the first place? Does the total computed intensity
> take into account the different angles the light is illuminating the
> surface from?
>
> You say the process traces backwards according to the max trace limit.
> (In fact, I think there might even be a parameter to change it for the
> radiosity system so it's different to the main trace.) Does POV-Ray only
> save the final intensities, or does it cache all the intermediate values
> too?

All you questions can easily and quickly be answered by looking at the
freely available source code!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Andrew the Orchid <voi### [at] devnull> wrote:
> OK, so... it works by tracing backwards like normal, but with extra rays
> being spawned for diffuse illumination, approximately? (Just like
> specular reflection and refraction require additional rays.)
>

Yes.

> Well, that answers the main question.
>
> Just to clarify... Are rays fired evenly in all directions? Completely
> at random? Are they set up to "avoid" the object under consideration?
> Are their directions in any way related to the direction of the ray that
> hit this surface in the first place? Does the total computed intensity
> take into account the different angles the light is illuminating the
> surface from?
>

In the ideal case, you would want to use completely random rays, but POV-Ray
does not do this. Instead it uses a pre-computed table of ray directions
whose density falls off as the angle from the normal increases. Were it not
for this density fall-off, they would have roughly uniform coverage, but
with some quasi-randomness in their actual placement. (Jim McElhiney has
posted in more detail how he chose the sample set).

This density falloff places more weight on light that is coming to the point
head on, rather than at an angle, in accordance with Lambert's cosine law.
It saves computing time by tracing fewer rays in angles that contribute
less to the illumination. However, this approach has undesirable side
effects with regards to the irradiance caching process.

No, the directions of the gather rays are the same regardless of angle of
the ray that hit the surface in the first place. Also, before a gather ray
is shot, there is a check to make sure that it does not go behind the
surface in question.

> You say the process traces backwards according to the max trace limit.
> (In fact, I think there might even be a parameter to change it for the
> radiosity system so it's different to the main trace.) Does POV-Ray only
> save the final intensities, or does it cache all the intermediate values
> too?
>

No, I said it uses the radiosity recursion_limit, not the max_trace limit.
POV-Ray caches the intermediate values, too. However, it will only reuse
samples from the irradiance cache when the bounce depth of the stored
sample matches the bounce depth of the sample point in question.

> Andrew.
>
> PS. Some graphical diagram in the help file would be really useful here.
> I /think/ I understand the overall principle now, but for a long time I
> was very confused by this feature.

I agree on that! I'm not on the POV-Ray team, but I'd like to make one when
I get a chance.


George
http://www.gammaburst.net

Post a reply to this message

>
> All you questions can easily and quickly be answered by looking at the
> freely available source code!
>
>     Thorsten

With all due respect, it isn't easy or quick for a programmer unfamiliar
with the POV-Ray source code, let alone a non-programmer!

George

Post a reply to this message

George Pantazopoulos wrote:
> 
> In the ideal case, you would want to use completely random rays, but POV-Ray
> does not do this.

This is not really correct.  Completely random directions would not lead 
to better but worse results (you can easily try this).  There are 
sometimes artefacts due to the sample set being the same everywhere - 
MegaPOV has a patch for this purpose.  But apart from that using an 
optimized set of sampling directions is the best method.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> George Pantazopoulos wrote:
> >
> > In the ideal case, you would want to use completely random rays, but POV-Ray
> > does not do this.
>
> This is not really correct.  Completely random directions would not lead
> to better but worse results (you can easily try this).  There are
> sometimes artefacts due to the sample set being the same everywhere -
> MegaPOV has a patch for this purpose.  But apart from that using an
> optimized set of sampling directions is the best method.
>
>

Hi Christoph,

I'm willing to take your word on this, that an optimized distribution is
best, with one reservation. Specifically that it can cause artefacts when
used with the irradiance caching system.

When an illuminance sample is gathered, information about the distance to
all objects hit by the gather rays is cached along with the illuminance
value. This information includes the minimum distance and the (harmonic)
mean distance to all the objects encountered.

Later when this sample is a candidate for reuse, these statistics are used
to calculate the effective radius of the sample to see how reusable it is.
The optimized sample set used by default has fewer rays as the angle to the
normal gets larger. This means that low-lying objects near a sample point
can get missed by the gather rays. The effect of this would be a too-large
radius of reuse, resulting in artefacts.

George

Post a reply to this message

George Pantazopoulos wrote:
> 
> Later when this sample is a candidate for reuse, these statistics are used
> to calculate the effective radius of the sample to see how reusable it is.
> The optimized sample set used by default has fewer rays as the angle to the
> normal gets larger. This means that low-lying objects near a sample point
> can get missed by the gather rays. The effect of this would be a too-large
> radius of reuse, resulting in artefacts.

The non-uniform density of samples is not specific to the precomputed 
sample set, you would also use that when using random directions.  I 
don't think the effect you describe is a common source of artefacts but 
if you have an example for it i'd be interested.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

> All you questions can easily and quickly be answered by looking at the
> freely available source code!

True - if I can just work out how to interpret C... (It seems the 
language was explicitly designed to by crypted and difficult to read.)

Oh - and if I can work out which file it's in.

I did download the source once - I wanted to find out what a Sturmian 
root solver is, and how it works. I was eventually forced to give up, 
because it made no sense at all.

Post a reply to this message