|
|
| 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 provided 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}}
| |
| | |
| == Known limitations ==
| |
| === Vertex lighting ===
| |
| [[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.]]
| |
| [[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 ({{ent|$illumposition}}, if one is defined in the model, or '''Lighting origin''', if defined in [[Hammer]]) and appear similar to [[prop_dynamic|dynamic props]]. This is the only behavior available in versions up to {{src06}}.
| |
| | |
| With per-vertex lighting enabled (available since {{src07}}), [[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 [[LOD]]s is advisable.
| |
| | |
| In engine versions prior to {{csgobranch}}[[CSGO]] and {{strata}}[[Strata Source]], if any material on the prop's model uses bump mapping ({{ent|$bumpmap}}, {{ent|$normalmap}} or {{ent|$phong}}), per-vertex lighting <span style="font-weight:bold; color:white">will be forcibly disabled</span>.
| |
| | |
| 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 {{src13mp}} and {{gmod}}[[Garry's Mod]] branches, VRAD can apply [[lightmap]]s 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 {{ent|$bumpmap}}, {{ent|$phong}} or {{ent|$normalmap}}.
| |
| | |
| When baking a lightmap for a model, VRAD will use the same UV and scaling as the {{ent|$basetexture}} of the model's first material of its first skin (taking {{ent|$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 [[skin]]s 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 {{ent|$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 {{cmd|$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 <code>prop_static</code> count toward that limit, having too many can make the compile fail.
| |
| * In {{src07}}{{src13}}{{l4dbranch}} there can be up to 8192 entities (counting static props);
| |
| * In {{asbranch}}{{p2branch}} up to 16384;
| |
| * In {{csgobranch}} up to 20480;
| |
| * In {{mapbase}} up to 65536 (works with any {{src13sp}} 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 {{code|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 [[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; the check is performed by the compiler. A modified [[VBSP]] can avoid it. See [[#VBSP deletes model|below]].}}
| |
| | |
| === Models with bodygroups ===
| |
| {{code|Prop_static}} does not support selectable {{ent|$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 {{dods}})
| |
| | |
| {{workaround|Either compile a separate model for each desired variation (doesn't use up an [[edict]], better lighting), or use {{ent|prop_dynamic}} (easier, less file duplication).}}
| |
| | |
| == 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]] or [[$illumposition]]). Not compatible with per-vertex lighting.}}
| |
| {{KV|Disable per-vertex lighting|intn=disablevertexlighting|bool|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.
| |
| : {{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 cascade lighting hits a static prop.
| |
| {{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 [[$detailblendmode]] 8 or 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 enabled.)|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 enabled.)|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 lower number such as 50 (along with {{code|disablevertexlighting}} set to 1) to create a prop that can cast shadows, but isn't rendered in-game. This is [[cheap]]er than using [[blocklight]] brushes, as it does not count towards brush and [[brushside]] limits.}}
| |
| {{KV SystemLevelChoice}}
| |
| :{{tip|Set {{code|mingpulevel}} or {{code|mincpulevel}} to an large number such as 20 (along with {{code|disablevertexlighting}} set to 1) to create a prop that can cast shadows, but isn't rendered in-game. This is [[cheap]]er than using [[blocklight]] brushes, as it does not count towards brush and [[brushside]] limits.}}
| |
| {{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.