Loading in 5 sec....

CSE 380 – Computer Game Programming Collision Detection & ResponsePowerPoint Presentation

CSE 380 – Computer Game Programming Collision Detection & Response

Download Presentation

CSE 380 – Computer Game Programming Collision Detection & Response

Loading in 2 Seconds...

- 92 Views
- Uploaded on
- Presentation posted in: General

CSE 380 – Computer Game Programming Collision Detection & Response

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 - - - - - - - - - - - - - - - - - - - - - - - - - -

CSE 380 – Computer Game ProgrammingCollision Detection & Response

Erin Catto’s Box2D

- 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)

- 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

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

- 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]

- 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

- We can have 2 AABBs
- Don’t test them against each other

- First, reduce the problem
- only perform additional phases on pairs of object on same “islands”

- 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

- region coordinates for cell

- Source: http://en.wikipedia.org/wiki/Image:Octree2.png

- 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

- 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

- 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”

- only test against:

- For min/max tile rows/columns:

- 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

- 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

- 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

- 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

- 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

- determine potentially colliding primitives (ex: triangles) of a pair of objects
- Ref[3]
- CSE 381 will cover these things next fall

- 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 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

- 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

- 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

- What’s that?
- An object moves through another object because collision is never detected

- 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

- Swept shapes
- Potential problem: false positives
- Good really only for early rejection tests

- Calculate first contact times
- Resolve contacts in order of occurrence

- 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]

- 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

- 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

- 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

- 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

- 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

- 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