The following triangle makes SuperPatch POV-Ray 
(at least my DJGPP build) crash with SIGSEGV when 
rendered at 320x240. 
Removing the 'reflection' from the triangle lets it render OK
so I assume this is one of those 'reflection normals, etc' 
things.
(The same scene and resolution with official POV goes
fine.)

I am curious as to how it renders in other builds of 
SuperPatch.
/*---------- bad triangle ----------------------------------*/
triangle{
        <75.194025, -159.990988, 51.303515>,
        <-110.075813, -155.973645, -48.712199>,
        <53.753353, 90.153147, 153.284065>

        texture{
                pigment { rgb<1,0,0> }
                finish { reflection .1}
        }
        rotate<0,80,0>
}

camera{
        location <450.00, 0.00, 00>
        look_at <0.00, .00, 0.00>
}
light_source {
        <1100, 100, -200>
        color 1
}

/*-----------------------------------------------*/

Post a reply to this message

On Wed, 30 Jun 1999 19:00:44 -0400, edna dornblazer
<hac### [at] geocitiescom> wrote:

>The following triangle makes SuperPatch POV-Ray 
>(at least my DJGPP build) crash with SIGSEGV when 
>rendered at 320x240. 
>Removing the 'reflection' from the triangle lets it render OK
>so I assume this is one of those 'reflection normals, etc' 
>things.
>(The same scene and resolution with official POV goes
>fine.)

Works fine in my Windows superpatch too.  Make sure your source has
the lighting.c that's dated June 10.  The older one has a bug when you
use reflection.  There was one other change from that version, too, in
render.c.

Post a reply to this message

Ron Parker wrote:

> On Wed, 30 Jun 1999 19:00:44 -0400, edna dornblazer
> wrote:
> >The following triangle makes SuperPatch POV-Ray
> >(at least my DJGPP build) crash with SIGSEGV when
> >rendered at 320x240.
[ ... ]
> Works fine in my Windows superpatch too.  Make sure your source has
> the lighting.c that's dated June 10.  The older one has a bug when you
> use reflection.  There was one other change from that version, too, in
> render.c.

lighting.c and render.c are both from June 10.
My trace says its crashing from Reflect() calling Trace() 
which calls Determine_Apparent_Colour(),
and for some damn reason on the line call to Normal() 
(Triangle_Normal()) which is just a memcpy from and to
a couple of perfectly fine addresses.

Could there be something just so offensive about a 
particular spot (and view of that spot) on a triangle 
that POV acts like this?

Post a reply to this message

edna dornblazer wrote:
> lighting.c and render.c are both from June 10.
> My trace says its crashing from Reflect()
[ ... ]

I think I found it.
In lighting.c, in Reflect():
    
    z = (FRAND() * 2) - 1;
    t = FRAND() * M_PI * 2;
    r = sqrt(1 - z*z);
Well, FRAND*2 (at least with MSDOS/DJGPP) on occasion returns 
numbers slightly bigger than 1.0, and the subsequent 
r=sqrt(negative number) yields NaN vectors a little later.
Replacing the r=sqrt() line with
     r = sqrt(fabs(1 - z*z));
at least lets that stupid triangle render.

Post a reply to this message

On Thu, 01 Jul 1999 13:16:05 -0400, edna dornblazer wrote:
>edna dornblazer wrote:
>> lighting.c and render.c are both from June 10.
>> My trace says its crashing from Reflect()
>[ ... ]
>
>I think I found it.
>In lighting.c, in Reflect():
>    
>    z = (FRAND() * 2) - 1;
>    t = FRAND() * M_PI * 2;
>    r = sqrt(1 - z*z);
>Well, FRAND*2 (at least with MSDOS/DJGPP) on occasion returns 
>numbers slightly bigger than 1.0, and the subsequent 
>r=sqrt(negative number) yields NaN vectors a little later.
>Replacing the r=sqrt() line with
>     r = sqrt(fabs(1 - z*z));
>at least lets that stupid triangle render.

Ah, that makes sense.  Windows has a tendency to ignore FP errors.

Hm, I'm piling up all sorts of bugfixes.  Time for a bugfix release,
methinks.  Now to find them all...

Post a reply to this message