Comparison of Collision Detection Algorithms Tony Young M.Math Candidate July 19th, 2004

Outline Collision Detection Background –What is collision detection? –Applications and Importance Detection Algorithms –Bounding Boxes –Bounding Spheres –BSP Trees –Hubbard

What is Collision Detection? Collision detection is the processing of two object’s bounds to determine if those bounds intersect at any time, t Collision detection is a difficult problem to solve in constant or linear time Collision detection schemes are used in many applications

Applications and Importance Marine, Land and Air navigation –Detecting if/when collisions between two vehicles will take place –Aiding in avoiding collisions with alerts to captains, drivers and pilots

Applications and Importance Accident Alerts –Automatically notifying police of collisions at intersections, on highways, etc. –Aids in response time and provides details as to the speed of collision, etc. –Potentially saves lives!

Applications and Importance Graphics Rendering –Important for rendering a scene –We want realistic things to happen

Applications and Importance Simulation –Simulations should be as accurate to life as possible –Objects move according to impacts

Applications and Importance Animation –In order to properly render animations we must know when fabrics are pulled tight against bodies, items are resting on tables, etc. –Lifelike animation requires lifelike modeling of collisions, and this requires collision detection

Applications and Importance Computer Games –In order to determine when a player is hit, or how an object should move in a scene, collisions must be detected

Applications and Importance Overriding themes –Safety –Entertainment –Research –Three opposites, but both very important to our current value system in North America

Bounding Boxes Place a box around an object –Box should completely enclose the object and be of minimal volume –Fairly simple to construct Test intersections between the boxes to find intersections

Bounding Boxes Each box has 6 faces (planes) in 3D –Simple algebra to test for intersections between planes –If one of the planes intersects another, the objects are said to collide

Bounding Boxes Example bounding boxes

Bounding Boxes Space complexity –Each object must store 8 points representing the bounding box –Therefore, space is O(8) and Ω(8)

Bounding Boxes Time complexity –Each face of each object must be tested against each face of each other object –Therefore, O((6n) 2 ) = O(n 2 ) n is the number of objects

Bounding Boxes Pro –Very easy to implement –Very little extra space needed Con –Very coarse detection –Very slow with many objects in the scene

Bounding Spheres Similar to bounding boxes, but instead we use spheres –Must decide on a “center” point for the object that minimizes the radius –Can be tough to find such a sphere that minimizes in all directions –Spheres could leave a lot of extra space around the object!

Bounding Spheres Each sphere has a center point and a radius –Can build an equation for the circle –Simple algebra to test for intersection between the two circles

Bounding Spheres Example bounding spheres

Bounding Spheres Space complexity –Each object must store 2 values - center and radius - to represent the sphere –Therefore, space is O(2) and Ω(2) –Space is slightly less than bounding boxes

Bounding Spheres Time complexity –Each object must test it’s bounding sphere for intersection with each other bounding sphere in the scene –Therefore, O(n 2 ) n is the number of objects –Significantly fewer calculations than bounding boxes!

Bounding Spheres Pro –Even easier to implement (than bounding boxes) –Even less space needed (than bounding boxes) Con –Still fairly coarse detection –Still fairly slow with many objects

BSP Trees BSP (Binary Space Partitioning) trees are used to break a 3D object into pieces for easier comparison –Object is recursively broken into pieces and pieces are inserted into the tree –Intersection between pieces of two object’s spaces is tested

BSP Trees We refine our BSP trees by recursively defining the children to contain a subset of the objects of the parent –Stop refining on one of a few cases: Case 1: We have reached a minimum physical size for the section (ie: one pixel, ten pixels, etc) Case 2: We have reached a maximum tree depth (ie: 6 levels, 10 levels, etc) Case 3: We have placed each polygon in a leaf node Etc… - Depends on the implementer

BSP Trees Example BSP Tree

BSP Trees Example BSP Tree

BSP Trees Example BSP Tree

BSP Trees Example BSP Tree

BSP Trees Collision Detection –Recursively travel through both BSP trees checking if successive levels of the tree actually intersect If the sections of the trees that are being tested have polygons in them: –If inner level of tree, assume that an intersection occurs and recurse –If lowest level of tree, test actual intersection of polygons If one of the sections of the trees that are being tested does not have polygons in it, we can surmise that no intersection occurs

BSP Trees Collision Detection Example

BSP Trees Collision Detection Example

BSP Trees Collision Detection Example

BSP Trees Collision Detection Example

BSP Trees Collision Detection Example

BSP Trees Space Complexity –Each object must store a BSP tree with links to children –Leaf nodes are polygons with geometries as integer coordinates –Therefore, space depends on number of levels of tree, h, and number of polygons (assume convex triangles - most common), n –Therefore, space is O(4 h + 3n) and Ω(4 h + 3n)

