|
|
| (24 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| {{langsp}} | | {{APH|prop_static}} |
| It is used to [[cheap]]ly add a [[model]] to the world. It cannot move, animate, or accept [[input]] (with the limited exception of {{ent|$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 <code>prop_static</code> entities.
| |
| | |
| A <code>prop_static</code> ''will'' collide with other objects assuming it has a [[collision mesh]], and, unlike all other model entities, can be lit per-vertex and cast shadows onto [[lightmap]]s.
| |
| | |
| {{altnames|name1=static_prop}}
| |
| | |
| == Bugs and Limitations ==
| |
| [[File:Static prop bumpmaps.png|thumb|Demonstration of static prop lighting with and without {{ent|$bumpmap}} in {{src13|4}}, on a vanilla jeep model from {{dods|4}}. Note the differences in lighting accuracy on the jeep which is partially underneath the bridge.]]
| |
| {{modernImportant|Models using [[bump maps]] or {{ent|$phong}} cannot be lit per-vertex, ''except in the {{csgobranch|4}} and {{strata|4}}'', and will be lit based upon the model's origin instead! }}
| |
| {{tip|{{since|{{src07}}}} As lighting is done per-vertex, ''higher-poly models will be lit more accurately than low-poly models''. Use [[$lod|LoD]] models to simplify lighting (and GPU load) as the camera gets further from props.}}
| |
| {{note|In {{src13mp|4}} and {{gmod|4}}, static props can use lightmaps using the static prop's UVs. They come with the same limitations as per-vertex lit props, and cannot be used on models with bump maps.
| |
| {{warning|{{Expand|noborder=1|title=Addtional caveats|{{warning model lightmaps}}}}}}
| |
| }}
| |
| {{warning|[[VBSP]] enforces a soft limit on how many entities, including {{mono|prop_static}}s, can be compiled into a map. If the limit is reached, [[VBSP]] will fail to compile the map. The default limits are as such:
| |
| * {{src07}}{{src13}}{{l4dbranch}} 8192 MAX_MAP_ENTITIES
| |
| * {{asbranch}}{{p2branch}} 16384 MAX_MAP_ENTITIES
| |
| * {{csgobranch}} 20480 MAX_MAP_ENTITIES
| |
| * {{mapbase}} 65536 MAX_MAP_ENTITIES (supports all {{src13sp}} games)
| |
| In practice, the maximum number of prop_statics will be less than this, due to the limit being shared between all entities in the map.
| |
| {{tip|This is a soft limit, and can be circumvented with a modified [[VBSP]] by editing {{file|public/bspfile|h}}. A BSP file can theoretically contain over 4 billion static props.}} }}
| |
| {{bug|{{code|prop_static}} does not support selectable {{ent|$bodygroup}} submodels (although it does support selectable {{ent|$texturegroup}} skins); only the first one will be used. Despite this, VRAD will generate lightmap shadows from ''all submodels'' present in the MDL! (tested in {{dods}}) {{workaround|Do one of the following:
| |
| * Compile a separate model for each desired variation (doesn't use up an [[edict]], better lighting)
| |
| * Use {{ent|prop_dynamic}} (easier, less file duplication)
| |
| }} }}
| |
| | |
| === Consistency ===
| |
| In order to enforce consistency of behavior, models with [[prop_data|embedded physics data]] cannot be <code>prop_static</code>. Use the Hammer Model Browser's info tab to check for support.
| |
| {{workaround|This is not an engine limitation, but rather an arbitrary restriction imposed by the compile tools, and can be bypassed with a modified [[VBSP]]; see [[#VBSP deletes model|below]].
| |
| }}
| |
| | |
| == Keyvalues ==
| |
| {{KV|Collisions|intn=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.}}}}
| |
| {{KV|Screen Space Fade|intn=screenspacefade|bool|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.}}
| |
| {{KV|Lighting Origin|intn=lightingorigin|targetname|An {{ent|info_lighting}} from which to sample lighting (instead of the model's origin). Disables per-vertex lighting.}}
| |
| {{KV|Disable Vertex lighting|intn=disablevertexlighting|bool|Prop will be vertex lit more similarly to dynamic props, being lit based upon its origin instead of per-vertex. Set this to "Yes" to significantly reduce VRAD compile times if the prop does not benefit from complex lighting.
| |
| : {{modernConfusion|This doesn't actually disable vertex lighting, but rather uses a simpler form of it that calculates vertex colors based upon the color, brightness, and direction of the origin (or {{ent|$illumposition}}) at runtime instead of prebaking the them per-vertex into a [[VHV]] file (which is packed into the compiled [[BSP (Source)|BSP]]).}}
| |
| : {{modernImportant|Enabling this overrides {{code|generatelightmaps}}!}}
| |
| : {{bug|Cascade shadows from {{bms|4}} doesn't work properly with {{ent|prop_static}} if vertex lighting is enabled. Use this property if cascading lighting hits a static support.
| |
| {{expand|title=Bug example.|
| |
| <br>
| |
| <gallery mode=nolines widths=520px heights=292px>
| |
| File:CSM_VertL2.jpg|Without vertex lighting.
| |
| File:CSM_VertL1.jpg|With vertex lighting.
| |
| </gallery>
| |
| }}
| |
| }}
| |
| }}
| |
| {{KV|Disable Self-Shadowing with vertex lighting|intn=disableselfshadowing|bool|When vertex lighting is enabled, prevent the geometry from self-shadowing (casting shadows onto itself).}}
| |
| {{KV|Ignore surface normal for computing vertex lighting|intn=ignorenormals|bool|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.}}}}
| |
| {{KV|Alpha|intn=renderamt|int|Alpha of the fade, where 0 is fully transparent and 255 is fully opaque.|since=L4D}}
| |
| {{KV|Render Color (R G B)|intn=rendercolor|color255|Tint the model with this color.|since=L4D}}
| |
| {{KV|Generate (and use) lightmaps for this static prop|intn=generatelightmaps|bool|Generate a lightmap for this prop. Requires <code>-StaticPropLighting</code> to be enabled in VRAD. For more information, visit [https://tf2maps.net/threads/guide-prop-lightmaps.24682/ tf2maps.net].
| |
| :{{note|Lightmapping can be also faked on static props using the [[Modulate]] shader in all games, although syncing the lighting can be difficult.}}
| |
| :{{bug|{{css}} This setting doesn't work on models with multiple skins.}}
| |
| :{{warning|Several caveats and limitations; see note and warnings above.}}
| |
| :{{note|{{bms|not}} While this KV does exist in Black Mesa's FGD, it is unused; [[Xengine]] does not support [[$lightmap|lightmapped props]].}}|only=2013MP|also={{gmod}}}}
| |
| {{KV|Lightmap Resolution X|intn=lightmapresolutionx|int|The resolution of the generated lightmap in the X (or U) direction. (Only used if Generate Lightmaps is Yes.)|only=2013MP|also={{gmod}}}}
| |
| {{KV|Lightmap Resolution Y|intn=lightmapresolutiony|int|The resolution of the generated lightmap in the Y (or V) direction. (Only used if Generate Lightmaps is Yes.)|only=2013MP|also={{gmod}}}}
| |
| {{KV|Enable Bounced Lighting|intn=enablelightbounce|bool|Whether VRAD should create indirect lighting from this prop.|since={{csgobranch}}}}
| |
| {{KV|Disable Prop Combine|intn=preventpropcombine|bool|Prevent this static prop from combining with any other static props in vbsp.|since={{csgobranch}}}}
| |
| {{KV|Uniform Scaling|intn=uniformscale|float|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).}}|since={{csgobranch}}}}
| |
| {{todo|add scaling kvs from p2ce}}
| |
| {{KV|Name|intn=targetname|target_source|The name that {{ent|ship_base_interaction}}{{ship}}/postcompile{{teamspen}} 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.|only={{ship}}{{teamspen}}}}
| |
| | |
| {{KV Studiomodel|static=1|noscroll=1}}
| |
| {{KV BaseFadeProp}}
| |
| {{KV DXLevelChoice}}
| |
| :{{tip|Set {{code|maxdxlevel}} to 60 (along with {{code|disablevertexlighting}} set to 1) to create a prop that can cast shadows, but doesn't appear in-game. This is [[cheap]]er than using [[blocklight]] brushes, as it does not count towards brush and [[brushside]] limits.{{modernConfirm|Setting a fake non-zero dxlevel, such as 50, might work as well.}} }}
| |
| {{KV SystemLevelChoice}}
| |
| {{KV Angles}}
| |
| | |
| ==Common Mistakes==
| |
| === VBSP deletes model ===
| |
| {{codeblock|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 <code>prop_static</code>. Note that this does not necessarily mean the model cannot be used with {{mono|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 {{ent|prop_dynamic}} instead, or {{ent|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 {{ent|$staticprop}} or there is no <code>allowstatic 1</code> in the {{cmd|prop_data}}. Example:
| |
| :: <source lang=Java>
| |
| $KeyValues
| |
| {
| |
| prop_data
| |
| {
| |
| "base" "Metal.Medium"
| |
| "allowstatic" "1"
| |
| }
| |
| }
| |
| </source>
| |
| | |
| If it is not your custom model, but has the "static" flag in the model viewer (was compiled with {{cmd|$staticprop}}:
| |
| * If {{gmod}}, add {{mono|-allowdynamicpropsasstatic}} to the [[VBSP]] compile options.
| |
| * If {{src13}}, use the VBSP from {{slammin|4}} ({{src13sp}} or {{src13mp}}), [https://hl2-beta.ru/index.php?action=downloads;sa=view;down=155;language=english VBSP prop_static fix] ({{src13sp}} only), {{mapbase|4}} ({{src13sp}} only), or {{gmod|4}} ({{src13mp}} only).
| |
| * Otherwise, use {{srcskineditor|4}} to add {{code|"allowstatic" "1"}} to the [[MDL (Source)|MDL]]'s {{cmd|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 <code>$definebone</code> of a model; it should be without any slashes. Also check position there, values should be zeroed.
| |
| | |
| == See also ==
| |
| * [[Prop Types Overview]]
| |
| ** {{ent|prop_dynamic}}
| |
| ** {{ent|prop_physics}}
| |
| ** {{ent|prop_detail}}
| |
Note:Archived rest of page history of page prop_static
Important:These pages are linked often from page history logs so Special:WhatLinksHere will not show anything.