(using 3.7.1 beta 9 in Win7)

I happened to be testing a scene while using a very low 'brightness' value for
radiosity, and noticed that the render slows to a crawl. I'm using all the rad
defaults otherwise (and default Render_Block_Size.)

radiosity{brightness .03}

Somewhere below .05, things start slowing down. Adding antialiasing into the mix
slows it down further (which might be expected, but the render appears to stall,
or almost so.) I don't yet know if this slowdown is scene-dependent-- e.g.,
number of objects, textures, etc.

Such a low value isn't really a *practical* one to use, but I was wondering what
the reason is for the slow-down, or if it's expected behavior.

Post a reply to this message

Am 09.03.2018 um 20:44 schrieb Kenneth:
> (using 3.7.1 beta 9 in Win7)
> 
> I happened to be testing a scene while using a very low 'brightness' value for
> radiosity, and noticed that the render slows to a crawl. I'm using all the rad
> defaults otherwise (and default Render_Block_Size.)
> 
> radiosity{brightness .03}
> 
> Somewhere below .05, things start slowing down. Adding antialiasing into the mix
> slows it down further (which might be expected, but the render appears to stall,
> or almost so.) I don't yet know if this slowdown is scene-dependent-- e.g.,
> number of objects, textures, etc.
> 
> Such a low value isn't really a *practical* one to use, but I was wondering what
> the reason is for the slow-down, or if it's expected behavior.

If anything, I'd expect the render to speed up, due to adc_bailout.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> If anything, I'd expect the render to speed up, due to adc_bailout.

That was my own expectation too (or else, to take the *same* amount of time.)
Not based on anything technical, just a 'naive expectation' ;-)

From further experiments, the render doesn't stall, it just gets *really* slow.

Some observations, to try and eliminate some of the variables:
The slowdown actually occurs at a very sharp 'brightness' threshold of
exactly(?) .020.  (i.e., .021 doesn't show this.) And further reducing the
brightness to .001 does NOT cause an even slower render-- so the .020 threshold
seems to be the one and only 'point of change'.  For my particular scene and
render size, the 'usual' render time with rad (and brightness 0.7) is 11 seconds
elapsed time. At and below the brightness 'threshold', it's 176 seconds.

POV's default adc_bailout is 1/128 or  .0078, so as a general observation, it's
not adc_bailout that's 'coinciding' with this .020 threshold value. (But raising
adc_bailout *above* the threshold  -- to, say, .030-- does speed up the render
*somewhat*, by about 25-percent, which might be expected anyway(?); but it
doesn't 'eliminate' the slowdown. From this, it seems that adc_bailout isn't the
prime cause.

The returned 'max_level' in messages is always the same-- no change with any rad
'brightness' change. For my particular test scene, which has reflections, I set
it to 10, and the returned value is always 6/10

It doesn't look like it depends on number of objects in a scene, or maybe just
to a very small degree. And doesn't change when reflections are used vs setting
their values to 0.0

Using 1 thread vs 2 threads doesn't affect the sharp .020 threshold (although 1
thread is naturally slower, as would be expected.)

These are the message statistics for 3 renders at different rad 'brightness'
levels; the .020 render shows some *wild* increases in the rad numbers...

For my NORMAL rad render (brightness .7)---

Radiosity samples calculated:              652 (0.12 %)
  discarded due to low quality:              4
  retained for re-use:                     648
Radiosity samples reused:               554819
Radiosity sample rays shot:              18518
Radiosity octree nodes:                    350
Radiosity octree samples/node:            1.85
Radiosity blocks examined:           110415486
Radiosity blocks passed test 0:      110415486 (100.00 %)
Radiosity blocks passed test 1:       48096790 (43.56 %)
Radiosity blocks passed test 2:       35244548 (31.92 %)
Radiosity blocks passed test 3:       11033876 (9.99 %)
Radiosity blocks passed test 4:        6664283 (6.04 %)
Radiosity blocks passed test 5:        6448266 (5.84 %)
Radiosity blocks rejected:           103967220 (94.16 %)
----------------------------------------------------------------------------
Radiosity Depth 0 calculated:              413 (0.08 %)
Radiosity Depth 0 reused:               542072
Radiosity Depth 0 rays shot:             14455
----------------------------------------------------------------------------
Radiosity (final) calculated:               59 (0.01 %)
Radiosity (final) reused:               544181
Radiosity (final) rays shot:              2047
----------------------------------------------------------------------------
  Pass     Depth 0    Depth 1           Total
----------------------------------------------------------------------------
  1            133        169             302
  2            222         69             291
  Final         58          1              59
----------------------------------------------------------------------------
  Total        413        239             652
  Weight     0.182      0.061
//----//-----//----//-----//----//-----------

At .021 rad 'brightness'---not much change ...

Radiosity samples calculated:              488 (0.09 %)
  discarded due to low quality:              2
  retained for re-use:                     486
