 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
(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
|
|
| |
| |
|
|
From: clipka
Subject: Re: radiosity brightness-- subtle problem at low values
Date: 10 Mar 2018 04:01:11
Message: <5aa39ed7$1@news.povray.org>
|
|
|
| |
| |
|
|
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] anonymous org> 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
|
|
| |
| |
|
|
From: clipka
Subject: Re: radiosity brightness-- subtle problem at low values
Date: 10 Mar 2018 19:00:05
Message: <5aa47185$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: clipka
Subject: Re: radiosity brightness-- subtle problem at low values
Date: 11 Mar 2018 17:28:20
Message: <5aa59f74$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: clipka
Subject: Re: radiosity brightness-- subtle problem at low values
Date: 12 Mar 2018 21:26:39
Message: <5aa728cf$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
