# Sensor based vs. AABB based collision

I'm trying to write a simple collision system, which will probably be primarily used for 2D platformers, and I've been planning out an AABB system for a few weeks now, which will work seamlessly with my grid data structure optimization. I picked AABB because I want a simple system, but I also want it to be perfect.

Now, I've been hearing a lot lately about a different method to handle collision, using sensors, which are placed in the important parts of the entity. I understand it's a good way to handle slopes, better than AABB collision.

The thing is, I can't find a basic explanation of how it works, let alone a comparison of it and the AABB method. If someone could explain it to me, or point me to a good tutorial, I'd very much appreciate it, and also a comparison of the advantages and disadvantages of the two techniques would be nice.

-
Sensors are often AABB or Spheres, the terminoligy is in reference to how they are treated in a physics simulator such as Box2D. Often people will use multiple smaller boxes to make a more accurate representation of a larger box. Sensors are used with physics simulators because they don't respond to contact and simply pass though things only change thier state of no collsion or collision. This can be used to alter the players positioning to push them out of walls for very basic collsion handling instead of a simulated responce. – ClassicThunder Jun 26 '13 at 18:15
But anyways it is kinda hard to answer your question because you are asking for a comparison between a way to represent shaps and how a shape should interect with the world. If you ask what are sensors and how to use them for 2d platformer physics I'm sure you can get an excelent answer. If you want to know how the math behind AABB search around a bit and if you find no such question (I seem to remeber a few though) alter your question to ask that. – ClassicThunder Jun 26 '13 at 18:20

The basic concept, used for many years now, is to just send out ray (really, line segment) queries from your character. If the character has gravity applies or is moving donwards, shoot two rays from the bottom two corners of the character's collision box and see if anything is close. You can react differently depending on which of the two registers a hit.

You may need to experiment with the number of rays, the distance cut-off (how long of a line segment you're checking), and the exact placement. Putting them at the exact corners may be problematic, but putting them some number of pixels "in" from the corners may work better. You may want a third ray in the middle. Etc.

One nice effect of this is that, since you use a ray cast and not generic SAT, you can handle collisions nicer. With SAT you often get a sliding effect on slopes. You also can't automatically deal with characters running down a slope super well (they'll end up bouncing a bit; you can see this in modern 3D games, too, like Fallout) with plain SAT/bounding volumes.

Another benefit is that with the rays you can tell if only one side of the character is off a ledge and do a different "balancing on a ledge" animation (e.g., Sonic).

Lastly, with the rays you can get continuous collision (you can see if a collision is about to happen and when rather than resolving it after a collision). This has uses in many cases (e.g., the sliding-on-slopes problem I mentioned) and helps to avoiding tunneling of high-speed objects without using small time steps - just lengthen your rays.

You can use these rays when jumping or running, too. It's way better to send out a ray and know that your character can't walk left than to move left and then be pushed out of the wall. In the latter, you'll end up with a silly "running while against a wall" animation, you aren't able to easily have box pushing or the like, and so on. The rays let you know "can't run left, don't even animate running" as well as "to the left is a box, do push animation if it can move".

-
Interesting. Technically, I could send out a ray with the direction and magnitude of the velocity vector, and also figure out the best points to send the ray out of on the fly. I just have to figure out a way to integrate it into my grid based system. Thanks! – Hillel Jun 26 '13 at 18:53
OK, now my problem is one I was struggling with even in the purely AABB system. Since it's the only one I can find in this method, that's not too bad. Say I want to check collision for every cell the player might be passing through, I would need to figure out which tiles the ray intersects. That shouldn't be too bad, but the thing is, I need more than that- I need to calculate the cells for the whole AABB of the player. Maybe it could be done by sending additional rays from his corner points? Well, I'll figure it out. – Hillel Jun 26 '13 at 19:20
Using the AABB for tile-overlapping works just fine. It's the actual physics where the rays come in handy. – Sean Middleditch Jun 26 '13 at 20:28
For the rays themselves, your ray/line test system needs to handle tiles on its own, using e.g. Bresenham's or something a bit simpler and more specialized to the task. It need to take the starting position to calculate a starting tile and can then calculate which of tile's edges it will collide with given its position in the tile and direction, and then you can calculate the next tile (and the collision point is the new starting point in that new tile). – Sean Middleditch Jun 26 '13 at 20:52
Yeah, that's how I solved it. And it turns out that casting rays from the AABB corners does the trick as well, solving that problem. Now I only have to find out which of the object's edges the player is going to collide with, and I think I have an idea how to do that, using linear algebra. Anyway, I'm kinda new to this site- if I wanna post the algorithm when I finish it, do I answer my own question? Or do I add it to the question body? – Hillel Jun 27 '13 at 5:57