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