Radiosity samples reused:               551113
Radiosity sample rays shot:              15532
Radiosity octree nodes:                    194
Radiosity octree samples/node:            2.51
Radiosity blocks examined:           106617093
Radiosity blocks passed test 0:      106617093 (100.00 %)
Radiosity blocks passed test 1:       45451542 (42.63 %)
Radiosity blocks passed test 2:       33397572 (31.32 %)
Radiosity blocks passed test 3:       10591487 (9.93 %)
Radiosity blocks passed test 4:        6467663 (6.07 %)
Radiosity blocks passed test 5:        6245374 (5.86 %)
Radiosity blocks rejected:           100371719 (94.14 %)
----------------------------------------------------------------------------
Radiosity Depth 0 calculated:              402 (0.07 %)
Radiosity Depth 0 reused:               542083
Radiosity Depth 0 rays shot:             14070
----------------------------------------------------------------------------
Radiosity (final) calculated:               58 (0.01 %)
Radiosity (final) reused:               543434
Radiosity (final) rays shot:              2012
----------------------------------------------------------------------------
  Pass     Depth 0    Depth 1           Total
----------------------------------------------------------------------------
  1            130         73             203
  2            215         12             227
  Final         57          1              58
----------------------------------------------------------------------------
  Total        402         86             488
  Weight     0.182      0.002
//----//-----//------//----//-----//----------------

At the .020 brightness 'threshold'---

Radiosity samples calculated:            29460 (5.43 %)
Radiosity samples reused:               513025
Radiosity sample rays shot:            1031100
Radiosity octree nodes:                     24
Radiosity octree samples/node:         1227.50
Radiosity blocks examined:          6329956857
Radiosity blocks passed test 0:     6329956857 (100.00 %)
Radiosity blocks passed test 1:      627510814 (9.91 %)
Radiosity blocks passed test 2:      627510814 (9.91 %)
Radiosity blocks passed test 3:      495632471 (7.83 %)
Radiosity blocks passed test 4:      486380116 (7.68 %)
Radiosity blocks passed test 5:      468726634 (7.40 %)
Radiosity blocks rejected:          5861230223 (92.60 %)
----------------------------------------------------------------------------
Radiosity Depth 0 calculated:            29460 (5.43 %)
Radiosity Depth 0 reused:               513025
Radiosity Depth 0 rays shot:           1031100
----------------------------------------------------------------------------
Radiosity (final) calculated:            29009 (5.35 %)
Radiosity (final) reused:               512763
Radiosity (final) rays shot:           1015315
----------------------------------------------------------------------------
  Pass     Depth 0           Total
----------------------------------------------------------------------------
  1            141             141
  2            310             310
  Final      29009           29009
----------------------------------------------------------------------------
  Total      29460           29460
  Weight     0.182

Post a reply to this message

Am 10.03.2018 um 20:25 schrieb Kenneth:

> For my NORMAL rad render (brightness .7)---
> 
> Radiosity samples calculated:              652 (0.12 %)
>   discarded due to low quality:              4
>   retained for re-use:                     648
> Radiosity samples reused:               554819
> Radiosity sample rays shot:              18518
> Radiosity octree nodes:                    350
> Radiosity octree samples/node:            1.85
> Radiosity blocks examined:           110415486
> Radiosity blocks passed test 0:      110415486 (100.00 %)
> Radiosity blocks passed test 1:       48096790 (43.56 %)
> [...]
> ----------------------------------------------------------------------------
>   Pass     Depth 0    Depth 1           Total
> ----------------------------------------------------------------------------
>   1            133        169             302
>   2            222         69             291
>   Final         58          1              59
> ----------------------------------------------------------------------------
> [...]
> 
> At .021 rad 'brightness'---not much change ...
> 
> Radiosity samples calculated:              488 (0.09 %)
>   discarded due to low quality:              2
>   retained for re-use:                     486
> Radiosity samples reused:               551113
> Radiosity sample rays shot:              15532
> Radiosity octree nodes:                    194
> Radiosity octree samples/node:            2.51
> Radiosity blocks examined:           106617093
> Radiosity blocks passed test 0:      106617093 (100.00 %)
> Radiosity blocks passed test 1:       45451542 (42.63 %)
> [...]
> ----------------------------------------------------------------------------
>   Pass     Depth 0    Depth 1           Total
> ----------------------------------------------------------------------------
>   1            130         73             203
>   2            215         12             227
>   Final         57          1              58
> ----------------------------------------------------------------------------
> [...]
> 
> At the .020 brightness 'threshold'---
> 
> Radiosity samples calculated:            29460 (5.43 %)
> Radiosity samples reused:               513025
> Radiosity sample rays shot:            1031100
> Radiosity octree nodes:                     24
> Radiosity octree samples/node:         1227.50
> Radiosity blocks examined:          6329956857
> Radiosity blocks passed test 0:     6329956857 (100.00 %)
> Radiosity blocks passed test 1:      627510814 (9.91 %)
> [...]
> ----------------------------------------------------------------------------
>   Pass     Depth 0           Total
> ----------------------------------------------------------------------------
>   1            141             141
>   2            310             310
>   Final      29009           29009
> ----------------------------------------------------------------------------
>   Total      29460           29460
>   Weight     0.182

Here are a few interesting observations:

