On 2/21/2018 8:38 AM, Stephen wrote:
> On 21/02/2018 13:19, Bald Eagle wrote:
>> Stephen <mca### [at] aolcom> wrote:
>>
>>> Too much coffee? ;-)
>>
>>

>>
>> (Though "enough coffee" is an unusual state of affairs.)
>>
> 
> Whoop, whoop, whoooooop!
> 
> Attention! Low, low level coffee alarm.
> 
> 

I did not know you were a Juggalo, Stephen.


Mike

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>
> > Are you saying that it doesn't matter which corners I choose, as long as
> > the corners are opposite of each other? I don't quite understand.
>
> You need to choose the nearest and the farthest corners, to get the largest
> spread to scale your color map across.

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.
>
> Kenneth didn't realize that bounding boxes are _always_ cardinal-axis aligned.

.... un, yeah, except for that ;-)

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. But in renders looking exactly along the x/y/z axes, there is
clearly additional space between object and box-- when the box should exactly
delineate the boundaries of the object(?). Why that occurs when the object is
rotated is mysterious; it doesn't always happen. But it does make me suspicious,
that maybe just maybe the REAL bounding box may not actually be cardinal-axis
aligned?? Otherwise, where is the extra space coming from? Maybe it's just the
natural behavior of auto-bounding... ?

Post a reply to this message

Attachments:
Download 'chromadepth_bounding_boxes_2.jpg' (123 KB)

Preview of image 'chromadepth_bounding_boxes_2.jpg'

"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?
And that white arrow is from the origin through the center of 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})...} ?

What IS that, and how is it made?   There might be some odd CSG thing going on.
Have you tried just a simple cylinder?

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.

>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...

> Otherwise, where is the extra space coming from? Maybe it's just the
> natural behavior of auto-bounding... ?

vide supra

Post a reply to this message

On 21/02/2018 14:00, Mike Horvath wrote:
> On 2/21/2018 8:38 AM, Stephen wrote:
>> On 21/02/2018 13:19, Bald Eagle wrote:
>>> Stephen <mca### [at] aolcom> wrote:
>>>
>>>> Too much coffee? ;-)
>>>
>>>

>>>
>>> (Though "enough coffee" is an unusual state of affairs.)
>>>
>>
>> Whoop, whoop, whoooooop!
>>
>> Attention! Low, low level coffee alarm.
>>
>>
> 
> I did not know you were a Juggalo, Stephen.
> 


Juggalo, gigolo? Who cares. ;-)

Did you not read to the end of the letter?
"U" is the international signal for "You are standing/running into danger".

As for Low-low... ;-)


-- 

Regards
     Stephen

Post a reply to this message

"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'

"Kenneth" <kdw### [at] gmailcom> wrote:
> Those slicing planes sure do look like what *could*
> be a differently-oriented and incorrect bounding-box shape.

Oops, I just realized that my slicing planes (and the corner points) wouldn't
produce a nicely-square box, but a trapezoid/whatever. Oh well, it was fun to do
anyway. I really thought I was on to something important... :-O

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > Those slicing planes sure do look like what *could*
> > be a differently-oriented and incorrect bounding-box shape.
>
> Oops, I just realized that my slicing planes (and the corner points) wouldn't
> produce a nicely-square box, but a trapezoid/whatever. Oh well, it was fun to do
> anyway. I really thought I was on to something important... :-O

"parallelpiped"
https://en.wikipedia.org/wiki/Parallelepiped
http://mathworld.wolfram.com/Parallelepiped.html

I'll look over your preceding post when I get some more time - off to work I
go...

Post a reply to this message

Well, I've found the root of the problems-- all having to do with the object's
bounding-box:

1) There IS a subtle flaw in my code. Right now, I can't describe it clearly in
words, or how to go about fixing it.

2) There's nothing wrong with POV-ray's bounding boxes or min_extent/max_extent
or vlength (except maybe the 'extra space' that's sometimes between object and
box boundaries, depending on the object's rotation. That's still a mystery.)

3) I had another misconception, about the meaning of a bounding-box's min_extent
and max_extent locations. They are *just* coordinates in space-- and the
location of any 'shoot-from' point to *find* those coordinates has an important
bearing on whether they are considered 'near' or 'far' (i.e., which is min and
which is max.) That was my mistaken notion of the points appearing to 'reverse.'

I'm making an animation to show both my current code flaw AND this min/max
relationship. It's very instructive ;-)  I'll post it.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> 3) I had another misconception, about the meaning of a bounding-box's min_extent
> and max_extent locations. They are *just* coordinates in space-- and the
> location of any 'shoot-from' point to *find* those coordinates has an important
> bearing on whether they are considered 'near' or 'far' (i.e., which is min and
> which is max.) That was my mistaken notion of the points appearing to 'reverse.'


Yes, I think I was [too briefly] trying to point toward that when I asked about
the [virtual/real] camera direction.
The bounding box coordinates are absolute coordinates referenced to the origin.
 10 > 0 > -10

Write out a formula using min() and max() to calculate the min_extent and
max_extent functions, and you'll _get it_.

Post a reply to this message

BTW: If it's not clear yet (because of my digressions about bounding-box stuff),
my code example works fine and dandy *if* CAM_LOCATION is at the origin,
<0,0,0>. (It puts both the 'MAIN camera' and its associated spherical pigment
there.) I haven't seen any problems when doing so.

Post a reply to this message