Prop Types Overview

From Valve Developer Community
Revision as of 18:56, 8 April 2005 by Erik Johnson (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Overview of Prop Types

The word prop in the Source is generally synonymous with polygon models. 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. 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.


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.
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 prop_static, prop_dynamic, prop_physics, prop_physics_multiplayer, prop_physics_override, and prop_dynamic_override in the entity documentation for more details.

See maps\sdk_prop_types.vmf for examples of some of the prop types in use. Prop types in further detail

Differences in Prop types

This section has more detail on the differences in the prop types. The following table shows some ways in which the prop types are different:

model entity Number in level Always Rendered Collision Lighting Casts Shadows Physics
prop_detail 10,000's No No Point No Static No physics No Hierarchy No animation
prop_static 1,000's Yes Yes Vertex Static (lightmap) Static No physics No hierarchy No animation
prop_dynamic 100's Yes Yes Vertex Dynamic (projected) Hierarchy + animation
prop_physics 10's-100's Yes Yes Vertex Dynamic (projected) Hierarchy + animation + physics
prop_ragdoll less than 10 Yes Yes Vertex Dynamic (projected) Hierarchy + animation + ragdoll physics

Entries in the table explained:

Number in level: Typical amounts to populate a level and retain acceptable performance. Always rendered: Is the prop type always drawn, regardless of how far away you are from the object? Collision: Does this prop type has the capability to collide with other objects? Lighting: Lighting method used for lighting/shadows cast upon the object. Cast Shadows: Does this prop type cast lightmap shadows, or does it use dynamic projected shadows? Physics: Methods this prop type interacts with the physics and animation systems.

Characteristics of prop_detail:

  • Can have 10's of thousands of them in a level.
  • 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.

Characteristics of 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.
  • 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.

Characteristics of 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 do cast dynamic shadows.
  • Will be vertex lit like standard studio models.
  • Will use LOD
  • Will exist on low-end hardware.
  • Fade distances can be set in Hammer editor.
  • 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.

Characteristics of 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?

Characteristics of prop_ragdoll:

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

Automatically Emitting prop_details on a Material

Models of type prop_detail can be set to be randomly emitted from surfaces based upon the material assigned to the surface. The file detail.vbsp describes detail prop groups. Each detail prop group specifies which prop_detail models are emitted from that group. A material can indicate which detail prop group is assigned to it by adding this line to the .vmt file:

%detailtype = "detail_group_name"

Where detail_group_name is the one of the detail prop group entries in detail.vbsp.

Here's an simple example of a detail prop group, as defined in detail.vbsp:

   swamp_grass_and_rocks 
   { 
      "density" "800.0" 
      Group1 
      { 
        "alpha" "1.0" 
        Model1 
        { 
           "model" "models/junk/rock1.mdl" 
           "amount" "0.3" 
        } 
        Model2 
        { 
           "model" "models/junk/rock2.mdl" 
           "amount" "0.3" 
        }    
      } 
      
      Group2 
      { 
        "alpha" "0.0" 
        Model1 
        { 
           "model" "models/foliage/Grass_tuft_003a.mdl" 
           "amount" "0.1" 
        } 
        Model2
        { 
           "model" "models/foliage/Grass_tuft_004b.mdl"
           "amount" "0.3"
        } 
      } 
   } 

"Density" describes how many points to randomly generate on all surfaces that have materials that use this detail prop group. Larger numbers will generate more detail props.

Then, you can specify as many groups of detail props as you like. Materials on non-displacement surfaces will only use one group, but displacement surfaces may use multiple groups. Each group specifies a list of the models that will be randomly emitted. The model fields above describe which studio model to use, and the "amount" field describes how many to emit relative to the other models in the list. For advanced users: If the amounts of all the models within a single group add up to less than 1, then the system will actually emit less than the maximum number of models described by "density".

The "alpha" field is only used for displacement surfaces. When a displacement surface is using a material that blends between two textures, the alpha describes how much of each texture to use. The detail system looks at that alpha to choose which group to select models from. For example, lets say you've got a displacement with two textures on it, one is road (alpha = 1 for the road) and the other is grass (alpha = 0 for the grass). In the example above, it would emit rocks on the road and grass tufts on the grass, since the group with "alpha" "1.0"<code> contains rock models and the group with <code>"alpha" "0.0" contains grass models. Note that you can make as many groups as you want; for example, if you were to add a group with "alpha" "0.5", this would create detail props using that group's models wherever the displacement is blending halfway between the rocks and grass.

Using the detail prop system with .MDLs can actually be fairly expensive owing to a high per-model overhead that currently exists in DirectX. To avoid this, you may also use sprites with the detail prop system, which doesn't have this overhead and is consequently at least 10x faster than using .MDLs. Here's how to specify a detail model group that uses detail sprites:

Group1
{
	"alpha" "1"
	Model1
	{
		"sprite" "288 0 128 128 512" 
		"spritesize" "0.5 0.0 19 25"
		"spriterandomscale" "0.2"
		"amount" "0.2"
		"detailOrientation" "2"
	}
	Model2
	{
		"sprite" "0 0 128 128 512"
		"spritesize" "0.5 0.0 23 30"
		"spriterandomscale" "0.2"
		"amount" "0.1"
		"detailOrientation" "2"
		}
}

The textures for detail sprites must all be placed in sub-regions of the texture "detailsprite.vtf".

The first two numbers in the "sprite" field shown above specify the (X, Y) coordinate of the upper left corner of the sprite as it lies within the detailsprite.vtf texture. The next two numbers specify the width and height of the sprite. The final number is the size of the detailsprite.vtf texture in pixels.

The first two numbers in the "spritesize" line specifies the rotational center of the detail sprite in normalized coordinates: (0,0) specifies the lower left, and (1,1) specifies the upper right. In the example above, the rotational center of the sprite is halfway along the lower edge of the sprite. The final two numbers in the "spritesize" line indicate the width and height of the sprite in world units when it gets drawn.

"spriterandomscale" specifies a random amount to scale the width and height of the detail sprite (in the example, the sprite will be between 80% and 120% of the size indicated in the "spritesize" line).

Finally, "detailOrientation" specifies how the detail sprite will move. A value of 0 indicates that it will not rotate; 1 means that it will always face the camera, and 2 means it will rotate around its Z-axis to try to face the camera as best it can.