Am 22.01.2014 11:05, schrieb fomhorian:
> I'm getting black lines & patches no matter what. :/
>
> Code:
>
> // +FN16 +BS5 +RP4 +RVP +am3 +a0.1 +r512 +ac0.999995 +w800 +h800
                                ^^^^^ ^^^^^ ^^^^^^^^^^^

The settings interact as follows:

The "+a0.1" setting specifies that you accept an error(*) of up to 10% 
per pixel. This is quite a lax setting, for high-quality renders I'd 
recommend "+a.01".

(*The error margin is relative to 100% white for pixels somewhere 
between black and white; for brighter pixels, the error margin is 
relative to the resulting pixel colour itself.)

The "+ac0.999995" setting specifies that you want a 99.9995% confidence 
that any given pixel is indeed within the accepted marging of error; an 
equivalent statement (at least in layman's terms) is that you accept 
0.0005% of all pixels to be outside the accepted margin of error. This 
is an extremely strict setting, for high-quality renders I'd recommend 
something about "+ac0.99".

The "+r512" option specifies how many samples you accept for any given 
pixel to be taken in the worst case; the value is not taken literally, 
but rather according to the formula:

     max_samples = 4^r

(The rationale behind this parameterization is that it is similar in 
order of magnitude as the effective maximum number of samples in 
anti-aliasing mode 2, while at the same time being easy to express as a 
formula.)

I guess I don't need to tell you that 4^512 (= ca. 10^308) is much more 
than you'll ever need, and in a worst-case scenario could stall your 
render for just a bit short of eternity. For practical purposes, "+r9" 
should be enough for any render.


To sum it up, for practical purposes the following settings should be ok 
for high-quality renders:

     +am3 +a0.01 +ac0.99 +r9


If you experience excessive noise, try lowering the "+a0.01" setting.

If you experience stray dot artifacts, try increasing the "+ac0.99" setting.

Further increasing the "+r9" setting should typically not be necessary.


That said, it seems that you indeed have spotted a problem in UberPOV, 
but it's not related to blurred reflections. Somehow, the perturbed 
normals of the plane appear to lead to nonsense results very close to 
the horizon, leading to invalid colour values for individual rays, which 
sort of "dominate" the results for any other rays shot for the same 
pixel and (in the Windows version) manifest as pitch black pixels. (In 
the Linux version, they may lead to bright white pixels instead.)

I'll have to investigate whether these nonsense results are indicative 
of an actual bug that needs to be fixed, or rather rare but inevitable 
consequences of rounding errors that can safely be worked around.

Post a reply to this message