Physics Entity Overview

It has been suggested that Constraint be merged into this article or section. (Discuss)

The addition of physics to the Source engine has opened up a broad range of simulation possibilities. From swinging tires to constrained mechanisms, designers are now able to produce machines and objects that work in realistic ways physically. To create these objects, multiple physics entities must be employed to describe how entities are physically constrained or related to one another. Here we'll list these entities and their uses.

Constraints

In real-life, objects are constrained together by various means. Doors are attached to their frames via hinges that they can swing on. Your arm is attached to your torso via a ball socket joint. Heavy objects can be moved via a rope and pulley system. These concepts are exactly mimicked in the Source engine's physics implementation. Below is a list of the various constraint systems you can use to attach entities to one another.

phys_constraintsystem

If you have a collection of objects connected by constraints, the constraint solvers may fight each other as they are each solved locally (without regard to any of the other constraints). This can cause a system of constraints to be unstable. You'll see this as vibration or jiggling. To prevent this problem, you can use a phys_constraintsystem for each group of connected constraints and have that group refer to it as their system manager. When this is done, those solvers will be iterated as a group, which will create a feedback loop between the constraints so that interactions between them can be managed. The constraint system also allows you to control the number of iterations - so you can spend more CPU to get the solution to be tighter. Generally problems here are the result of objects of dissimilar mass being connected by constraints. If a large-mass object is in violation of the constraint, it may take more iterations for it to move to a non-violating position/orientation. Note that all ragdolls create a constraint system internally to solve these kinds of problems.

phys_constraint

The most simple constraint available, this constraint simply attaches one entity to another, as if it were fixed by a rigid constraint like nails or glue. The entity defines two fields for the two entities to constrain. If either entity is left blank, the provided entity will be rigidly attached at the origin of the constraint. This is most often used to constrain objects to the world. Like all constraints, you may also specify a force or torque limit - which the constraint will "break" at. When enough force or torque is applied to the object attached to the constraint it will break, causing it to disable itself and produces an output which can be used to orchestrate other events. See mapssdk_phys_constraint.vmf

phys_ballsocket

A ball socket constraint is identical to how your arm attaches to your torso at the shoulder. An object is fixed to another object at a point and is able to rotate and move in a spherical motion around that point. This can be used to express the connection between a rope and a piece of world architecture within the game. The rope will be able to rotate in a sphere around the point on the world. See mapssdk_phys_ballsocket.vmf

phys_hinge

Like the hinge of a door, this constraint allows the constrained objects to rotate in one axis of movement. The axis of hinge is expressed via a helper tool inside of Hammer. The hinge can be given a friction component, which causes it to come to a rest more quickly like an old rusty hinge might. The "load scale" field is identical to the phys_motor implementation. See mapssdk_phys_hinge.vmf

phys_lengthconstraint

This is a constraint that preserves the distance between two entities. If the "Keep Rigid" flag is set, it can be thought of it as a rod. If not, it acts like a virtual rope (with some amount of "give"). See mapssdk_phys_lengthconstraint.vmf

phys_pulleyconstraint

Essentially, this constraint is really two length constraints and two points in space. It is similar to virtual rope connected to two objects, each suspended from a pulley above them. The constraint keeps the sum of the distances between the pulley points and their suspended objects constant. In other words, moving one constrained object will cause the other to move as well to keep the "rope" length constant. See mapssdk_phys_pulleyconstraint.vmf

phys_convert

phys_convert should be used to convert the behavior of a brush or model to physics. For example, let's say you made a func_tracktrain with some prop_dynamic entities attached as children. For a while you use Entity I/O to move the tracktrain and its children along some path, then at some event you want the train to explode and become physically simulated to tumble. You can use a phys_convert to convert the tracktrain and the dynamic props into physics objects at the time of that event (since func_tracktrain and prop_dynamic do not have the desired physics behavior built in). See mapssdk_phys_convert.vmf

phys_ragdollconstraint

Like a normal phys_constraint but used to tether ragdolls to a location in space, this constraint also allows the user to control how much movement in each axis is permitted, as well as how much friction is applied in each axis. See mapssdk_phys_ragdollconstraint.vmf

phys_slideconstraint

This constraint allows movement along one axis. You can think of this like a shower curtain ring sliding along the curtain rod. Like the hinge constraint, the entity provides a visual helper for specifying the direction of travel. See mapssdk_phys_slideconstraint.vmf

phys_keepupright

Some objects need to attempt to remain upright. This constraint applies torque to a physics object to attempt to do just that. The number of degrees of angular torque that can be applied per second is specified in the "Angular Limit" field of the entity. The higher the number, the more rigidly the object will maintain its upright positioning. See mapssdk_phys_keepupright.vmf

phys_spring

This is a physically simulated spring. The "Length" field specifies what is known as the natural spring length. This is how long the spring would be if it was at rest (nothing hanging on it or attached). When you attach something to the spring, it will stretch longer than its natural length. The amount of stretch is determined by the "Sprint Constant" field. The larger the spring constant, the less stretch the spring will accommodate. See mapssdk_phys_sprint.vmf

Miscellaneous

phys_magnet

An entity that acts like a magnet, attaching metallic physics objects to itself when they touch it. See mapssdk_phys_magnet.vmf

phys_motor

An entity that tries to spin a target entity at a particular speed. This can be thought of as a motor with an axle connecting directly to an object. Connected to a tire, it could make it spin much like a car's tire. There is also a "load scale" field which works similarly to horsepower. The motor will attempt to move an object at a given velocity, but if that object creates resistance (from a collision, for instance), the motor will use the load scale field to increase its output to continue and move the object at the correct speed. A value of "2" would make the motor exert twice as much force as it normal would need to in order to move the attached object, should it meet with resistance. See mapssdk_phys_motor.vmf

phys_ragdollmagnet

A simple entity that attracts ragdolls towards it. This is often useful for getting a more reliably dramatic death from a corpse. The entity can attract at a point, or as a "bar", meaning the entity is pulled towards that axis but not directly at a point in space. This is useful for pulling a ragdoll towards a railing's edge at any point along that edge, while not pulling it towards a specific point. See mapssdk_phys_ragdollmagnet.vmf

phys_thruster

This entity applies force to an entity along a specified axis. This is directly analogous to a rocket's engines propelling it forward. The entity also has a built-in timing feature which allows the designer to specify a duration for the thruster to propel its target, then stop. See mapssdk_phys_thruster.vmf

phys_torque

Like the phys_motor entity, this entity applies angular velocity to an object. This entity also has the ability to ignore the mass of the object being turned, as well as having a built in timer which allows the entity to exert torque on the attached entity for a given amount of time, disabling itself afterwards. See mapssdk_phys_torque.vmf