CSE 380 – Computer Game Programming Collision Detection & Response

1. CSE 380 – Computer Game ProgrammingCollision Detection & Response Erin Catto’s Box2D

2. Collision Detection Calculations • What data are we looking for? • Do these two objects potentially collide? • Do these two objects collide? • When did these two objects collide? • Where did these two objects collide? • where on geometry of objects, points of impact • These 4 questions get progressively: • more computationally expensive to implement • more complex to implement (more math)

3. Phases of Collision Detection • Spatial Partitioning Algorithms • problem reduction • only perform additional phases on pairs of object on same “islands” • Broad Phase – early rejection tests • Do the coarse Bounding Volumes of two objects collide? • Narrow Phase • Do the tight bounding volumes of two objects collide? • What are the contact points on object geometries? • Done down to the last triangle in 3D games

4. Common Bounding Volumes • Note that the space craft has been rotated • Ref: [1], Figure 4.2 • This semester, we like AABBs • axis-aligned bounding boxes

5. Bounding Volumes • The base geometry used for all collision tests • instead of the shape’s geometry, which is too expensive • Properties of desirable BVs: • inexpensive intersection tests • tight fitting • inexpensive to compute • easy to rotate and transform • use little memory • Ref: [1]

6. Assumptions for this semester • All sprites & game objects: • have rectangular Bounding Volumes (AABBs) • don’t rotate, or • if they do rotate, we don’t care about them colliding with stuff • Thus: • no polytope collision detection equations • no rotation equations • this makes life much easier

7. How about a big, complicated object? • We can have 2 AABBs • Don’t test them against each other

8. Spatial Partitioning • First, reduce the problem • only perform additional phases on pairs of object on same “islands” • Common Solutions: • Octree Algorithms (quadtrees for 2D) • Uniform Grid Algorithms • also: Portals (ala Quake), BSP trees (Binary Space Partitions), Spatial Hashing, etc.

9. Octrees • Used to divide a 3D world into “islands” • 2D divided via Quadtrees • Why? • to make rendering more efficient • to make collision detection more efficient • What would be the data for these nodes? • region coordinates for cell • though a smart implementation might eliminate this too • AABBs

10. Octree • Source: http://en.wikipedia.org/wiki/Image:Octree2.png

11. Octree Drawbacks • Objects cross islands • octree has to be constantly updated • not so bad • Objects straddle islands • collision detection may involve objects from multiple islands • can be a headache

12. Uniform Grids • Fast mechanism for reducing the problem • used for 2D & 3D games • Steps: • divide the world into a grid of equal sized cells • associate each object with the cells it overlaps • only objects sharing a cell are compared • Serves 2 purposes: • reduces the problem for sprite-sprite collision detection • provides solution for easy sprite-world collision detection

13. Calculating Grid Position • What cells does our sprite currently occupy? • How would you calculate that? • For min/max tile rows/columns: • sprite.X/tileWidth • sprite.Y/tileHeight • (sprite.X+sprite.Width)/tileWidth • (sprite.Y+sprite.Height)/tileHeight • For this guy, cells (0,0), (0,1), (1,0), & (1,1) • only test against: • other objects in those cells • collidable tiles in those cells (treat like objects) • don’t let sprites occupy “collidable cells”

14. Grid Cell Collision & Walkable Surfaces • Side-scrollers simulate gravity • not necessarily accelerated (constant velocity) • move all affected sprites down by dY • This way, characters can fall • We must detect when sprites are colliding with a floor/platform • Easy solution: make a tile with a walkable surface at the very top of the image • Collision system will handle response

15. Grid Cell Collision Advantages/Disadvantages • Advantages • easy to implement • very fast (computationally inexpensive) • Disadvantages • constrains look of game to grid-like world • Action Game alternative: • use this algorithm for some board collision detection • use other algorithms for other collisions • i.e. inclines

16. Object Tests Premise • Think of all collision tests as between pairs of collidable objects • In our games this means: • sprite object – to – game tile object • sprite object – to – sprite object • In a single game loop, for each sprite, we may have to check against • many other sprites • many other tiles

