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