My own experience with tracing using Point_At_Trans() shows some weird (well,
*unexpected*) results, having to do with how the traced-on objects are oddly
rotated 'around' the normals that trace finds. It's easy to see this by tracing
a plain sphere from a randomly-orbiting trace location, with the trace direction
pointing at the center of the sphere. For making the object to place at all
those traced points, construct a little CSG object (at the origin as usual)
that shows an obvious 'direction'--like two cylinders made into an upside-down
'L'. When these are traced on using Point_At_Trans(Norm)  they show up where
they are supposed to, but as diamond-shaped 'patches' where all the objects in
each patch have the same rotation around the objects' 'relative y' axis, with
each patch's orientation different by 90-degrees or so from the other patches
(if that makes any sense!)

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. Perhaps there's some subtle code
missing from the macro, I don't know.

The same thing occurs when tracing a height_field and using the macro; the bumps
of the HF can be considered as the 'upper half' of the sphere example I've
given. (And tracing a HF can produce even more rotational strangeness when
using the found normals--having to do with the image_map resolution the HF is
made from, and *if* a trace 'ray' happens to hit a triangle vertex point or
near(?) it. From my own limited tests, it seems that the normal has a direction
of <0,1,0> or straight up.)

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

Ken W.

Post a reply to this message