"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > ... but there's possibly *some* kind of problem (maybe 'problem'
> > is not the right word) for how trace creates its normal in the first
> > place. But I haven't exactly narrowed the problem down to trace itself;
> > it may be in how the normal is being 'processed' by other POV-ray tools..
> >
>
> POV-Ray "measures" the normal of the surface that the ray intersects.
> I'm pretty sure that there's no problem there.
>
> Clearly understanding what those other macros actually do is probably
> where the problem lies.
>

Yeah, I think you're right on both counts. For some strange reason, I've always
had a half-baked belief that trace's normal (or *any* normal) has a preferred
'handedness' when it comes to applying an object along that normal... meaning,
the normal ITSELF might somehow be *rotating* the object to a new orientation,
depending on which direction the normal faces into the x/y/z universe.  But
that's silly: a normal is *just a vector direction*. And I have to finally
dispel my mythical thinking. ;-) Thanks for waking up my tired ol' brain.

The object rotational problems I see when using the Point_At_Trans and
Reorient_Trans macros are specific to those tools, I agree. I've tried mightily
to 'correct' the resulting 'unexpected' object rotations (which DO result from
the normal's direction into space), but it's all quite mathematically
complicated.

Try tracing a simple sphere from random directions with thousands of greeble
objects applied, while using the found normals and those alignment macros to
place them, and you'll see what I mean.

Here's an example using the Point_At_Trans macro, applying typical pre-made
objects. Note the delineated 'diamond' rotational patches.

Post a reply to this message

Attachments:
Download 'traced_sphere_using_point_at_trans.jpg' (118 KB)

Preview of image 'traced_sphere_using_point_at_trans.jpg'