This preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full Document
Unformatted text preview: Chapter 4 Bounding Volumes Directly testing the geometry of two objects for collision against each other is often
very expensive, especially when objects consist of hundreds or even thousands of
polygons. To minimize this cost, object bounding volumes are usually tested for
overlap before the geometry intersection test is performed. A bounding volume (BV) is a single simple volume encapsulating one or more
objects of more complex nature. The idea is for the simpler volumes (such as boxes
and spheres) to have cheaper overlap tests than the complex objects they bound.
Using bounding volumes allows for fast overlap rejection tests because one need
only test against the complex bounded geometry when the initial overlap query for
the bounding volumes gives a positive result (Figure 4.1). Of course, when the objects really do overlap, this additional test results in an
increase in computation time. However, in most situations few objects are typically
close enough for their bounding volumes to overlap. Therefore, the use of bounding
volumes generally results in a significant performance gain, and the elimination of
complex objects from further tests well justifies the small additional cost associated
with the bounding volume test. For some applications, the bounding volume intersection test itself serves as a
sufficient proof of collision. Where it does not, it is still generally worthwhile pruning
the contained objects so as to limit further tests to the polygons contained in the
overlap of the bounding volumes. Testing the polygons of an object A against the
polygons of an object B typically has an 0(112) complexity. Therefore, if the number of
polygons to be tested can be, say, cut in half, the workload will be reduced by 75%.
Chapter 6, on bounding volume hierarchies, provides more detail on how to prune
object and polygon testing to a minimum. In this chapter, the discussion is limited
to tests of pairs of bounding volumes. Furthermore, the tests presented here are
primarily homogeneous in that bounding volumes of the same type are tested against
each other. It is not uncommon, however, to use several types of bounding volumes
at the same time. Several nonhomogeneous BV intersection tests are discussed in the
next chapter. 75 76 Chapter4 BoundingVolumes Figure 4.1 The bounding volumes of A and B do not overlap, and thus A and B cannot
be intersecting. Intersection between C and D cannot be ruled out because their bounding volumes overlap. Many geometrical shapes have been suggested as bounding boxes. This chapter
concentrates on the shapes most commonly used; namely, spheres, boxes, and convex
hull—like volumes. Pointers to a few less common bounding volumes are provided in Section 4.7. Desirable BV Characteristics Not all geometric objects serve as effective bounding volumes. Desirable properties for bounding volumes include: 0 Inexpensive intersection tests
0 Tight fitting 0 Inexpensive to compute 0 Easy to rotate and transform 0 Use little memory The key idea behind bounding volumes is to precede expensive geometric tests
with less expensive tests that allow the test to exit early, a so—called ”early out.”To
support inexpensive overlap tests, the boundingvolume must have a simple geomet—
ric shape. At the same time, to make the early—out test as effective as possible the
bounding volume should also be as tight fitting as possible, resulting in a trade—off
between tightness and intersection test cost. The intersection test does not necessarily
just cover comparison against volumes of the same type, but might also test against
other types of bounding volumes. Additionally, testing may include queries such as __7 ﬁ 4.2 Axis—aligned Bounding Boxes (AABBS) 77 BETTER BOUND, BETTER CULLING FASTER TEST, LESS MEMORY “annot SPHERE AABB 8DOP CONV EX HULL
inding Figure 4.2 Types of bounding volumes: sphere, axisaligned bounding box (AABB), oriented
bounding box (088), eightdirection discrete orientation polytope (8—DOP), and convex hull.
napter . . . . . . . . .
:onv ex pornt inclus1on, ray intersection With the volume, and intersection With planes and
ded in _ polygons.
Bounding volumes are typically computed in a preprocessing step rather than at
runtime. Even so, it is important that their construction does not negatively affect
resource build times. Some boundingvolumes, however, must be realigned at runtime i
when their contained objects move. For these, if the bounding volume is expensive 3
to compute realigning the bounding volume is preferable (cheaper) to recomputing
it from scratch.
_ Because bounding volumes are stored in addition to the geometry, they should
perties ideally add little extra memory to the geometry. Simpler geometric shapes require less
memory space. As many of the desired properties are largely mutually exclusive, no
specific bounding volume is the best choice for all situations. Instead, the best option
is to test a few different bounding volumes to determine the one most appropriate ; ‘
for a given application. Figure 4.2 illustrates some of the trade—offs among five of i ]
the most common bounding volume types. The given ordering with respect to better l
bounds, better culling, faster tests, and less memory should be seen as a rough, rather S
than an absolute, guide. The first of the bounding volumes covered in this chapter is
the axis—aligned bounding box, described in the next section.
ic tests _ _ . i ll
rut/’To 4.2 AXISaligned Bounding Boxes (AABBs) i 1;
zomet— Ii
ble the The axis~aligned bounding box (AABB) is one of the most common bounding volumes. ii (i
ide_0ff It is a rectangular six—sided box (in 3D, four—sided in 2D) categorized by having its ii i
assarily faces oriented in such a way that its face normals are at all times parallel with the il
against axes of the given coordinate system. The best feature of the AABB is its fast overlap “'
such as _ check, which simply involves direct comparison of individual coordinate values. ‘j 78 Chapter4 BaimdingVolumes (a) (b) (C) Figure 4.3 The three common AABB representations: (a) minmax, (b) minwidths, and
(c) center—radius. There are three common representations for AABBs (Figure 4.3). One is by the
minimum and maximum coordinate values along each axis: // region R = {(X, y, z) ! min.x<=x<=mux.x, min.y<=y<=max.y, min.z<=z<=max.z } struct AABB {
Point min;
Point max; This representation specifies the EV region of space as that between the two oppos~
ing corner points: min and max. Another representation is as the minimum corner
point min and the width or diameter extents dx, tit, and dz from this corner: // region R = {(X, y, z) tmin.x<=x<=min.x+dx, min.y<=y<=min.y+dy, min.z<=z<=min.z+dz} struct AABB {
Point min; float d[3]; // diameter or width extents (dx, dy, dz) The last representation specifies the AABB as a center point C and halfwidth
extents or radii 1m, 1y, and rz along its axes: // region R = {(x, y, z) } lc.x—Xi<=rx, lc.y—yt<=ry, c.z—zi<=rz } struct AABB {
Point c; // center point of AABB
float r[3]; // radius or halfwidth extents (rx, ry, rz) l5, and by the DPPOS—
corner .z+dz} lfwidth 4.2 Axis—aligned Bounding Boxes (AABBs) 79 In terms of storage requirements, the center—radius representation is the most
efficient, as the halfwidth values can often be stored in fewer bits than the center
position values. The same is true of the width values of the min—width representation,
although to a slightly lesser degree. Worst is the min—max representation, in which
all six values have to be stored at the same precision. Reducing storage requires
representing the AABB using integers, and not ﬂoats, as used here. If the Object
moves by translation only, updating the latter two representations is cheaper than
the min—max representation because only three of the six parameters have to be
updated. A useful feature of the center—radius representation is that it can be tested
as a bounding sphere as well. 4.2.1 AABBAABB Intersection Overlap tests between AABBs are straightforward, regardless of representation. Two
AABBs only overlap if they overlap on all three axes, where their extent along
each dimension is seen as an interval on the corresponding axis. For the min—max
representation, this interval overlap test becomes: int TestAABBAABB(AABB a, AABB b) {
// Exit with no intersection if separated along an axis
if (a.max[0] < b.min[0] [I a.m1'n[0] > b.max[0]) return 0;
if (a.max[1] < b.min[1] H a.m1'n[1] > b.max[1]) return 0;
if (a.max[2] < b.min[2] H a.m1'n[2] > b.max[2]) return 0;
// Overlapping on all axes means AABBs are intersecting
return 1; } The min—width representation is the least appealing. Its overlap test, even when
written in an economical way, still does not compare with the first test in terms of
number of operations performed: int TestAABBAABB(AABB a, AABB b)
{ float t; if ((t = a.min[0]  b.min[0]) > b.d[0] [I t > a.d[0]) return 0;
if ((t = a.m1'n[1]  b.min[1]) > b.d[1] [I —t > a.d[1]) return 0;
if ((t = a.m1'n[2]  b.min[2]) > b.d[2] H t > a.d[2]) return 0;
return 1; Chapter 4 Bounding Volumes Finally, the center—radius representation results in the following overlap test: int TestAABBAABB(AABB a, AABB b) { ,
if (Abs(a.c[0]  b.c[0]) > (a.r[0] + b.r[0])) return 0;
if (Abs(a.c[1]  b.c[1]) > (a.r[1] + b.r[1])) return 0;
if (Abs(a.c[2]  b.c[2]) > (a.r[2] + b.r[2])) return 0;
return 1; } On modern architectures, the Abs() call typically translates into just a single
instruction. If not, the function can be effectively implemented by simply stripping
the sign bit of the binary representation of the floating—point value. When the AABB
fields are declared as integers instead of ﬂoats, an alternative test for the center—
radius representation can be performed as follows. Mth integers, overlap between
two ranges [A, B] and [C, D] can be determined by the expression overlap = (unsigned int) (B  C) <= (8  A) + (D  C); By forcing an unsigned underflow in the case when C > B, the left—hand side
becomes an impossibly large value, rendering the expression false. The forced over—
ﬂow effectively serves to replace the absolute value function call and allows the center—radius representation test to be written as: int TestAABBAABB(AABB a, AABB b) { int r; r = a.r[0] + b.r[0]; if ((unsigned int) (a.c[0]  b.c[O] + r) > r + r) return 0;
r = a.r[1] + b.r[1]; if ((unsigned int) (a.c[1]  b.c[l] + r) > r + r) return 0;
r = a.r[2] + b.r[2]; if ((unsigned int) (a.c[2]  b.c[z] + r) > r + r) return 0;
return 1; > Working in integers allows other implementational tricks, many of which are archi—
tecture dependent. SIMD instructions, if present, typically allow AABB tests to be
implemented in just a few instructions worth of code (examples of which are found
in Chapter 13). Finally, in a collision detection system that has to perform a mas—
sive number of overlap tests it may be worthwhile ordering the tests according to
the likelihood of their being taken. For instance, if operations largely take place in
an almost flat xz plane the y—coordinate test should be performed last, as it is least discriminatory. WMMMWMWWWWMMMMM single
pping
AABB
enter—
tween ld side
1 over—
NS the ‘n 0;
*n 0;
‘n 0; e archi—
ts to be
3 found
a mas—
‘ding to
place in
is least 4.2.2 4.2 Axis—aligned Bounding Boxes (AABBS) 81 (b) (C) Figure 4.4 (a) AABBs A and B in world space. (b) The AABBs in the local space ofA. (c) The
AABBS in the local space of B. Computing and Updating AABBs Bounding volumes are usually specified in the local model space of the objects they
bound (which may be world space). To perform an overlap querybetween two bound—
ing volumes, the volumes must be transformed into a common coordinate system.
The choice stands between transforming both bounding volumes into world space
and transforming one bounding volume into the local space of the other. One benefit
of transforming into local space is that it results in having to perform half the work
of transformation into world space. It also often results in a tighter bounding volume
than does transformation into world space. Figure 4.4 illustrates the concept. The
recalculated AABBs of objects A and B overlap in world space (Figure 4.4a). However,
in the space of object B, the objects are found to be separated (Figure 4.4c).
Accuracy is another compelling reason for transforming one bounding volume
into the local space of the other. A world space test may move both objects far away
from the origin. The act of adding in the translation during transformation of the local
near—origin coordinates of the bounding volume can force many (or even all) bits of
precision of the original values to be lost. For local space tests, the objects are kept
near the origin and accuracy is maintained in the calculations. Note, however, that by
adjusting the translations so that the transformed objects are centered on the origin
world space transformations can be made to maintain accuracy as well.
Transformation into world space becomes interesting when updated bounding
volumes can be temporarily cached for the duration of a time step. By caching a
bounding volume after transformation, any bounding volume has to be transformed
just once into any given space. As all bounding volumes are transformed into the
same space when transforming into world space, this becomes a win in situations
in which objects are being checked for overlap multiple times. In contrast, caching
updated bounding volumes does not help at all when transforming into the local
space of other bounding volumes, as all transformations involve either new objects 82 Chapter4 Boundingiblumes or new target coordinate systems. Caching of updated bounding volumes has the
drawback of nearly doubling the required storage space, as most fields of a bounding
volume representation are changed during an update. Some bounding volumes, such as spheres or convex hulls, naturally trans~
form into any coordinate system, as they are not restricted to speciﬁc orientations.
Consequently, they are called nonaligned or (freely) oriented bounding volumes.
In contrast, aligned bounding volumes (such as AABBs) are restricted in what ori—
entations they can assume. The aligned bounding volumes must be realigned as
they become unaligned due to object rotation during motion. For updating or
reconstructing the AABB, there are four common strategies: 0 Utilizing a fixed—size loose AABB that always encloses the object 0 Computing a tight dynamic reconstruction from the original point set 0 Computing a tight dynamic reconstruction using hill climbing 0 Computing an approximate dynamic reconstruction from the rotated AABB The next four sections cover these approaches in more detail. 4.2.3 AABB from the Object Bounding Sphere The first method completely circumvents the need to reshape the AABB by making it
large enough to contain the object at any orientation. This fixed~size encompassing
AABB is computed as the bounding box of the bounding sphere of the contained
object A. The bounding sphere, in turn, is centered in the pivot point P that A rotates
about. Its radius r is the distance to the farthest object vertex from this center (as
illustrated in Figure 4.5). By making sure the object pivot P lies in the center of the
object, the sphere radius is minimized. The benefit of this representation is that during update this AABB simply need be
translated (by the same translation applied to the bounded object), and any object
rotation can be completely ignored. However, the bounding sphere itself (which has
a better sound than the AABB) would also have this property. Thus, bounding spheres
should be considered a potential better choice of bounding volume in this case. 4.2.4 AABB Reconstructed from Original Point Set The update strategy described in this section (as well as the remaining two update
strategies to be described) dynamically resizes the AABB as it is being realigned with
the coordinate system axes. For a tightly fitted bounding box, the underlying geometry
of the bounded object is examined and the box bounds are established by finding
the extreme vertices in all six directions of the coordinate axes. The straightforward
approach loops through all vertices, keeping track of the vertex most distant along has the
)unding trans—
ttations.
'olumes.
rhat ori—
gned as
ating or ArABB making it
npassing
ontained
A rotates
enter (as
:er of the I need be
ny object
Ithh has
g spheres
case. r0 update
,rned with
geometry
ty ﬁnding
itforwarcl
ant along 4.2 Axis—aligned Bounding Boxes (AABBS) 83 Figure 4.5 AABB of the bounding sphere that fully contains object A under an arbitrary
orientation. the direction vector. This distance can be computed through the projection of the
vertex vector onto the direction vector. For comparison reasons, it is not necessary
to normalize the direction vector. This procedure is illustrated in the following code,
which finds both the least and most distant points along a direction vector: // Returns indices imin and imax into pt array of the least and
// most, respectively, distant points along the direction dir
void ExtremePointsAlongDirection(Vector dir, Point pt, int n, int *imin, int *imax)
{
float minproj = FLT_MAX, maxproj = FLT_MAX;
for (int i = O; i < n; i++) {
// Project vector from origin to point onto direction vector
float proj = Dot(pt[i], dir);
// Keep track of least distant point along direction vector
if (proj < minproj) {
minproj = proj; L
‘*'im1'n = 1';
}
// keep track of most distant point along direction vector
if (proj > maxproj) {
maxprdj = proj;
*imax = i; 84 Chapter4 Boundingiblumes Figure 4.6 When computing a tight AABB, only the highlighted vertices that lie on the
convex hull of the object must be considered. When n is large, this C(71) procedure can be expensive if performed at runtime.
Preprocessing of the vertex data can serve to speed up the process. One simple
approach that adds no extra data is based on the fact that only the vertices on the
convex hull of the object can contribute to determining the bounding volume shape
(Figure 4.6). In the preprocessing step, all k vertices on the convex hull of the object
would be stored so that they come before all remaining vertices. Then, a tight AABB
could be constructed by examining these It first vertices only. For general concave
volumes this would be a win, but a convex volume, which already has all of its
vertices on its convex hull, would see no improvement. By use of additional, dedicated, precomputed search structures, locating extremal
vertices can be performed in O(logn) time. For instance, the Dobkin—Kirkpatrick
hierarchy (described in Chapter 9) can be used for this purpose. However, due to
the extra memory required by these structures, as well as the overhead in traversing
them, they have to be considered overkill in most circumstances. Certainly if tight
bounding volumes are that important, tighter bounding volumes than AABBs should
be considered. AABB from Hillclimbing Vertices of the Object
Representation Another way to speed up the AABB realignment process is to use an object rep~
resentation in which neighboring vertices of a vertex can be found quickly. Such a
representation allows the extreme vertices that deﬁne the new AABB to be located
through simple hill climbing (Figure 4.7). 9 on the untime. simple
l on the
e shape
e object
it AABB
concave
ill of its :xtremal
kpatrick
, due to
aversing
I if tight
5 should iect rep—
n Such a
2 located 4.2 Axis—aligned Bounding Boxes (AABBs) 85 (a) (b) Figure 4.7 (a) The extreme vertex E in direction d. (b) After object rotates counterclockwise,
the new extreme vertex E’ in direction d can be obtained by hill climbing along the vertex path
highlighted in gray. Instead of keeping track of the minimum and maximum extent values along each
axis, six vertex pointers are maintained. Corresponding to the same values as befo...
View
Full Document
 Spring '10
 Jhala,A

Click to edit the document details