Advanced Lighting

== Light Entities ==
=== ===
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.
=== ===
A normal light that lights only the particles created by an and lights nothing else. Useful for enhancing lighting in areas with steam and such.
=== ===
Similar to a light_dynamic, this is an invisible projective light source that can change and move over time. Its position, field-of-view and range can change and it can be aimed at moving objects. env_projectedtextures are unique due to the fact that they cast real dynamic shadows from any geometry (brush or model) onto both brushes and models (even themselves), unlike render-to-texture shadows. This system is used for the player's flashlight in Source engine games.
env_projectedtexture is the most expensive light source in the engine. None of the lighting is done during map compilation, and all calculations are done real-time. Having more than one or two will drastically hurt performance on older video cards. Also, note that, when used on and earlier engine versions without the fixes found here, the shadows will be very "grainy," low-resolution, and unable to have a parent. These issues have been fixed in newer engine iterations like ; however, you are limited to rendering only one projected texture at a time (including the player's flashlight).
=== Glowing textures ===
In 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 .vmt or .rad file and is beyond the scope of this article. Doing so can save the mapper the effort of trying to create an even lighting effect across a surface that’s meant to be the light source.
Click on the Glowing Textures link above for more information.
== Related Entities ==
======
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 , naming it, and specifying that name in the properties for the Ladder prop.
======
Used 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 maps use this to simulate bloom from regular light sources as well, but it is recommended that you use instead.
======
This 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.
=== ===
Used to control the exposure of the HDR lighting effects. Can be given inputs to control more effects. It's common to have a to do the initial settings on loading the map.
=== Smoothing groups ===
Used 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. 
=== Lightmaps ===
A 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 ==
 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.
=== -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 file from the game in question using GCFScape or Crafty, place it in the game folder (or folder in case if the game (such as ) loads it's own light.rad in instead of custom one/edited light.rad.), 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).
This also enables support for lightmapping static props in and , with the same limitations as per-vertex lighting, plus inaccurate lighting if the prop has overlapping UVs, multiple materials, and/or multiple skins. See and 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.
==== 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 ===
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 series are a good example of this). This results in a large, unrealistic shadow. A workaround for this is to create a 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.
== See also ==
* Lighting
* Intermediate Lighting
* 
* Light editor
== External links ==
* Creating Shadows with -TextureShadows
* Advanced lighting Video Tutorial
Category:Level Design
Category:Lighting