When you rotate an object, is its bounding box rotated accordingly?
I mean: suppose you have a box {-1,1}. Its bounding box is surely box
{<-1,-1,-1>, <1,1,1>}. Now suppose you rotate the box this way: box {-1,1
rotate 45}. What's its bounding box now? box {<-1,-1,-1>,<1,1,1> rotate
<45,45,45>} or box {<-1.500,-1.500,-1.707>,<1.500,1.500,1.707>}?

If it's box {-1,1 rotate 45} then min_extent and max_extent don't return the
minimum and maximum coordinates of an object's bounding box, but simply the
minimum and maximum coordinates of the smallest box (alligned with the axes)
containing that object (of course this behaviour is highly desiderable).

If it's box {<-1.500,-1.500,-1.707>,<1.500,1.500,1.707>} (as min_extent and
max_extent return) then the *degree of optimization* of a CSG (i.e. its
render time) depends on its orientation.

What I'm not getting here? Does what I've said make any sense?

Thanks in advance,

--
Jonathan.

Post a reply to this message

JRG wrote:
> 
> When you rotate an object, is its bounding box rotated accordingly?
> I mean: suppose you have a box {-1,1}. Its bounding box is surely box
> {<-1,-1,-1>, <1,1,1>}. Now suppose you rotate the box this way: box {-1,1
> rotate 45}. What's its bounding box now? box {<-1,-1,-1>,<1,1,1> rotate
> <45,45,45>} or box {<-1.500,-1.500,-1.707>,<1.500,1.500,1.707>}?
> 
Not the first solution; I did not check the maths for the coordinates, but
it's probably the second.

> If it's box {-1,1 rotate 45} then min_extent and max_extent don't return the
> minimum and maximum coordinates of an object's bounding box, but simply the
> minimum and maximum coordinates of the smallest box (alligned with the axes)
> containing that object (of course this behaviour is highly desiderable).
> 
> If it's box {<-1.500,-1.500,-1.707>,<1.500,1.500,1.707>} (as min_extent and
> max_extent return) then the *degree of optimization* of a CSG (i.e. its
> render time) depends on its orientation.

Of course. By using only parralel to the axis bounding-box, the check for
a component is quick. Then, for each hit bounding box, it's time to
get some real computation and avoid the empty part.
It's obvious that rotating a box make it render slower, because the
bounding box reports some empty spaces that can only be discovered by
a real computation. But at least, the set of box in the upper part of the
image is not influencing the rendering of the lower part (until you add
reflection and refraction, and the rays bounces toward the upper set,
but that's another story...)

> 
> What I'm not getting here? Does what I've said make any sense?

I do not know. Yes.
Bounding box are great helper for small and complex objects, 
they 'JUST' save a lot of computation in most usual cases.
(replace your box object with a blob or superellipsoid, to get an idea
of the difference of using or not the bounding box for a rendering,
when the object is not alone in the middle of the scene).

What were your questions ?

Post a reply to this message

Wasn't it JRG who wrote:
>When you rotate an object, is its bounding box rotated accordingly?
>I mean: suppose you have a box {-1,1}. Its bounding box is surely box
>{<-1,-1,-1>, <1,1,1>}.

If would be if it *had* a bounding box. POV doesn't normally perform
automatic bounding on a simple box object (presumably because checking a
ray for intersection with a box is as quick as checking for intersection
with the bounding box).

A quick test shows that the automatic bounding boxes are oriented along
the axes, manual bounding boxes are affected by rotate commands that
appear after the bounded_by command.

It might also be worth noting that the vista buffers (which are derived
from the automatic bounding boxes) are oriented parallel to the edges of
the picture, which may well not be the same as parallel to the axes.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message