BSP Trees Time Complexity –Each object must be tested against every other object - n 2 –If intersection at level 0, must go through the tree - O(h) Assume all trees of same height –Depends on number of intersections, m –Therefore, O(n 2 + m*h) and Ω(n 2 )

BSP Trees Pros –Fairly fine grain detection Cons –Complex to implement –Still fairly slow –Requires lots of space

Hubbard Makes use of Sphere Trees and Space- time Bounds to iteratively refine it’s accuracy Two phases –Broad Phase: constructs space-time bounds and does coarse comparisons –Narrow Phase: run only if broad phase detects a collision; refines detection to determine if there really was a collision

Hubbard - Broad Phase Constructs space-time bounds –4D structure giving conservative estimate of where objects might be in the future Finds intersections between space-time bounds at time t i for objects O 1 & O 2 –Can stop processing until t i arrives

Hubbard - Broad Phase –At t i, checks O 1 & O 2 ’s bounding spheres to determine if an intersection occurs –If yes, refers objects to narrow phase –If no, recalculate space-time bounds and start again

Hubbard - Narrow Phase Progressively refines intersection test accuracy –Uses better approximations to O 1 and O 2 through the constructed sphere trees –Each level of a sphere tree fits object more tightly –Can recursively check for intersections on small parts of the tree

Hubbard - Narrow Phase Allows system to interrupt algorithm after each iteration –System gets as accuracy proportional to amount of computing time it can spare Narrow phase terminates when –Case 1: System interrupts: current result is final –Case 2: Finds no intersection at a sphere tree level –Case 3: Hits sphere tree leaves: Intersection

Hubbard - Example Start System –Construct Sphere Trees –Run scene Broad Phase on Frame 1 –Calculates space-time bounds –Finds intersection between O 1 and O 2 at t i = 5 Run scene to Frame 5

Hubbard - Example Broad Phase on Frame 5 –Detects no collision on bounding spheres –Calculates space-time bounds –Finds intersection between O 2 and O 3 at t i = 7 Run scene to Frame 7

Hubbard - Example Broad Phase on Frame 7 –Detects collision on bounding spheres Narrow Phase on Frame 7 for O 2 & O 3 –Detects collision on level 1 spheres –Detects collision on level 2 spheres –Detects no collision on level 3 spheres Exit case 2

Hubbard - Example Broad Phase on Frame 8 –Calculates space-time bounds –Finds intersection between O 3 and O 4 at t i = 10 Run scene to Frame 10

Hubbard - Example Broad Phase on Frame 10 –Detects collision on bounding spheres Narrow Phase on Frame 10 for O 3 and O 4 –Detects collision on level 1 spheres –Detects collision on level 2 spheres –Detects collision on level 3 spheres –No more levels - collision detected Exit case 3

Hubbard - Example Broad Phase on Frame 11 –Calculates space-time bounds –Finds intersection between O 4 and O 5 at t i = 12 Run scene to Frame 12

Hubbard - Example Broad Phase on Frame 12 –Detects collision on bounding spheres Narrow Phase on Frame 12 for O 4 and O 5 –Detects collision on level 1 spheres –Detects collision on level 2 spheres –Detects collision on level 3 spheres –Interrupted by system - collision currently detected Exit case 1

Hubbard - Problem! Collision may not be present further down the tree –Collision is reported anyway because system interrupted without narrow phase completing –Leads to false positives

Hubbard - Space-Time Bounds Space-time bounds are 4D structures –represent object’s possible location in 3D over time System knows –Object’s position - p(x,y,z) –Object’s velocity - v(x,y,z) –Object’s acceleration - a(x,y,z) –Value, M, such that | a(t) | ≤ M until t = t j

Hubbard - Space-Time Bounds Then, we know that p is subject to the inequality | p(t) - [p(0) + v(0)t] | ≤ (M / 2)t 2 Thus, object’s position is inside a sphere of radius (M / 2)t 2 centered at p(0) + v(0)t

Hubbard - Space-Time Bounds - Example Position of p at t = 0

Hubbard - Space-Time Bounds - Example Possible position of p at t = 0.1

Hubbard - Space-Time Bounds - Example Possible position of p at t = 0.2

Hubbard - Space-Time Bounds - Example Possible position of p at 0 ≤ t ≤ 1

Hubbard - Space-Time Bounds - Example Possible enclosing hypertrapezoid

Hubbard - Space-Time Bounds This approximation results in large amounts of conservatism –Hypertrapezoid bounds areas that object could never occupy If we know that acceleration is limited to a certain directional vector, d(t), we can generate a cutting plane behind object’s position

