Prop Types Overview

From Valve Developer Community
Jump to: navigation, search
Русский 简体中文

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. Do 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_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.

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, the game 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.

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