$lightmap

Stub

This article or section is a stub. You can help by adding to it.

$lightmap is a material shader parameter available on the VertexLitGeneric shader in the following Source games or engine branches:
Source 2013 Multiplayer and  Garry's Mod.

It defines a lightmap to be used to light the MDL model's material, instead of the per-vertex lighting used by prop_static or point-based vertex lighting used by other models.

This parameter does not usually need to be added manually, as VRAD will generate model lightmaps automatically if generatelightmaps is enabled for the prop_static and -StaticPropLighting is enabled in VRAD. Nonetheless, it can still be added manually, such as for using a lightmap on a prop_dynamic, or if a prop_static has multiple materials (as VRAD can only generate lightmaps for the first material and skin).

Tip:

• VRAD has a -dumppropmaps option, which will create external TGA versions of the generated static prop lightmaps which can be converted to VTF and manually defined as a $lightmap.
• For already-compiled maps, the lightmaps are stored as PPL files. These can be converted to VTF using Ficool2's proptexelvtf.exe (direct download).

Confirm: If $lightmap is used to manually define lightmaps for a prop_static, it may be necessary to disable vertex lighting for the prop (disablevertexlighting) to prevent VRAD from wasting time calculating lighting for the prop and generating a VHV file that will ultimately go unused and waste space.

Note:The VertexLitGeneric shader code for lightmapped props from can be backported to , but the lightmaps will need to be explicitly defined in the VMT, rather than generated as PPL files by VRAD.

VMT syntax

$lightmap <texture>

models/lightmapped/example.vmt

vmt

VertexLitGeneric { $basetexture "models/lightmapped/example_base" $lightmap "models/lightmapped/example_lightmap" }

Limitations and caveats

Warning:Models use the same UVs for lightmaps as $basetexture, and the model's lightmap is affected by $basetexturetransform; as such, lightmapping on models with overlapping or tiling UVs may not appear as intended!
Additionally, lighting seams may appear on edges with non-contiguous texture UVs; this is more noticeable on lower-resolution lightmaps.

Bug:Lightmaps for models with multiple materials do not compile properly in VRAD! A lightmap will only be compiled for the first material on the model, that is a combined version of all the UV's used by all materials.

Workaround: Define a pre-baked $lightmap in the VMT of the VertexLitGeneric material (can be obtained using -dumppropmaps in VRAD).

Warning:Model lightmaps generated with VRAD are compiled as RGB888 (24-bit SDR) PPL files which can result in noticeable color banding when brightly lit in HDR mode.

Workaround:

• Define a pre-baked RGBA16161616f $lightmap in the VMT of the VertexLitGeneric material. A custom-coded compiler would be required to this accurately.
• Increase lightmap resolution (results may vary).
• Move light source further away from the lit surface.

Warning:Models using $bumpmap cannot receive lightmaps, they will fall back to vertex-lighting based upon the models' origin.

Note:There is an in-engine check that confirms whether or not the $bumpmap parameter is defined for a material, a custom shader cannot simply use both as there are a dozen technicalities that have to be overcome.

Technical

If $bumpmap, $normalmap, or $phong is defined, the engine will not send the lightmap data to the shader. For $bumpmap, a workaround for this is to use a differently named parameter. ($NormalTexture) to get the normal map and undefining $bumpmap. However no static lighting data can be received by the shader, if the $bumpmap parameter is not set to anything. This refers to lights that are not named and are not inherently dynamic. This may be prefered as the static light information is already prebaked in the lightmap, however it means you cannot receive direction information from the lights. No light direction means no bumped lighting from the lightmap. Aka no specular highlights. A fix for this would be modifying VRAD to spit out a lightmap that is *2 the size on the U axis and then storing an average light direction there or doing some other smart technique to 'memorize' light directions. This in-engine check also exists for $phong, however getting around the issue is more tricky. The default value of the integer parameter will be 0 even if not set in the vmt. Thus making $phong always be defined in a way.

See also

• Modulate - A shader that can be used to fake lightmaps or vertex coloring in all Source engine branches. It can bypass some of the limitations of $lightmap, but requires additional setup to look convincing.