These were originally just tests for myself, but they looked interesting enough
to post. ;-) (Thanks to Mike Horvath for giving me the idea to work on this
stuff.)

This 3-part animation relates to the 'chromadepth' discussion at ...

http://news.povray.org/povray.binaries.images/thread/%3Cweb.5a8edc2ab61f5657c437ac910%40news.povray.org%3E/

The  code I posted there makes use of an object's bounding-box (the automatic
bounding mechanism that's  behind-the-scenes of POV-Ray.). Min-extent and
max_extent are used to get the corner coordinates of that box. My code has a
subtle flaw, although it does what it's supposed to do ' most of the time'.
This video shows that flaw-- and the bounding-box behavior as well.

If you're not familiar with the comments there, this video probably makes no
sense ;-)  But I'll try to explain:

The main object in the scene is a flattened cylinder.

Next, I made a spherical-pattern pigment. The pigment has a constantly changing
scale, AND a constantly changing index list of its colors; both of those changes
are derived from finding the bounding-box coordinates of the object-- as
measured from what I call the 'MAIN camera' in the video, not the <0,0,0>
origin-- and used as scaling factors. The spherical pigment is also centered on
that camera. This way, no matter where the camera is, it always looks at the
object AND it applies the changing pigment to that object-- so that the
'important' part of the pigment always exactly covers the object in the right
way (more or less!), no matter where.

One problem with my code is, the  bounding-box coordinates naturally (but
unfortunately) *change*, if the object is rotated.  I didn't forsee that.
Another is that the meaning of which coordinate is 'near' or  'far'  can CHANGE,
depending on where those coordinates are measured from when using min_entent and
max_extent. My code didn't take that into account. (But I think it's easy to
fix.)

But the biggest problem shows up in part 4 of the video. It's not an easy one to
explain,: basically, as the camera viewing axis approaches a right angle to an
imaginary 'plane' between the two bounding-box corners, the difference in
camera-distance to those two points begins dropping to zero- (then 'reverses',
as to which point was originally 'near' or 'far.') That's a more subtle and
not-so-easily fixed flaw in my code  :-/    IMO, min_extent/max_extent
mistakenly begin working in reverse at that point, sensing the now-'far' point
as  the 'near' one, for example. That doesn't seem right.

In the video:

These renders were made with a *separate* camera, at a different location from
the 'MAIN camera', to show what's going on. The white line represents the
line-of-site between MAIN camera and object. The blue box shows the bounding-box
volume. The two small spheres show its min_extent/max_extent coordinates--
yellow for min, black for max-- and apparently they *remain* min and max no
matter what.  Overlayed is a simple sphere that has the identical MAIN spherical
pigment applied to it as to the cylinder object-- and likewise applied *from*
the MAIN camera position. I included it to show the pigment's color_map
'limits'-- the white to either side of the 'important' blue and red colors.
There are also geen 'slicing planes' that come in when things go awry, to show
the incorrect extent of the color_map's important colors on the object, and how
they shrink down.

Part 1: The 'MAIN camera (and pigment) location is fixed; the main object moves
away from it. Everything works OK, no matter how great the distance is between
them.

Part 2: Same exact test, but now the object is rotating. This shows the changing
bounding-box size-- and how it affects the spread of the color_map (in my code,
that is.) So far, it all still works reasonable well.

Part 3) The most interesting one. The MAIN camera/pigment is now moving around.
The object has been pre-rotated into a good position to show the effects--as
they go awry. ;-)

Post a reply to this message

Attachments:
Download 'chromadepth_with_bounding_box.mp4.mpg' (3467 KB)