Advanced Lighting
Light Entities
light_dynamic An invisible light source that can change and move over time. Its position can change and it can be aimed at moving objects. Dynamic lights are recalculated continuously, which means they have a higher processing cost but are much more flexible than static lighting. Use this type of light sparingly, because it is the most expensive light for the engine to render.  Note:This entity actually consists of two lights, a cone-shaped light and a spot world light. Some values may affect one and not the other. |
env_particlelightA normal light that lights only the particles created by an env_smokestack and lights nothing else. Useful for enhancing lighting in areas with steam and such. |
env_projectedtextureSimilar to a
Note:The farther you cast the shadow, the less detailed the shadow map will be due to the perspective projection. Lower FOV, higher NearZ, and closer proximity to the shadow casters (as it's not wasting any space rendering nothing) often give best results. When shadows start to lose detail, the most obvious defect is light bleeding, and the shadow will "be pulled" away from the caster(s). |
Glowing texturesIn a few cases it’s possible to make the texture itself appear bright or even to emit light, but doing so requires the use of a Click on the Glowing Textures link above for more information. |
Related Entitiesinfo_lighting This is an entity used to specify the origin from which another entity is lit. Sometimes due to drastic changes in light over short distances or complex shadows a model can appear to be lit incorrectly. By using this entity the model will be lit as though it were stationed at this location. One common example is the HL2 static Ladder props; when used in dark areas they may appear to glow, which can be corrected by inserting an info_lighting, naming it, and specifying that name in the properties for the Ladder prop. Tip:It is generally better to use -staticproplighting when compiling instead of tweaking the lighting origin. See below. | |||
env_lightglowUsed to create a bright almost-flare that will fade out at specified distances. Generally used to transition dark tunnels to bright outsides. Used as a precursor to the HDR effect to fake a change in exposure of the light. Some Team Fortress 2 maps use this to simulate bloom from regular light sources as well, but it is recommended that you use env_sprite instead.[confirm]
| |||
info_no_dynamic_shadowThis forces a particular brush face to not receive any of the dynamic shadows created by physics entities or NPC’s. It’s used rarely but may be needed to hide incorrect or bad shadows that create an artificial look. | |||
env_tonemap_controller Used to control the exposure of the HDR lighting effects. Can be given inputs to control more effects. It's common to have a logic_auto to do the initial settings on loading the map. | |||
Smoothing groupsUsed to smooth lighting between faces. Found in the face edit dialog, the groups allow the lighting of a face to be smoothed between other faces to produce rounded effects with lighting. A classic example is when making a cylinder: If no smoothing groups are set, each face on the brush will catch light separately and will be lit separately. This will create a very obvious effect of separating each face. If they are all placed in the same smoothing group, the light will be blurred between the faces creating a much smoother rounder look on the pillar. Tip:Smoothing groups have virtually no effect on performance, apart from adding extra time for VRAD to compile, so use them on your final compile. | |||
LightmapsA lightmap is the lighting data of each face. The stored light is then added to the face giving it brightness. The lightmap's scale refers to the number of texture pixels per light pixel (luxel). Smaller values mean more luxels, thus a better quality but larger BSP size and compile times. |
Compile Options
Source 2007 added three additional options you can use when compiling to improve the realism during compile. To access these, open Expert mode in the Run Map dialog and select "HDR Full compile -final (slow!)"; then, select the "$light_exe" line in the list below that. In the Parameters field, append the options you wish to use, as shown below.
Note:These considerably increase compile time, so it is recommended that you save them for the last few stages of your map.-staticproppolys
Normally, VRAD creates shadows under static props based on the collision mesh, since collision meshes are usually much simpler but still close enough to the prop's shape. This is usually sufficient, but some props may have oversimplified collision meshes—or none at all—causing VRAD to create unnatural shadows. This option allows you to override this for certain props and force VRAD to use the polygon mesh instead. This is also necessary if you need to use -textureshadows (see below). Simply append -staticproppolys to the $light_exe Parameters list (see above).
-textureshadows
Not all props have their "holes" defined solely by geometry. Mesh fences, for example, use textures with alpha channels. VRAD does not normally recognize these, so if you use them you will have to either disable shadows from them (which sometimes produces decent results) or add this option, which forces VRAD to take alpha channels into account as well, just like with brushes.
To make -textureshadows work on models compiled without $casttextureshadows, you need to create a custom RAD file for your map listing which props you want this option to affect. Extract the lights.rad file from the game in question using GCFScape or Crafty, place it in the game folder, and give it a new name. Then, open it in any text editor and append the line forcetextureshadow [full path of prop] to the file for each model you want this to affect. You will also need to have -staticproppolys enabled for this to work. Finally, append -lights [name of your custom RAD file] -textureshadows to the $light_exe Parameters list (see above).
-staticproplighting
Unlike the other two, this option affects the lighting received by props. Props are generally lit based on the lighting levels at their origin (see info_lighting above), which can lead to unnatural lighting if a light source is aimed at only one side of the prop or if the prop is half in shadow and halfway in light. This option forces VRAD to calculate the lighting level at each vertex instead. Of these three options, this one will probably affect compile time the most, but it is usually a necessary step in making the map's props look convincing.
Simply append -staticproplighting to the $light_exe Parameters list (see above).
Warning:This will disable info_lighting entities on static props that don't use bump maps!Note:
- light_spot will cause vertex lighting even without this parameter.
- This will cause some props, such as pine trees, to try to cast shadows on themselves, creating an unrealistic look. To fix this, under the prop's properties, set the value for Disable Self-Shadowing with vertex lighting to "Yes."
- Props that use bump maps or phong materials cannot be lit per-vertex, except in
CS:GO engine branch and 
Strata Source. Such props will fall back to origin-based lighting, even if the map was compiled without the normal maps and phong present.
Tip:As lighting is done per-vertex, higher poly models will be lit more accurately than low-poly models. Use LoD models to simplify lighting (and GPU load) as the camera gets further from props.This also enables support for lightmapping static props in 
Source 2013 Multiplayer and 
Garry's Mod, with the same limitations as per-vertex lighting, plus inaccurate lighting if the prop has overlapping UVs, multiple materials, and/or multiple skins. See prop_static and $lightmap for a full explanation and list of caveats.
Techniques
Lightmap Optimization
Lightmaps store nearly all the lighting information in Source BSPs, and their efficient use equates directly to efficient lighting. They are the key contributor to BSP file size: efficient usage is a must for anyone wanting their map to be downloaded off the cuff and is preferable for everybody.
Lightmap scale is the basic component of optimization. It determines how detailed lighting information will be for a given face (you can see the effects above). The more information stored, the bigger the file size. Small lightmap scales allow for fine details but come at the cost of a bigger file, and lag if very high-density lightmap is overused. Large lightmap scales create fuzzier lighting but lead to smaller files. Determining when a face needs a detailed lightmap and when it doesn't is therefore the task.
This can mostly be done by eye from a compiled map. Look for the faces that receive high-contrast shadows or specific details, as they are often the best candidates for low (i.e., detailed) lightmap scales. Faces with slow blends or lighting that only slightly differs across them on the other hand can safely have their scale raised.
Note:Remember to take into account the size of a face, too. Moving a large face even one point up or down can have very large effects[confirm]. Don't be afraid to split the face into segments if you need to.Example
For a working example, look to the hallway shown on the right. One side shows the in-game compiled version and the other side shows the lightmaps as displayed in Hammer. The lightmap view is easy to access: left click on the word "Camera" in the top left of your 3D view, and from the drop down select 3D Lightmap Grid. In this view, yellow faces have smaller-than-default scales, white faces are at the default, and blue are larger.
The hallway we are looking at has wall-mounted lights and a few ceiling lights as well. In the picture it's clear to see where the lightmap scale has been increased and decreased. The front of the pillar has an increased lightmap because of the light source on its face, to catch all the detail. This is not such a major problem as the pillar is a small thin face and the only area with a lower scale. The floor and a few of the walls along the edge have been scaled up, as looking at the in-game rendering little to no detail or change is seen in the lightmap; they are excellent candidates, the floor especially so with its large size. The other faces have been left at the default resolution as they all have some play of shadows or changes in brightness. While not detailed or essential enough to warrant a smaller scale, increasing the scale would only serve to create poor-looking lighting as the lack of detail would show.
While technically possible to decrease the entire scale across the entire map for crisp shadows, the compile time and filesize expense almost always outweighs the benefit. Finding the balance between increasing and decreasing the lightmaps may take a few lighting compiles and some guesswork, but performed correctly can both enhance your map and reduce its file size.
Shadow Creation
Creating shadows from translucent materials with -TextureShadows (External Link)
Shadow Creation: Alternative Method
Note:This is deprecated with the introduction of new lighting parameters in Source 2007. If it is still used, the blocklight brushes should be inside the visible geometry instead of on top of it, to avoid casting shadows on the geometry itself.Some props appear to allow static light to pass through it, but have a collision mesh that swallows the prop whole (most, if not all, fence props in the 
Half-Life 2 series are a good example of this). This results in a large, unrealistic shadow. A workaround for this is to create a func_brush from the material, disable the shadows, and utilize the toolsblocklight tool texture. This can be easy or difficult, depending on the size of the prop. Basically, you must draw brushes of toolsblocklight where light would normally be blocked on the brush/prop.
By creating the trusses out of Block Light material, you can "fake" the shadows.
