Per default, all collision objects collide with all other collision objects. It is often useful or required to disable collisions between collision objects or certain groups of collision objects. Examples:

• Two objects in a computer game describe static scenery, like two walls. It is not necessary to compute the contacts between this two objects. For this case, all static objects could be assigned to a collision group that should not collide with itself.
• Objects can pass through each other, for example, in many games avatars can walk through each other like ghosts. In this case the collision between the avatar collision objects should be disabled.
• In physics simulation two objects can be attached two each other using "joints". Most of the time the two connected objects should not collide with each other.

To disable all collision for an individual collision object the collision object can be disabled (see property Enabled).

The collision detection further uses filters at two points in the collision detection pipeline that define which objects can collide with each other and what contacts are computed.

Caution
Collision filters are not used in closest-point queries!

You can set a broad phase filter using the property Filter of CollisionDomainBroadPhase. Use the broad phase filter if the filtering rules are simple and do not change during the runtime of your application. For example, filtering of collisions between static objects is usually done in the broad phase.

Caution
Do not change the filter rules of a broad phase at runtime! Changing filter rules can invalidate the information that is cached in the broad phase, which slows down the broad phase. Use a narrow phase filter instead!

Narrow phase filters are set using the property CollisionDetectionCollisionFilter. Use the narrow phase filter if the filtering rules are complex or can change during the runtime of your application. For example, if a game character can drink a magic potion that allows him to go temporarily through walls, this would be best solved using a narrow phase filter because the filter rules are complex and subject to change.

Any class that implements IPairFilterT of CollisionObjects can be used as collision filter. DigitalRune Geometry contains two classes that implement this interface: DelegatePairFilterT and CollisionFilter. The first one calls a user defined callback method to filter collision object pairs. The second one has an internal table which enables or disables collisions between specific pairs of collision objects or collision groups (see CollisionGroup).

Some collision detection libraries or physics libraries have special support for static objects. Collision objects can be set to "static" which means that collisions between two static objects are not computed. This improves performance because a game level typically consists of many static objects.

DigitalRune Geometry has no "IsStatic" property for collision objects because for some applications it is necessary to compute collisions between "static" objects. Therefore, the meaning of "IsStatic" depends on the context in which the collision detection is used.

If a game level consists of many static objects and collisions between static objects should not be computed, you can use collision filtering to disable collision between static objects. For example, you can use the convention that all static objects use CollisionGroup 0 and dynamic objects use a collision group greater than 0. And in the collision filter you can disable collisions of group 0 with group 0.

Other options to control which objects can collide with which objects are:

• Put objects which should not collide into different collision domains (This improves performance as well.)
• Change the collision algorithm matrix if a pair of shape types should never collide in a specific application.

Reference

Other Resources