View source for Material optimization

{{lang|{{PAGENAME}}|title=Material Optimization}}[[Category:Material System]]
{{back|Optimization (level design)}}
{{toc-right}}

== Shader Fallbacks ==
''(This section is only relevant if you are creating new materials. [[#Overdraw|Skip it?]])''
{{todo|Document $fallbackmaterial.}}

It goes without saying that not all PCs are equal. Your materials will need to look good on a wide range of specifications, and the best way of achieving acceptable performance at the low-end without sacrificing fidelity at the high-end is with [[shader]] fallbacks.

The good news is that Valve's stock materials are already set up with fallbacks, where appropriate, and in most cases you won't need to do any work in this area at all. The even better news is that if you ''do'' need to create a fallback, all of the hard work of benchmarking different hardware and graphics settings has already been done by Valve and all you need do is choose between a handful of coarse [[DirectX Versions|DirectX levels]] and other miscellaneous graphics settings.

=== Usage ===
Shader fallbacks are parameters of the material like any other, and should go inside the material's original pair of curly braces (<code>{</code> and <code>}</code>).

==== Fallback Shaders ====
:{{src07|since}}

 "<=dx90"
 {
 	&lt;VMT Parameters to set&gt;
 }

{{warning|You must wrap conditional statements in quotes if an equals sign <code>{{=}}</code> is used in it like the example above, or it will create a parsing error.}}

The parameters within a fallback are only applied if its opening statement is true. Accepted values include:

{| class="standard-table" style="width: 100%;"
! Name !! Condition !! Notes
|-
|<DX95||Below {{code|dxlevel 95}}||
|-
|<DX90
|rowspan=4|{{code|dxlevel 90}}||
|-
|<=DX90||
|-
|>=DX90||
|-
|>DX90||
|-
|>=DX90_20b
|rowspan=2|{{code|dxlevel 92}}||
|-
|<DX90_20b||
|-
|dx9||||Ditto of <code>>=DX90</code> for legacy compatibility
|-
|hdr||||
|-
|hdr_dx9||||Ditto of <code>hdr</code> for legacy compatibility
|-
|ldr||||
|-
|360||Game is running on the {{360|name}}||
|-
|srgb||Game is using correct [[sRGB]] blending
|-
|GPU<1
| rowspan=4 |Comparison of <code>gpu_level</code> [[console variable]]
| rowspan=4 |{{l4d|since}} {{src13|not}}
|-
|GPU<2
|-
|GPU>=1
|-
|GPU>=2
|}

==== Fallback Shaders (Legacy) ====
{{collapse top|Fallback Shaders {{l4d|removed}}}}
{{note|The following material, created before conditionals were added to the engine, is actually a bad example. It is not future-proof: systems running HDR_DX9 will not see normal mapping because it is only defined for DX9 and DX8 mode.

To avoid this issue in your own materials, use the conditional statements above or target high-end computers in the main body of the material, and use fallbacks only to remove/replace/tweak features for the benefit of older machines.}}
 LightmappedGeneric_DX8
 {
 	&lt;DX8 parameters&gt;
 }
 
While a "top-level" shader is called in the first line of a material, the actual job of rendering is passed down by the engine to a specific 'family member'. You can pass commands that only apply to a single child shader by providing its name. '''[[Half-Life 2 Shader Fallbacks|There is a full list of fallback shaders here.]]'''
 
=== Example ===

You can clear a value out by typing <code>""</code> (two quotes, nothing between).

 LightmappedGeneric
 {
 	$basetexture metal/metalwall078a
 	$surfaceprop metal
 
 	$envmap	env_cubemap
 	$envmaptint "[.56 .56 .75]"
 	$envmapcontrast 1
 	$envmapsaturation 1
 
 	LightmappedGeneric_DX9
 	{
 		$bumpmap metal/metalwall078a_normal
 		$normalmapalphaenvmapmask 1
 		$envmaptint "[.09 .1 .12]"
 	}
 
 	LightmappedGeneric_DX8
 	{
 		$bumpmap metal/metalwall078a_normal
 		$nodiffusebumplighting 1
 		$normalmapalphaenvmapmask 1
 	}
 
 	LightmappedGeneric_NoBump_DX8
 	{
 		$basetexture metal/citadel_metalwall078a
 		$basealphaenvmapmask 1
 	}
 }
{{Collapse bottom}}

=== Conditional Tests ===
:{{src07|since}}

 "srgb?$color" "[1.2 1.2 1.2]"
 "!srgb?$color" "[0.8 0.8 0.8]"

There are also conditional tests that can also be applied directly to variables and inverted with a preceding exclamation point <code>!</code>.

{| class="standard-table" style="width: 100%;"
! Name !! Condition !! Notes
|-
|hdr||||
|-
|ldr||||
|-
|360||Game is running on the {{360|name}}||
|-
|srgb
| rowspan=3 |Game is using correct [[sRGB]] blending
|-
|srgb_gameconsole
| rowspan=2 |{{csgo|since}}
|-
|srgb_pc
|-
|lowfill||<code>mat_reduceparticles</code> [[console variable]] is true||{{l4d|since}} {{src13|also}} Has nothing to do with <code>mat_reducefillrate</code>
|-
|SonyPS3||Game is running on the {{ps3|name}}
| rowspan=10 |{{l4d|since}} {{src13|not}}
|-
|gameconsole
|-
|GPU<1
| rowspan=6 |Comparison of <code>gpu_level</code> [[console variable]]
|-
|GPU<2
|-
|GPU<3
|-
|GPU>=1
|-
|GPU>=2
|-
|GPU>=3
|-
|HighQualityCSM
| rowspan=2 |[[CSM]] quality
|-
|LowQualityCSM
|}

== Overdraw ==
[[File:mat_fillrate.jpg|thumb|250px|Using <code>mat_fillrate</code> to investigate overdraw. Problem areas end up bright red.]]

[[Wikipedia:Fillrate|Fillrate]] refers to the number of pixels that a video card can shove into its memory per second, independently of the time needed to decide what color they should be. It becomes an issue when the user tries to run a game at a higher resolution than the card is capable of, or more commonly when a given pixel is being processed and re-processed many times.

This latter effect is known as "overdraw" and occurs when a material is [[$translucent|translucent]] (particles are dreadful), uses [[normal mapping]], uses [[specular reflection]]s, and/or is refractive. [[Dynamic light]]s and effects like [[motion blur]] and [[HDR]] (but ''not'' [[color correction]]) are also culprits. You can spot overdraw  by checking {{ent|showbudget}} for an unusually large "Swap Buffer" bar, and examine its effect precisely with <tt>mat_fillrate</tt>.

The only true solution to overdraw is reducing the number of pixels that needs to be re-processed. This can be done with a shader fallback, by creating fewer objects, or by reducing screen resolution. There are also a few tricks that can be employed, albeit to limited effect, which follow.
{{tip|To temporarily work around fillrate issues, use {{ent|mat_viewportscale}}.}}

=== Particles ===
See [[:Category:Particle_System#Particle_Performance|Particle Performance]].

=== Refraction ===
Any object that crosses the plane of a refractive material will be rendered twice: once for the direct view, and again for the refracted view (it's also rendered for reflection, but that can't be helped). This becomes avoidable when the water is obscured—for instance, if the object is embedded in a [[displacement]] sand drift. By raising the model or cutting the water brush so that it doesn't extend beneath the displacement, a whole rendering pass can be avoided.

You can examine what is being rendered for refraction with <tt>mat_showwatertextures 1</tt>.

=== Normal Mapping ===
{{ent|LightmappedGeneric}} materials are the prime suspects here. To help a little, you can add {{ent|$nodiffusebumplighting|1}} to the material in question, but as ever, the only true solution is a fallback.

Creating [[$ssbump|SSBumps]] instead of generic normalmaps may save on performance slightly, although gains are likely to be low on modern hardware.
{{tip|If creating DirectX 8 fallbacks, use <code>LightmappedGeneric_NoBump_DX8</code> to differentiate between video cards that have and haven't been deemed suitable for normal mapping by Valve.}}

=== Water ===
With [[Water (shader)|Water]], overdraw is caused by both refraction and reflection, often over a large area. You can disable either or both if needed:

;<code>$forcecheap 1</code>:Disables both reflection ''and'' refraction.
;<code>$refracttexture</code>
;<code>$reflecttexture</code>:Using these commands without passing a texture bypasses one or both.

If you've got fillrate and CPU to burn, you can forcibly make the water do local reflections regardless of video config settings by specifying <tt>$forceexpensive 1</tt>, and you can forcibly make the water reflect entities by specifying <tt>$reflectentities 1</tt>.

== Special Materials ==
{{main|Tool textures (Source)}}
===Nodraw===
[[File:Toolsnodraw.gif|right|tools\toolsnodraw]]

<code>tools\toolsnodraw</code> prevents a surface from being drawn at all, prevents lightmaps from being compiled for it, and prevents it from reflecting light (it still casts shadows). Use it on surfaces that will never be seen by the player but can't be sealed off by another brush, such as the tops of roofs and ledges, the far side of building in inaccessible areas, particularly those in [[Menu_Background_Map|background map]]s, and underneath displacements and func_detail (it may be necessary to leave a few units of textured brush underneath them to avoid seams due to vertex precision inaccuracies).

===Black===
<code>tools/toolsblack</code> is a material that is pitch black and doesn't bounce any light. It's useful at the bottom of deep pits, in inaccessible caves, etc.
{{important|In some games (ex: {{css}} {{csgo}} {{dods}} {{L4d}} {{l4d2}}), toolsblack is lightmapped. In such instances, {{code|vgui/black}} should be used instead.}}

===Skybox 2D===
A [[3D Skybox]] is drawn in full whenever the <code>tools/toolsskybox</code> material is being drawn. You can avoid this by using <code>tools/toolsskybox2d</code> in its place. Obviously, this only has an effect when the normal skybox material isn't visible, and it doesn't have any effect when there is no 3D skybox.