cse 380 computer game programming collision detection response n.
Skip this Video
Download Presentation
CSE 380 – Computer Game Programming Collision Detection & Response

Loading in 2 Seconds...

play fullscreen
1 / 34

CSE 380 – Computer Game Programming Collision Detection & Response - PowerPoint PPT Presentation

  • Uploaded on

CSE 380 – Computer Game Programming Collision Detection & Response. Erin Catto’s Box2D. 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?

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'CSE 380 – Computer Game Programming Collision Detection & Response' - ramla

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
collision detection calculations
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)
phases of collision detection
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
common bounding volumes
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
bounding volumes
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]
assumptions for this semester
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
how about a big complicated object
How about a big, complicated object?
  • We can have 2 AABBs
    • Don’t test them against each other
spatial partitioning
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.
  • 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
  • Source: http://en.wikipedia.org/wiki/Image:Octree2.png
octree drawbacks
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
uniform grids
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
calculating grid position
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”
grid cell collision walkable surfaces
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
grid cell collision advantages disadvantages
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
object tests premise
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
broad phase
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
narrow phase
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
priori vs posteri
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
discrete vs continuous collision detection
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
time in between frames
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
axis separation tests
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







be careful of tunneling
Be careful of Tunneling
  • What’s that?
  • An object moves through another object because collision is never detected
a note about timing
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
one way to avoid tunneling
One way to avoid tunneling
  • Swept shapes
  • Potential problem: false positives
    • Good really only for early rejection tests
better way to avoid tunneling
Better way to avoid tunneling
  • Calculate first contact times
  • Resolve contacts in order of occurrence
continuous collision detection
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]
times as
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
% 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
what about 2 moving objects
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
so how do we calculate the when
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
what collision system should you use
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
physics timing
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)
  • [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