(1) The .020 render has no "Depth 1" samples (none stored at any rate).
This is probably due to them being so dim that they're deemed irrelevant
(think adc_bailout). Note how the number of "Depth 1" samples already
decreases noticeably in the .021 render; the threshold is probably due
to a combo of adc_bailout and surface brightness.

(2) The .020 render has a shitload of samples taken during the final
render. Not sure what happens here - for some reason, during the final
render the algorithm seems to think it has no usable samples at all, and
keeps adding more. This additional sampling already consumes some time.

(3) In addition, the extra samples are filed in virtually the same
places in the octree (the data structure holding the radiosity samples
for fast lookup), leading to a high number of samples per node, which is
poison for the radiosity sample lookup.

(4) The low number in "Radiosity blocks passed test 1" might be an
indication that the samples taken are stored at the wrong level in the
octree.


Looks definitely broken.

Post a reply to this message

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

> Here are a few interesting observations:
>
> (1) The .020 render has no "Depth 1" samples (none stored at any rate).
> This is probably due to them being so dim that they're deemed irrelevant
> (think adc_bailout). Note how the number of "Depth 1" samples already
> decreases noticeably in the .021 render; the threshold is probably due
> to a combo of adc_bailout and surface brightness.
>

That got me thinking about the brightness levels in my test scene. (I didn't
take into account the relative darkness of shadows or pigment values etc.) SO, I
constructed a MUCH simpler test. From the looks of *this* code, no pixel in the
render falls below a certain 'middle brightness'-- maybe .3 or .4-- but the vast
render slowdown still occurs at the .020 rad-brightness 'threshold'. (BEWARE:
This scene renders *REALLY* slowly at the threshold-- 42 minutes, vs. 5 seconds
at a more normal rad brightness(!) Try reducing the number of boxes in the #for
loop; that *should* help somewhat.)

All very interesting! Uh, in some way.  ;-)

--------
#version 3.71; // beta 9

global_settings{
     assumed_gamma 1.0
     max_trace_level 5
     radiosity{brightness .020}  // or .021 for much faster render
     }
#default{finish{ambient .15 emission .3 diffuse .55}}

camera {
  perspective
  location  <-40, 90, -40>
  look_at   <70, 0,  70>
  right     x*image_width/image_height
  angle 40
}

light_source {
  0*x
  color rgb 1
  translate <500, 800, -500>
}

sky_sphere{pigment{rgb .7}}

plane{y,0  no_shadow
    pigment{rgb .4}
     }

#declare S = seed(119);
#for(i,1,900)
box{0,<1 + 4*rand(S),1 + 150*pow(.4*rand(S),2),1 + 4*rand(S)>
      translate 230*<rand(S),0,rand(S)>
      pigment{rgb 1}
      no_shadow
      }
#end
//----------------

The resulting 'threshold' render statistics (at a 640 X 480 render size, no
AA)...
----------------------------------------------------------------------------
Shadow Ray Tests:            217989   Succeeded:                     0
----------------------------------------------------------------------------
Radiosity samples calculated:           307805 (100.00 %)
Radiosity samples reused:                    0
Radiosity sample rays shot:           10773175
Radiosity octree nodes:                     10
Radiosity octree samples/node:        30780.50
Radiosity blocks examined:         46876375851
Radiosity blocks passed test 0:    46876375851 (100.00 %)
Radiosity blocks passed test 1:    19910334530 (42.47 %)
Radiosity blocks passed test 2:    19910334530 (42.47 %)
Radiosity blocks passed test 3:     7100384879 (15.15 %)
Radiosity blocks passed test 4:     5593912132 (11.93 %)
Radiosity blocks passed test 5:     5365165980 (11.45 %)
Radiosity blocks rejected:         41511209871 (88.55 %)
----------------------------------------------------------------------------
Radiosity Depth 0 calculated:           307805 (100.00 %)
Radiosity Depth 0 reused:                    0
Radiosity Depth 0 rays shot:          10773175
----------------------------------------------------------------------------
Radiosity (final) calculated:           307200 (100.00 %)
Radiosity (final) reused:                    0
Radiosity (final) rays shot:          10752000
----------------------------------------------------------------------------
  Pass     Depth 0           Total
----------------------------------------------------------------------------
  1            130             130
  2            475             475
  Final     307200          307200
----------------------------------------------------------------------------
  Total     307805          307805
  Weight     0.443
----------------------------------------------------------------------------
Peak memory used:          97529856 bytes
----------------------------------------------------------------------------
Render Time:
  Photon Time:      No photons
  Radiosity Time:   0 hours  0 minutes  0 seconds (0.015 seconds)
              using 2 thread(s) with 0.015 CPU-seconds total
  Trace Time:       0 hours 42 minutes 24 seconds (2544.042 seconds)
              using 2 thread(s) with 4608.830 CPU-seconds total

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
(BEWARE:
> This scene renders *REALLY* slowly at the threshold-- 42 minutes, vs. 5 seconds
> at a more normal rad brightness(!) Try reducing the number of boxes in the #for
> loop; that *should* help somewhat.)
>

Well, I just tried that: Even with only FIVE boxes in the scene, the threshold
render takes 44 minutes-- only 1 minute less than using 900 boxes.

