IPhysicsObject: Difference between revisions
Jump to navigation
Jump to search
Note:Avoid simulating completely separate physics objects with one entity. Although VPhysics doesn't care one way or the other, game systems which use bounding boxes will become very inefficient should the objects become far apart. You will also encounter problems with velocity calculations when the "main" object is moving but others aren't (or vice versa). It's probably possible to work around all of these issues with the mod SDK, but only after a lot of work!
TomEdwards (talk | contribs) mNo edit summary |
TomEdwards (talk | contribs) |
||
| Line 34: | Line 34: | ||
== Multiple IPhysicsObjects == | == Multiple IPhysicsObjects == | ||
An entity can represent up to 1024 <code>IPhysicsObject</code>s. This happens in Valve's code with vehicle wheels and whenever a model has [[$collisionjoints]]. | An entity can represent up to 1024 <code>IPhysicsObject</code>s. This happens in Valve's code with vehicle wheels and whenever a model has [[$collisionjoints]] (the "must all be convex" limitation of which is imposed by studiomdl, not the engine). | ||
{{note|Avoid simulating completely separate physics objects with one entity. Although VPhysics doesn't care one way or the other, game systems which use [[bounding box]]es will become very inefficient should the objects become far apart. You will also encounter problems with velocity calculations when the "main" object is moving but others aren't (or vice versa). It's probably possible to work around all of these issues with the mod SDK, but only after a lot of work!}} | {{note|Avoid simulating completely separate physics objects with one entity. Although VPhysics doesn't care one way or the other, game systems which use [[bounding box]]es will become very inefficient should the objects become far apart. You will also encounter problems with velocity calculations when the "main" object is moving but others aren't (or vice versa). It's probably possible to work around all of these issues with the mod SDK, but only after a lot of work!}} | ||
Revision as of 08:57, 22 June 2011
IPhysicsObject is the basic representation of a rigid VPhysics object. It can be accessed with CBaseEntity::VPhysicsGetObject().
Member functions
Properties
SetMass()SetInertia()- Overrides this object's mass/inertia. Todo: Units
SetDamping()
Confirm:Sets rotation damping (how fast the object stops spinning)SetDragCoefficient()- Set friction. Todo: Units
SetBuoyancyRatio()- Sets buoyancy Todo: "Ratio"?
Forces
ApplyForceCenter()ApplyForceOffset()- Applies inches/s force.
ApplyTorqueCenter()- Applies degrees/s rotation.
AddVelocity()SetVelocity()SetVelocityInstantaneous()- Adds or sets velocity in a physically incorrect way that affects the object regardless of its current mass/inertia.
SetPosition()SetPositionMatrix()- Teleports the object to a new location. Todo: Impact of teleporting an object short distances every frame vs. letting it find its own way.
Multiple IPhysicsObjects
An entity can represent up to 1024 IPhysicsObjects. This happens in Valve's code with vehicle wheels and whenever a model has $collisionjoints (the "must all be convex" limitation of which is imposed by studiomdl, not the engine).
Note:Avoid simulating completely separate physics objects with one entity. Although VPhysics doesn't care one way or the other, game systems which use bounding boxes will become very inefficient should the objects become far apart. You will also encounter problems with velocity calculations when the "main" object is moving but others aren't (or vice versa). It's probably possible to work around all of these issues with the mod SDK, but only after a lot of work!