Am 24.05.2018 um 23:51 schrieb Alain:
>>> The only thing guaranteed is
>>> that the entirety of the object lies /somewhere/ within those bounds.
>>>
>>
>> I've always been curious about why this is so. For example, assume a
>> short
>> cylinder (short in y) and with no rotations. Taking the
>> min_extent/max_extent of
>> that object as-is, the resulting 'bounding box' shape tightly hugs
>> that object
>> (meaning, the bounding-box 'axis planes' just touch the object.)
>>
>> But if the object is rotated (around all three axes, for argument's
>> sake), the
>> resulting bounding-box (its planes) are generally some distance away
>> from any of
>> the cylinder's surfaces. I.e., there are gaps of empty space between
>> object and
>> bounding box. I'm sure that there IS a technical reason for this; but
>> a simple
>> (naive!) question would be: Why does rotating an object 'mess up' the
>> bounding-box tightness?

It's a combination of multiple things:

- For the sake of performance, perfect tightness is not mandatory.
Reasonable close-ness is perfectly sufficient.

- For the sake of performance, bounding boxes _must_ be axis-aligned.

- For the sake of flexibility, the algorithm to compute bounding boxes
for transformed objects must be able to cope not only with rotations,
but with arbitrary transformations.

- For the sake of developer sanity, bounding boxes must be reasonably
easy to compute.

So in most cases, the algorithm for computing a bounding box for a
transformed primitive (except for pure scaling and translation) is as
follows:

- Compute a preliminary b'box based on the untransformed object.
- Apply the transformation to the preliminary b'box.
- Compute the final b'box to fit snugly around the corners of the
transformed preliminary b'box.

Since the preliminary b'box is guaranteed to contain the entire object,
and this property is unaffected by transformations; and since the final
b'box is guaranteed to contain the entire transformed preliminary b'box;
this algorithm guarantees that the final b'box contains the entire
object, without wasting too many brain cells on figuring out how to
compute the b'box for e.g. a shear-transformed sphere.

In a worst-case scenario, the resulting b'box will present at most twice
as big of a cross section to rays as an ideal b'box would, which I guess
is acceptable in terms of performance.


(You could try to measure the performance loss by taking an arbitrary
scene with axis-aligned primitives, and rotating all of them by 45
degrees around the camera axis. Also, if you are mathematically
inclined, you could implement algorithms to compute better-fitting b'boxes.)

Post a reply to this message