Mike Horvath <mik### [at] gmailcom> wrote:
>
> I attached the macros I created based on your code. However, it still
> requires some labor on the user's part, since the camera could be
> located anywhere, and not necessarily closest to the minimum extent or
> farthest from the maximum extent, etc. There needs to be some way to
> automatically determine which of the bounding box's 8 corners is the
> closest and which is the farthest from the camera.
>

Hmm, an interesting thought.

I've always assumed that finding vlength to the min_extent/max_extent
bounding-box positions would never fail to return the proper spatial
coordinates, regardless of what 'orientation' the object was in, relative to the
vlength 'shoot-from' position. In other words (AFAIU) the object itself has
'set' bounding box corner values for the particular spatial location that it's
at-- values relative to the origin at <0,0,0> (and which can naturally *change*
depending on the object's rotation, for example-- i.e., the corners shift
around.) And that there's always *some* set of distinct nearest-corner and
farthest-corner values, *as referenced to the vlength shoot-from position*, not
the origin. My assumption is that the vlength/min_extent/max_extent combination
would *always* pick out what IT sees as the nearest corner and farthest corner,
relative to itself (not relative to the <0,0,0> origin.)

If I'm wrong about any of this, then my code concept is wrong as well, in a
strangely subtle way.

I do recall past discussions in 'the old days' that there were some problems
with bounding boxes not being translated (rotated?) correctly when the object
itself was; but that was fixed, ASAIK.

The answer to all this may be buried in my #debug messages-- all the various
values returned-- but it looks like some vector analysis is required to tease
out an answer. Ugh.

Post a reply to this message