Talk:$lightmap
Source 2013 lightmap documentation post on ModDB
Most of this has been documented here since, but I'm linking it here since this user's explanation is articulated a bit better than what's currently on the wiki.
— SirYodaJedi (talk) 15:46, 28 February 2024 (PST)
- A quick summary of the undocumented limitations of the lightmap system present in Source 2013 and TF2 Branch which may prevent lightmaps from rendering
In the process of updating one of our models to support lightmaps, I noticed that while VRAD was packing lightmaps into all the static props in my test map, only the HL2 model I was using as a control test was actually displaying them. After decompiling the model and comparing the .qc files (scripts that define the visual and physical attributes of a model) there weren't any major differences between the two aside from what source .smd files they were pulling the model data from. This led me to a long process of commenting out material code and retesting the map, which led me to discover some undocumented limitations in the material system. If you're working in Source and want fancy lighting on your models, keep the following in mind:
- Your UV map must be unwrapped with each face in a unique position with no reused space, since Source will not generate a new UV channel to store the lightmaps like more modern engines do. Any overlap will create potential lighting errors on your model.
- Normal maps are not supported with lightmaps, but do have priority. Design your model and its material to not require a normal map, or else the model will default to vertex lighting.
- Phong shading is not supported with lightmaps, but similar to normal maps, does have priority. If you want reflectivity, 'traditional' specularity, including specular masks, are supported.
- Regardless of whether it is being used by the specific instance of a model, a model having any skins that do not conform to these guidelines will disable lightmap rendering for the model entirely. I don't know why this is, as static props cannot change skins at runtime, but perhaps Valve originally intended this system to also support non-moving dynamic props.
