First off, a shameless plug to my website deticated to Source Engine Level design. You can find downloads, tutorials, and more content here: TopHATTwaffle's Website[www.tophattwaffle.com]

Lighting is a very important part of levels. It can change the mood, feeling, and immersion level for the player. Without light, a level is never truly complete. VALVe's lighting has been increasing over the years, but still mostly remains lightmapped, with some dynamic shadow mapping added in newer games.

In this guide you'll learn from the basics, to more advanced parts of lighting. So kick back and enjoy the read.

VRAD is the command-line tool that takes a compiled BSP map and embeds lighting data into it. VRAD’s static and pre-compiled light is bounced around the world with a radiosity algorithm.
VRAD will:

• Generate lightmaps
  
• Generate ambient samples
  
• Generate per-object or per-vertex prop_static and detail prop lighting

VRAD is the generally the slowest (assuming that you've optimized VIS correctly in the level.) of the three compilers due to the many, many calculations it must perform. Lighting optimization can help, as can ensuring your map is free of leaks

Tip 1 Placing a standard light entity is rather simple, but the most common mistake is placing it too close to the model. In real life the light is projected from the bulb, but this is not how it works in source engine. No matter how bright a light is when placed too close to a brush will give a rather unsightly bright circle. The light is actually projected from the center of the entity, the small “X” in the middle. All you need to do is pull the entity away from the brush. Both lights have the same brightness of 150. You can see the difference in the screenshot.

Tip 2 The colors of the lights are important to the feel, and mood of a area. This is quite some reading you can do on this. Here are the links.
Color Temperature
Lighting Psychology

A light is almost NEVER solid white, this is why I get a bit angry when I see a 255 255 255 200 light. (All light in source engine is colored in Red Green Blue Intensity)

The lighting psychology is a good thing to read, it will allow you get inside of the player’s head to keep them feeling what you want.

Most lights in game will be from a red, to a blue. Whilst most lights lights in the real world produce a warm yellow glow. You will see me mostly use a yellow glow in my maps. The light settings for the first picture is: 255 239 202 150

• Yellow/Green – When a player stumbles upon a room lit by yellow lighting, it automatically makes them feel either accomplished, content, or comfortable, depending on the situation. Also a very stealthy color. Makes the player more aware, and more careful. It also gives the environment a living, breathing quality.
  
• Blue/Purple – The color of sadness. Blue rooms seem very full of memory. It’s the opposite of yellow, so it’s a good way to make players slow down and think. It can also cause players to second guess, so be careful.
  
• Red/Orange – Using red will make players feel like they need to do things quickly. Almost like the place is “gonna blow.” Putting enemies in the way of the escape only helps exaggerate the suspense of the situation.
  
• White/Brightness – White doesn’t really make the player think much. Normally just makes the player focus on the job that needs to be done and not much else. If you want to make a good map, use white when NPCs are talking or telling a story. Players will focus more on the talking than the unimpressive background.
  
• Black/Darkness – Gives a large sense of uncertainty and insecurity. Good for scary maps. If you use this, don’t use it too much because, like white, it’s not meant for fun. When a player has just finished a completely dark portion of the map, make sure that when they ascend, they see something really bright and cool for a sense of accomplishment and contrast.

Tip 3 The brightness, or intensity, can help set the mood almost as much as color. This is a shot of the same light, with 4 different brightness settings.

Tip 4 NEVER name a light unless you need to. Giving a light entity a targetname makes VRAD compile a second lightmap “page” for the surfaces that its emitted light touches. This won’t harm in-game performance, but it will increase compile time and BSP filesize, regardless of whether the light ever receives input to change its state.

However, the system can be overloaded if you try to make it handle a large number of overlapping named lights (since the number of pages needed increases exponentially). When this happens performance can be harmed and you may well see lighting anomalies.

VRAD attempts to avoid this with its hard-coded limits of two switchable lights affecting a brush face and 32 pages in total. You can help too by giving lights that will always change state at the same time a shared targetname, which makes VRAD merge their pages together.

A static, invisible, omni-directional light source. Can be turned on and off through the I/O system (note that this will increase the complexity of your lightmaps, as pre-compiled values must be stored for each on/off combination and cost more memory). Able to set up with patterns given effects but cannot move locations. Light is cast in all directions from the origin of the entity. The brightness depends upon the falloff values you set up. This light entity is the simplest of all lights and is used commonly.

While light travels from its source, it usually diminishes in intensity, limiting the area that its source can illuminate. This diminishing is called “light attenuation” or “fall-off.

The light_spot is a very versatile form of lighting. Although it is typically use to direct light in a cone shape, it can be changed depending on your need.
When the light_spot is first placed you will see a cone displayed from it, this shows the path that the light will take. This is rather simple to set up. It can also be used to create a florescent light. This is a more favorable option over the light entity.


There is a inner, and outer angle. This allows you to change how the light_spot displays light. In the screenshot you see a cone, this has been changed to give use the florescent light feel. These are the settings used for light_spots in the picture to the right.

• 1. Just a light entity, With the brightness of: 255 227 187 600
  
• 2. light_spot, with the brightness of: 255 227 187 600 inner angle:50 outer angle:90
  
• 3. Light_spot, with brightness of: 255 227 187 300 inner angle:50 outer angle:90. AND a light with the brightness of: 255 227 187 15, and a ratio of 0:1:0 (you will learn about this ratio below)

There are many things that can be done to further make the lighting in your map look real. This is done with the Constant-Linear-Quadratic Falloff. These are how the light is projected. The lights are stock set to 100% Quadratic. (Constant:0 Linear:0 Quadratic:1 (0:0:1)) Keep in mind that this is ALOT of information to take in, that is one reason this is not a video. you can re-read things easier then re-watching.
The information below if straight from the VDC


Constant Attenuation - The picture on the right shows a lightsource displaying the simplest of attenuations: Constant attenuation. The keyvalues Constant, Linear and Quadratic have here been set to “1″, “0″ and “0″ respectively, creating a Constant-Linear-Quadratic ratio of 1:0:0, meaning that the attenuation is 100% Constant, 0% Linear, and 0% Quadratic.

The 100% constant attenuation will result in a light that has no attenuation at all. The intensity, represented by the brigtness setting of the light entity, will be totally unaffected by distance, continuing until it hits a surface, theoretically capable of illuminating an infinite area. This type of light can be seen from the sky (sunlight, monlight and starlight), and other large and distant light sources. It can also be used for setting local ambient lighting (by letting it illuminate the shadows of the room) or mood lighting.

As a 100% constant lightsource is an extreme type of light, constant light is mostly used in combination with the other two types of attenuations, to “soften” or limit them.


Linear Attenuation - This is the same light entity, but at a 0:1:0 ratio, making its lighting 100% linear instead.

Mathematically, the decline of this type of light is linear, inversely proportial to the distance from the light source (I = 1/d where I is intensity and d is distance). This means that the light intensity (set by its brightness) will diminish (at a fixed rate) as it travels from its source. To compensate for this decline, Valve has boosted the intensity of the lightsource to 100 times its brightness.

In the real world a 100% linear lightsource would be practically impossible, as it would represent a real world soft light of infinite size, but in the virtual world, a 0:1:0 lightsource is believable for most entity based lightsources.


Quadratic Attenuation - This is a normal, unmodified light source, preset to 0:0:1, making it 100% Quadratic.

Mathematically, the attenuation of a 100% quadratic light is exponential (quadratic), expressed as “I = 1/d^2″, meaning that the further the light travels from its source, the more it will be diminished. This creates a very sharp drop in light. To compensate for the fast decline of quadratic lights, Valve has boosted the intensity of them to be 100^2 (10 000) times more intense than the actual intensity.

An unmodified (100% quadratic) lightsource represents a pure “point light source” in the real world. In the virtual world, this effect looks like a lightsource shining through murky water, looking far from typical real world lightsource behavior.
When used in moderation, quadratic attenuation can be used not only for small lightsources, but also to reflect light travelling through something more dispersing than air, like air humidity (like fog) or water.

Mixing Attenuation - When blending between these three types of attenuation, you set the proportions of each attenuation type against the other two types. To avoid confusion, keep in mind that you can set the scale of these proportions as you wish: A proportion of 3:6:1 gives the exact same result as 6:12:2, or 30:60:10, which can easily be translated to 30%, 60% and 10%.

Although the Constant-Linear-Quadratic Falloff is a very good way to fine tune the projection of the lighting in your level, this can be very confusing. You can still tune the lighting using the falloff distance.

This is, in theory, the same as the information listed above, but you have a little less control. But it’s easier to set up, just set the numbers and go.

50 percent falloff distance: What ever you set this to the light will dissipate down to 50% by this distance. Same for the 0%.

As you can see from the screenshots above and below, the falloff gives you almost the same effect you would get with the Constant-Linear-Quadratic Falloff. All of the lights in the picture here use these settings: 255 239 202 200

Then env_projected texture is a special entity that can project light, and dynamic shadows of the receivers.
As you can see here it projects a texture and draws the dynamic shadows. This gives us a very erry feeling that can be frightful if seen from the corner of your eye. If you do not give it a texture it will just display a color that you tell it to. Any light projected from this will NOT be bounced like other lights compiled with VRAD are.

You’re only allowed to have one of these on at a time. Any game made after Portal 2 will have nicer shadows emitted from this entity. Games before Portal 2 will have grainy shadow edges.

Games such as Counter-Strike Global Offensive can have a dynamic lights broadcast from the skybox using the shadow_control entity along side the light_enviroment

This is a entity that projects the light from the “Tools/Skybox” texture. When creating part of your level that uses a outside area you should use this. This, used in combo with, env_sun gives you the good feel of the sun. The env_sun just displays a sprite, where the light_environment actually displays the light. To set this light up just give it a angle and some color. You should only have 1 light_environment in a level.

There are things you can add to your level that will produce a glow effect from the source of the entity. These entities are Env_Sprites, and point_spotlights.

Env_Sprites are typically used for a normal light glow, they are defaulted to be circle light glows, but can be changed to any sprite.

First to create a env_sprite, just create it. Then send the render mode to “World Space Glow.” This will allow the sprite to render in game (See Render Modes for details) Then set your color and FX amount. This will tone down, or intensity the effect of the sprite. For a florescent light set the FX amount to around 140ish.

Point_spotlights are used to create a light beam from the source, and a blinding effect when looked at straight on. These are even easier to set up then the env_sprite. Just create one and point it. Under the flags of the point_spotlight there is a flag that will enable the dynamic light for this. This effect is very expensive to render and should not be used alot.

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. The first image with the finest shadows has a lightmap scale of 4, the 2nd image is 16, and the 3rd image is 64. To change the lightmap scale just open the face edit sheet and lower the value. This value should remain a power of 2 between 2 and 64. (2,4,8,16,32,64) When settings a lightmap scale, set it to the receiving face, not the casting. To view your light map grid int he 3D view, click on “Camera” on the 3d view and select “3D Lightmap Grid”

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.

HDR lighting gives your map a whole new feel of realism with lighting. It stands for High Dynamic Range Lighting, basically. It makes things glow as they would in real life. When you go from a dark tunnel, to a bright outside environment you are basically blinded. Just like if you wake up at noon and look outside. But the HDR is not always good to right after a compile, it is often too bright, or dark. To fine tune this you need a env_tonemap_controller. Just add it to a map, then name it “tonemap” Next load the game. Fire this console command:

• ent_fire tonemap setautoexposuremax #
  
• ent_fire tonemap setautoexposuremin #
  
• ent_fire tonemap SetBloomScale # (Bloom ONLY)

For the numbers on the max, I like to start with 6 and go from there. Then set the min to about .75 and go from there. Then write these numbers down once you are happy with them. You may not notice anything happen when you change the bloom scale, this is because HDR is on, and not bloom. Basically just take the low average of the max and min. So if max=4 min=.5 set the bloom to about 1.5. Then create a logic_auto in your level and add the following outputs:

• “onmapspawn” tonemap,setautoexposuremax,#,0.00,-1
  
• “onmapspawn” tonemap,setautoexposuremin,#,0.00,-1
  
• “onmapspawn” tonemap,SetBloomScale ,#,0.00,-1

Make sure to compile your map with HDR to see the results.

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 separate 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 no affect on performance, apart from adding extra time for RAD to compile, so use them on your final compile.

The Orange Box engine (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. These are not normally recognized by VRAD, 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, 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 is usually a necessary step in making the map’s props look convincing.

Simply append -staticproplighting to the $light_exe Parameters list (see above).

NOTE: 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.”

- Valve Developer Community
To see what these do, view the images/watch the end of Tutorial 74: Advanced lighting[www.tophattwaffle.com] has gone over this as well.

There are alot of limits that the source engine has limits on. I’ll list all of the limits I know about below (lighting limits only.)

• One environment in a given level. Only the first one will work. Having more then one in a level may cause errors.
  
• Any given brush can have a max of 4 different light styles on it. Having more will cause lighting errors.
  
• Lights styles are different types of light colors, not brightness.
  
• EX of 5 different lights styles: 255 255 0 200, 0 255 255 200, 255 0 255 200, 128 128 128 200, 0 128 255 200
  
• EX of 6 different lights, but not different styles. 255 255 0 100, 255 255 0 300, 0 255 255 600, 0 255 255 150, 128 128 128 100, 128 128 128 1200. This will not cause errors, because there are only 3 different styles. The brightness does not effect a style.
  
• The brightness of a light must be positive, if not it will suck the light from your map. Or cause errors.
  
• 32 Light map pages, when naming lights that would share a face. Name them the same.