17. Broad Phase • Do the coarse AABBs of two objects collide? • Common solution: • separating axis algorithms • including temporal coherence • More sophisticated solution: • Sweep & Prune • an extension of separating axis, more efficient for many elements

18. Narrow Phase • What are the contact points on object geometries? • for 3D might be convex hulls • Two Steps • determine potentially colliding primitives (ex: triangles) of a pair of objects • AABB tree algorithms • determine contact between primitives • GJK algorithms • Ref[3] • CSE 381 will cover these things next fall

19. priori vs. posteri • Approaches to collision detection & response • Priori: check if something is going to collide before moving it, then make the necessary correction • Posteri: check if something has collided and make the necessary corrections

20. Discrete vs. Continuous Collision Detection • Discrete collision detection • perform collision detection at sampled instances of time (like end of frame) • can lead to tunneling problems • “contact data is obtained by computing the penetration depth of a collision” • Continuous collision detection • perform collision detection in continuous space-time • More on this in a moment

21. Time in between frames • We will make calculations and update velocities and positions at various times • When? • In response to: • input at start of frame • AI at start of frame • collisions/physics when they happen • likely to be mid-frame

22. Axis Separation Tests • How do we know if two AABBs are colliding? • if we can squeeze a plane in between them • i.e. if their projections overlap on all axes NO COLLISION COLLISION A C B D

23. Be careful of Tunneling • What’s that? • An object moves through another object because collision is never detected

24. A note about timing • If we are running at 30 fps, we are only rendering 1/30th of the physical states of objects • Squirrel Eiserloh calls this Flipbook syndrome [2] • More things happen that we don’t see than we do • We likely won’t see the ball in contact with the ground

25. One way to avoid tunneling • Swept shapes • Potential problem: false positives • Good really only for early rejection tests

26. Better way to avoid tunneling • Calculate first contact times • Resolve contacts in order of occurrence

27. Continuous Collision Detection • For each moving object, compute what grid cells it occupies and will cross & occupy if its current velocity is added • Find the first contact time between each object pair that may occupy the same grid cells • Sort the collisions, earliest first • Move all objects to time of first collision, updating positions • Update velocities of collided objects in pair • Go back to 1 for collided objects only • If no more collisions, update all objects to end of frame • Ref[3]

28. Times as % • You might want to think of your times as % of the frame • Then correct positions according to this % • For example, if I know my object is supposed to move 10 units this frame (we’ve locked the frame rate), if a collision happens ½ way through, move all affected objects ½ distance of their velocity and recompute collisions data for collided data • Re-sort collisions and find next contact time

29. % Example • A at (1, 5), velocity of (4, -3) • B stationary at (4, 4) • When will they collide? • When A goes one unit to the right • How long will that take? • If it takes 1 frame to go 4 units, it will take .25 frames to go 1

30. What about 2 moving objects? • Solution, give the velocity of one to the other for your calculations • make one of them stationary • then do the calculation as with grid tiles • make sure you move both objects • make sure you update the velocities of both objects

31. So how do we calculate the when? • We can do it axis by axis • What’s the first time where there is overlap on all 3 axes? • For each axis during a frame, what is the time of first and last contact? • txf, txl, tyf, tyl • When is the time of collision? • first moment tx and ty overlap

32. What collision system should you use? • AABB for each collidable object • Velocity vector for each dynamic object • Uniform Grids for problem reduction • Continuous Collision Detection • using method of separating axis algorithm • momentum equations for collision responses • if necessary • pweep and prune for efficiency

33. Physics & Timing • Christer Ericson & Erin Catto’s recommendations: • physics frame rate should be higher resolution than rendering • minimum of 60 frames/second for physics calculations • makes for more precise, and so realistic interactions • How do we manage this? • tie frame rate to 60 fps, but don’t render every frame • don’t worry about this for now • Note: these operations might commonly be done in different threads anyway (have their own frame rates)

34. References • [1] Real Time Collision Detection by Christer Ericson • [2] Physics for Game Programmers by Squirrel Eiserloh • [3] Collision Detection in Interactive 3D Environments by Gino van den Bergen