Swept-Polygon Collision Detection

Like most collision systems, Torque X detects collisions in two phases. First, broad-phase, early-out collision is very common in collision detection schemes. The goal is to very quickly determine objects that will definitely not collide with each other, so that you don't have to check these objects against each other in the next, much more expensive narrow-phase of exact object-object collision detection. Once Torque X is done deciding what objects definitely will not collide with each other, it has a much smaller (hopefully) list of objects which might possibly collide with each other. Torque X is then capable of performing swept-polygon collision detection, which can detect both overlapping objects, and disjoint objects which collide in forward-time.

Collision Polygons

Collision polygons can be applied to any object as either a regular polygon with any number of sides or a custom convex polygon. This means that you can define tight-fitted custom polygons for your sprites which are sized along with the sprite, making it possible to create nicely accurate collision systems while alleviating the need to constantly adjust the collision polygons.

Individual Collision Causation and Response

With Torque X, you can specify which objects you wish to collide with on a per object basis based on object type or based on what layer its on. You can also have objects collide with everything or nothing at all. Torque X does a lot of work making sure that your collisions are efficient so objects that should not be dealing with collisions do not check for collisions which reduces the process time spent on collisions. For example, you might turn off friendly fire by assigning objects on the same team and their projectile fire to the same layer, and turning off their collision with the team's layer. Collision detection is an expensive operation, and this can especially be true when you're dealing with accurate swept-polygon collision, as Torque X does. So, by specifying that an object should only collide with particular object types, you can reduce the collision search space substantially, speeding up the entire process.

Restrict Collisions Between Layers or Groups

Objects can also be assigned to layers, and to groups, and these layers and groups can be used in collision detection. For example, you might turn off friendly fire by assigning objects on the same team and their projectile fire to the same group, and turning off their collision with the team's group. Besides offering fine-grained control over the kinds of collisions you want different objects to have, this layer and group system also allows you to speed up collision detection. Collision detection is an expensive operation, and this can especially be true when you're dealing with accurate swept-polygon collision, as Torque X does. So, by specifying that an object should only collide with particular layers and groups, you can reduce the collision search space substantially, speeding up the entire process.

Collision Reactions

Objects can be configured with a collision delegate function to generate some sort of reaction upon collision. One obvious use of this system would be to generate explosions at the points of contact between two objects. Or, your collision script might implement its own custom physics processing system... maybe you want some of your objects to actually deform upon collision. Torque X comes with a variety of collision and physics responses, which are are free to used or you can use your own custom responses. The collision component works with the physics component seamlessly. For example a falling rock could have both the physics and collisions component enabled. When it is falling the physics system is at work but when it collides with the ground then collision component reports back to the physics component that there is a collision so the physics component produces a response. In this case it bounces and eventually comes to a stop on the ground.

Prototype-Based Configuration

Objects can be very precisely configured for various collision behaviors, and the system itself is very easy to extend or over-ride. Also, these settings can be pre-defined, so you can create prototype collision settings and share them across many objects, making it even quicker and easier to get collision set up.