Mike Horvath <mik### [at] gmailcom> wrote:

>
> Well, you can see this effect in POV-Ray too if you change the camera's
> angle parameter.
>
>
https://commons.wikimedia.org/wiki/File:Camera_focal_length_distance_house_animation.gif
>

I hadn't seen that before. it's a nice illustration of what happens.

A couple of years ago, I made some related (or not!) tests with my digital
camera: Setting it on a tripod, I made a wide-angle photo of a scene, and then a
telephoto view. I wanted to see if there was any apparent '3-D depth change' to
objects when comparing the two, based on the lens setting (probably a silly
experiment with a foregone conclusion, but I wanted to test it anyway.) I took
the wide-angle photo into Photoshop and blew it up, and chose a small rectangle
of a distant object to compare to the telephoto view. Except for the noisy
nature
of the blow-up, they both looked identical.

Post a reply to this message

I'll see if I can provide some of my code from the camera view frustum project -
that had some good basic code that I looked up to implement.  It might be
applicable.

Also, I'd start by "going 2-D" and looking down from halfway between the camera
and object, with an orthographic camera, and a gridlined plane.
That might help highlight issues and provide more visual clues.

Post a reply to this message

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

>
> What it looks like so far is that, if I (pre-)rotate the object before being
> translated, the ''near' and 'far' bounding_box corners are actually rotating
> along with the object-- i.e., their 'near' and 'far' relationship appears to be
> reversing! (Or vlength is choosing the wrong corner?)

No, I was mistaken about that-- the corners aren't 'rotating' with the object.
But there *are* definite reversals of 'near' and 'far' corners, depending on
....? (camera/object distance, maybe.)  I'm still working that out...

Bald Eagle wrote:
> Also, I'd start by "going 2-D" and looking down from halfway between the camera
> and object, with an orthographic camera, and a gridlined plane.
> That might help highlight issues and provide more visual clues.

That's pretty much exactly what I'm doing right now, with a few bells and
whistles thrown in too. I resorted to animation tests, to try and *clearly*
determine what's up with the applied color_map re: the changing-shape(!)
bounding_box...

Post a reply to this message

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'

"Kenneth" <kdw### [at] gmailcom> wrote:
I have no idea how to compensate for that-- no
> 'fudge factor' that I can think of.

You take the vectors for the original bounding box and do the same vector
transform on them that you do for the object.  Then they define the corners of
the original bounding box, but in the new location / orientation.

If you'd like, for posterity, maybe take a long-ish cylinder, show a bounding
box (like a wire_box) and animate the cylinder being rotated, and how the BB
changes.
Then do the same with a "bounding box" using the transformed vectors as corners
- you'll have to build that wire box manually, or at least edit the code for it
in the include file so it takes 8 corners as arguments...

Post a reply to this message

On 2/20/2018 7:07 AM, Kenneth wrote:
> 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.
> 
> 

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.


Mike

Post a reply to this message

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.

Kenneth didn't realize that bounding boxes are _always_ cardinal-axis aligned.

I'm not entirely sure that it matters, but I think that between Kenneth, and
clipka and Bill P.'s past posts on pattern/distance functions, the answer is
close at hand.

I feel the need to write something like "Pokorny's past partial posts on
pigments and proximity patterns for particles"...

There.  :)

Post a reply to this message

On 21/02/2018 11:30, Bald Eagle wrote:
> I feel the need to write something like "Pokorny's past partial posts on
> pigments and proximity patterns for particles"...
> 
> There.

Too much coffee? ;-)

-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

> Too much coffee? ;-)


Sadly, not enough.  Yet.

(Though "enough coffee" is an unusual state of affairs.)

Post a reply to this message

On 21/02/2018 13:19, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
> 
>> Too much coffee? ;-)
> 
> 
> Sadly, not enough.  Yet.
> 
> (Though "enough coffee" is an unusual state of affairs.)
> 

Whoop, whoop, whoooooop!

Attention! Low, low level coffee alarm.


-- 

Regards
     Stephen

Post a reply to this message