I then decided to substitute a MUCH-smaller 'ground box' for my plane{y,0...}...
         box{<-1,-.1,-1>,<200,0,200> no_shadow
               pigment{rgb .4}
            }

.... my quasi-theory being that it would present FAR less of a surface area for
radiosity to check for samples vis-a-vis the five boxes, rather than the
infinite expanse of a plane. That helped *somewhat*-- a 33-minute render vs. 44
minutes. But not what I was expecting.

HOWEVER... using NEITHER the ground box nor the plane-- and just letting the
sky_sphere contribute its radiosity to the five box objects-- the render time
dropped to an astonishing 1.5 seconds! In other words, the 'threshold'
completely disappeared (even when using rad 'brightness' .001)

*That* makes me think that there may be some hidden 'radiosity shadow'
calculations going on behind-the-scenes, when there shouldn't be-- the ground
box or plane somehow casting shadows that radiosity is 'seeing.' (Yet my scene
has NO shadows, AFAIK.) Or if not that, then something that's having a similar
effect on the radiosity algorithm.

I don't know if these insights are *useful*-- but again, the results are quite
interesting.

Post a reply to this message

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

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

clipka <ano### [at] anonymousorg> wrote:
>
> No, I mean, literally, NEVER EVER set radiosity brightness below 1.0 (if
> you want realistic renders).
[snip]

I had to give this info (and Alain's comments) some deep thought-- because until
now, I've always varied radiosity's brightness to 'balance' the scene lighting
and look. I've always 'tweaked' it -- reduced it --just to get the scene to have
the contrast I want. Keeping the rad brightness at 1.0 is a new paradigm shift
for me(!)

I now understand the 'technical' need to do so, although it initially gave me
some worries about the many(?) changes I might have to make to my non-HDR scenes
that use a light_source. But there's a simple and easy workaround: I can use TWO
identical image_mapped sky domes or spheres (a trick that has probably been
mentioned in the newsgroups) along with rad brightness 1.0:

1)  the sphere for RADIOSITY lighting only:
       no_shadow
       no_image
       no_reflection
       finish{ emission *my choice*}  // to get the contrast I want

2) the sphere for the VISIBLE sky image (and for reflections in objects):
      no_shadow
      no_radiosity
      finish{emission 1.0} // for an accurate reproduction of the image_map, as
     // seen in the render

This probably still amounts to 'tweaking'-- but unless there's a remaining
technical problem, it works for me.

And THANKS for correcting my long-held misconceptions.

Post a reply to this message

Le 18-03-17 à 10:39, Kenneth a écrit :
> clipka <ano### [at] anonymousorg> wrote:
>>
>> No, I mean, literally, NEVER EVER set radiosity brightness below 1.0 (if
>> you want realistic renders).
> [snip]
> 
> I had to give this info (and Alain's comments) some deep thought-- because until
> now, I've always varied radiosity's brightness to 'balance' the scene lighting
> and look. I've always 'tweaked' it -- reduced it --just to get the scene to have
> the contrast I want. Keeping the rad brightness at 1.0 is a new paradigm shift
> for me(!)
> 
> I now understand the 'technical' need to do so, although it initially gave me
> some worries about the many(?) changes I might have to make to my non-HDR scenes
> that use a light_source. But there's a simple and easy workaround: I can use TWO
> identical image_mapped sky domes or spheres (a trick that has probably been
> mentioned in the newsgroups) along with rad brightness 1.0:
> 
> 1)  the sphere for RADIOSITY lighting only:
>         no_shadow
>         no_image
>         no_reflection
>         finish{ emission *my choice*}  // to get the contrast I want
> 
> 2) the sphere for the VISIBLE sky image (and for reflections in objects):
>        no_shadow
>        no_radiosity
>        finish{emission 1.0} // for an accurate reproduction of the image_map, as
>       // seen in the render
> 
> This probably still amounts to 'tweaking'-- but unless there's a remaining
> technical problem, it works for me.
> 
> And THANKS for correcting my long-held misconceptions.
> 
> 
> 
> 
> 
> 
If you are using that model, you can use a lower resolution, highly 
blured, version of the light probe for the radiosity part.
But, you don't need to use that method. A single sphere is very good. 
Generaly, if the light probe is to bright for the radiosity, then, it's 
also probably to bright for the reflections. I've seen that case. The 
usual solution is to reduce the global emission value for the probe.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
> >
> If you are using that model, you can use a lower resolution, highly
> blured, version of the light probe for the radiosity part.
> But, you don't need to use that method. A single sphere is very good.
> Generaly, if the light probe is to bright for the radiosity, then, it's
> also probably to bright for the reflections. I've seen that case. The
> usual solution is to reduce the global emission value for the probe.

I was actually referring to a typical (or old-school?) LOW-dynamic-range image,
for the sky sphere(s). Plus a single light_source in the scene to mimic the Sun,
or whatever. But for an HDR light probe, your suggestions are good-- no 2nd
sphere required.

And using a low-resolution image for the *radiosity* sky is a useful idea in
either scenario. Other than saving memory, though, I'm wondering if a low-rez
blurry image takes less time-- or fewer computations-- when POV-Ray processes
the radiosity light.... instead of using a higher-rez or more 'detailed' image.

