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

clipka <ano### [at] anonymousorg> wrote:
> 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.
>

Interesting. My (apparently outdated) philosophy of reducing brightness comes
from v3.6.2 days-- when things were a bit screwy all around, in hindsight ;-)
Thanks.

re: the slowdown...
> 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.

Ah, that ol' single-precision vs. double-precision devil. (Uh, as if I know what
I'm talking about, ha.) Glad to see that you were able to figure out how to
'exorcise the demon' !  Nice detective work.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> 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.)

Thinking about this further: I assume you mean, when using a HDR light probe for
the sky and no other lights in the scene? A brightness value of 1.0 would make
sense.

Whereas, when using a typical LDR sky photo, and a (single) light in the scene
for the 'Sun', a rad brightness value of 1.0 could be too bright, for various
reasons.

Given that the objects in the scene have  finish {diffuse 1.0 emission 0} --
with ambient turned off automatically-- and a light_source of rgb 1 (or more
likely less than that), it would *seem* natural to turn down rad's brightness
below 1.0. So that any object surfaces never exceed a surface brightness of 1.0
max; otherwise, there's a danger of washing out the object colors. It would all
depend on how bright the single light_source is: if it's set to rgb 0.6, then
rad brightness should not exceed 0.4, according to my theory.

Of course, this all depends on light_source/surface brightness and rad
brightness being simply additive (i.e., the combination can go beyond 1.0.)
That's what I've always assumed, anyway.

However, I do see a major problem with my argument: The parts of the scene in
*shadow* are only receiving the rad lighting-- and such shadow illumination
would *vary* depending on my light_source brightness. Not very logical, I admit.
(Or more specifically, not 'realistic.')  So I guess such a lighting scenario
is, by default, not 'realistic'  at all, but just an attempt to make the scene
'pleasing to the eye.'  I.e., balancing 'Sunlight' brightness against shadow
brightness, just to prevent any colors from being washed out.

Post a reply to this message

Le 18-03-16 à 15:17, Kenneth a écrit :
> clipka <ano### [at] anonymousorg> wrote:
>>
>> 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.)
> 
> Thinking about this further: I assume you mean, when using a HDR light probe for
> the sky and no other lights in the scene? A brightness value of 1.0 would make
> sense.
> 
> Whereas, when using a typical LDR sky photo, and a (single) light in the scene
> for the 'Sun', a rad brightness value of 1.0 could be too bright, for various
> reasons.
> 
> Given that the objects in the scene have  finish {diffuse 1.0 emission 0} --
> with ambient turned off automatically-- and a light_source of rgb 1 (or more
> likely less than that), it would *seem* natural to turn down rad's brightness
> below 1.0. So that any object surfaces never exceed a surface brightness of 1.0
> max; otherwise, there's a danger of washing out the object colors. It would all
> depend on how bright the single light_source is: if it's set to rgb 0.6, then
> rad brightness should not exceed 0.4, according to my theory.
> 
> Of course, this all depends on light_source/surface brightness and rad
> brightness being simply additive (i.e., the combination can go beyond 1.0.)
> That's what I've always assumed, anyway.
> 
> However, I do see a major problem with my argument: The parts of the scene in
> *shadow* are only receiving the rad lighting-- and such shadow illumination
> would *vary* depending on my light_source brightness. Not very logical, I admit.
> (Or more specifically, not 'realistic.')  So I guess such a lighting scenario
> is, by default, not 'realistic'  at all, but just an attempt to make the scene
> 'pleasing to the eye.'  I.e., balancing 'Sunlight' brightness against shadow
> brightness, just to prevent any colors from being washed out.
> 
> 
> 
> 

The best way to go when a light probe is to bright or dark is to adjust 
it's emission down or up respectively. Don't play with brightness.

Next, you can adjust the diffuse part of your textures. Most of the 
time, the default of 0.7 is correct, but at times, you may need to use a 
slightly smaller value. It don't get bumped up to diffuse 1 when you use 
radiosity, only ambient get turned off.
With radiosity scenes, default is :
finish{diffuse 0.7 ambient 0 emission 0}

Alain

Post a reply to this message

Am 16.03.2018 um 20:17 schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
>>
>> 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.)
> 
> Thinking about this further: I assume you mean, when using a HDR light probe for
> the sky and no other lights in the scene? A brightness value of 1.0 would make
> sense.
> 
> Whereas, when using a typical LDR sky photo, and a (single) light in the scene
> for the 'Sun', a rad brightness value of 1.0 could be too bright, for various
> reasons.

No, I mean, literally, NEVER EVER set radiosity brightness below 1.0 (if
you want realistic renders).

The reason is that the radiosity brightness parameter is /not/ applied
to the end result of radiosity computations, but /at each level of depth/.

Consider a scene where one area (A) receives direct light from a classic
light source; another area (B) is placed such that it does not receive
any direct light, but diffuse light from (A); and yet another area (C)
is placed such that it does not receive any direct light nor diffuse
light from (A), but diffuse light from (B).

In such a scene, POV-Ray will scale the brightness of (B) by the
radiosity brightness setting, but it will scale the brightness of (C) by
the /square/ of the radiosity brightness setting. Thus, tampering with
the radiosity brightness setting will skew the relative brightness of
areas B and C (and also areas A and B).

The algorithm is designed such that it gives most realistic results at a
radiosity brightness setting of 1.0 (if it wasn't for recursion_limit
and adc_bailout, which both cause the algorithm to underestimate the
diffuse illumination, so to compensate, radiosity brightness should be
slightly higher than 1.0).


If you really think your scene gets too bright with radiosity enabled,
it's your light sources (light_source and sky sphere) which are to blame.

> Given that the objects in the scene have  finish {diffuse 1.0 emission 0} --
> with ambient turned off automatically-- and a light_source of rgb 1 (or more
> likely less than that), it would *seem* natural to turn down rad's brightness
> below 1.0. So that any object surfaces never exceed a surface brightness of 1.0
> max; otherwise, there's a danger of washing out the object colors. It would all
> depend on how bright the single light_source is: if it's set to rgb 0.6, then
> rad brightness should not exceed 0.4, according to my theory.

I see your point, but you're mistaken: Radiosity isn't an /alternative/
way of lighting things - it accounts for paths of illumination that
would otherwise be /missing/ from classic light source computations.

So in a sense it's not /activating/ radiosity that screws up your scene
brightness - it's /de-activaing/ radiosity that does.


If you're worried about the balance between direct and indirect
illumination and/or the total brightness of your scene, the proper knobs
to tweak are the brightness levels of the light sources and the sky sphere.


> However, I do see a major problem with my argument: The parts of the scene in
> *shadow* are only receiving the rad lighting-- and such shadow illumination
> would *vary* depending on my light_source brightness. Not very logical, I admit.
> (Or more specifically, not 'realistic.')  So I guess such a lighting scenario
> is, by default, not 'realistic'  at all, but just an attempt to make the scene
> 'pleasing to the eye.'  I.e., balancing 'Sunlight' brightness against shadow
> brightness, just to prevent any colors from being washed out.

You /can/ use the radiosity brightness setting for artistic purposes, to
emphasize shadows; however, my point remains: If you want /realistic/
renders, you should never ever set it below 1.0.

The problem with that kind of artistic tweaking is that you're depriving
yourself of any means to design your materials and light sources based
on physical principles, which means you're stuck with tweaking and
re-tweaking.

Post a reply to this message