Hubbard - Space-Time Bounds Cutting plane –allows us to reduce the size of the hypertrapezoid –Allows us to make more accurate broad phase detections –Requires application to provide d(t)

Hubbard - Space-Time Bounds A complete space-time bound, B, requires –Application provided M –Application provided d(t) –Calculated hypertrapezoid - T –Calculated cutting plane - P

Hubbard - Space-Time Bounds - Example Possible complete space-time bound

Hubbard - Using Bounds How do we use space-time bounds? –Recall: If they intersect, we have detected a coarse collision Intersection of bound B 1 and B 2 can happen in three ways: –(1) A face, f 1, of T 1 intersects a face, f 2, of T 2

Hubbard - Using Bounds Intersection of bound B 1 and B 2 can happen in three ways: –(2) A face, f, of a T intersects a cutting plane, P, of a T Object can never be behind the cutting plane Only care about part of f in front of P To get in front of P, f must intersect another face Only care about intersection of two faces

Hubbard - Using Bounds Intersection of bound B 1 and B 2 can happen in three ways: –(3) A cutting plane, P 1, of T 1 intersects a cutting plane, P 2, of T 2 Object can never be behind the cutting plane Only care about part of P 1 in front of P 2 and vs. To get in front of P 1, a face from T 1 must intersect a face from T 2 Only care about intersection of two faces

Hubbard - Using Bounds Reduced three cases of intersection to one that we care about How do we find intersections? –Projection –Subdivision

Hubbard - Finding Intersections Relies on three axioms (proved in papers, not here) –Each face f of a hypertrapezoid T is “normal” to one of the axis of the coordinate system –Each face f is included in a face set, F a = { f | f is normal to axis a}, a in {x, y, z} –Each intersection takes place between two faces in the same F a

Hubbard - Finding Intersections Algorithm can test each combination in each face set

Hubbard - Finding Intersections: Projection Step 1: Project each face in a face set, F a, onto the a-t plane. –Faces will appear as 2D lines on the plane –Intersection of these lines is necessary but not sufficient for an intersection of two faces

Hubbard - Finding Intersections: Projection Step 2: Find intersections between 2D line segments –Trivial algebra and mathematics –Keep track of each intersection, I, as a set of intersecting faces, and the point on the t plane where they intersect

Hubbard - Finding Intersections: Projection Step 3: Check intersection of cube cross-sections of the hypertrapezoids that the two faces in I belong to at time t –Trivial algebra and mathematics –If intersection no longer present, drop faces –If intersection still present, keep faces

Hubbard - Finding Intersections: Projection Step 4: Determine if point of intersection is behind a cutting plane for either hypertrapezoid –If so, intersection is discarded –If not, intersection is real and is reported Remember: We are only interested in the EARLIEST intersection!

Hubbard - Projection Example

Faces in the 3D plane

Hubbard - Projection Example Faces projected onto t-z plane

Hubbard - Projection Example Projections intersect at t=1

Hubbard - Projection Example Cube cross-sections intersect

Hubbard - Projection Example Intersection below cutting plane

Hubbard - Finding Intersections: Subdivision Recoursively divide hypertrapezoids into 3D cubes along the t-axis –Test for intersections between any pair of cube faces in 3D –If there is an intersection, subdivide the cubes and check again Aim is to find time t at which intersection takes place –Base case is an application-provided ∆t

Hubbard - Subdivision Example Check first section

Hubbard - Subdivision Example Intersection: subdivide

Hubbard - Subdivision Example Intersection: subdivide again

Hubbard - Subdivision Example ∆t reached with intersection at t=1

Hubbard - Projection vs. Subdivision Projection is more difficult to implement Subdivision might suffer from false positives due to bad ∆t Projection executed faster during empirical tests and is thus used in the final version of the algorithm –Tests used 200 sets of randomly distributed hypertrapezoids of varying parameters (ie: position, velocity, etc.)

Hubbard Space-time bounds are nice, but are only half the equation We need sphere trees for each object in the scene in order to run our narrow phase

Hubbard - Sphere Trees Sphere trees are a constant refinement of a bounding sphere for an object –An object is represented as a set of overlapping spheres –The overlapping spheres are represented as a set of tighter overlapping spheres, etc. until we reach the application’s requested accuracy level

Hubbard - Sphere Trees –Progressively more spheres are used at each level of the tree in order to approximate the object closer –The spheres at level i + 1 more tightly cover the area that the spheres at level i cover –Spheres are very easy to compare for intersection

Hubbard - Sphere Trees - Example Level 0: the root

Hubbard - Sphere Trees - Example Level 1

Hubbard - Sphere Trees - Example Level 2: etc…

