User Tools

Site Tools


gamedev:colliders

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
gamedev:colliders [2008/07/31 22:46] dragonlordgamedev:colliders [2024/03/14 16:34] (current) dragonlord
Line 1: Line 1:
-====== Physics with Colliders ======+{{tag>physics collider collision}} 
 +<WRAP youarehere> 
 +[[:start|Start Page]] >> [[:gamedev|Game Development with the Drag[en]gine]] >> **Physics with colliders** 
 +</WRAP> 
 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 collider to another one at runtime. This way you can build complex game entities composed of multiple individual colliders. The game scripts do not have to worry about moving colliders with their attached parent colliders since the physics module takes care of this. Colliders can be attached using one of the various ways. Each has different a different use.+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: 
 +  * #@LinkApiDocDE2_HTML~classdeBillboard.html,Billboard~@# 
 +  * #@LinkApiDocDE2_HTML~classdeCamera.html,Camera~@# 
 +  * #@LinkApiDocDE2_HTML~classdeCollider.html,Collider~@# 
 +  * #@LinkApiDocDE2_HTML~classdeComponent.html,Component~@# 
 +  * #@LinkApiDocDE2_HTML~classdeDebugDrawer.html,DebugDrawer~@# 
 +  * #@LinkApiDocDE2_HTML~classdeEnvMapProbe.html,EnvMapProbe~@# 
 +  * #@LinkApiDocDE2_HTML~classdeForceField.html,ForceField~@# 
 +  * #@LinkApiDocDE2_HTML~classdeLight.html,Light~@# 
 +  * #@LinkApiDocDE2_HTML~classdeLumimeter.html,Lumimeter~@# 
 +  * #@LinkApiDocDE2_HTML~classdeMicrophone.html,Microphone~@# 
 +  * #@LinkApiDocDE2_HTML~classdeNavigationSpace.html,NavigationSpace~@# 
 +  * #@LinkApiDocDE2_HTML~classdeParticleEmitterInstance.html,ParticleEmitterInstance~@# 
 +  * #@LinkApiDocDE2_HTML~classdePropField.html,PropField~@# 
 +  * #@LinkApiDocDE2_HTML~classdeSpeaker.html,Speaker~@# 
 +  * #@LinkApiDocDE2_HTML~classdeTouchSensor.html,TouchSensor~@#
  
 ===== 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 always keeps the same position relative to the parent. Therefore the collider 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 [[gamedev:constraints|Constraint]] then the attached prop can move according to this constraint. Otherwise it does not change it's position relative to the parent 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 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 [[gamedev:constraints|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 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 of type component or a rig collider. It does not work with a collider volume since it has no 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.+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.
  
 ====== 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 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.+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:main|Game Development Informations]] 
-  * [[:start|Main page]] 
gamedev/colliders.1217544369.txt.gz · Last modified: 2008/07/31 22:46 by dragonlord