# using per pixel collision for an elastic response

I realize this might be open ended ended but curious if I just did some over kill...

http://xbox.create.msdn.com/en-US/education/catalog/tutorial/collision_2d_perpixel

and i reworked it to work with my animation code in XNA and what not. It works well, but now I want to use this to decide if there was a collision and to have the items (characters) bounce off eachother elastically. Was the per pixel too much and I could of just used a bounding box ? (in fact would that of been preferred for what needs to be calculated in the response for an elastic collision?)

Looking for guidance really.

-

It depends on how much realism you are aiming for. There is generally a trade-off between realism and algorithm complexity. I recommend starting with the simplest algorithms, then adding complexity until the desired realism is achieved.

There are two parts to collision simulation that must be considered:

1. Collision detection: determining if two objects are touching
2. Collision response: deciding what happens to two objects that are touching

First, collision detection:

Of course, pixel-perfect collision detection gives nicer results, but at the cost of more processing power. This adds up because for N sprites, roughly N*N collision checks are needed. Recommended for sprites with complex collision areas that don't move particularly quickly.

Bounding box is computationally much cheaper, but will tend to give false-positive collisions, especially if you have funky shaped sprites. Two objects may be touching according to their bounding boxes, but visually they don't appear to touch. Recommended for (almost) rectangular shaped sprites and sprites that move very quickly (false-positives will be imperceptible).

A related test, bounding-circle, is slightly more computationally taxing than bounding box, and good for round-shaped sprites.

As Bloodyaugust recommended, it is wise to first test for a bounding box collision, then only execute a pixel-pixel perfect test when necessary.

Next, collision response:

In order to accurately model the angles objects rebound from a collision, the exact point of collision and the two collision surface normal vectors are needed.

Pixel-perfect tests can give a more accurate collision point than bounding box, but don't necessarily provide more information about the collision normal vectors. I would guess both pixel perfect and bounding box would estimate collision normal vectors based on the coordinates of the two colliding objects. They may not even use the actual point of collision when calculating the collision response. The collision response algorithm is not necessarily tied to the collision detection algorithm.

Finally, most physics-based game engines use something more accurate than pixel-perfect collision. (Even pixels are rough approximations of the actual objects they represent.) These engines model sprites with 2D/3D models that describe the objects in terms of geometrical shapes. Thus they can achieve sub-pixel accuracy!

I will close with a demo of a game that uses bounding-circle detection, and calculates the collision response based on exact point of collision (of the bounding circles) and the collision normal vectors. Make sure to press Backspace to see the behind-the-scenes bounding circle collision stuff: Leftium's Asteroids.

-

What you did is not necessarily overkill, but perhaps more work than you needed to do. Quick tip: use bounding boxes collision first, then use per-pixel after confirming a general area collision. It will save you a lot of processing.

-
the response is independent of the collision ? – Codejoy Jul 30 '12 at 21:54
What are you asking? That's not a very clear question. – Bloodyaugust Jul 30 '12 at 22:20