Hubbard - Sphere Trees Accuracy of sphere tree, or “tightness of fit”, is important to ensure that we have proper accuracy –Algorithm could stop narrow phase at any point –Want to make sure that we have the most accurate detection possible to that point

Hubbard - Sphere Trees Construction of sphere tree is a form of multiresolution modeling –Very complex task –Tough to automate efficiently Many algorithms –We will look at Medial-Axis Surface method

Hubbard - Sphere Trees Medial-axis surface –Corresponds to the “skeleton” of an object –Difficult to build for a 3D polyhedron Algorithm works backwards –Covers the object with tightly fitting spheres first –Combine spheres into larger ones at next step –Sphere tree is constructed bottom-up

Hubbard - Sphere Trees Start by making the smallest sphere that covers an area of the object and touches it at eight points –Repeat until the entire object is enclosed in these spheres Continue by combining adjacent spheres into larger ones –Stop when we combine all remaining spheres into one large sphere

Hubbard - Sphere Trees - Example Possible first computation of medial-axis surface algorithm

Hubbard - Problem This process takes a HUGE amount of time! –An object with 626 triangles took 12.4 minutes to generate a sphere tree! –Note that sphere trees are also constructed prior to running the scene

Hubbard - Putting it all together Take scene as input –Object models –Values of M and d(t) Generate sphere tree for each object Calculate first space-time bound –Calculate hypertrapezoid and cutting plane –Calculate t i where first intersection takes place Start scene and broad/narrow phase testing

Hubbard - Example Sample scene

Hubbard - Example Sphere trees

Hubbard - Example Initial space-time bound

Hubbard - Example Initial intersection

Hubbard - Example Initial intersection above cut plane: t i =5

Hubbard - Example Run scene to t=5 Recalculate space-time bounds –Still intersects Run narrow phase at t=5

Hubbard - Example Sphere trees intersect at level 0

Hubbard - Example Sphere trees intersect at level 0

Hubbard - Example Sphere trees intersect at level 1

Hubbard - Example Sphere trees intersect at level 2

Hubbard - Example No levels left - intersection reported Could have exited if application interrupted us –Since we had an intersection at each level, we would have reported an intersection Could have exited if we found no intersection at a lower level –We had no lower levels to resort to

Hubbard - Evaluation Tested against Turk’s method which tests for intersections between spheres stored in BSP trees (no space-time bounds) –If detections are found very early in the simulation (before 0.25 sec), Hubbard is slower than Turk –Otherwise, Hubbard experiences a detection speed boost of approximately 10 times over Turk

Hubbard - Evaluation Speed-up in % over Turk’s BSP trees –Mean speedup is % –Level is tree level (their 1 = example 0) –Number is of cases to reach that level

Hubbard - Evaluation Space Complexity –Each object has One Hypertrapezoid - 4 D = 16 points One Sphere Tree - 2 h links with 2 h spheres (2 h *(2 points)) One set of direction and acceleration vectors - 2 points One set of bounding values (M and d(t)) - 2 values –Object’s structures do not depend on each other –Therefore, space is O(2 h + 4 h + 20) and Ω(2 h + 4 h + 20)

Hubbard - Evaluation Time Complexity –Broad Phase Must compare each face in each set to each other face in each set - O(3(2n) 2 ) = O(n 2 ) - and - Ω(1) –n is the number of objects –Narrow Phase Must compare spheres in the sphere tree for the two colliding objects - O(m) - and - Ω(1) –m is the number of levels of sphere tree compared –Therefore, time is Ω(1) and O(n 2 + m) per run of detection algorithm

Hubbard - Conclusions Algorithm allows average-case real-time collision detection Faster than Turk’s algorithm (previously thought to be the best) May have false positives if application interrupts processing too early in narrow phase (doesn’t get far enough down the tree) Constructing sphere trees is slow

Summary Collision detection is a difficult problem –Many different strategies –Most based on object models –Tough to do in real time Collision detection strategies have not progressed significantly –Some small advances in speed and space –No major new developments Most focus is now on collision detection through image processing

Summary Bounding Boxes –Space but not time efficient –Very inaccurate detection –Not real-time Bounding Spheres –Space but not time efficient –Relatively inaccurate detection –Not real-time

Summary BSP Trees –Inefficient in time and space –Quite accurate detection –Not real-time Hubbard –Relatively efficient in time but not space –Highly accurate detection –Not real-time (but can be close)

Summary The clear winner depends on the application –Hubbard performs best for most “real world” applications where objects are known ahead of time (ie: games, animation, ATC, etc.) –BSP trees are good for objects that are not known ahead of time (ie: auto collision –Bounding boxes / spheres are good for objects of that approximate shape, or for very fast detection (ie: primitive games, primitive scene animation)

Questions?