Talk:$lightmap

From Valve Developer Community
Jump to navigation Jump to search

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.
One more note: whether or not the model you're using is displaying lightmaps, the information is still being generated and stored if you've set the prop to use them, so make sure it supports lightmaps before activating that setting! Otherwise, you'll be adding to your compile time and BSP filesizes for no benefit, or at least until you change your material.

Dead link to tool

The link to ficool's PPL converter is dead, as it is a direct Discord link.

Those are absolutely unreliable, as Discord will eventually deprecate them (not only for downloadable files, for media too) and they'll display This content is no longer available.

A fix that works for a time being is to paste them back in Discord (makes the content appear then), download the thing, rehost it elsewhere and give a proper link.

Someone should do that, I don't have own space to host it (and I don't want to touch ficool's stuff in general). Cvoxalury (talk) 01:30, 21 June 2024 (PDT)

Added in late 2014

Idk where would be the most appropriate place to mention this, but this shader parameter and the associated VRAD and engine integration was added in late 2014 for the unfinished map Tfwiki favicon.png rd_asteroid. I figured someone would want to have an example of how Valve used it.
SirYodaJedi (talk) 07:57, 18 September 2024 (PDT)