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

>>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.

Cool. :-)

So... the pretrace step... Is the video from that used for anything? Or 
is the only purpose of this step to fill up the cache?

>>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.
> 
> 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.
>
> 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.

...does all of this mean that the diffuse highlight options don't affect 
radiosity?

Also, while we're on the subject, does radiosity take (specular) 
reflection into account as well? (Never tried it, but I assume it does...)

>>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.

So there's a separate cache for each depth?

>>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.

Yeah, I might have a go at it too at some point...

Andrew.

Post a reply to this message

While I'm here - slightly different question.

They recommend you don't try to render radiosity images in parallel. 
Would it be possible to run the pretrace step, save the rad data, and 
then start a full render going on 2 instances of POV-Ray, both loading 
back the same rad data? (I'd have to turn off additional sampling, 
probably.) Would that work OK? Anyone ever tried it?

(My dad has a faster computer than me - and it's dual CPU.)

Andrew.

Post a reply to this message

> So... the pretrace step... Is the video from that used for anything? Or
> is the only purpose of this step to fill up the cache?
>

Its just to seed the cache with values (somewhat evenly distributed over the
scene space).

>
> ...does all of this mean that the diffuse highlight options don't affect
> radiosity?
a>

What I said doesn't lead to that conclusion. However, those faked diffuse
highlights (phong, specular) are indeed deliberately disabled for radiosity
gather
rays "since this causes problems with colors being far to bright"(quoted
from lighting.cpp Diffuse_One_Light() ).

> Also, while we're on the subject, does radiosity take (specular)
> reflection into account as well? (Never tried it, but I assume it does...)

Yup, real specular reflection (not the faked highlights) is taken into
account! I've been having some fun with that lately, by disabling the
irradiance cache and taking samples for every pixel. It's slow, but
beautiful and funn :) The fun part is that I HAVE written software that
lets me (and hopefully you sometime) render in parallel, so I don't go
crazy waiting for the render :)

George

Post a reply to this message

> While I'm here - slightly different question.
>
> They recommend you don't try to render radiosity images in parallel.
> Would it be possible to run the pretrace step, save the rad data, and
> then start a full render going on 2 instances of POV-Ray, both loading
> back the same rad data? (I'd have to turn off additional sampling,
> probably.) Would that work OK? Anyone ever tried it?
>
> (My dad has a faster computer than me - and it's dual CPU.)
>
> Andrew.

Yup, as long as both machines use the same irradiance cache to render their
subimages, and you turn off always_sample, you wont get any tiling
artifacts (*).

*If your shared irradiance cache is not sufficiently filled, however,
POV-Ray will still take samples if it can't find any to reuse, even if
always_sample is set to off. This would have the effect of not using the
same irradiance data for each tile, and may lead to the tiling artifacts
depending on how often POV-Ray is forced to sample during the final pass.

Ideally you want the caches to be the same exactly, but even having the
caches close but not matched suppresses the tiling artifacts to varying
degrees (sometimes greatly).

If you render in parallel simply by controlling POV-Ray with an external
script (using +SC/+EC/+SR/+ER), it will do a radiosity pretrace for each
tile, using only the image dimensions that tile occupies. This would make
the irradiance data used per tile drastically different, leading to the
dreaded tile artifacts. It would also by default throw away all the rad
data used after every tile.

In the parallel software I've written (which involves a patch to POV-Ray), I
do the pretrace only once per machine using the full image dimensions. (I
preserve the rad data internally after the pretrace and between individual
tiles). Then I crank out each tile (subimage) without doing any partial
image pretraces for the tiles. This greatly suppressed those tile
artifacts! I'm pleased and encouraged by this, and I want to take it
further.

As it stands now, each machine is doing duplicate work in the pretrace. The
next thing I want to try is to have each machine render a slightly
different pretrace (using jittered, or stratified sampling), then have all
the machines upload their results to the Client, combine them, and send the
full cache to each machine in preperation for the real rendering (the
tiles). Assuming
sending the rad data does not take too much time, this would be a
significant speedup over the current approach!

George

Post a reply to this message

>>So... the pretrace step... Is the video from that used for anything? Or
>>is the only purpose of this step to fill up the cache?
> 
> Its just to seed the cache with values (somewhat evenly distributed over the
> scene space).

OK. Whereas without that step, you would fill up one corner of the cache 
first, potentially meaning other parts don't have the influence they should?

>>...does all of this mean that the diffuse highlight options don't affect
>>radiosity?
> 
> What I said doesn't lead to that conclusion. However, those faked diffuse
> highlights (phong, specular) are indeed deliberately disabled for radiosity
> gather
> rays "since this causes problems with colors being far to bright"(quoted
> from lighting.cpp Diffuse_One_Light() ).

Right. But when I ment was, there's a keyword (roughness?) which 
controls the angle at which light affects the surface. I was trying to 
figure out whether the rad calculations take this into account.

>>Also, while we're on the subject, does radiosity take (specular)
>>reflection into account as well? (Never tried it, but I assume it does...)
> 
> Yup, real specular reflection (not the faked highlights) is taken into
> account! I've been having some fun with that lately, by disabling the
> irradiance cache and taking samples for every pixel. It's slow, but
> beautiful and funn :) The fun part is that I HAVE written software that
> lets me (and hopefully you sometime) render in parallel, so I don't go
> crazy waiting for the render :)

