Bill DeWitt wrote:
> 
>     I've been trying to figure this out, considering that I don't really
> understand matrixes or meshes and I am working with a D in highschool
> algebra.
> 
>     The only way I can see to do it is to somehow read the mesh into an
> separate program of some sort. Was this what you meant, John? I think I can
> write a C program that might do it, though I think it -might- be just
> barely possible in PovRay itself.

If the object file you're using writes the numbers in human-readable format,
and separates the figures with commas, then yes, a POV-Ray script can read
the file in.  Try editing the file with a text editor.  If you see a bunch of
numbers (possibly separated by commas), you're good to go; if you see a whole
bunch of garbage, then the data is either (a) written in the internal format
for representing floating point numbers, or (b) has been scrambled/encrypted
for some reason.  Note that to be readable by POV, the numbers must all be
separated by commas; if they aren't there, you'll have to add them.

You will of course need to know which number represents what.  If the file
contains nothing but triangle data, you can be fairly sure that any
fractional numbers represent a component of a vector; but whether this is
vector is a vertex, normal, or UV mapping, is still not discernable.  It's
one of those guessing games that makes computer fun to use.

If you can arrange to create a mesh with a known number of vertices and
triangles, you can look for those same numbers in the data file; this will be
very helpful in figuring out the file format.

>     Also, I now have a trial version of Rhino (been running for 3 days so
> as to not use up any iterations 8-) and it exports a nice mesh. Can I
> assume that the order in which it is written  "goes in the same direction
> for each triangle (either clockwise or counter-clockwise) "?

No.  It might just throw them out there.

The way to definitively tell is to look at every edge, and look to see the
order in which the end points are referenced the triangles that border on
that edge.  If they are referred to in reverse order from each other, the
triangles face in the same direction; otherwise they face in opposite
directions.  When making this test, the third vertex in each triangle is
treated as if it *precedes* the first.

This is probably confusing, so I'll try to simplify it a bit.  You have two
triangles, ABC and DEF.

If (A=D and B=F) or
   (A=D and C=E) or
   (A=E and B=D) or
   (A=E and C=F) or
   (A=F and B=E) or
   (A=F and C=D) or
   (B=D and C=F) or
   (B=E and C=D) or
   (B=F and C=E)

then the triangles face in the same direction.

If (A=D and B=E) or
   (A=D and C=F) or
   (A=E and B=F) or
   (A=E and C=D) or
   (A=F and B=D) or
   (A=F and C=E) or
   (B=D and C=E) or
   (B=E and C=F) or
   (B=F and C=D)

then the triangles face in opposite directions.

> Oh, I think I just thought of a way to test this but just in case I still
> would like to hear any input. Basically I am thinking of writing a parser
> inside of a povray file.

The trick is handling the mismatched triangles; you eventually have to turn
one around, but you have to make sure you're turning the correct one around,
and for speed reasons you should have a mechanism to prevent checking a
given edge more than once.  These problems are left as an exercise to the
interested student :-).

Regards,
John

Post a reply to this message