Hola,

Working on this section in docs:
http://wiki.povray.org/content/Documentation:Reference_Section_3.2#Adjusting_Radiosity

and came across something I'm not quite clear on. In particular the
"maximum_reuse" entry ... 3rd line into that entry refers to
"reuse_count" setting ... typo? (lifted this from change-log)

Also a general review of that section would be nice before I call this
section done. So anyone who feels inclined to have a look, please do so.
If you see anything else that needs attention, either mention it here
... or on the "talk" page for that section, and I'll follow up.

Thanks
Jim

Post a reply to this message

Am 28.05.2010 19:54, schrieb Jim Holsenback:
> Hola,
>
> Working on this section in docs:
>
http://wiki.povray.org/content/Documentation:Reference_Section_3.2#Adjusting_Radiosity
>
> and came across something I'm not quite clear on. In particular the
> "maximum_reuse" entry ... 3rd line into that entry refers to
> "reuse_count" setting ... typo? (lifted this from change-log)

No typo - just multiple modifications to radiosity that ended up being 
submitted as a single change batch.

(1) "The maximum_reuse parameter now governs the maximum effective 
radius of a sample more directly."

This mod does indeed refer to the "maximum_reuse" setting.

(2) "When a new sample has been gathered after sample lookup returned 
insufficient samples, sample lookup is no longer run again; instead, the 
new sample is interpolated with the results of the earlier lookup."

This mod is an internal optimization.

(3) "The actual number of samples required to satisfy the reuse_count 
setting is now influenced by sample quality, with high-quality samples 
reducing the effective number of samples required (down to 1/4 of the 
parameter value in extreme cases) and low-quality samples increasing the 
number. Note that this may change the balance between speed and quality 
for some scenes."

This mod changes the effect of the "reuse_count" setting.

Post a reply to this message

Am 28.05.2010 19:54, schrieb Jim Holsenback:
> Hola,
>
> Working on this section in docs:
>
http://wiki.povray.org/content/Documentation:Reference_Section_3.2#Adjusting_Radiosity
>
> and came across something I'm not quite clear on. In particular the
> "maximum_reuse" entry ... 3rd line into that entry refers to
> "reuse_count" setting ... typo? (lifted this from change-log)
>
> Also a general review of that section would be nice before I call this
> section done. So anyone who feels inclined to have a look, please do so.
> If you see anything else that needs attention, either mention it here
> ... or on the "talk" page for that section, and I'll follow up.

---------------------------
  always_sample

You can force POV-Ray to only use the data from the pretrace step and 
not gather any new samples during the final radiosity pass. This may 
reduce splotchiness. To do this, use always_sample off, by default it is 
on. It can also be usefully when reusing previously saved radiosity data.
---------------------------

As a matter of fact, for high-quality results "always_sample off" is 
virtually a /must/, and for quick renders it's a good thing as well. 
(Expect this value's default to change accordingly before the release; 
I'm even pondering removing that parameter altogether.)

---------------------------
  brightness

The brightness keyword specifies a float value that is the degree to 
which objects are brightened before being returned upwards to the rest 
of the system. The default value is 1.0. In cases where you would raise 
the global_settings{ambient_light value} to increase the over all 
brightness in a non-radiosity scene, you can use brightness in a 
radiosity scene.
---------------------------

This is actually not so good advice. In an ideal world, "brightness" 
should be set to 1.0. If the overall brightness doesn't seem to fit, the 
diffuse color of objects and/or the overall brightness of light sources 
(including ambient>0 objects) should be adjusted.

A typical problem in radiosity scenes is that people set "pigment" to 
e.g. "rgb <1.0,1.0,1.0> and "diffuse" to 1.0, and then tweak the light 
source and "ambient_light" brightness to make the image look right. This 
will not work in radiosity scenes, as it will give too strong 
interreflections. While you /can/ compensate for this by reducing 
radiosity "brightness", it's generally discouraged. Instead, in this 
case the surface properties should be fixed (e.g. "diffuse" set to 
something around 0.7, which is much more realistic).

An exception is the adjusting of "brightness" to compensate for low 
"recursion_limit" settings: Setting "recursion_limit" to e.g. 1 
effectively suppresses part of diffuse interreflection (those using more 
diffuse bounces); to compensate for this, it is suggested to increase 
"brightness" a bit (e.g. 1.2 instead of 1.0).

----------------------------
  nearest_count

The nearest_count integer value is the minimum number of old ambient 
values blended together to create a new interpolated value. The total 
number blended will vary depending on error_bound. All previous values 
that fit within the specified error_bound will be used in the average.

It will always be the n geometrically closest reusable points that get 
used. If you go lower than 4, things can get pretty patchy. This can be 
good for debugging, though. Must be no more than 20, since that is the 
size of the array allocated. The default value is 5.
----------------------------

This sounds contradictory to me: Is the total number of blended samples 
governed by error_bound, or will only the n geometrically closest 
samples be used?

Fact is, there is no upper limit on the number of samples blended - all 
available samples are blended that match the error_bound and 
maximum_reuse settings. Nor is there any internal data structure these 
days that would require nearest_count to be capped. (The "nearest_count" 
parameter is still limited to 20, but this is just a relic which 
probably hasn't been removed for the sole reason that values >20 are not 
really very useful in practice.

Post a reply to this message

On 05/28/2010 05:15 PM, clipka wrote:
> <snipped a bunch of useful info>

Looks like I have my work cut out for me ;-)
GOOD stuff ... Tausend Dank!

Post a reply to this message

On 05/28/2010 04:04 PM, clipka wrote:
> 
> (3) "The actual number of samples required to satisfy the reuse_count
> setting is now influenced by sample quality, with high-quality samples
> reducing the effective number of samples required (down to 1/4 of the
> parameter value in extreme cases) and low-quality samples increasing the
> number. Note that this may change the balance between speed and quality
> for some scenes."
> 
> This mod changes the effect of the "reuse_count" setting.

is there a default value associated with this parameter?

Post a reply to this message

Am 29.05.2010 12:25, schrieb Jim Holsenback:
> On 05/28/2010 04:04 PM, clipka wrote:
>>
>> (3) "The actual number of samples required to satisfy the reuse_count
>> setting is now influenced by sample quality, with high-quality samples
>> reducing the effective number of samples required (down to 1/4 of the
>> parameter value in extreme cases) and low-quality samples increasing the
>> number. Note that this may change the balance between speed and quality
>> for some scenes."
>>
>> This mod changes the effect of the "reuse_count" setting.
>
> is there a default value associated with this parameter?

Oh my, looks loke I wrote a bit of nonsense back then...

Replace All
   Seach text:   "reuse_count"
   Replace with: "nearest_count"

Post a reply to this message

On 05/30/2010 04:21 PM, clipka wrote:
> Oh my, looks loke I wrote a bit of nonsense back then...
> 
> Replace All
>   Seach text:   "reuse_count"
>   Replace with: "nearest_count"

ha-ha .. you're entitled ;-)

thanks for the clarification!

Post a reply to this message