Choosing the Right World‑Prop Entity Type in Source Engine Maps

Choosing the Right World‑Prop Entity Type in Source Engine Maps

When building a map for Source 1 or Source 2, the choice of world‑prop entity (prop_static, prop_dynamic, prop_physics) directly impacts performance, lighting, collision handling, and interactivity. The decision hinges on four constraints:

• Performance: draw‑call cost and CPU load.
• Lighting: baked vs dynamic shading.
• Collision & Interactivity: need for physics simulation or player interaction.
• Map compilation workflow: static props require map recompilation for any change.

Supported Entity Types

Below is a concise comparison of the three entity classes used in Source 1 (the same names apply in Source 2 after verifying the FGD).

Entity Type	Movement	Animation	Physics	Lighting Model	Typical Cost
prop_static	None – stationary at compile time	None	None	Baked lightmaps (no dynamic shadows)	Lowest per‑instance draw cost; batch‑friendly
prop_dynamic	Can be moved or scaled via script or entity	Supports skeletal animation	No physics unless driven by script	Dynamic shadows or vertex lighting (depends on compile)	Medium per‑instance cost; breaks static batching
prop_physics	Fully movable, can be pushed by players	No built‑in animation (requires separate model)	Simulated rigid body with collision response	Dynamic lighting (receives real‑time shadows)	Highest CPU and network bandwidth cost; limit usage in multiplayer

Trade‑off Summary

Static props excel when you need decorative geometry that never moves, casts no real‑time shadows, and can be rendered in a single draw call. Dynamic props add runtime flexibility at the expense of higher draw calls and more complex lighting, but they remain cheaper than physics props. Physics props are reserved for objects that must react to player interaction, such as crates that can be lifted or barrels that roll, because the simulation overhead is significant and can desynchronize multiplayer state.

Concrete Validation Steps

To verify which entity type fits your map, create a minimal test map in Hammer and place one instance of each class.

1. Map setup – In Hammer, create a new map, add a simple brush, then insert three entities:
• prop_static – use a static model (e.g., models/props_c17/furniture_cabinet001a.mdl).
• prop_dynamic – use a model that supports skeletal animation (e.g., models/props_c17/door001a.mdl).
• prop_physics – use a physics‑enabled model (e.g., models/props_c17/barrel001.mdl).
2. Compile the map – Run the standard compile command (vbsp → vvis → vrad). Ensure you are using the target engine branch’s FGD to confirm entity class names.
3. In‑game draw‑call inspection – Launch the map in the engine console and enable wireframe mode:

mat_wireframe 1

While panning the camera, open the entity list with:

r_drawentities 1

Observe the number of draw calls for each prop type; static props should group together, while dynamic and physics props generate separate calls.

4. CPU profiling – Use the built‑in performance console (press ~ to open) and enable the “showfps” and “showbudget” commands. Record the per‑frame CPU time while moving past each prop type. Expect static props to contribute the least CPU time.
5. Lighting verification – Place a dynamic light source (e.g., a spotlight) and watch the shading on each prop. Static props will retain their baked lightmaps; dynamic props will receive real‑time illumination, and physics props will show the same dynamic shading as dynamic props.
6. Collision test – For physics props, enable player pickup by using the “use” key. Verify that the object reacts to physics forces and that networked clients see the same movement (if testing multiplayer).

Practical Decision Flow

1. Determine if the object ever moves or changes shape at runtime. If not, select prop_static.
2. If the object needs animation (e.g., a door opening) but no physical interaction, choose prop_dynamic.
3. If the object must be pushed, carried, or collide with other physics objects, use prop_physics and limit its count, especially in multiplayer maps.

Limitations and Checks

Static props cannot be repositioned without recompiling the map, which may be undesirable for level editors who need rapid iteration. Dynamic props break static batching, increasing draw calls; monitor the mat_drawsolid and mat_wireframe statistics to ensure performance stays within target limits. Physics props consume both CPU cycles for simulation and network bandwidth for state synchronization; excessive use can cause desynchronization or frame‑rate drops in multiplayer sessions.

Always double‑check the exact entity class names and spawnflags in the target branch’s FGD or entity script files before committing the map to source control. The names may differ between Source 1 and Source 2 (e.g., prop_physics might be prop_physics_override in a custom build).

By following the validation steps above, you can confidently select the appropriate world‑prop entity type, balancing visual fidelity, performance, and gameplay requirements.