Mmm... sounds interesting.

Although... I suspect photon maps are faster. ;-)

Actually, I suppose you could program POV-Ray to try to illuminate an 
entire scene with photon maps. I imagine that would go real slow, 
compute a lot of photons you can't see, and generally not look so great. 
(Does photon mapping work for a depth of more than 1?)

Andrew.

Post a reply to this message

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

> 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.

Heh...probably not the best way to go about it. Try this:
http://shadowfax.homelinux.net/cs275/

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

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

> Right. But when I ment was, there's a keyword (roughness?) which 
> controls the angle at which light affects the surface. I was trying to 
> figure out whether the rad calculations take this into account.

You're asking whether the parameters controlling how lighting falls off 
as angle to the surface changes control the weighting of the radiosity 
samples? As far as I know, no...it uses a plain ol' Lambertian falloff, 
where the point weighting or distribution is done according to the 
cosine of the angle to the surface normal. That is, it assumes the 
surface is perfectly diffuse. This is usually a good enough 
approximation for things radiosity is used for.

The parameter you're thinking of is probably brilliance, which modifies 
the Lambertian falloff by raising it to a power...the falloff is 
pow(cos(angle), brilliance). As far as I know, the sample rays will 
"see" the effects of brilliance on other surfaces, but their weighting 
will be unaffected by it.
(Someone should probably check whether the "too bright" problem of 
highlights still applies...)


> Actually, I suppose you could program POV-Ray to try to illuminate an 
> entire scene with photon maps. I imagine that would go real slow, 
> compute a lot of photons you can't see, and generally not look so great. 

What you describe is "global photons". Possible, can very accurately 
simulate actual physical effects which are otherwise difficult or 
impossible, but extremely memory hungry and not really efficient. 
Multi-pass techniques might be useful...shoot a few million photons, do 
a render pass with the radius of effect of each photon limited (get a 
really dim, spotty picture), and continue to shoot photons and add the 
results together until you get a final picture. Jitter each pass 
slightly, and you get some antialiasing or focal blur in the bargain.


> (Does photon mapping work for a depth of more than 1?)

It wouldn't be very useful if it didn't. ;-)
You can actually specify separate max_trace_level and adc_bailout for 
photons. If you don't, the values specified for rendering are used.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:

>>Actually, I suppose you could program POV-Ray to try to illuminate an 
>>entire scene with photon maps. I imagine that would go real slow, 
>>compute a lot of photons you can't see, and generally not look so great. 
> 
> 
> What you describe is "global photons". Possible, can very accurately 
> simulate actual physical effects which are otherwise difficult or 
> impossible, but extremely memory hungry and not really efficient. 
> Multi-pass techniques might be useful...shoot a few million photons, do 
> a render pass with the radius of effect of each photon limited (get a 
> really dim, spotty picture), and continue to shoot photons and add the 
> results together until you get a final picture. Jitter each pass 
> slightly, and you get some antialiasing or focal blur in the bargain.
> 
> 
> 

Seems that WinOsi does something similar : http://www.winosi.onlinehome.de/

But indeed, it is very slow... But then it's supposed to be very 
accurate as well...

-- 
Vincent

Post a reply to this message