Prop Types Overview

The word prop in the Source is generally synonymous with code-simulated model entities. There are various prop entity categories, each representing models with specific functions. Each one is chosen for a specific reason and has individual trade-offs in features and performance.

Prop types

The following table lists the main prop types placed by level designers, and their overall characteristics:

Model entity	Properties
prop_detail	Detail geometry - static models that do not move. Do not contain any physics properties or collision data. Cannot break. Does not cast shadows. Can be automatically placed by assigning a detail type to a material. Generally not placed individually by level designers. The least expensive geometry to render. These may not even be rendered on low-end machines. Examples: Grass, rocks, plants.
prop_static	Static geometry - models that do not move. Does not contain physics properties other than collision, and cannot break. Cannot have any joints or animation. Casts lightmap shadows. Inexpensive geometry to render. Examples: pipes, light fixtures, rocks, telephone poles.
prop_physics	Models with built-in physical properties. Moves and collides using the rigid-body physics system. Can be constrained to other physics objects using hinges or other constraints. It can also be configured to break when it takes enough damage. Casts dynamics shadows. Expensive to move and render. Works worse with sv_turbophysics set. Examples: barrels, small debris, furniture.
prop_ragdoll	Physics props with ragdoll physics skeletons. Have all the properties of physics props and can also use the rigid body ragdoll physics system to have multiple colliding or bending parts. Very expensive to move and render. Examples: Corpses, multi-piece cardboard boxes, mattresses.
prop_dynamic	Models that can be placed in hierarchy and can have joints and play animations. Can also be configured to break when taking enough damage. Can be hierarchically attached to other objects. Can cast dynamic shadows. More expensive than static geometry, less expensive than physics geometry. Examples: Robotic arms, machinery, models animated in cut scenes.
prop_sphere	!FGD Physics props which are a perfect sphere, such as playground balls. Cheaper than creating a spherical physics mesh for such a prop, although the sphere size can only be defined in .
prop_physics_multiplayer	Physics props using a simplified physics collision system designed for multiplayer games. Have less networking overhead than standard physics props, necessary for the bandwidth-limited environment of multiplayer games. Works better with sv_turbophysics set.
prop_physics_override	Special prop type used to override the properties built into the model. Has identical cost of a prop_physics.
prop_dynamic_override	Special prop type used to convert a model that is designed to be used as a prop_static, and giving it the properties of a prop_dynamic. Has identical cost of a prop_dynamic.

See the Source SDK sample map mapsrc\sdk_prop_types.vmf for examples of some of the prop types in use.

Additional prop types exist in different games for more specific use cases; see Category:Prop entities for a list of all prop known types in all games.

Restrictions in Use

To ensure consistency in the behavior of props across maps, Source restricts what models may be used for each prop type. For example, a barrel which is physics-based in one map should not be static in another, unless there is very good reason for it to be so. If you use the wrong prop type with a model, VBSP may delete the prop from your map.

In Hammer's Model browser, There are three check marks in the "info" tab. These are: "physics", "static", and "dynamic"

• If "physics" is checked, the model may only be used as prop_physics or prop_ragdoll, or as prop_dynamic_override.
• "Static" is required to use with prop_static.

You will get an error in your compile log if you use the wrong type of model for a prop_static:

Error! prop_static using model "[model]", which must be used on a dynamic entity (i.e. prop_physics). Deleted.

or:

Error! To use model "[model]"
      with prop_static, it must be compiled with $staticprop!
Error loading studio model "[model]"!

You will get a console error in-game if you place a prop_physics which is not set up for physics:

prop_physics at [x] [y] [z] uses model [model], which has no propdata which means it must be used on a prop_static. DELETED.

Override Entities

prop_dynamic_override

Most models will work with prop_dynamic, with the exception of physics models. If you want to use a physics model with all its physics disabled, use prop_dynamic_override.

prop_physics_override

Props which are to be physically simulated must have prop data compiled into them. The entity prop_physics_override allows you to input this data from Hammer, and allows you to use most models as a physics prop.

Note:For using physics props with prop_static, see Prop_static#VBSP_deletes_model. The prop still must be compiled with $staticprop.

Creating Props

