Physics is a vast field ranging from simple kinematic physics to full dynamic rigid or soft body physics. The Drag[en]gine tries to provide a simple yet flexible system to deal with all these different kinds of physics. This topic has two major audiences. The first audience are the physics module programmers. Their interest is in adapting their level of physics simulation to the game engine. You are free to implement as much of the physics as you see fit. There are just a few things which are required to work for the module to be usable. The second audience are the scripting module programmers. They have to provide a wrapping of the physics system to be used by the game programmer. Depending on the use of the scripting module only a subset of the functionality can be exposed to the game scripts. The last group are the game developers itself. Their choice of scripting module already dictates to a large degree how they work with the physics. Nevertheless the basic system stays the same.
Colliders are the basic building stone of the physics system. No matter if used for kinematic or dynamic physics simulation they are the most important matter to understand. A collider is basically a physics body. It has no visual appearance only a shape of some kind and physical properties. The physics module takes care of doing all the physical simulation itself while delegating some kinematic physics tasks to the game scripts where required. Colliders exists in various flavors depending on the task at hand. Common for all colliders are the physical properties and the geometry information like position and orientation. The orientation is given as a quaternion. The physical properties are described below. First the description of the individual collider types.
Collider volumes are the most simple colliders and consist of a list of Shapes defining the collider shape. Collider volumes are therefore a simple rigid body with a shape that does not change ( usually ). A typical example would be a box prop. Most of the time one shape is enough to define the collider shape but sometimes you need more. Try to stick to boxes and spheres as they are the fastest shapes around. You can also use a collision mesh if the analytical shapes can not do the trick. Analytic shapes are though always faster than a collision mesh so use them whenever possible to improve performance.
Collider volumes are also best used for kinematic physics as well as collision testing related to AI.
Collider components are more complex than collider volumes. Using a component they are best used for skeletal animations and simulations. The rig assigned to the component is used to build multiple rigid bodies with individual Shapes as well as joints between them. Ragdoll physics is one possible use of this collider type. Rig files define the layout of the collider component parts and can be edited using the Rig Editor. The collider component uses the bone state of the assigned component. During simulation these bone states are updated. Therefore you can use the same component you use for rendering with a collider component and both are synchronized. Therefore if you want to use dynamic physics on the collider component you should not manipulate the bone states of the assigned component using Animators.
Collider rigs are similar to collider components in that they use a rig but since they have no assigned component they store the bone states themselves. Hence they behave the same as collider components with the additional benefit that you can use only a rig without requiring an entire component. This can be useful for AI where the rig is supposed to influence where the actor walks to but the rig in question is not made to be used by a component or model at all. You can use the Rig Editor to edit the rig files used to drive the collider rig. Since Animators only operate on components there is no need to pay attention to not use them.
One of the strength of the collider system is that you can attach positional resources to colliders at runtime. This way you can build complex game entities composed of multiple individual colliders with resources attached to them. The game scripts do not have to worry about moving collider with their attached resources since the physics module takes care of this. Resources can be attached using one of the various ways. Each has different a different use. The following types of resources can be attached:
State attachments are the most easy ones. You specify a position and orientation relative to the parent collider coordinate system. The physics module then ensures that the resource always keeps the same position relative to the collider. Therefore the resource is attached statically to the parent collider. A typical use is to attach a prop to a another prop like an arrow to a box it has been shot into. If you use a Constraint then the attached prop can move according to this constraint. Otherwise it does not change it's position relative to the parent collider.
Bone attachments are similar to static attachments with the only difference that they are relative to a bone in the parent collider instead of the parent collider itself. If the bone in question does not exist the bone attachment behaves like a static attachment. Bone attachments are typically use to attach props to an actor like attaching a flashlight to the hand of an actor. If you use a Constraint then the attached prop can move according to this constraint. The constraint base is then affected by the bone.
Weight attachments work similar to bone attachments with the only difference that more than one bone can be specified. Each bone has a weight assigned. Therefore the position relative to each bone is weighted and then summed up. A typical example would be to stick a prop to an actor like an arrow to an actor. Since models have various bone weights used the attached arrow can not be attached to one bone alone too. If you use a Constraint then the attached prop can move according to this constraint. The base of the constraint is affected then by the weights.
Rig attachments are another step further. Instead of attaching to a bone in the parent collider it attaches to the rig in the parent collider. Therefore this kind of attachment can only be used with collider resources of type component or a rig. What happens is hat the bone of the rig of the attached collider are mapped to the bones of the rig of the parent collider. Matching bones take over the state of their parent bones. This can be used to attach for example cloth to an actor. The cloth moves then accordingly to the actor since it uses the bone states of the parent collider. You can not use a constraint for this type of attachment since there exists no single point of attachment.
All colliders have physical properties. The following list describes them briefly.
|Specifies the mass of the entire collider in kg. This is used mostly only by the collider volume. All other collider types have a rig assigned which already specifies mass for the entire object or individual bones.
|Defines the translational or linear velocity of an object in m/s.
|Defines the rotational or angular velocity of an object in radians/s. Scripting modules tend to convert this into degrees/s.
|Overwrites the gravity defined in the parent world object if use local gravity is enabled. Defines the acceleration in m/s2 and can point into any direction. Often set to (0,0,0) to produce a floating object.
|Collision Response Type
|Defines the type of the collision response. This simply indicates how the object is simulated. If this is dynamic then the physics system does all the collision detection and collision response calculations. If this is though kinematic then the game scripts are asked to provide the collision response on their own. For all AI related colliders this is usually set to kinematic. Also for objects having motions or physical behaviors different than conventional physics using kinematic would be a good idea.
In the world everything collides with everything ( on the subatomic level that is ) but in game development this kind of granularity is simply not possible hence collisions have to be filtered and some allowed while others are ignored. To get this system to operate fast the Drag[en]gine uses two ways to select collisions: groups and masks. The group can be used if a Collider is supposed to collide only with a predefined set of Colliders and Terrains. All participants get the same group number assigned which is an integer value without any limitations. A collision happens if two Colliders or a Collider and a Terrain have the same group number. The group number 0 is reserved and indicates that no group selection is used. Hence Colliders and Terrains with the group number 0 collide with anybody. The second way is the collision mask. This is again an integer value but this time it is used as a bit array. Therefore each Collider and Terrain can be assigned a set of 32 bit flags. A Collider collides with another Collider or a Terrain if they share at least one set bit. For this their masks are ANDed and if the result is not 0 a collision is tracked. The group and mask can be set on all Colliders and Terrains.
During each frame update the game scripts have to call the detectCollisions function to update the physics simulation. After the simulation has been done the Physics Module calls the colliderChanged function which the Scripting Module forwards to the game scripts stating that a collider has been altered during the course of the last physics simulation. The game scripts have to update the internal states using the state of the collider at the time of the call. Colliders can be set to have one of the possible response types. During the callbacks you can alter the state of the Colliders. This can be used for example to disable a trigger Collider or altering collision group and mask.
Static response type indicates that a Collider does not move one inch during collisions. This is the typical choice for static scene geometry or various triggers. Static Colliders have no linear nor angular velocity. Altering the position and orientation of a static Collider is therefore not going to influences pushes on other Colliders.
Kinematic response type indicates that the Collider is moved around by the game script due to animation or cinematic scripts. This is the typical choice for AI routines ( a player collision box for example or a projectile ) or any other object which is not influenced by conventional physics like a levitating object or a moving piece of machinery. If a collision with such a Collider is registered the collisionResponse function is called ( again forwarded to the game script in one way or the other depending on the used Scripting Module ) asking for the physical reaction to this collision. The game scripts have to set during this call the new velocity and optional the position of the Collider. An info object is provided with informations about the collision to calculate the proper collision response. To avoid jerky movement you should only alter the velocities and not the position or orientation directly. This is also the right time to alter game states or play sounds for example.
Dynamic response type indicates a fully dynamic Collider submit under the influence of physics. The Physics module takes the responsibility to calculate the collision response using the Collider properties including physics oriented texture properties in the Skin objects assigned to Terrains or Components ( if used by the Colliders ). Here too the collisionResponse function is called. The info structure is provided as in the kinematic case but this time you are only supposed to alter some physics properties ( like for example restitution force depending on the materials hitting each other ) and not Collider properties as well as taking necessary game action like playing a sound or altering game states. The Physics Module can then calculate the proper response depending on the behavior you set ( NOTE: this will most probably be improved using a material response table but the call is still invoked to give you the chance to trigger game specific events ).