Am 11.03.2018 um 20:03 schrieb Kenneth:

> The resulting 'threshold' render statistics (at a 640 X 480 render size, no
                                                    ^^^^^^^^^ !!!
> ----------------------------------------------------------------------------
>   Pass     Depth 0           Total
> ----------------------------------------------------------------------------
>   1            130             130
>   2            475             475
>   Final     307200          307200
              ^^^^^^ !!!

Final render produces exactly 1 radiosity sample per pixel. So POV-Ray
obviously thinks that /all/ the samples it gathered so far (whether
during pretrace or while rendering previous pixels) are totally useless.

Post a reply to this message

In light of these weird results, I'm wondering what effect (if any) the
'threshold' phenomenon has on a USUAL rad render of any typical scene. For
example, a scene using rad brightness 0.7. My tests up to now have all been with
the *entire scene* run at brightness .020 (i.e., with the value pre-set in the
radiosity{...} block.)  But does this underlying brightness 'threshold' also
affect 'typical' rad renders in a microscopic or local way? I'm thinking of what
might happen to a particular pixel or group of pixels that happen to fall below
..020 in brightness, for whatever reason.  In other words, does the phenomenon
kick in for just those dark pixels (or dark rad 'patches')?

Of course, my understanding of the rad 'brightness' mechanism itself could be
wrong.

Or maybe my 'armchair philosophy' is just getting too far ahead of the facts ;-)

Post a reply to this message

Am 12.03.2018 um 20:58 schrieb Kenneth:
> In light of these weird results, I'm wondering what effect (if any) the
> 'threshold' phenomenon has on a USUAL rad render of any typical scene. For
> example, a scene using rad brightness 0.7. My tests up to now have all been with
> the *entire scene* run at brightness .020 (i.e., with the value pre-set in the
> radiosity{...} block.)  But does this underlying brightness 'threshold' also
> affect 'typical' rad renders in a microscopic or local way? I'm thinking of what
> might happen to a particular pixel or group of pixels that happen to fall below
> ...020 in brightness, for whatever reason.  In other words, does the phenomenon
> kick in for just those dark pixels (or dark rad 'patches')?
> 
> Of course, my understanding of the rad 'brightness' mechanism itself could be
> wrong.
> 
> Or maybe my 'armchair philosophy' is just getting too far ahead of the facts ;-)

Having had a closer look at the whole shebang, there aren't any local
effects to this: There is just a bug that will kick in whenever

    (brightness/2)^(DEPTH+1) <= adc_bailout

where DEPTH ranges from 0 to (recursion_limit-1).

(Note that radiosity adc_bailout defaults to 0.01, not 1/128 as you
previously claimed.)

If the bug kicks in for DEPTH=0, it causes the symptoms you've observed.

If the bug only kicks in for DEPTH=1 or higher, something else seems to
be masking the problem at least partially.


The bug is tied to the radiosity importance sampling mechanism:

When radiosity rays are shot for an individual sample, each ray is
assigned a /queried importance/, which gradually increases from 0.0
(first ray) to 1.0 (last ray); this /queried importance/ is compared to
the /radiosity importance/ of whatever object is hit by the ray, and
computation proceeds only if the object is found importand enough;
otherwise, the radiosity algorithm will pretend that it never shot the
ray in the first place.

Note that since radiosity importance cannot be set to 0.0 or lower, at
least the first ray shot should find an important enough object.

However, when (brightness/2)^(DEPTH+1) is smaller than the adc_bailout,
ray computation is cut even shorter, and the tracing algorithm
erroneously reports a radiosity importance of -1, which the radiosity
algorithm subsequently categorizes as "lower than queried", pretending
the ray was never shot. Since this happens for all rays, the algorithm
ends up with a sample of zero rays.

During post-processing of radiosity rays, a quality value is also
assigned to each ray, and the average of the quality value is assigned
to the sample as the sample's base quality; however, with no rays shot,
this value is left at the arbitrary value of 0.

When trying to re-use samples, the radiosity algorithm will weigh the
base quality of each sample with some other factors such as distance and
geometric orientation, then sum up the resulting effective quality
value. If the sum exceeds a certain threshold (zero during the final
render), the algorithm considers the samples to be sufficient, and
refrains from gathering additional samples for that paticular location.

Note that when the bug kicks in, the base quality values of all samples
will be zero, and so will their weighted quality sum, leading the
algorithm to believe that it hasn't found enough useful samples yet
(even during final render), and that it needs to gather more.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> Having had a closer look at the whole shebang, there aren't any local
> effects to this: There is just a bug that will kick in whenever
>
>     (brightness/2)^(DEPTH+1) <= adc_bailout
>
> where DEPTH ranges from 0 to (recursion_limit-1).
>
> (Note that radiosity adc_bailout defaults to 0.01, not 1/128 as you
> previously claimed.)
>

Yep, just saw that in the docs.
Sorry for the confusion;  I was recalling the 1/128 value from *something* in
v3.6.x days-- obviously not adc_bailout though. (Actually, I had forgotten that
radiosity has its own adc_bailout; I was earlier referring to the
global_settings value. Which isn't 1/128 either, but 1/255!)

So, from the equation... using the .020 'threshold' and DEPTH of 0,

(.020/2)^(1) <= .01   or, .01 <= .01

.... which is where the problem occurs.

I guess the safest bet right now is: Don't set rad 'brightness ' below .021!
Which nobody would normally do anyway ;-)

Thanks for taking the time to do such a deep analysis.

