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