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:47] 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 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.1217544427.txt.gz · Last modified: 2008/07/31 22:47 by dragonlord