Prop static

It is used to cheaply add a model to the world. It cannot move, animate, or accept input (with the limited exception of ). 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.
== Known limitations ==
=== Vertex lighting ===
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 vertex-lit based on its origin (, 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 via ), 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 , if any material on the prop's model uses normal mapping (, or ), 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.
The and support per-vertex lighting on normal-mapped and $phong materials, and does not suffer from this limitation.
=== 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 per-vertex lighting, this feature cannot be used together with , or .
When baking a lightmap for a model, VRAD will use the same UV and scaling as the of the model's first material of its first skin (taking 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 vanilla VRAD comes as RGB888 (24-bit SDR) in a special PPL format, which can make color banding noticeable in HDR mode (especially if a light source is close to the prop). generates and uses separate RGBA16161616f lightmaps for HDR mode.
=== 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.
=== 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.
=== Models with bodygroups ===
 does not support selectable 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 )
== Keyvalues ==
</dd>
: 
:
:
==Common Mistakes==
=== VBSP deletes model ===
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 .
If the model does not have "static" flag in the model viewer (as in, was not compiled with $staticprop):
* You need to use instead, or if you want it to have physics.
If the model is your custom model:
* Either your model's QC file is missing or there is no allowstatic 1 in the . 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 :
* If , add to the VBSP compile options.
* If , use the VBSP from ( or ), VBSP prop_static fix ( only), ( only), or ( only).
* Otherwise, use to add to the MDL's , 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
** 
** 
** 
static