Well, I figured out what the problem is. I've posted an image of my latest
tests. (The white arrow illustrates the camera-to-object direction-- and shows
that the code itself is working; the color 'stripes' on the object are in the
correct orientation of the 'spherical' pattern, slicing through the object.) In
the images, I put small spheres at the min_extent and max_extent positions. The
blue box represnts the bounding-box shape that's found.

But POV-ray's automatic bounding boxes don't behave the way I thought :-(

I was assuming that a bounding box would 'hug' the object. As you can see in the
top images, it does. Nice and tight. But when an object is rotated, the bounding
box changes its size-- whereas I was expecting it to remain just like the top
images no matter what... like the object was 'wrapped' in the same-size box,
which would rotate with it. That was a major misconception on my part, and it
definitely affects my code idea. I have no idea how to compensate for that-- no
'fudge factor' that I can think of.

At first, I thought this was really screwy behavior; but I see now what is
actually happening. The bounding box shape is like an 'orthographic projection'
of the object boundaries-- AS IF PROJECTED FROM strictly the x/y/z planes.
That's the key. The camera or object location doesn't affect that
strictly-rectangular shape. (If I were to set up a camera looking exactly in x,
y, or z, I'm sure I would see only one face of the box.)

I now seem to remember newsgroup discussions in the past about this behavior,
but I had forgotten about it.

The images also show a sphere superimposed onto the cylinder object. Its radius
is 1/2 of the diagonal distance between min_extent and max_extent, and I
textured it with the same main color_map pigment, from the same translated
location as the main object's color_map. It may not be too clear here, but in my
animation tests it shows that the color_map's 'color limits' are also expanding
and contracting with the changing box shape, naturally enough. *That's* why my
code's fudge factors seemed arbitrary.

I'm still trying to determine why the bounding-box coordinates sometimes
'reverse' themselves. I think it's a combination of too-much-distance between
camera and object, and some precision errors. But that's worth finding out
about, if there's a distance limit to getting usable min_extent and max_extent
values, depending on the orientation of an object.

Post a reply to this message

Attachments:
Download 'chromadepth_bounding_boxes.jpg' (224 KB)

Preview of image 'chromadepth_bounding_boxes.jpg'