Specific qc code will make your model suitable for some types of props, and unsuitable for others.

	prop_detail	prop_static	prop_dynamic	prop_physics	prop_ragdoll
$staticprop	Yes	Yes	Optional	Optional	No
prop_data	No	No	No	Yes	Yes
$collisionjoints	No	No	Optional	No	Yes
$collisionmodel	No	Optional	Optional	Yes	No

Notes: "Yes" or "No" means that the prop may be removed from the game, or otherwise not work if done incorrectly. "Optional" means that the code will work and is usually a good idea. Click the links for instructions on how to use the corresponding .qc code and what they do.

Prop_detail models may only use materials with the UnlitGeneric shader. See Detail props for more info.

$staticprop has the effect of collapsing all bones and nullifying all skeletal animations. If your prop needs no bones or animations, staticprop is a worthwhile optimization. In Hammer's Model browser, the check box marked "static" lets you know that $staticprop has been used.

Characteristics

prop_detail

• Can have 10's of thousands of them in a level. (64,000 limit in Left 4 Dead)
• Can be .MDLs or sprites. Sprites are much faster to render than .MDLs.
• Can be placed inside the Hammer editor or by adding a material property %detailtype to a .vmt file which causes Vbsp to automatically generate detail props over particular materials (described below).
• Can never collide with them.
• Are lit with a constant color (for optimization)
• Don’t affect lightmaps in the world.
• Automatically fade out when they exceed a particular distance from the player (controlled by the console variables cl_detaildist and cl_detailfade).
• Will probably not ever be rendered on low-end hardware.
• Must use models compiled with $staticprop in their .qc file.
• Have no network overhead + very low memory usage.
• Is not a real entity, has no inputs or outputs.
• May not have animations.
• Can not be hierarchically attached to other entities.
• From a visibility standpoint, they are assumed to be points.

prop_static

• Can have thousands of them in a level.
• Can be placed inside the Hammer editor.
• Can have collision associated with them.
• Will affect lightmaps in the world – can cast lightmap shadows.
• Will be vertex lit like standard studio models. (option for static prop lightmaps is available in TF2 or Source SDK 2013 MP)
• Will use LOD system.
• User selectable as to whether the prop is rendered on low end hardware.
• Fade distances can be set in Hammer editor.
• Must use models compiled with $staticprop in their .qc file.
• Have no network overhead + very low memory usage.
• Is not a real entity, has no inputs or outputs.
• May not have animations or joints.
• Can not be hierarchically attached to other entities.
• Optimal from a visibility standpoint, it uses the convex hull of the object.

prop_dynamic

• Can have hundreds of them in a level.
• Can be placed inside the Hammer editor.
• Can have collision associated with them.
• Will not affect lightmaps in the world, but they can cast dynamic shadows.
• Will be vertex lit like standard studio models.
• Will use LOD.
• Will render on low-end hardware.
• Fade distances can be set in Hammer.
• May use models that are not compiled with $staticprop.
• May have animations.
• Have low (but non-zero) network overhead + higher memory usage (as much as any entity).
• Is a real entity with inputs and outputs.
• Can be hierarchically attached to other entities.
• Optimal from a visibility standpoint, it uses the convex hull of the object.
• From a visibility standpoint, they are assumed to be boxes.

prop_physics

• Can have tens to hundreds of them in a level, depending on complexity.
• Can be placed inside the Hammer editor.
• Must have collision associated with them.
• Will not affect lightmaps in the world, but they do cast dynamic shadows.
• Will be vertex lit like standard studio models.
• Will use LOD system.
• Fade distances can be set in Hammer editor.
• Are faded earlier on low-end hardware unless settings changed.
• May use models that are not compiled with $staticprop.
• May have animations.
• Have low (but non-zero) network overhead + higher memory usage (as much as any entity).
• Is a real entity with inputs and outputs.
• Can not be directly hierarchically attached to other entities.
• Can be constrained to other entities by various physics constraints entities.
• Optimal from a visibility standpoint, it uses the convex hull of the object.
• From a visibility standpoint, they are assumed to be boxes.
• Additional characteristics?

prop_ragdoll

• Same as prop_physics, but can use skeletons for ragdoll physics.
• Has very high network overhead.

See also

• Automatically emitting prop_details on a material