Post a reply to this message

Am 17.03.2018 um 15:39 schrieb Kenneth:

> 1)  the sphere for RADIOSITY lighting only:
>        no_shadow
>        no_image
>        no_reflection
>        finish{ emission *my choice*}  // to get the contrast I want
> 
> 2) the sphere for the VISIBLE sky image (and for reflections in objects):
>       no_shadow
>       no_radiosity
>       finish{emission 1.0} // for an accurate reproduction of the image_map, as
>      // seen in the render
> 
> This probably still amounts to 'tweaking'-- but unless there's a remaining
> technical problem, it works for me.

It remains tweaking indeed: This approach still breaks some (realistic)
brightness balance - namely that between radiosity and specular reflections.

Post a reply to this message

Am 17.03.2018 um 22:32 schrieb Kenneth:

> I was actually referring to a typical (or old-school?) LOW-dynamic-range image,
> for the sky sphere(s). Plus a single light_source in the scene to mimic the Sun,

If only the sun is overexposed, that's ok; for realism, use the sky
sphere as-is, plus a classic light source to model the portion of the
sun that exceeds the image's dynamic range.

The sky sphere will be picked up by radiosity and reflections, while the
classic light source sun will be picked up by classic diffuse and
highlights.

Radiosity and diffuse are mutually balanced automatically (if you don't
tamper with radiosity brightness ;)); reflections and highlights must be
mutually balanced manually, which is tricky in 3.7 and earlier.


> And using a low-resolution image for the *radiosity* sky is a useful idea in
> either scenario. Other than saving memory, though, I'm wondering if a low-rez
> blurry image takes less time-- or fewer computations-- when POV-Ray processes
> the radiosity light.... instead of using a higher-rez or more 'detailed' image.

It generally allows you to get away with a lower number of samples, as
small bright light sources like the sun get spread out over a wider
region and are therefore easier to hit with fewer rays.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 17.03.2018 um 15:39 schrieb Kenneth:

> > This probably still amounts to 'tweaking'-- but unless there's a remaining
> > technical problem, it works for me.
>
> It remains tweaking indeed: This approach still breaks some (realistic)
> brightness balance - namely that between radiosity and specular reflections.

