"Kenneth" <kdw### [at] earthlinknet> wrote:
> I've done a fair amount of thinking about this, and it seems to me that the
> problem--if there really *is* one--is that there's no way for Point_At_Trans to
> know where left and right are, referenced to the sphere surface itself. Because
> the normal at a point really has no 'rotation' component built in, to tell
> Point_At_Trans what to do at each point.

Yes, that's exactly the point. As a matter of fact, how would you *define* left
and right in such a context at all?

So the only constraint Point_At_Trans uses for choosing left and right is that
its computations don't go berserk (for instance, choosing left to be coincident
with up would obviously mess up things).

> Perhaps there's some subtle code missing from the macro, I don't know.

No, it's perfectly fine as it is. If you need more control over left/right
issues, you'll need to use a series of VCross operations instead.


> Luckily, when using a rather amorphous shape for the traced-on object--like a
> blob--these rotation anomalies don't show themselves too badly.

Even in such cases it is probably wise to do a random rotation about the y axis
first, to kill off any remaining subtle patterns due to orientation.

Post a reply to this message