I repost this one, as it seems there are no furter comments to it ...

This also happens on Beta 2

I can't see why the following scene won't render when changing "Value" to 1.5
or lower ...


// --------------------------------------------------------------------------
---------
background{
color rgb <1,1,1>
}

camera{
 location<-2.5,0,5>
 look_at<-2.5,0,0>

}
    sor {
        #declare Value=0.2
       5,
       <0.0,   -1.0>
       <0.0,   -0.5>
       <Value,   0.5>   // <------ change Value to 0.15 or lower ... and see
       <0.3,   1.0>
       <0.4,   1.5>
       rotate z*90
        pigment{color rgb 1}
    }
light_source{
<100,100,100>
color rgb <1,1,1>
}

// --------------------------------





--
Jan Walzer <jan### [at] lzernet>

Post a reply to this message

"Jan Walzer" <jan### [at] lzernet> wrote...
>     sor {
>         #declare Value=0.2
>        5,
>        <0.0,   -1.0>
>        <0.0,   -0.5>
>        <Value,   0.5>   // <------ change Value to 0.15 or lower ... and
see

It is possible that the first two points, combined with a third point with a
height of 0.15, will cause the cubic spline to dip below a height of 0.0.
That would cause problems for the root solver.  Render with the values below
to see how the curve is concave, and how two zero-height points could cause
the SOR height to drop below 0.0.

Therefore, this is not really a bug, but a strange limitation of the SOR
object.

-Nathan


    sor {
        #declare Value=0.1
       5,
       <0.013,   -1.0>
       <0.013,   -0.5>
       <Value,   0.5>   // <------ change Value to 0.15 or lower ... and see
       <0.3,   1.0>
       <0.4,   1.5>
       rotate z*90
        pigment{color rgb 1}
        sturm
    }

Post a reply to this message

On Fri, 28 Sep 2001 00:29:01 -0400, Nathan Kopp wrote:
>
>"Jan Walzer" <jan### [at] lzernet> wrote...
>>     sor {
>>         #declare Value=0.2
>>        5,
>>        <0.0,   -1.0>
>>        <0.0,   -0.5>
>>        <Value,   0.5>   // <------ change Value to 0.15 or lower ... and
>see
>
>It is possible that the first two points, combined with a third point with a
>height of 0.15, will cause the cubic spline to dip below a height of 0.0.
>That would cause problems for the root solver.  Render with the values below
>to see how the curve is concave, and how two zero-height points could cause
>the SOR height to drop below 0.0.
>
>Therefore, this is not really a bug, but a strange limitation of the SOR
>object.

It might be a bounding thing, too.  I'm not sure the bounding routines really
care for negative-radius cylinders.

-- 
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions

Post a reply to this message

On 28 Sep 2001 10:20:14 -0400, Ron Parker wrote:
>On Fri, 28 Sep 2001 00:29:01 -0400, Nathan Kopp wrote:
>>
>>"Jan Walzer" <jan### [at] lzernet> wrote...
>>>     sor {
>>>         #declare Value=0.2
>>>        5,
>>>        <0.0,   -1.0>
>>>        <0.0,   -0.5>
>>>        <Value,   0.5>   // <------ change Value to 0.15 or lower ... and
>>see
>>
>>It is possible that the first two points, combined with a third point with a
>>height of 0.15, will cause the cubic spline to dip below a height of 0.0.
>>That would cause problems for the root solver.  Render with the values below
>>to see how the curve is concave, and how two zero-height points could cause
>>the SOR height to drop below 0.0.
>>
>>Therefore, this is not really a bug, but a strange limitation of the SOR
>>object.
>
>It might be a bounding thing, too.  I'm not sure the bounding routines really
>care for negative-radius cylinders.

In fact, having just gone through the bcyl routines looking for the other
SOR bug, I can testify that they do not like bounding cylinders where the
curve crosses 0, and are VERY likely to fail to render large chunks of the 
part of the spline contained in such an interval.

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Post a reply to this message