Thanks to all the suggestions I got here, I worked out the problem
with the flipped normals. The solution depended on two pieces of
information: 1.) that some converters and modellers throw out any
normals you try to supply and recompute them "for" you using
cross produces, as Ron observed, and that 2.) cross product is
not a commutative operation, so, as Philippe said, the order in
which you supply the triangle vertices determines the order in 
which the program's cross product function receives its operands,
affecting the direction it chooses for the normal. 

The "unify normals" option in 3DWin, by rights, should have solved
this problem, but it didn't seem to unify all normals equally,
leaving whole sides of the scan target inverted. Probably some 
extremely subtle aspect of the fact that mine is not an 
application anticipated by such programs. 

Ultimately, I went through a couple dozen pieces of scratch paper,
dusted off old knowledge about cross products, right hand rules, 
and the law of cosines before I hit on the solution, and, from 
there, eliminated several unnecessary steps to reach a shortcut 
to that solution that could easily be performed quickly by a POV 
macro. It was just a matter of using POV's own cross product and 
comparing the result to the normals of the triangle to determine
an export order based on whether the triangle's original normals
face toward or away from the scan direction. 

Charles

Post a reply to this message