gamedev:colliders
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| gamedev:colliders [2008/03/29 21:43] – created dragonlord | gamedev:colliders [2024/03/14 16:34] (current) – dragonlord | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== | + | {{tag> |
| + | <WRAP youarehere> | ||
| + | [[: | ||
| + | </ | ||
| 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. | 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 ====== | ====== Colliders ====== | ||
| Line 19: | Line 21: | ||
| ====== Attachments ====== | ====== Attachments ====== | ||
| - | One of the strength of the collider system is that you can attach | + | One of the strength of the collider system is that you can attach |
| + | * # | ||
| + | * # | ||
| + | * # | ||
| + | * # | ||
| + | * # | ||
| + | * # | ||
| + | * # | ||
| + | * # | ||
| + | * # | ||
| + | * # | ||
| + | * # | ||
| + | * # | ||
| + | * # | ||
| + | * # | ||
| + | * # | ||
| ===== Static Attachment ===== | ===== Static Attachment ===== | ||
| - | 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 collider | + | 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 |
| ===== Bone Attachment ===== | ===== Bone Attachment ===== | ||
| Line 31: | Line 48: | ||
| ===== Rig Attachment ===== | ===== Rig Attachment ===== | ||
| - | 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 colliders | + | 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 |
| ====== Physical Properties ====== | ====== Physical Properties ====== | ||
| Line 42: | Line 59: | ||
| |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 // | |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 // | ||
| - | ====== | + | ====== |
| - | | + | 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. |
| - | * [[:start|Main page]] | + | |
| + | ====== Callback System ====== | ||
| + | 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 ===== | ||
| + | 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 ===== | ||
| + | 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 ===== | ||
| + | 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 ). | ||
gamedev/colliders.1206826987.txt.gz · Last modified: 2008/03/29 21:43 by dragonlord
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