Post a reply to this message

Am 13.03.2018 um 20:12 schrieb Kenneth:

> I guess the safest bet right now is: Don't set rad 'brightness ' below .021!
> Which nobody would normally do anyway ;-)

Actually, the safest bet is: Don't set radiosity brightness to
/anything/ other than 1.0 in the first place! It wrecks realism anyway.

(A reasonable case can be made for brightness values slightly _above_
1.0, when recursion_limit is set particularly low (2 or even 1), to
compensate for the fact that this reduces the overall brightness of the
scene a bit. But brightness values below 1.0 are of the devil. Don't go
near them.)

Post a reply to this message

Le 18-03-13 à 15:12, Kenneth a écrit :
> clipka <ano### [at] anonymousorg> wrote:
>>
>> Having had a closer look at the whole shebang, there aren't any local
>> effects to this: There is just a bug that will kick in whenever
>>
>>      (brightness/2)^(DEPTH+1) <= adc_bailout
>>
>> where DEPTH ranges from 0 to (recursion_limit-1).
>>
>> (Note that radiosity adc_bailout defaults to 0.01, not 1/128 as you
>> previously claimed.)
>>
> 
> Yep, just saw that in the docs.
> Sorry for the confusion;  I was recalling the 1/128 value from *something* in
> v3.6.x days-- obviously not adc_bailout though. (Actually, I had forgotten that
> radiosity has its own adc_bailout; I was earlier referring to the
> global_settings value. Which isn't 1/128 either, but 1/255!)
> 
> So, from the equation... using the .020 'threshold' and DEPTH of 0,
> 
> (.020/2)^(1) <= .01   or, .01 <= .01
> 
> .... which is where the problem occurs.
> 
> I guess the safest bet right now is: Don't set rad 'brightness ' below .021!
> Which nobody would normally do anyway ;-)
> 
> Thanks for taking the time to do such a deep analysis.
> 
> 

If you *realy* want to set brightness that low, then you can dodge the 
bug by setting the radiosity's adc_bailout to something smaller than the 
default, like 1/128, 1/256 or less.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
>     (brightness/2)^(DEPTH+1) <= adc_bailout
>
> where DEPTH ranges from 0 to (recursion_limit-1).
>
While playing with this equation, I just noticed a result that seems to be
important.

Let's say radiosity's recursion_limit is the default of 2, brightness is the
'threshold' of .020, and adc_bailout is the default of .01---

(.020/2)^(1 + 1) <= .01 ?

Is the left-hand side of the equation less than .01? Yes, definitely; it's now
only  .0001. From that, it would seem that reducing adc_bailout to less than
this value would fix the slow render. Which it does!

But so does a higher adc_bailout of .009 for some reason (which is only .001
less than the default, and still much higher than .0001.) In fact, .009 removes
the slow render phenomenon at *any* brightness level and *any* recursion
limit... i.e., no matter how small the left-side equation becomes. And, the
render statistics now look like they are back to their 'usual' state. So maybe
the core problem resides in adc_bailout itself, or its default value?

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
>
> If you *realy* want to set brightness that low, then you can dodge the
> bug by setting the radiosity's adc_bailout to something smaller than the
> default, like 1/128, 1/256 or less.

Yes indeed, that does work. But the funny thing about the current bug is that
the slowdown only seems to occur with these values:

brightness:  <= .020
adc_bailout (for radiosity): >= .01 but < .05 (a small range, actually)
recursion_limit: *anything* (1 to 20)

Whereas, an adc_bailout of .009 solves everything; that value doesn't have to be
any lower, it seems.

Of course, this is with all of the other radiosity values being defaults. Maybe
they affect it too(?). I don't know; too many permutations to test ;-)

Post a reply to this message

Am 14.03.2018 um 03:21 schrieb Kenneth:

> Yes indeed, that does work. But the funny thing about the current bug is that
> the slowdown only seems to occur with these values:
> 
> brightness:  <= .020
> adc_bailout (for radiosity): >= .01 but < .05 (a small range, actually)
> recursion_limit: *anything* (1 to 20)
> 
> Whereas, an adc_bailout of .009 solves everything; that value doesn't have to be
> any lower, it seems.

Oh the fun of it!

The thing is even more complicated: Try adc_bailout 0.005 for snickers.


Your newest observations made me look again, and it turns out, the whole
thing isn't actually a logical bug: There had alwayas been measures in
place to prevent the problem from happening.

But alas! Those measures suffer from precision problems: One value that
should be /at least/ adc_bailout + EPSILON is passed around with the
same precision as colour values (i.e. single precision, as opposed to
double precision like most math stuff), causing it to be rounded,
sometimes ending up /smaller than/ adc_bailout.

Post a reply to this message

Am 13.03.2018 um 22:16 schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
> 
>>
>>     (brightness/2)^(DEPTH+1) <= adc_bailout
>>
>> where DEPTH ranges from 0 to (recursion_limit-1).
>>
> While playing with this equation, I just noticed a result that seems to be
> important.
> 
> Let's say radiosity's recursion_limit is the default of 2, brightness is the
> 'threshold' of .020, and adc_bailout is the default of .01---
> 
> (.020/2)^(1 + 1) <= .01 ?
> 
> Is the left-hand side of the equation less than .01? Yes, definitely; it's now
> only  .0001.

As I mentioned, the render slowdown effect only appears to occur if this
thing happens at DEPTH=0; for DEPTH=1, other effects may or may not happen.

Post a reply to this message