prop_static

Source Engine

Source 2

Not to be confused with the $staticprop and allowstatic (prop_data) QC commands.

prop_static is a internal point entity available in all Source games. It is used to cheaply add a model to the world. It cannot move, animate, or accept input (with the limited exception of $treesway). In fact, it doesn't exist as an entity after the map has been compiled. The vast majority of models in a typical map are prop_static entities.

A prop_static will collide with other objects provided it has a collision mesh, and, unlike all other model entities, can be lit per-vertex and cast shadows onto lightmaps.

AltNames: This entity is also tied to static_prop.

Known limitations

Vertex lighting

Demonstration of static prop lighting with and without $bumpmap in Source 2013, on a vanilla jeep model from Day of Defeat: Source. Note the differences in lighting accuracy on the jeep which is partially underneath the bridge.

Lighting can behave differently on a particular static prop depending on its settings and how its model and materials were authored. A prop with disabled per-vertex lighting will be lit based on its origin ($illumposition, if one is defined in the model, or Lighting origin, if defined in Hammer) and appear similar to dynamic props. This is the only behavior available in versions up to .

With per-vertex lighting enabled (available since ), VRAD will calculate and bake lighting and color information for each vertex of the model, typically resulting in a better, more realistic in-game look.

However, sometimes it can lead to undesireable stretches of shadow or highlights, especially on low-poly models or props with elongated proportions, like trees. The higher the poly count, the more accurate per-vertex lighting can be. It can become expensive on very high-poly models, so creating LODs is advisable.

In engine versions prior to CSGO and Strata Source, if any material on the prop's model uses bump mapping ($bumpmap, $normalmap or $phong), per-vertex lighting will be forcibly disabled.

This happens if any of the skins use $bumpmap or $phong, even if it's not the selected active skin.

Lightmaps on static props

In and Garry's Mod branches, VRAD can apply lightmaps onto static props, allowing for better blending between brush geometry and models. However, just like with vertex lighting, this feature cannot be used together with $bumpmap, $phong or $normalmap.

When baking a lightmap for a model, VRAD will use the same UV and scaling as the $basetexture of the model's first material of its first skin (taking $basetexturetransform into account, if present).

This means that:

• Models created with overlapping UV islands will get bad lightmaps, as they'll also be overlapping;
• If the model has multiple skins and or materials, only the first one will be used to lay down the lightmaps, potentially making overlapping worse;
• The lightmap will be cropped by the UV edges;
• Low-res lightmaps can bleed over the edges of the UV.

To make matters worse, the lightmap generated for props by VRAD comes in a special format, RGB888 (24-bit SDR) PPL, which can make color banding noticeable in HDR mode (especially if a light source is close to the prop).

Workaround: Using $lightmap in the VMT of the prop model's material can alleviate some of these issues. See its page for more detail.

Tip:Use the QC command $checkuv 0to1 overlap to prevent a model from compiling if it has incompatible UVs.

Compile limits for static props

VBSP limits the max number of entities on a map, including internal entities, and because prop_static count toward that limit, having too many can make the compile fail.

• In there can be up to 8192 entities (counting static props);
• In up to 16384;
• In up to 20480;
• In up to 65536 (works with any game).

Because, again, that limit concerns all map entities, the realistic maximum amount of static props will be lower.

Tip:This is a soft limit, and a modified VBSP can change it (MAX_MAP_ENTITIES in public/bspfile.h). A BSP file can theoretically contain over 4 billion static props.

Forced consistency

In order to enforce consistency of behavior, models with embedded physics data cannot be prop_static. Use the Hammer Model Browser's info tab to check for support.

Workaround: This is not an engine limitation; the check is performed by the compiler. A modified VBSP can avoid it. See below.

Models with bodygroups

Prop_static does not support selectable $bodygroup submodels; if there's any, only the first one will be used by the game. Despite this, VRAD will generate lightmap shadows from all submodels present in the MDL! (tested in )

