John, Thank for taking the time to type this all out. I even think I begin
to understand it. 8-)

    Now lets see if when added to the mix of a thousand other unfinished
projects, I can get anything done with the information...

"John VanSickle" <van### [at] erolscom> wrote in message
news:385814FE.E9BA9AD5@erols.com...
> 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