This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
gamedev:colliders [2008/07/31 22:46] – 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 43: | Line 60: | ||
====== Collision Groups and Masks ====== | ====== Collision Groups and Masks ====== | ||
- | 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 | + | 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. |
====== Callback System ====== | ====== Callback System ====== | ||
Line 56: | Line 73: | ||
===== Dynamic ===== | ===== 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 ). | 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 ). | ||
- | |||
- | ====== Links ====== | ||
- | * [[gamedev: | ||
- | * [[: |