"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > If I understand what you're asking, the min_extent/max_extent features
> > choose those corners automatically for you. (Although, some of my tests
> > indicate the 'reversal' of those, for some wacky reason.) But generally
> > speaking, they work quite well.
>
> I'm not sure why that would be or if I'm following exactly what you're doing.
> Your labels on the renders below seem to indicate that you're looking in
> negative directions for whatever reason.  Are you sure that's not part of the
> confusion?

The examples I've shown so far don't have that 'reversal' of the near-and-far
bounding-box points. I've only seen that behavior when the camera and object are
really far apart-- and I haven't gone back to test that yet. The orthographic
views I made were not rendered with the 'real' scene camera but with an extra
'uncoupled' camera, from a different viewpoint; so the -y vs. +y (etc) camera
orientations that I chose wouldn't matter.

> And that white arrow is from the origin through the center of the object?

Nope, it's from the *actual* scene-code camera position, through the object--
it's there just to prove to myself that my code is applying its chromadepth
spherical-pigment color_map correctly, and 'projected' /scaled in the correct
orientation between 'real' camera and the object.
>
> > But I'm seeing another oddity about the bounding box that I don't
> > understand. See the image.) Of course, I made the box object myself, as
> > a (hopefully-accurate!) representation of the bounding-box volume-- and
> > orientation.
>
> Are you just using something like box {min_extent(object{thing}),
> max_extent(object{thing})...} ?

Yep. I have to assume that it's representative of the object's REAL bounding
box.. barring any other unknown discoveries ;-) BTW, it's not part of the
scene's main operation and it's not CSG; it's just an extra object placed at the
same coordinates.
>
> I also suggested you do exactly what you're doing and animate the rotation of
> the object so you can see if that extra space is always there, or just with
> certain odd orientations.

Funny thing: I actually did such an animation-- a series of them, in fact. Maybe
I'll post one. They definitely show the (my) translucent box
'squashing-and-stretching' as the inner object rotates.
>
> > But it does make me suspicious, that maybe just maybe the REAL bounding
> > box may not actually be cardinal-axis aligned??
>
> Well, they have to be, because you're just getting 2 corners out of min
> and max extent, and if you box{} that...
>
I thought so too-- but I've been playing around with some experiments, and it
does seem possible to create a (fake) bounding-box in a *different* / tilted
orientation, that still uses the same two corner positions.

I made an image of that (using my 'uncoupled' camera again.) This time, the
'real' camera and the object are father apart than in my previous images-- and
which now shows a squashed color_map (possibly from an erroneous bounding-box
and wrong corner points?) Anyway, this image shows-- I think-- that *a*
bounding-box could conceivably be generated that doesn't really align to the
cardinal axes.

Just a fun experiment, really, but it looks too interesting to ignore. BTW, I
didn't create those slicing planes arbitrarily; they actually delineate the
spherical color_map's (scaled-up) index values in my code-- 'T' and 0.0 there.
I.e., the slicing planes would be the 'spherically-curved surfaces' of those
color_map values as they intersect the object, if that makes any sense. And the
center of that spherical pattern is also where the 'real' camera is located...
which is quite interesting. Those slicing planes sure do look like what *could*
be a differently-oriented and incorrect bounding-box shape.

Post a reply to this message

Attachments:
Download 'chromadepth_bb_experiment.jpg' (219 KB)

Preview of image 'chromadepth_bb_experiment.jpg'