Workaround: Either compile a separate model for each desired variation (doesn't use up an edict, better lighting), or use prop_dynamic (easier, less file duplication).

Keyvalues

Collisions (solid) <choices>

How the prop should interact with other objects.

• 0 - Not solid
• 2 - Use bounding box
• 6 - Use VPhysics (default)
  Note:Using this setting on models without a collision mesh will cause the engine to throw a warning upon loading the map. If you see such a warning, reset the collision of all props using the noted model to one of the other two choices.

Screen Space Fade (screenspacefade) <boolean>

If enabled, the prop will fade out based on how many screen pixels it covers. The start and end fade distances come to represent the pixels that the prop covers at the start and end of its fade when this is enabled.

Lighting Origin (lightingorigin) <targetname>

An info_lighting from which to sample lighting (instead of the model's origin or $illumposition). Not compatible with per-vertex lighting.

Disable per-vertex lighting (disablevertexlighting) <boolean>

Prop will be vertex lit more similarly to dynamic props: in real-time, based on its origin or $illumposition. This can significantly reduce VRAD compile times if the prop does not benefit from complex lighting.

Important:Enabling this overrides generatelightmaps!

Bug:Cascade shadows from Black Mesa doesn't work properly with prop_static if vertex lighting is enabled. Use this property if cascade lighting hits a static prop.

Workaround: Use -StaticPropLighting3 instead, this VRAD compile parametr doesn't cause this bug.

Bug example.

Without vertex lighting. With vertex lighting.

Disable Self-Shadowing with vertex lighting (disableselfshadowing) <boolean>

When vertex lighting is enabled, prevent the geometry from self-shadowing (casting shadows onto itself).

Ignore surface normal for computing vertex lighting (ignorenormals) <boolean>

When vertex lighting is enabled, ignore the surface normal of faces when calculating the vertex lighting, resulting in more uniform shading.

Tip:Useful for thin, translucent objects such as leaves on foliage props.

Alpha (renderamt) <integer> (in all games since )

Alpha of the fade, where 0 is fully transparent and 255 is fully opaque.

Render Color (R G B) (rendercolor) <color255> (in all games since )

Tint the model with this color.

Generate (and use) lightmaps for this static prop (generatelightmaps) <boolean> (only in ) (also in )

Generate a lightmap for this prop. Requires -StaticPropLighting to be enabled in VRAD. For more information, visit tf2maps.net.

Note:Lightmapping can be also faked on static props using $detailblendmode 8 or the Modulate shader in all games, although syncing the lighting can be difficult.

Bug: This setting doesn't work on models with multiple skins.

Warning:Several caveats and limitations; see note and warnings above.

Note:(not in ) While this KV does exist in Black Mesa's FGD, it is unused; Xengine does not support lightmapped props.

Lightmap Resolution X (lightmapresolutionx) <integer> (only in ) (also in )

The resolution of the generated lightmap in the X (or U) direction. (Only used if Generate Lightmaps is enabled.)

Lightmap Resolution Y (lightmapresolutiony) <integer> (only in ) (also in )

The resolution of the generated lightmap in the Y (or V) direction. (Only used if Generate Lightmaps is enabled.)

Enable Bounced Lighting (enablelightbounce) <boolean> (in all games since )

Whether VRAD should create indirect lighting from this prop.

Disable Prop Combine (preventpropcombine) <boolean> (in all games since )

Prevent this static prop from combining with any other static props in vbsp.

Uniform Scaling (uniformscale) <float> (in all games since )

Evenly scales a given model along the X Y Z axis.

Bug:In Hammer, undoing/redoing any changes (whether they are slight unit movements or scale changes) will result in the prop appearing "normal" sized in the 3D Textured Viewport (the model only appears normal sized and the value given is still shown upon reload of the VMF).

Todo: add scaling kvs from p2ce

Name (targetname) <targetname> (only in )

The name that ship_base_interaction/postcompile entities refer to this entity by^[How?]. Also useful regardless of game for being able to recognize specific prop_static entities in Entity Report. The name will not be in the compiled BSP.

Studiomodel:

World Model (model) <string>

The model this entity should appear as. 128-character limit.

Skin (skin) <integer>

Some models have multiple skins. This value selects from the index, starting with 0.

Tip:Hammer's model browser automatically updates this value if you use it to view different skins.

Bug:Static props with multiple skins will always calculate texture shadows based upon the alpha channel(s) from the default skin's texture(s), even though the alternative skins' alpha textures are loaded by VRAD. (tested in ).

Uniform Scale Override (uniformscale) <float> (in all games since )

A multiplier for the size of the static prop model.

Shadow:

Disable Shadows (disableshadows) <boolean>

Prevents the entity from creating cheap render-to-texture shadows, or lightmap shadows if the entity is a prop_static. Does not affect shadow mapping.

Disable Receiving Shadows (disablereceiveshadows) <boolean>

Prevent the entity from receiving dynamic shadows on itself.

Shadow Cast Distance (shadowcastdist) <integer> !FGD

Sets how far the entity casts dynamic shadows. 0 means default distance from the shadow_control entity.

Disable ShadowDepth (disableshadowdepth) <boolean> (in all games since )

Used to disable rendering into shadow depth (for projected textures) for this entity.

Disable flashlight (disableflashlight) <boolean> (in all games since )

Used to disable projected texture lighting and shadows on this entity.

Projected Texture Cache (shadowdepthnocache) <choices> (in all games since )

Used to hint projected texture system whether it is sufficient to cache shadow volume of this entity or to force render it every frame instead.

Choices

0 : Default 1 : No cache - render every frame 2 : Cache it - render only once

Reflection:

Render in Fast Reflections (drawinfastreflection) <boolean> (in all games since )

If enabled, this entity will render in fast water reflections (i.e. when a water material specifies $reflectonlymarkedentities) and in the world impostor pass.

BaseFadeProp:

Start Fade Dist (fademindist) <float>

Distance at which the entity starts to fade.

End Fade Dist (fademaxdist) <float>

Max fade distance at which the entity is visible.

• If start fade is <0, the entity will disappear instantly when end fade is hit.
• If end fade is <0, the entity won't disappear at all. (This is the default behavior.)

The values will scale appropriately if the entity is in a 3D Skybox.

Fade Scale (fadescale) <float>

If you specify so in worldspawn, or if the engine is running below DirectX 8 (DX7 in ), props will fade out even if the fade distances above aren't specified. This value gives you some control over when this happens: numbers smaller than 1 cause the prop to fade out at further distances, while those greater than 1 cause it to fade out at closer distances. Using 0 turns off the forced fade altogether. See also the QC command $noforcedfade.

DXLevelChoice:

Minimum / Maximum DX Level (mindxlevel / maxdxlevel) <choices> (removed since )

The entity will not exist if the engine is running outside the given range of DirectX Versions.

Choices

Warning:If these are used, the object may break when the user switches their DirectX settings. 0 - Default (no bounding) 60 - DirectX 6 (!FGD for mindxlevel) 70 - DirectX 7 80 - DirectX 8 (Geforce4 Ti 4600) 81 - DirectX 8.1 (GeForce FX 5200) 90 - DirectX 9 Shader Model 2 92 - OpenGL equivalent to DirectX 9 Shader Model 2 (using ToGL; only) !FGD 95 - DirectX 9 Shader Model 3 and DXVK 98 - DX9Ex ( only) !FGD

Tip:Set maxdxlevel to lower number such as 50 (along with disablevertexlighting set to 1) to create a prop that can cast shadows, but isn't rendered in-game. This is cheaper than using blocklight brushes, as it does not count towards brush and brushside limits.

SystemLevelChoice:

Minimum / Maximum Effect Details Level (mincpulevel / maxcpulevel) <choices> (in all games since )

Don't render for players with Effect Details levels that exceed the minimum or maximum.^{[Key names are related to cpu_level cvar used by Effect Details.]}

Choices

0: Default ("Low" formincpulevel, "High" formaxcpulevel) 1: Low 2: Medium 3: High

Minimum / Maximum Shader Details Level (mingpulevel / maxgpulevel) <choices> (in all games since )

Don't render for players with Shader Details levels that exceed the minimum or maximum.^{[Key names are related to gpu_level cvar used by Shader Details.]}

Choices

0: Default ("Low" formingpulevel, "Very High" formaxgpulevel) 1: Low 2: Medium 3: High 4: Very High

Tip:Set mingpulevel or mincpulevel to an large number such as 20 (along with disablevertexlighting set to 1) to create a prop that can cast shadows, but isn't rendered in-game. This is cheaper than using blocklight brushes, as it does not count towards brush and brushside limits.

Angles:

Pitch Yaw Roll (Y Z X) (angles) <angle>

This entity's orientation in the world. Pitch is rotation around the Y axis, yaw is the rotation around the Z axis, roll is the rotation around the X axis.

Common Mistakes

VBSP deletes model

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

The prop is not currently compatible to be used as prop_static. Note that this does not necessarily mean the model cannot be used with prop_static.

If the model does not have "static" flag in the model viewer (as in, was not compiled with $staticprop):

• You need to use prop_dynamic instead, or prop_physics_override if you want it to have physics.

If the model is your custom model:

• Either your model's QC file is missing $staticprop or there is no allowstatic 1 in the prop_data. Example:

$KeyValues
{
	prop_data 
	{
		"base" "Metal.Medium"
		"allowstatic" "1"
	}
}

If it is not your custom model, but has the "static" flag in the model viewer (was compiled with $staticprop:

• If , add -allowdynamicpropsasstatic to the VBSP compile options.
• If , use the VBSP from Slammin' Source Map Tools ( or ), VBSP prop_static fix ( only), Mapbase ( only), or Garry's Mod ( only).
• Otherwise, use Source Model Skin Editor to add "allowstatic" "1" to the MDL's prop_data, then revert to the original MDL after the map is compiled.

Model is off-center

If for some reason your model located incorrectly, check declared bone name in $definebone of a model; it should be without any slashes. Also check position there, values should be zeroed.

See also

• Prop Types Overview
  • prop_dynamic
  • prop_physics
  • prop_detail