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

Charles Fusner <cfu### [at] enternet> wrote:
: 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

  This is disastrous.
  It destroys all your normal calculations.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:
> 
> Charles Fusner <cfu### [at] enternet> wrote:
> : 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
> 
>   This is disastrous.
>   It destroys all your normal calculations.
> 

Yes, it's quite disappointing. It does mean, of course, that 
I don't have to worry about whether trace() returns the regular 
normal or the perturbed normal, since the perturbation would be 
thrown out anyway. But... since my experiments have revealed that 
this doesn't produce high quality meshes anyway (I'm now convinced
that would require internal access to the individual primitive types
and their surface parameters) I guess it can still be used to produce 
low to medium quality meshes that are only good for scaling and
positioning reference objects, although they won't *look* more than
passingly like the originals.

Charles

Post a reply to this message