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