POV-Ray : Newsgroups : povray.unofficial.patches : Bug in UberPOV beta 4 x64. Server Time
29 Mar 2024 01:06:56 EDT (-0400)
  Bug in UberPOV beta 4 x64. (Message 1 to 5 of 5)  
From: fomhorian
Subject: Bug in UberPOV beta 4 x64.
Date: 22 Jan 2014 05:10:00
Message: <web.52df97ba199d2992f1eb95b30@news.povray.org>
I'm getting black lines & patches no matter what. :/

Code:

// +FN16 +BS5 +RP4 +RVP +am3 +a0.1 +r512 +ac0.999995 +w800 +h800
// Rendertime 12min 55sek
// Win 8.1Pro x64 on AMD PhenomII with 8 GB ram
#version unofficial patch 3.7;
#patch "upov-reflection-roughness" 0.9;

global_settings{ assumed_gamma 2.2 max_trace_level 36 }

#default{ finish{ ambient 0.1 diffuse 0.7 }}

camera {
 perspective angle 75 location  <0.0 , 1.0 ,-3.0>  right
x*image_width/image_height look_at <0.0 , 1.0 , 0.0>
 aperture 0.025 blur_samples 512,2048 focal_point <0,1.0,0> confidence 0.999
variance 0.001
}

light_source{ < 3000,3000,-3000> color rgb 1 }

sky_sphere { pigment { gradient y
 color_map { [0.00 rgb <0.6,0.7,1.0>][0.35 rgb <0.1,0.3,0.8>][0.65 rgb
<0.1,0.3,0.8>][1.00 rgb <0.6,0.7,1.0>]}
 scale 2 }
}

plane{ <0,1,0>, 0
       texture{ pigment{ checker color rgb<1,1,1>*1.2 color
rgb<0.25,0.15,0.1>*0.05 }
                normal { bumps 0.75 scale 0.1 turbulence 0.5 omega 0.4 lambda
2.5 octaves 6 }
                finish { specular 0.1 roughness 0.1 }
              }
     }

sphere { <0,0,0>, 1.00
         texture {
                   pigment{ color rgb <1,0,0> }
                   finish { specular 1.0 roughness 0.0125 brilliance 2
reflection { 0.5 metallic 0.5 roughness 0.0125 } }
                 }

          scale<1,1,1>  rotate<0,0,0>  translate<0,1.35,0>
       }  // end of sphere -----------------------------------

I would have liked to paste or attach an image here but...
I've tried to vary the +r, the +ac & the number of samples that the
focal blur uses, also the conf & vari, but no success.
The black patches only exist at the horizon while the lines/dots are
on the sphere.

                                   Sincerely Rendering!


Post a reply to this message

From: James Holsenback
Subject: Re: Bug in UberPOV beta 4 x64.
Date: 22 Jan 2014 05:44:50
Message: <52dfa122$1@news.povray.org>
On 01/22/2014 05:05 AM, fomhorian wrote:
> I'm getting black lines & patches no matter what. :/
>
> Code:
>
> // +FN16 +BS5 +RP4 +RVP +am3 +a0.1 +r512 +ac0.999995 +w800 +h800

                                        ^---- Yikes!!!!

> // Rendertime 12min 55sek
> // Win 8.1Pro x64 on AMD PhenomII with 8 GB ram
> #version unofficial patch 3.7;
> #patch "upov-reflection-roughness" 0.9;
>
> global_settings{ assumed_gamma 2.2 max_trace_level 36 }
>
> #default{ finish{ ambient 0.1 diffuse 0.7 }}
>
> camera {
>   perspective angle 75 location  <0.0 , 1.0 ,-3.0>  right
> x*image_width/image_height look_at <0.0 , 1.0 , 0.0>
>   aperture 0.025 blur_samples 512,2048 focal_point <0,1.0,0> confidence 0.999
> variance 0.001
> }
>
> light_source{ < 3000,3000,-3000> color rgb 1 }
>
> sky_sphere { pigment { gradient y
>   color_map { [0.00 rgb <0.6,0.7,1.0>][0.35 rgb <0.1,0.3,0.8>][0.65 rgb
> <0.1,0.3,0.8>][1.00 rgb <0.6,0.7,1.0>]}
>   scale 2 }
> }
>
> plane{ <0,1,0>, 0
>         texture{ pigment{ checker color rgb<1,1,1>*1.2 color
> rgb<0.25,0.15,0.1>*0.05 }
>                  normal { bumps 0.75 scale 0.1 turbulence 0.5 omega 0.4 lambda
> 2.5 octaves 6 }
>                  finish { specular 0.1 roughness 0.1 }
>                }
>       }
>
> sphere { <0,0,0>, 1.00
>           texture {
>                     pigment{ color rgb <1,0,0> }
>                     finish { specular 1.0 roughness 0.0125 brilliance 2
> reflection { 0.5 metallic 0.5 roughness 0.0125 } }
>                   }
>
>            scale<1,1,1>  rotate<0,0,0>  translate<0,1.35,0>
>         }  // end of sphere -----------------------------------
>
> I would have liked to paste or attach an image here but...
> I've tried to vary the +r, the +ac & the number of samples that the
> focal blur uses, also the conf & vari, but no success.
> The black patches only exist at the horizon while the lines/dots are
> on the sphere.

I think the expectation that you can overcome the moire' effect of the 
checked plane at the horizon is unrealistic ... I mean +r512 holy moley!


Post a reply to this message

From: clipka
Subject: Re: Bug in UberPOV beta 4 x64.
Date: 22 Jan 2014 13:06:04
Message: <52e0088c$1@news.povray.org>
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

From: fomhorian
Subject: Re: Bug in UberPOV beta 4 x64.
Date: 23 Jan 2014 07:05:00
Message: <web.52e1054fe93e4fa2f1eb95b30@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> 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.

Well; I usually render with +a0.005, & I did start with +ac0.95...
I was surprised that POVRay could take +r512 actually & it still rendered way
quicker than my standard aa-settings & +AM2. Might it be possible for UberPOV to
have an adaptive range for the +r? Something like +ra9,512...

                                             Cheers from Sweden!


Post a reply to this message

From: clipka
Subject: Re: Bug in UberPOV beta 4 x64.
Date: 23 Jan 2014 08:30:43
Message: <52e11983$1@news.povray.org>
Am 23.01.2014 13:04, schrieb fomhorian:

> Might it be possible for UberPOV to
> have an adaptive range for the +r? Something like +ra9,512...

That wouldn't make any sense; the oversampling algorithm is adaptive 
already, with the +r parameter just specifying the absolute maximum 
number of rays per pixel.

The minimum number of rays per pixel is automatically computed from the 
+a and +ac settings.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.