Dear Povray -Experts,

  A while ago I reported problems with povray on Dec Alpha machines.
Povray 3.02 crashed with a
"Floating exception". This occured in do_specular. I tracked the problem
down to a
Layer_Normal whose magnitude was much larger than one. Consequently the
direction cosine was larger than one and in do_specular this is taken to
the power of the reciprocal roughness which eventually leads to very
large intensities. This Layer_Normal was derived from a Raw_Normal so I
have been trying to find out why the function

Normal (Raw_Normal, Ray_Intersection->Object, Ray_Intersection)

returns a Raw_Normal that is not normalized. However I got stuck in the
bewildering amount of
preprocessor statements, nested structs and pointer to functions.
Can anyone tell me where the code for Normal () is ?
( Normal has been defined in frame.h as :
#define Normal(x,y,z) ((*((y)->Methods->Normal_Method)) (x,y,z))
so the argument y ( here Ray_Intersection->Object ) is a struct that
contains the information
I need i.e. Ray_Intersection->Object->Methods->Normal_Method - the
address of a function.
But again I somehow lost track. Can anyone tell me where to find the
code that calculates
whatever it is that Normal does  ?

Even better,  can any experienced povray programmer look into that
problem himself ?

On Linux PC's this problem does not lead to a crash but apparently
results in black pixels whereas on SGI machines you find white pixels.

Yours,

   Lothar Esser

------------------------------------------------------------------
Dr. Lothar Esser
Howard Hughes Medical Institute
5323 Harry Hines Blvd.
Dallas Texas 75235-9050
E-mail : ess### [at] chopswmededu
------------------------------------------------------------------

Post a reply to this message

On Sun, 02 Aug 1998 16:31:07 -0500, Lothar Esser 
<ess### [at] chopswmededu> wrote:
>Can anyone tell me where the code for Normal () is ?
>( Normal has been defined in frame.h as :
>#define Normal(x,y,z) ((*((y)->Methods->Normal_Method)) (x,y,z))
>so the argument y ( here Ray_Intersection->Object ) is a struct that
>contains the information
>I need i.e. Ray_Intersection->Object->Methods->Normal_Method - the
>address of a function.
>But again I somehow lost track. Can anyone tell me where to find the
>code that calculates
>whatever it is that Normal does  ?

It depends on what object type you're using.  If you're using a sphere,
for example, you'd look in spheres.c.  For a Height Field, look in hfield.c.
Each of the object types initializes an array of pointers to point to their
individual implementations of a number of common functions, including 
Normal().  This is the object-oriented part of POV-Ray.

>Even better,  can any experienced povray programmer look into that
>problem himself ?

I'd be happy to take a look at it, but you don't seem to mention the type
of object you're working with.

Post a reply to this message

Ron Parker wrote:

> >Even better,  can any experienced povray programmer look into that
> >problem himself ?
>
> I'd be happy to take a look at it, but you don't seem to mention the type
> of object you're working with.

    Dear Mr. Parker,

      I didn't mention it because I have a bunch of different objects. I have
spheres, cylinders
    and smooth_triangles - but I can't say which object caused the problem. I
guess one can figure it
    out by looking it up in the Ray_Intersection->Object struct - right ?
    Mark Arrasmith told me that he had a similar problem on Dec Alpha machines.
He traced it back
    to some object that was parallel to the horizontal plane and he sort of
fixed it by rotating the
    scene slightly. If this is true, this fix won't help me much because I have
thousands of ojects so that
    in any given orientation I might have a few objects that are horizontal.

    In the meantime I fixed it unprofessionally by renormalizing Raw_Normal -
and it seems to work
    well so far. There are no more crashes and no black or white pixels.


    ( If you would like to have a crack at it, I could send you the scene that
causes the problem ( >  10 Mbytes; or you could tell me how to modify the
source to find out what the problem is. )

    Thanks,


--

   Lothar Esser

------------------------------------------------------------------
Dr. Lothar Esser
Howard Hughes Medical Institute
5323 Harry Hines Blvd.
Dallas Texas 75235-9050
E-mail : ess### [at] chopswmededu
------------------------------------------------------------------

Post a reply to this message

On Mon, 03 Aug 1998 10:53:00 -0500, Lothar Esser <ess### [at] chopswmededu> wrote:
>Ron Parker wrote:
>
>> >Even better,  can any experienced povray programmer look into that
>> >problem himself ?
>>
>> I'd be happy to take a look at it, but you don't seem to mention the type
>> of object you're working with.
>
>    Dear Mr. Parker,
>
>      I didn't mention it because I have a bunch of different objects. I have
>spheres, cylinders
>    and smooth_triangles - but I can't say which object caused the problem. I
>guess one can figure it
>    out by looking it up in the Ray_Intersection->Object struct - right ?

As I don't have an Alpha of my own, I'd guess your scene wouldn't help me
much.

I did a cursory examination of the normal functions for the three objects
you mentioned, and all do a VNormalize(Result, Result) as the last operation.

The normal method for the object in question is at 
Ray_Intersection->Object->Methods->Normal_Method

In case you don't have sufficient debug symbols, Normal_Method is the third
element of the Methods array (an array of pointers) and a pointer to the
Methods array is the first element of the Object structure.  Armed with this
pointer, you should be able to find a routine that you can identify in 
whatever debug symbols you might have.  Be warned: cylinders are actually
special cones, so you'll see Cone_Normal for either cylinders or cones.

Is it possible that one or more of your triangles have strange normals?
For example, a smooth_triangle defined as

   smooth_triangle { 0, -z, x, z, y, z }  

will have a zero normal along a line from .5*x to .5*y but will not trigger 
any warnings or errors at parse time.  When POV normalizes a zero normal, it 
should generate either a division by zero fault or a NAN.  It might be that 
the Intel processor or the specific compiler used for the build you're using
drops the NAN on the floor somewhere, while the Alpha build does the right 
thing and generates a fault.

I think you should be able to find most of these bad triangles by choosing a 
normal vector from one vertex and dotting each of the other two normal 
vectors with it.  If either or both results are negative, you might have a 
bad triangle. (I'm not 100% sure that this won't have some false positives or
false negatives, but it's based on the notion that smooth_triangles don't
work very well if the angle between normals is too large, and anything over
90 degrees, which would generate a negative dot product, is certainly pretty 
large.)

If you want to catch them automatically in POV, you can set a trap in 
parse.c in the Parse_Smooth_Triangle function.  Since these aren't your
garden-variety degenerate triangle, you may want to generate an error when
you see one rather than just eliminating it as the existing degenerate 
triangle test does.  If you're actually using a mesh, you'll have to set 
the trap in Parse_Mesh.

Post a reply to this message

Ron Parker wrote:

> I did a cursory examination of the normal functions for the three objects
> you mentioned, and all do a VNormalize(Result, Result) as the last operation.
>
> The normal method for the object in question is at
> Ray_Intersection->Object->Methods->Normal_Method
>
> Is it possible that one or more of your triangles have strange normals?
>

   This is a distinct possibility. I'll have my program that generates the input
for povray    check the normals for this problem. It should not happen but you
never know ...

> For example, a smooth_triangle defined as
>
>    smooth_triangle { 0, -z, x, z, y, z }
>
> will have a zero normal along a line from .5*x to .5*y but will not trigger
> any warnings or errors at parse time.  When POV normalizes a zero normal, it
> should generate either a division by zero fault or a NAN.

> I think you should be able to find most of these bad triangles by choosing a
> normal vector from one vertex and dotting each of the other two normal
> vectors with it.  If either or both results are negative, you might have a
> bad triangle.

> If you want to catch them automatically in POV, you can set a trap in
> parse.c in the Parse_Smooth_Triangle function.  Since these aren't your
> garden-variety degenerate triangle, you may want to generate an error when
> you see one rather than just eliminating it as the existing degenerate
> triangle test does.  If you're actually using a mesh, you'll have to set
> the trap in Parse_Mesh.

   Well, although I have come experience with C, I don't really feel up this. It
might take longer
    to find the place in povray and add some code without destroying it, than to
modify the
    program that generates the input.

   Thanks for all the good advice ! I do think I am on the right track thanks to
your help.

    Best wishes,

   Lothar Esser

------------------------------------------------------------------
Dr. Lothar Esser
Howard Hughes Medical Institute
5323 Harry Hines Blvd.
Dallas Texas 75235-9050
E-mail : ess### [at] chopswmededu
------------------------------------------------------------------

Post a reply to this message