:-(   As the old Yiddish saying says, "Oy Vey!"  :-P

I'm beginning to think that the only way to get a truly 'realistic' radiosity
render is to use an HDR light probe for the sky, with no additional light
sources... in which case, POV-Ray itself works with all the correct values(?)
and in the correct way.

Otherwise, it seems that using a LOW-dynamic-range sky + light_source(s)
requires *some* kind of tweaking (of one subtle thing or another).. yet which
still works against the radiosity mechanism, if only in a technical sense.

My desire to increase the contrast of a rad scene-- if I feel that it's
necessary-- looks like a no-win situation (except in the HDR light probe case).
Unless I simply postpone that step, and do it later as a post-processing effect
in another graphics app.

> Radiosity and diffuse are mutually balanced automatically (if you don't
> tamper with radiosity brightness...

*That* is a key insight that I've been wondering about. I hope I understand it
(as it relates to a LOW-dynamic-range sky set-up):

Given:
radiosity{brightness 1.0}
light_source{rgb .7}
object{... pigment{rgb <.3,.5,.7> finish{diffuse 1.0}}

Does the 'automatic balancing' keep the object surface color at <.3,.5,.7>
(depending of course on the angle-of-incidence of the light source hitting it)?
Or does my diffuse setting need to be manually reduced, to keep the color from
washing out to, say, <.6,1.0,1.2> (just as a conceptual idea, not real math). Or
am I still clueless about what 'automatic balancing means? :-O

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> Given:
> radiosity{brightness 1.0}
> light_source{rgb .7}
> object{... pigment{rgb <.3,.5,.7> finish{diffuse 1.0}}
>
> Does the 'automatic balancing' keep the object surface color at <.3,.5,.7>
> (depending of course on the angle-of-incidence of the light source hitting it)?
> ...

Let me re-word that, so it hopefully makes better sense...

Given:
radiosity{brightness 1.0}
light_source{rgb .7}
object{... pigment{rgb <.3,.5,.7> finish{diffuse 1.0}}

Does the 'automatic balancing' keep the object surface's DIFFUSE color from
exceeding .7*<.3,.5,.7> (as if NO radiosity is used)--depending of course on the
angle-of-incidence of the light source hitting the object? Or does my diffuse
setting need to be manually reduced, to keep the color from washing out to, say,

       .7*<.3 + 1.0,.5 + 1.0,.7 + 1.0>  or maybe  (1.0 + .7)*<.3,.5,.7>

....DUE TO THE ADDITION OF RADIOSITY LIGHT. Or am I still clueless about what
'automatic balancing' means? :-O

Post a reply to this message

Am 18.03.2018 um 21:31 schrieb Kenneth:

> Otherwise, it seems that using a LOW-dynamic-range sky + light_source(s)
> requires *some* kind of tweaking (of one subtle thing or another).. yet which
> still works against the radiosity mechanism, if only in a technical sense.

No, it shouldn't require tweaking.

(In v3.7 there's still /some/ tweaking to be done to balance reflections
vs. highlights. But stuff is improving.)


> My desire to increase the contrast of a rad scene-- if I feel that it's
> necessary-- looks like a no-win situation (except in the HDR light probe case).
> Unless I simply postpone that step, and do it later as a post-processing effect
> in another graphics app.

If you want realism, take what the proper settings give you.

If you want pure art, tweak as tweak can.

If you want art based on realism, render with proper settings, then
post-process to taste. (Inbuilt tonemapping featureas are on the agenda,
BTW.)


>> Radiosity and diffuse are mutually balanced automatically (if you don't
>> tamper with radiosity brightness...
> 
> *That* is a key insight that I've been wondering about. I hope I understand it
> (as it relates to a LOW-dynamic-range sky set-up):
> 
> Given:
> radiosity{brightness 1.0}
> light_source{rgb .7}
> object{... pigment{rgb <.3,.5,.7> finish{diffuse 1.0}}
> 
> Does the 'automatic balancing' keep the object surface color at <.3,.5,.7>
> (depending of course on the angle-of-incidence of the light source hitting it)?
> Or does my diffuse setting need to be manually reduced, to keep the color from
> washing out to, say, <.6,1.0,1.2> (just as a conceptual idea, not real math). Or
> am I still clueless about what 'automatic balancing means? :-O

`pigment { rgb Cp } finish { diffuse D }` means that /any/ incoming
light of brightness/colour Ci will be diffusely reflected for an
effective brightness/colour of Ci*Cp*D*F, where F is a factor that
solely depends on geometry (surface normal, incoming light direction and
outgoing light direction) and (if finish-level fresnel is enabled) the
refractive index of the material.

Point light sources, photon mapping and radiosity are all just methods
of computing which point on an object surface receives how much incoming
light from which direction, and they complement each other: The point
light source algorithm only takes into account light paths directly from
classic light sources to the observed surface (and not traversing photon
targets); the photon algorithm only takes into account light paths
refracted by photon targets; and the radiosity algorithm only takes into
account light paths where the light is bounced off other objects, or
where the light is emitted by another object (or a sky sphere) rather
than a classic light source.

There is no "washing out" caused by the radiosity algorithm itself: If
you replaced the sky sphere with a gazillion point light sources all
coloured in accordance with the image, you'd get pretty much exactly the
same result.


The surface of an object with pigment rgb <.3,.5,.7> will always have an
effective apparent colour of <.3,.5,.7>*Brightness, provided all the
light sources are "white" (R=G=B) and there is no specular reflection
nor specular highlights, nor "ambient" nor emission. (And no intervening
media or some such, of course.)

Note however that sky tends to be blue in hue, which might cause red and
yellow hues to appear more washed out; on the other hand, blue hues will
get more pronounced. To counteract this, make sure to tune your "sun"
light source to a yellowish hue, which by the way is also realistic.
(HDR sky spheres should normally already account for this effect.)

Post a reply to this message

Am 18.03.2018 um 22:02 schrieb Kenneth:

> Let me re-word that, so it hopefully makes better sense...
> 
> Given:
> radiosity{brightness 1.0}
> light_source{rgb .7}
> object{... pigment{rgb <.3,.5,.7> finish{diffuse 1.0}}
> 
> Does the 'automatic balancing' keep the object surface's DIFFUSE color from
> exceeding .7*<.3,.5,.7> (as if NO radiosity is used)--depending of course on the
> angle-of-incidence of the light source hitting the object? Or does my diffuse
> setting need to be manually reduced, to keep the color from washing out to, say,
> 
>        .7*<.3 + 1.0,.5 + 1.0,.7 + 1.0>  or maybe  (1.0 + .7)*<.3,.5,.7>
> 
> .....DUE TO THE ADDITION OF RADIOSITY LIGHT. Or am I still clueless about what
> 'automatic balancing' means? :-O

If you disable radiosity, your result image will have

    .7*Fc*<.3,.5,.7>

where Fc is a scalar (depending on angle of incidence and such stuff),
i.e. colour neutral.

If you enable radiosity and the sky colour is grey with a brightness of
.5, your result image will have:

    .7*Fc*<.3,.5,.7> + .5*Fr*<.3,.5,.7>

where Fr is also a scalar (again depending on angle of incidence and
such stuff), i.e. colour neutral; so in total you'll get:

    (.7*Fc+.5*Fr) * <.3,.5,.7>

So no washing out there - just more brightness.

Things get different if your sky sphere isn't colour neutral, but the
same would be true for a non-colour-neutral point light source.


But maybe instead of your colours getting "washed out", what you really
mean is that your colours are getting "burned" - the effect that you get
when one or two colour components exceed the dynamic range of the LDR
output file format and is thus clipped, effectively desaturating the colour.

If that is what you get, the proper solution is to tune down the
brightness of /both/ the sun and the sky (which, as noted before, isn't
the same as tuning down the radiosity brightness setting).

Post a reply to this message

On 18/03/2018 20:31, Kenneth wrote:
> My desire to increase the contrast of a rad scene-- if I feel that it's
> necessary--

That's the main reason I don't use radiosity. So I am following this 
thread with interest.
When rating entries in TC-RTC I would lower the gamma in PSP 9 to get an 
image that did not look washed out to my eyes.

-- 

Regards
     Stephen

Post a reply to this message

On 19-3-2018 19:05, Stephen wrote:
> On 18/03/2018 20:31, Kenneth wrote:
>> My desire to increase the contrast of a rad scene-- if I feel that it's
>> necessary--
> 
> That's the main reason I don't use radiosity. So I am following this 
> thread with interest.
> When rating entries in TC-RTC I would lower the gamma in PSP 9 to get an 
> image that did not look washed out to my eyes.
> 

I am not convinced that was caused by radiosity. My own 'obsession' with 
atmospheric media for instance, when it is not well balanced, gives some 
washout. I am struggling with it I confess (see my latest 'Cat Alley' 
for instance). To illustrate my point, look at my latest p.b.i. 
contribution "N". In both images radiosity was used and whether on the 
left hand image that may have led to washing out... I am not sure. In 
particular, I drastically changed my texturing of Poser model skins for 
instance.

-- 
Thomas

Post a reply to this message

On 20/03/2018 07:48, Thomas de Groot wrote:
> On 19-3-2018 19:05, Stephen wrote:
>> On 18/03/2018 20:31, Kenneth wrote:
>>> My desire to increase the contrast of a rad scene-- if I feel that it's
>>> necessary--
>>
>> That's the main reason I don't use radiosity. So I am following this 
>> thread with interest.
>> When rating entries in TC-RTC I would lower the gamma in PSP 9 to get 
>> an image that did not look washed out to my eyes.
>>
> 
> I am not convinced that was caused by radiosity. My own 'obsession' with 
> atmospheric media for instance, when it is not well balanced, gives some 
> washout. I am struggling with it I confess (see my latest 'Cat Alley' 
> for instance). 

I may have jumped to conclusions with too few examples.

> To illustrate my point, look at my latest p.b.i. 
> contribution "N". In both images radiosity was used and whether on the 
> left hand image that may have led to washing out... I am not sure. In 
> particular, I drastically changed my texturing of Poser model skins for 
> instance.
> 

The brickwork looks more distinctive as do the plants.

-- 

Regards
     Stephen

Post a reply to this message

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

>
> But maybe instead of your colours getting "washed out", what you really
> mean is that your colours are getting "burned" - the effect that you get
> when one or two colour components exceed the dynamic range of the LDR
> output file format and is thus clipped, effectively desaturating the colour.

Yes, that is what I meant-- and you explain it better than I did :-;
>
> If that is what you get, the proper solution is to tune down the
> brightness of /both/ the sun and the sky (which, as noted before, isn't
> the same as tuning down the radiosity brightness setting).

I do see the reason for rad brightness 1.0 now; but it's the turning down of the
sky brightness that puzzles me.

Still assuming a low-dynamic-range setup, not HDR: If I use a sky photo of
clouds that looks nice-- set to emission 1.0, and which might actually appear in
the rendered scene-- turning down its brightness (i.e., emission value) will
cause it to have a 'dull' visual look in the render (what was once full white
now being a somewhat darker gray, for instance.) While that may indeed 'balance'
the radiosity lighting as far as color-clipping of object surfaces goes, the
visual appearance of the 'sky' itself is now dull. (That was my reasoning for
making two identical photo-mapped sky spheres-- where the *visible* sky is still
at emission 1.0)

So maybe my two spheres simply don't have the proper no_reflection tags (or etc)
in the right places? You may have alluded to this earlier; but which setting to
use where is still a little mysterious (so that all the rad 'numbers' again work
correctly behind-the-scenes.) Sorry to keep asking these odd questions; there's
only a *little* bit of mystery remaining ;-)

Post a reply to this message

Le 18-03-18 à 16:31, Kenneth a écrit :
> clipka <ano### [at] anonymousorg> wrote:
>> Am 17.03.2018 um 15:39 schrieb Kenneth:
> 
>>> This probably still amounts to 'tweaking'-- but unless there's a remaining
>>> technical problem, it works for me.
>>
>> It remains tweaking indeed: This approach still breaks some (realistic)
>> brightness balance - namely that between radiosity and specular reflections.
> 
> :-(   As the old Yiddish saying says, "Oy Vey!"  :-P
> 
> I'm beginning to think that the only way to get a truly 'realistic' radiosity
> render is to use an HDR light probe for the sky, with no additional light
> sources... in which case, POV-Ray itself works with all the correct values(?)
> and in the correct way.
> 
> Otherwise, it seems that using a LOW-dynamic-range sky + light_source(s)
> requires *some* kind of tweaking (of one subtle thing or another).. yet which
> still works against the radiosity mechanism, if only in a technical sense.
> 
> My desire to increase the contrast of a rad scene-- if I feel that it's
> necessary-- looks like a no-win situation (except in the HDR light probe case).
> Unless I simply postpone that step, and do it later as a post-processing effect
> in another graphics app.
> 
>> Radiosity and diffuse are mutually balanced automatically (if you don't
>> tamper with radiosity brightness...
> 
> *That* is a key insight that I've been wondering about. I hope I understand it
> (as it relates to a LOW-dynamic-range sky set-up):
> 
> Given:
> radiosity{brightness 1.0}
> light_source{rgb .7}
> object{... pigment{rgb <.3,.5,.7> finish{diffuse 1.0}}
> 
> Does the 'automatic balancing' keep the object surface color at <.3,.5,.7>
> (depending of course on the angle-of-incidence of the light source hitting it)?
> Or does my diffuse setting need to be manually reduced, to keep the color from
> washing out to, say, <.6,1.0,1.2> (just as a conceptual idea, not real math). Or
> am I still clueless about what 'automatic balancing means? :-O
> 
> 
> 
> 
> 

You always can use a sky_sphere or a large sphere enclosing your scene. 
You can use emission value larger than 1 if you want, or need.
You don't need to use HDRI, or even any image format at all for your sky.

To increase the contrast, and get better shadows, you can reduce the 
error_bound value. The default is correct when you also use some 
conventional light, but it need to be lowered for pure radiosity scenes.

In the example that you provide, you need to also take into account the 
diffuse part of your finish. It's diffuse 0.7 if you don't explicitly 
change it.
Here, the colour is, for a light perpendicular to the surface and that 
highly unrealistic diffuse of 1 :
rgb<0.3, 0.5, 0.7>*<0.7, 0.7, 0.7> = <0.21, 0.35, 0.49>
Next, if you use some colour picker, there is an additional gamma 
handling to take into account that will effectively change all channels 
in a non-linear way and thus change their relative values and reduce the 
saturation.

Don't forget that using diffuse 1 is NOT realistic. A very bright 
surface may have a diffuse as high as 0.95 or even 0.98, never 1.

Using diffuse 1 is a very good way to get washed out colours.


Alain

Post a reply to this message

Am 3/21/2018 um 0:00 schrieb Kenneth:
> I do see the reason for rad brightness 1.0 now; but it's the turning down of the
> sky brightness that puzzles me.
> 
> Still assuming a low-dynamic-range setup, not HDR: If I use a sky photo of
> clouds that looks nice-- set to emission 1.0, and which might actually appear in
> the rendered scene-- turning down its brightness (i.e., emission value) will
> cause it to have a 'dull' visual look in the render (what was once full white
> now being a somewhat darker gray, for instance.) While that may indeed 'balance'
> the radiosity lighting as far as color-clipping of object surfaces goes, the
> visual appearance of the 'sky' itself is now dull. (That was my reasoning for
> making two identical photo-mapped sky spheres-- where the *visible* sky is still
> at emission 1.0)
> 

Besides of what others have said I'd like to add that it is a common 
mistake to define the diffuse reflectance way too strong. E.g. a *white* 
piece of paper is something like rgb <0.5, 0.48, 0.42> with diffuse 0.6 
and as it happens I just measured (for some project of mine) some white 
silk and its diffuse reflectance is rgb <0.42, 0.40, 0.38>.
On the other hand light sources are not limited to rgb <1,1,1> and 
especially the value for sunlight should be much higher. This gives you 
(with proper radiosity use i.e. brightness = 1) easily a nice and 
realistic lighting with good contrast and - most important when you aim 
for realism - without any tweaking.

-Ive

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
>
> Don't forget that using diffuse 1 is NOT realistic. A very bright
> surface may have a diffuse as high as 0.95 or even 0.98, never 1.
>
> Using diffuse 1 is a very good way to get washed out colours.
>

and Ive wrote...
> ...it is a common
> mistake to define the diffuse reflectance way too strong. E.g. a *white*
> piece of paper is something like rgb <0.5, 0.48, 0.42> with diffuse 0.6

Yes, I'm now understanding that concept as well, far better than I used to.

My prior assumption about a typical low-dynamic-range scene-- of almost always
using diffuse 1.0 for an object's surface-- was based on several factors
(assuming that both ambient and emission are at 0.0 for argument's sake, and NO
radiosity):  With a light_source set to rgb 1.0, and an object's color of
<.3,.5,.7> --with no additional phong or specular to complicate things-- my
understanding was that the very *brightest* color of the object's surface would
never exceed <.3,.5,.7> (but could  go below that, naturally.) That may still be
the case with a purely white light_source-- but the addition of anything else
(radiosity, colored light etc) naturally complicates things, so that
*something* in the scene needs to be tweaked (in brightness or whatever) to keep
any parts of the render from 'clipping' in brightness-- past the 1.0 maximum
pixel level for a LDR render, as Clipka mentioned.

From all that's been said so far, it appears that this tweaking needs to be done
*by eye*, to try and make sure that any clipping is kept to a minimum. Perhaps
the 'by eye' method is just a given-- and it's certainly what I had to do in
v3.6.x days (though with limited success.) *Which* parts to tweak can be ...
complicated, though. Even with POV-ray's up-to-date changes re: radiosity,
assumed_gamma etc, a successful/realistic render nevertheless appears to require
a *by eye* approach.

I don't have any complaints about that need; and I'm certainly open to being
corrected if I'm wrong ;-)

Post a reply to this message