Render the example scene below, with the new UVPov. You should see darker
patches behind the two objects. Here are a few observations:
1) It only appears when antialiasing is on, and only during the final pass.
Probably some calculation is omitted with sub-pixel rays.
2) Very high quality (many rays, low error_bound) will eliminate (or obscure?)
the dark patches, but other freaky things occur (see for yourself). Maybe
related, maybe not.

I'm wondering if this has something to do with the non-constant
distance_maximum, since the problem seems to occur on a flat background around
outstanding objects... I may be wrong, though.

Margus

//BEGIN SCENE

global_settings{
    ini_option "+qr"
    ini_option "Preview_Start_Size=4"
    ini_option "Preview_End_Size=2"
    radiosity{
        brightness 2
        count 100 //try 1200
        error_bound 1 //try 0.05
        gray_threshold 0
        low_error_factor .5 //try 0.1
        minimum_reuse 0.015
        nearest_count 5
        recursion_limit 2
        max_sample 10
        adc_bailout .01/10
    }
}

camera{location <-1,2,-4> look_at <-2.5,2,-1> angle 90}

plane{z,4
    pigment{rgb <.7,.7,.65>}
    finish{ambient 0 diffuse .6}
    hollow
}

sphere{<-3,2,3>,.5 pigment{rgb 1} finish{ambient 10 diffuse 0}}

cylinder{-y,y,.2 pigment{rgb 1} finish{ambient 10} translate z*3+y*2}

Post a reply to this message

Yes.  It's a bug.  Found and fixed (for the next release of UVPov).  It was
a bit of legacy code (from the original radiosity) that was messing up my
changes.  It was caused by some code in the supersample() function related
to antialiasing.

I had seen this before but didn't make the connection between antialiasing
and the dark spots.

-Nathan

Margus Ramst <mar### [at] peakeduee> wrote...
> Render the example scene below, with the new UVPov. You should see darker
> patches behind the two objects. Here are a few observations:
> 1) It only appears when antialiasing is on, and only during the final
pass.
> Probably some calculation is omitted with sub-pixel rays.
> 2) Very high quality (many rays, low error_bound) will eliminate (or
obscure?)
> the dark patches, but other freaky things occur (see for yourself). Maybe
> related, maybe not.
>
> I'm wondering if this has something to do with the non-constant
> distance_maximum, since the problem seems to occur on a flat background
around
> outstanding objects... I may be wrong, though.
>
> Margus
>

Post a reply to this message

Margus Ramst <mar### [at] peakeduee> wrote ...

> 2) Very high quality (many rays, low error_bound) will eliminate (or
obscure?)
> the dark patches, but other freaky things occur (see for yourself). Maybe
> related, maybe not.

High numbers here:

>         count 1200
>         error_bound 0.05
>         low_error_factor 0.1

Ok, now you've put the error bound TOO low.  When it is this low the
following happens:
For each pixel, POV tries to find previously computed values and use them.
But it fails because the error bound is so low that none of the previous
values work.  So, instead, it takes shoots out another 1200 rays and gathers
again.  Then it uses this single estimate to color that pixel.  Then it does
it again for the next pixel.  This totally defeats the entire purpose of
reusing samples.  And it adds noise to the radiance estimate, sonce now you
have quickly-changing radiosity (a different estimate for each pixel)
instead of gradually-changing radiosity.

So I guess what I'm saying is that, when it comes to UVPov's radiosity, that
'too much of a good thing...' saying does apply.

The following gives a pretty good radiance estimate (at least it looks
pretty good to me).  Note the decreased low_error_factor:  this causes just
about all gathering to occur during the preview passes and almost none to be
done in the final pass, which leads to a much better radiance estimate
(albiet a slower render).  You could probably go down to an error_bound of
about 0.9 or 0.8 (not much less than that, though) but then increase that
low_error_factor back up to maybe 0.4.  Also note the increased
nearest_count (more things to average generally means a better estimate).

(low_error_factor could probably go down to 0.2, and nearest_count probably
up to 15 or 20, but when that doesn't change the scene much and really slows
things down.  Also, with that low of a low_error_factor*error_bound
combination, you could just skip straight to the 2x2 preview pass)

    radiosity{
        brightness 2
        count 150
        error_bound 1
        gray_threshold 0
        low_error_factor .3
        minimum_reuse 0.015
        nearest_count 10
        recursion_limit 1
        max_sample 10
        adc_bailout .01/10
    }


-Nathan

Post a reply to this message