Can someone explain per-pixel collision detection?

Question

Can someone explain the pros and cons of it and any math involved with it?

Answer 1

It's more accurate than vertexes (or hit-boxes etc). I'm assuming you're talking about 2d here (3d would be box-model vs vertex). Per-pixel would allow you to have detailed sprites which small things (missiles, say) would collide with more realistically.

It's more math and slower than the conventional method, which would be to draw a box (or some other easily math shape like a circle) and say 'this is the actor, anything in here is he'. It is however, more accurate.

Answer 2

For 2D: You do not need any math for this problem, you need only a custom bitblit-routine. You will blit collision candidates into a hidden surface by painting their collisionmasks onto this surface and checking, if the pixels you just want to draw are (pixel != 0) . Then you will have a collision. Of course, you should precheck by bounding rectangles if an collision can occur.

For 3D: You will need math(a lot)!

basically you will check each surface of your actor against each surface of your enemy. This will be done by calculating a plane-ray intersection. There is a lot of optimization possible here, but it depends on your 3d representation. This is also no Per-Pixel-Collision, but Per-Vertex-Collision

Answer 3

The pros have already been mentioned: It’s pixel-perfect and fair, there are no false positives nor false negatives. The main disadvantage is that it’s expensive to compute, but if You do a simple bounding box check first, this should not be a big problem. In the age of OpenGL and DirectX there is one more problem: The sprite data are usually textures, which means they are in the VRAM and You cannot check the pixel values easily Yourself. In OpenGL You can use the glReadPixels function to get the intersected portion of two sprites back to RAM and check the collision, or You can use the occlusion query. The occlusion query approach should have better performance, as You are not moving data back from GPU, but occlusion queries are not supported everywhere (ie. they are not supported in OpenGL ES, somebody please correct me if I am wrong).

Answer 4

When talking pros and cons you also have to consider collision response. What do you want to do when a collision is detected? If you're detecting an object hitting another object where the result is one or both of the objects being destroyed, then per-pixel collision detection is good and accurate. If you want the object to react in some other way, i.e. sliding against a wall, bouncing, etc... then you may want to work with some type of bounding rectangle/circle/oval which will make the collision response seem smoother and more consistent, with less chance of getting stuck.

Answer 5

taking about OpenGL and the texture-case: you could precalculate a bit matrix for the image and test if two pixels are overlapping.

Answer 6

Per-pixel collision detection is a relic from the past, when graphics was simple and 2D hardware included free collision checking between sprites and backgrounds. While todays 2d graphics is more complex, per-pixel collision checks are rarely used, especially because object visible shape and collision shape are usually different. Circles or boxes are sufficient for most cases. Also, since opengl-based graphics hardware can't do collision check anymore, you have to write additional rendering code, using CPU for sole purpose of collision checking, while keeping additional bitmap data in system memory, since graphics memory cannot be accessed directly.