Managing Physics Stability in the Source Engine

The Problem: The "Physics Explosion"

Every developer working with the Source Engine has encountered the "physics explosion": a prop that suddenly vibrates violently and launches across the map at supersonic speeds. This usually happens when two collision meshes interpenetrate—meaning they overlap in a way the engine cannot resolve—causing the physics solver to apply an extreme corrective force to separate them.

To prevent this, you must move beyond basic prop placement and manage how the engine's modified Havok implementation handles rigid body dynamics, mass ratios, and sleep states.

Collision Geometry and Mesh Simplification

The Source Engine handles collision through a hierarchy of shapes. While it is tempting to use a complex mesh for a prop, the engine performs best with primitive shapes (spheres, boxes) or convex hulls. A convex hull is a shape where any line segment between two points inside the shape stays entirely inside the shape; it has no "dents" or holes.

When a prop uses a concave mesh for collision, the engine often approximates it with multiple convex pieces. If these pieces overlap or if a player's collision box gets wedged into a concave corner, the solver may fail, leading to instability. The rule of thumb is to keep collision meshes as simple as possible, prioritizing primitive boxes over custom hulls whenever the visual difference is negligible.

The Impact of Mass Ratios

Stability in the Source Engine is heavily dependent on the mass ratio between interacting objects. If a very light object (e.g., a 1kg pencil) is pinned between a heavy object (e.g., a 1000kg shipping container) and a static world brush, the physics solver struggles to find an equilibrium.

When the mass difference is too extreme, the solver may overshoot the corrective position in a single frame, pushing the light object further into the heavy one. This creates a feedback loop of increasing force. To maintain stability, avoid mass ratios exceeding 10:1 for objects that are expected to maintain constant contact.

Practical Implementation: Testing and Visualization

To diagnose why a prop is behaving erratically, you need to see the invisible boundaries the engine is actually calculating. You can do this using the developer console.

Diagnostic Steps

1. Launch the game/map with -dev enabled in the launch options.
2. Open the console (typically the ~ key).
3. Run the following command to visualize collision boundaries:

   phys_boxes 1

4. Observe the colored boxes around your props. If you see boxes flickering or overlapping significantly when a prop is at rest, you have a collision conflict.

Risk: Running phys_boxes in a map with hundreds of physics entities can significantly drop your frame rate, as the engine must render debug geometry for every active physics handle.

Configuration Example: Stable Prop Setup

When configuring a physics prop in the Hammer Editor, use these guidelines for a stable, interactable object:

Property	Recommended Value	Reasoning
Collision Model	Convex Hull / Box	Prevents interpenetration glitches.
Mass	10 - 50 units	Balances player "push" force with stability.
Friction	0.5 - 0.7	Prevents objects from sliding infinitely on slopes.

Limitations and CPU Overhead

The Source Engine's physics system is largely single-threaded in older versions. This means that as the number of "awake" physics objects increases, the CPU cost rises linearly. The engine uses a sleep mechanism to disable calculations for stationary objects, but any interaction—even a player walking near a prop—can "wake" a cluster of objects.

If you have a room filled with hundreds of small physics debris items, you risk a massive frame drop the moment a grenade goes off. To mitigate this, use phys_push settings to limit how much force players can transfer to objects, or convert non-essential physics props to static models once they have settled.

Verification Checklist

To verify your physics implementation is stable, perform these three checks:

• The Corner Test: Push a prop into a 90-degree corner of the map. It should stop firmly without jittering.
• The Stack Test: Stack three of the same props. They should remain still; if they begin to "dance" or slide, your friction or mass settings are too low.
• The Boundary Check: Use phys_boxes 1 to ensure the collision hull matches the visual mesh closely enough that players don't feel they are hitting invisible walls.