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:47] – 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 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: | ||
- | * [[: |