|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|