"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I'm still mighty curious about why the use of min_extent and max_extent
> (as usedor derived from the moving 'MAIN camera' location) 'flip' their
>  meaning of 'near' and 'far', depending on the relative locations of
> camera and object...

Duh. I just realized my conceptual flaw (after *days* of thinking about it the
wrong way!) Various comments here and in the other thread may have pointed the
way, but I didn't grasp it.

1) Given: The min_extent and max_extent coordinates are *just* coordinates in
space-- the bounding-box corners-- which never change (unless I rotate the
object of course, or change its position).

2) I'm using vlength to find those coordinates-- from the changing 'MAIN camera'
position

3) Those found vlengths *NATURALLY* change, depending on where the origin of
vlength is (the 'MAIN camera' position) in relation to the never-changing
bounding-box corners.

4) It's my particular use of the *difference* between the two vlengths (and the
resulting L_1/L_2 equation) that causes the color_map to sometimes squash down
too much-- depending solely on the position of the 'MAIN camera' (which is also
the center of the spherical pigment.) The color spread just happens to look
correct at most times, but that's ... pure luck. The *difference* in vlengths
(from camera position) to the two bounding-box corners can indeed shrink to
almost nothing in some cases.  Part 4 of my animation test clearly shows this --
except that I didn't see what it truly meant!

5) Even with the camera/pigment placed at <0,0,0>, there are still *slight*
flaws with the resulting color_map spread on an object-- unless the object
itself is 'centered' along two of the three default x/y/x axes. The reason for
this is because of 2) and 3). For an object centered at, say, <13,26,50>, the
'MAIN camera' needs to be at <13,26,0> (or some other z-position)-- because this
is the only relationship whereby the found vlengths (the difference between
them, that is) is accurate, as far as scaling the spherical pigment to exactly
extend between object boundaries (or rather, between bounding-box corners.)

I think the trace() idea will easily solve these problems.

Post a reply to this message