Intermediate Lighting: Difference between revisions
SintaxError (talk | contribs) |
Angry Beaver (talk | contribs) (spellcheck + touchup + wrote using lightmaps) |
||
| Line 2: | Line 2: | ||
=Introduction= | =Introduction= | ||
{{Int lvl design}} | {{Int lvl design}} | ||
This tutorial will cover the more advanced lighting techniques used in [[Source]] maps. If you are new to lighting in [[Valve Hammer Editor|Hammer]], you may want to read the [[Adding_Light|basic light tutorial]] first. To begin all the possible ways to create light and then | This tutorial will cover the more advanced lighting techniques used in [[Source]] maps. If you are new to lighting in [[Valve Hammer Editor|Hammer]], you may want to read the [[Adding_Light|basic light tutorial]] first. To begin the tutorial all the possible ways to create light will be covered and then onto all the settings related to playing with lighting. This will then be followed by a set of more in depth mini articles on how to use and take advantage of the lighting you’ve been introduced to. | ||
{{clr}} | {{clr}} | ||
=Light Entities= | =Light Entities= | ||
This is a list and rundown of each entity you can use to cast physical light. The titles for each section link to the page for the entity itself. | This is a list and rundown of each entity you can use to cast physical light. The titles for each section link to the page for the entity itself. It’s important to remember that these entities cast light in some form or another. | ||
==[[light]]== | ==[[light]]== | ||
| Line 20: | Line 20: | ||
A directional form of the light entity, its cone-shape allows for a directed form of light. Again it can be turned on and off through inputs, though a switchable light_spot may cause lightmap errors. This is a static light that can be pointed in any direction. And is also recommended for common use. | A directional form of the light entity, its cone-shape allows for a directed form of light. Again it can be turned on and off through inputs, though a switchable light_spot may cause lightmap errors. This is a static light that can be pointed in any direction. And is also recommended for common use. | ||
{{note|When using this entity, it may be necessary to turn the brightness value up significantly to | {{note|When using this entity, it may be necessary to turn the brightness value up significantly to achieve visible results. Streetlights for example may need brightnesses of 3000-4000.}} | ||
==[[light_dynamic]]== | ==[[light_dynamic]]== | ||
{{todo|add img}} | {{todo|add img}} | ||
An invisible light source that can change and move over time. | 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 shape light and a spot world light. Some values may affect one and not the other.}} | {{note|This entity actually consists of two lights, a cone shape light and a spot world light. Some values may affect one and not the other.}} | ||
| Line 34: | Line 34: | ||
{{todo|add img}} | {{todo|add img}} | ||
A directional light cast in only one direction, the direction is decided by the | A directional light cast in only one direction, the direction is decided by the key values entered. The key is that the light is only cast from the <code>tools/toolsskybox</code> texture. The first key value, Brightness, controls direct lighting. This approximates direct sunlight. The second key value, Ambient, controls indirect lighting from the sky. This is the diffuse light that is cast on every face that can "see" the sky. Basically the shadow the light leaves. | ||
If you don't want to come up with your own values for this entity, the values used in the official [[Valve]] games for each skybox, are given [[Sky_List|here]]. | If you don't want to come up with your own values for this entity, the values used in the official [[Valve]] games for each skybox, are given [[Sky_List|here]]. | ||
Normally, only one light_environment entity is required per level. A [[3D Skybox]] requires placement of an extra light_environment within the 3D skybox. If multiple light_environment entities are placed, [[Vrad]] uses the | Normally, only one light_environment entity is required per level. A [[3D Skybox]] requires placement of an extra light_environment within the 3D skybox. If multiple light_environment entities are placed, [[Vrad]] uses the key values from the first found light_environment to calculate the lighting.{{clr}} | ||
==[[Glowing Textures|Glowing Textures]]== | ==[[Glowing Textures|Glowing Textures]]== | ||
{{todo|add img}} | {{todo|add img}} | ||
In a few cases | In a few cases it’s possible to make the texture itself appear bright or even to emit light. 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 affect across a surface that’s meant to be the lights source.{{clr}} | ||
==[[env particlelight]]== | ==[[env particlelight]]== | ||
| Line 53: | Line 53: | ||
{{todo|add img}} | {{todo|add img}} | ||
A straight light beam used for a spotlight | A straight light beam used for a spotlight effect. A mix of several affects including a flare when looking at it directly, a beam along the direction it’s pointing, and a light_dynamic where the beam touches the ground. While incapable of moving on its own it may be tied to a moving entity, alternately there is the [[npc_spotlight]] option. This is exactly the same as a spotlight but is controlled by an NPC's intelligence and therefore can be controlled precisely and fluently. Due to the dynamic light this is an expensive lighting source to render and should be used sparingly.{{clr}} | ||
=Related Items= | =Related Items= | ||
{{todo|add img}} | {{todo|add img}} | ||
This is a list of all the topics related to lighting itself but don't emit light. While none of these emit any physical light | This is a list of all the topics related to lighting itself but don't emit light. While none of these emit any physical light their all essential to creating effects with it. If it’s controlling the lighting of entities or controlling an [[npc antlion|antlion's]] shadow they all fall under lighting effects.{{clr}} | ||
==[[Info lighting]]== | ==[[Info lighting]]== | ||
| Line 67: | Line 67: | ||
==[[env_lightglow]]== | ==[[env_lightglow]]== | ||
[[image:env_lightglow.jpg|thumb|150|right|the | [[image:env_lightglow.jpg|thumb|150|right|the light glow effect]] | ||
{{todo|add img}} | {{todo|add img}} | ||
| Line 75: | Line 75: | ||
{{todo|add img}} | {{todo|add img}} | ||
Often misinterpreted as a light that creates lighting like the sun it is instead an effect that places a flare in the sky that looks and acts like the sun. Casting no light at all it is often used with a | Often misinterpreted as a light that creates lighting like the sun it is instead an effect that places a flare in the sky that looks and acts like the sun. Casting no light at all it is often used with a light_environment to create its lighting affect.{{clr}} | ||
==[[shadow_control]]== | ==[[shadow_control]]== | ||
| Line 86: | Line 86: | ||
{{todo|add img}} | {{todo|add img}} | ||
This forces a particular brush face to not | 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 hid incorrect or bad shadows that create an incorrect look. | ||
==[[env_tonemap_controller]]== | ==[[env_tonemap_controller]]== | ||
| Line 95: | Line 95: | ||
==[[Lightmap|Lightmaps]]== | ==[[Lightmap|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 | 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. | ||
[[image:intlight_lmap4.jpg|thumb|135px|left|A lightmap scale of 4]] | [[image:intlight_lmap4.jpg|thumb|135px|left|A lightmap scale of 4]] | ||
[[image:intlight_lmap16.jpg|thumb|135px|left|A lightmap scale of 16]] | [[image:intlight_lmap16.jpg|thumb|135px|left|A lightmap scale of 16]] | ||
| Line 101: | Line 101: | ||
==[[Vrad]]== | ==[[Vrad]]== | ||
It is the part of the compiling process that will generate all your lighting effects, | It is the part of the compiling process that will generate all your lighting effects, it’s also one of the longest parts of a compile and can often be the one you need to run the most. With no way to estimate lighting effects apart from experience, it can often be tiresome to compile enough time to get a lighting effect right. The topic of how to compile Rad well is tackled later. For now familiarization with its features and setup should be a priority.{{clr}} | ||
=Techniques= | =Techniques= | ||
This covers how to use the mentioned items to create effective lighting. Before a lot of practical knowledge was covered. But knowledge is useless unless it's utilized well. The next few sections are specifics about how to use all the information to create better lighting in your maps.{{clr}} | This covers how to use the mentioned items to create effective lighting. Before, a lot of practical knowledge was covered. But knowledge is useless unless it's utilized well. The next few sections are specifics about how to use all the information to create better lighting in your maps.{{clr}} | ||
==Creating a | ==Creating a True Light Source== | ||
Creating a true light source can often be a challenge. Simply placing a light entity does nothing to explain where that light came from or why its there. A true light source is one that appears like it should be there and sits comfortably | Creating a true light source can often be a challenge. Simply placing a light entity does nothing to explain where that light came from or why its there. A true light source is one that appears like it should be there and sits comfortably within the environment. Often a good light is made up of multiple entities. Commonly there are two: one for the light and one for its source like a prop_static or a func_detail with an appropriate texture. | ||
[[Image:Light_decklight01_on.jpg|thumb|125px|right|Common light]] | [[Image:Light_decklight01_on.jpg|thumb|125px|right|Common light]] | ||
The first step is to determine what lighting sources are | The first step is to determine what lighting sources are available. Look for textures or models that would be emitting light. Filtering by the word 'light' in either the model or texture browser works well. Now pick one that fits the feel of the room(i.e. industrial lights for an industrial scene) and place that model or texture in the room. For this example pick the light shown on the right and place it with a prop_static. | ||
Now that there's something that looks like it would emit light, the next step is to create the light it's emitting. Look at the source | Now that there's something that looks like it would emit light, the next step is to create the light it's emitting. Look at the source that’s been chosen. Is the light going to be slightly colored? Is it going to be only in one direction? Use the assorted light entities to create the effect and set the properties up right. With the given example the light is going to be focused in one direction, so pick a light_spot. Next, this is a bright light, so give it a brightness of 200. Then look at its colour, it's a very white light so confirm it's a white light being emitted. Now line it up compared to the prop_static, alter the angles so it appears to come from the prop static. | ||
Now | Now there’s a light lined up to its source, there may be a problem though. Sometimes the model used for the source is going to block the light that the light is trying to cast. So go into the prop_static's properties and make sure that it has "Disable shadows" set to "yes". This means that the source of the light will not block the light itself. Now it’s a working setup group them so they always stay together. Now if you need more lights you can copy this group. | ||
Another way to create a high quality light source that portrays real life better but doesn't compromise on | Another way to create a high quality light source that portrays real life better but doesn't compromise on performance is combination of a light and light_spot. Position the light_spot as described above, but position the light around 50 units away from the model that is the light's source. Make this light have a brightness of approximately 50 and is the same colour as the light_spot. This will often create a more correct form of glow on surfaces that the light_spot often lacks. {{clr}} | ||
==Static Vs Dynamic== | ==Static Vs Dynamic== | ||
There are many advantages, performance wise, of using static light sources over dynamic ones. Static lights carry no additional processing weight so | There are many advantages, performance wise, of using static light sources over dynamic ones. Static lights carry no additional processing weight so their use is essential to fast rendering maps. Dynamic lights can carry a lot of rendering weight and can be expensive to use in your map. Its important to know where and when to use each type of light and avoid using the wrong type. | ||
Firstly static lights are calculated during the VRAD compile process; therefore, there is next to no calculations done | Firstly static lights are calculated during the VRAD compile process; therefore, there is next to no calculations done in game it merely needs to render the light calculated which is a fast process. The common static lights are light, light_spot and light_environment but there are conditions that can change this. The problem comes with a static lights is the fact that it is static. While they allow very precise and detailed lighting no special effects can be given with static lighting because it’s not going to change. | ||
Dynamic lighting on the other hand comes in two flavors. | Dynamic lighting on the other hand comes in two flavors. There are the switchable lights and the true dynamically calculated lights. Each has its own processing weight but both are expensive to render and should be used sparingly. | ||
Switchable lights are the same as | Switchable lights are the same as static lights in that they use lightmap information compiled during RAD. A light is set as being switchable by one of three things such as giving it a name, giving it a style, or giving it a pattern. Regular lights that don't support dynamic effects are the lights generally used as switchable lights, this includes lights like light, and light_spot but '''not''' light_environment. Switchable lights use a set of two lightmaps on and off. Switchable lights alternate or blend between the two lightmaps, this allows partial brightness while keeping it to just two lightmaps. This gives all the benefits of the static lighting but allows it to change and be partially dynamic. Say you have two switchable lights shining on the same face, how many lightmaps are needed? | ||
*Light 1 & 2 ON | *Light 1 & 2 ON | ||
*Light 1 ON, 2 OFF | *Light 1 ON, 2 OFF | ||
*Light 1 OFF, 2 ON | *Light 1 OFF, 2 ON | ||
*Light 1 & 2 OFF | *Light 1 & 2 OFF | ||
That's four states in total. You add a third switchable light and it goes up to eight lightmaps. Here becomes the problem with switchable lights, it becomes expensive in lightmaps to create all the possible states. So expensive | That's four states in total. You add a third switchable light and it goes up to eight lightmaps. Here becomes the problem with switchable lights, it becomes expensive in lightmaps to create all the possible states. So expensive in fact that there is a hardcoded limit that means you can only have two switchable lights affecting the same face. There is a slight solution though, the lights with identical names will all be given the same lightmap, so you can have 50 switchable lights with the same name shining on the same face. Because of the extra lightmaps switchable lights use it increases the amount of time it takes RAD to run, increases file size, and also uses up system resources when it alternates between them; however, a switchable light sat in one state or the other has little or no more effect than a static light. | ||
True dynamic lighting is something that has to be built into the entity itself, its most often recognized by the Parent property within the entity. The entities with the built in dynamic effect are light_dynamic and point_spot. Point_spot is special in the unique fact that is has a flag that can enable it as dynamic or static, its set to dynamic by | True dynamic lighting is something that has to be built into the entity itself, its most often recognized by the Parent property within the entity. The entities with the built in dynamic effect are light_dynamic and point_spot. Point_spot is special in the unique fact that is has a flag that can enable it as dynamic or static, its set to dynamic by default and can often catch you off guard. The dynamic process done for dynamic lights is run entirely within the game, this means it has little to no effect on the RAD compile or file size but it will slow down your map. The system slowdown caused by dynamic lights is generally consistent as the light needs to be rendered continuously. Such entities should only be used when the source of the light is moving, if the light itself is not meant to move then it shouldn't be a true dynamic light. If it’s merely meant to turn on and off it should be switchable. No movement should be static. If used improperly the costs of using dynamic lighting will be outweighed by the benefits of doing so. Dynamic lights should be used even more sparingly than switchable lights. Another down side to the dynamic light is that to simplify the calculations it doesn’t run process like reflection and diffusion, this results in harsher simpler looking lights. | ||
Static lights are easy on the engine and give great detail, but dynamic lights represent the possibility for movement and change, but cost a greater | Static lights are easy on the engine and give great detail, but dynamic lights represent the possibility for movement and change, but cost a greater amount to render and loose detail. The easiest way to tell what effect the dynamic lights are having is to test your map with the <code>+[[Showbudget]]</code> command. This allows you to figure out when an effect is too much and lighting effects are slowing down your map. Good use of dynamic lights can only improve your map, but they can be a costly effect. | ||
{{clr}} | {{clr}} | ||
==Using | ==Using Lightmaps Well== | ||
Lightmaps store nearly all the lighting information with source levels, their efficient use basically equates to efficient lighting. The key contributor to file size efficient lightmap usage is a must for anyone wishing their map to be downloaded. But if it just stores the lighting how is it used, and what makes it efficient. | |||
The key is the lightmap scale, this determines how much information will be stored about the lighting on that face. More information stored, bigger file sizes. Small lightmap scales allow for small details in the lighting on faces but come at the cost of a bigger file. Large lightmap scales only allow for large details and little clarity but allow for smaller files. So the biggest key becomes determining when a face needs a detailed lightmap, and when it doesn't. Mostly this can be eyeballed within a compiled map in game. The key is to look for the faces that receive high contrast shadows or specific details. They are often the best candidates for low lightmap scales as the lighting detail will be pulled out. Faces with slow blends or lighting that only slightly differs may only need a large lightmap scale as the extra detail given by a lower scale would be unused and wasted. Another key apart from whether the face needs it is whether the face can take it. If you were to decrease the scale on a large face it would add substantially more to the file size. Oppositely a slight increase in scale on a large face could save a large amount of file size. Keeping faces you’re scaling up small and scaling down large faces is another solid approach to take. | |||
[[Image:intlight_lightmaps.jpg|thumb|200px|right|A working 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 used in Hammer. For those unfamiliar with the lightmap view in Hammer its easy to access, left click on the word Camera in the top left of your 3D view. Now from the drop down select 3D Lightmap Grid, It will show and color code the lightmaps on your faces. Yellow means a more detailed face, white is standard, and blue is larger. The hallway has wall mounted lights and a few ceiling lights as well. In the picture it’s clear to see where I increased and decreased the lightmap. The front of the pillar has an increased lightmap because of the light source on its face. To catch all the detail of the light being emitted it uses a low scale. 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, looking at the picture little to no detail or change is seen in the lightmap so their 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 maps scale for crisp beautiful shadows the expense will outweigh the benefit, instead finding the balance between increasing and decreasing the lightmaps may take a few lighting compiles and some guesswork but used correctly can enhance your map and reduce its file size. | |||
{{clr}} | |||
==Compiling RAD Well== | ==Compiling RAD Well== | ||
| Line 145: | Line 153: | ||
=Conclusion= | =Conclusion= | ||
This covers the base of all lighting effects. Any lighting affect that can be | This covers the base of all lighting effects found in standard source games. Any lighting affect that can be achieved is a mixture of all or some of these effects. | ||
{{todo|create nav bar}} | {{todo|create nav bar}} | ||
[[Category:Level Design]] | [[Category:Level Design]] | ||
Revision as of 20:58, 26 June 2006
Introduction
Template:Int lvl design This tutorial will cover the more advanced lighting techniques used in Source maps. If you are new to lighting in Hammer, you may want to read the basic light tutorial first. To begin the tutorial all the possible ways to create light will be covered and then onto all the settings related to playing with lighting. This will then be followed by a set of more in depth mini articles on how to use and take advantage of the lighting you’ve been introduced to.
Light Entities
This is a list and rundown of each entity you can use to cast physical light. The titles for each section link to the page for the entity itself. It’s important to remember that these entities cast light in some form or another.
light
An invisible light source. Can be turned on and off through inputs. 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 and cheapest of all lights and is the most useful. Use this light whenever possible.
light_spot
A directional form of the light entity, its cone-shape allows for a directed form of light. Again it can be turned on and off through inputs, though a switchable light_spot may cause lightmap errors. This is a static light that can be pointed in any direction. And is also recommended for common use.
Note:When using this entity, it may be necessary to turn the brightness value up significantly to achieve visible results. Streetlights for example may need brightnesses of 3000-4000.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 shape light and a spot world light. Some values may affect one and not the other.light_environment
A directional light cast in only one direction, the direction is decided by the key values entered. The key is that the light is only cast from the tools/toolsskybox texture. The first key value, Brightness, controls direct lighting. This approximates direct sunlight. The second key value, Ambient, controls indirect lighting from the sky. This is the diffuse light that is cast on every face that can "see" the sky. Basically the shadow the light leaves.
If you don't want to come up with your own values for this entity, the values used in the official Valve games for each skybox, are given here.
Normally, only one light_environment entity is required per level. A 3D Skybox requires placement of an extra light_environment within the 3D skybox. If multiple light_environment entities are placed, Vrad uses the key values from the first found light_environment to calculate the lighting.
Glowing Textures
In a few cases it’s possible to make the texture itself appear bright or even to emit light. 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 affect across a surface that’s meant to be the lights source.
env particlelight
A normal light that lights only the particles created be an env_smokestack and lights nothing else. Useful for enhancing lighting in areas with steam and such but rarely used due its specific nature.
(npc or point)_spotlight
A straight light beam used for a spotlight effect. A mix of several affects including a flare when looking at it directly, a beam along the direction it’s pointing, and a light_dynamic where the beam touches the ground. While incapable of moving on its own it may be tied to a moving entity, alternately there is the npc_spotlight option. This is exactly the same as a spotlight but is controlled by an NPC's intelligence and therefore can be controlled precisely and fluently. Due to the dynamic light this is an expensive lighting source to render and should be used sparingly.
Related Items
This is a list of all the topics related to lighting itself but don't emit light. While none of these emit any physical light their all essential to creating effects with it. If it’s controlling the lighting of entities or controlling an antlion's shadow they all fall under lighting effects.
Info 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.
env_lightglow
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.
env_sun
Often misinterpreted as a light that creates lighting like the sun it is instead an effect that places a flare in the sky that looks and acts like the sun. Casting no light at all it is often used with a light_environment to create its lighting affect.
shadow_control
Used to control all the dynamic shadows cast within the game. Shadows cast by NPC's or physics entities fall into this category. Used to line up the shadows angles so they appear correct with lighting. The one directional nature may be a problem but use of triggers to even it out should help.
info_no_dynamic_shadow
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 hid incorrect or bad shadows that create an incorrect look.
env_tonemap_controller
Used to control the exposure of the HDR lighting effects. Unless used with fully implemented HDR it has little/no effect.
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.
Vrad
It is the part of the compiling process that will generate all your lighting effects, it’s also one of the longest parts of a compile and can often be the one you need to run the most. With no way to estimate lighting effects apart from experience, it can often be tiresome to compile enough time to get a lighting effect right. The topic of how to compile Rad well is tackled later. For now familiarization with its features and setup should be a priority.
Techniques
This covers how to use the mentioned items to create effective lighting. Before, a lot of practical knowledge was covered. But knowledge is useless unless it's utilized well. The next few sections are specifics about how to use all the information to create better lighting in your maps.
Creating a True Light Source
Creating a true light source can often be a challenge. Simply placing a light entity does nothing to explain where that light came from or why its there. A true light source is one that appears like it should be there and sits comfortably within the environment. Often a good light is made up of multiple entities. Commonly there are two: one for the light and one for its source like a prop_static or a func_detail with an appropriate texture.
The first step is to determine what lighting sources are available. Look for textures or models that would be emitting light. Filtering by the word 'light' in either the model or texture browser works well. Now pick one that fits the feel of the room(i.e. industrial lights for an industrial scene) and place that model or texture in the room. For this example pick the light shown on the right and place it with a prop_static.
Now that there's something that looks like it would emit light, the next step is to create the light it's emitting. Look at the source that’s been chosen. Is the light going to be slightly colored? Is it going to be only in one direction? Use the assorted light entities to create the effect and set the properties up right. With the given example the light is going to be focused in one direction, so pick a light_spot. Next, this is a bright light, so give it a brightness of 200. Then look at its colour, it's a very white light so confirm it's a white light being emitted. Now line it up compared to the prop_static, alter the angles so it appears to come from the prop static.
Now there’s a light lined up to its source, there may be a problem though. Sometimes the model used for the source is going to block the light that the light is trying to cast. So go into the prop_static's properties and make sure that it has "Disable shadows" set to "yes". This means that the source of the light will not block the light itself. Now it’s a working setup group them so they always stay together. Now if you need more lights you can copy this group.
Another way to create a high quality light source that portrays real life better but doesn't compromise on performance is combination of a light and light_spot. Position the light_spot as described above, but position the light around 50 units away from the model that is the light's source. Make this light have a brightness of approximately 50 and is the same colour as the light_spot. This will often create a more correct form of glow on surfaces that the light_spot often lacks.
Static Vs Dynamic
There are many advantages, performance wise, of using static light sources over dynamic ones. Static lights carry no additional processing weight so their use is essential to fast rendering maps. Dynamic lights can carry a lot of rendering weight and can be expensive to use in your map. Its important to know where and when to use each type of light and avoid using the wrong type.
Firstly static lights are calculated during the VRAD compile process; therefore, there is next to no calculations done in game it merely needs to render the light calculated which is a fast process. The common static lights are light, light_spot and light_environment but there are conditions that can change this. The problem comes with a static lights is the fact that it is static. While they allow very precise and detailed lighting no special effects can be given with static lighting because it’s not going to change.
Dynamic lighting on the other hand comes in two flavors. There are the switchable lights and the true dynamically calculated lights. Each has its own processing weight but both are expensive to render and should be used sparingly.
Switchable lights are the same as static lights in that they use lightmap information compiled during RAD. A light is set as being switchable by one of three things such as giving it a name, giving it a style, or giving it a pattern. Regular lights that don't support dynamic effects are the lights generally used as switchable lights, this includes lights like light, and light_spot but not light_environment. Switchable lights use a set of two lightmaps on and off. Switchable lights alternate or blend between the two lightmaps, this allows partial brightness while keeping it to just two lightmaps. This gives all the benefits of the static lighting but allows it to change and be partially dynamic. Say you have two switchable lights shining on the same face, how many lightmaps are needed?
- Light 1 & 2 ON
- Light 1 ON, 2 OFF
- Light 1 OFF, 2 ON
- Light 1 & 2 OFF
That's four states in total. You add a third switchable light and it goes up to eight lightmaps. Here becomes the problem with switchable lights, it becomes expensive in lightmaps to create all the possible states. So expensive in fact that there is a hardcoded limit that means you can only have two switchable lights affecting the same face. There is a slight solution though, the lights with identical names will all be given the same lightmap, so you can have 50 switchable lights with the same name shining on the same face. Because of the extra lightmaps switchable lights use it increases the amount of time it takes RAD to run, increases file size, and also uses up system resources when it alternates between them; however, a switchable light sat in one state or the other has little or no more effect than a static light.
True dynamic lighting is something that has to be built into the entity itself, its most often recognized by the Parent property within the entity. The entities with the built in dynamic effect are light_dynamic and point_spot. Point_spot is special in the unique fact that is has a flag that can enable it as dynamic or static, its set to dynamic by default and can often catch you off guard. The dynamic process done for dynamic lights is run entirely within the game, this means it has little to no effect on the RAD compile or file size but it will slow down your map. The system slowdown caused by dynamic lights is generally consistent as the light needs to be rendered continuously. Such entities should only be used when the source of the light is moving, if the light itself is not meant to move then it shouldn't be a true dynamic light. If it’s merely meant to turn on and off it should be switchable. No movement should be static. If used improperly the costs of using dynamic lighting will be outweighed by the benefits of doing so. Dynamic lights should be used even more sparingly than switchable lights. Another down side to the dynamic light is that to simplify the calculations it doesn’t run process like reflection and diffusion, this results in harsher simpler looking lights.
Static lights are easy on the engine and give great detail, but dynamic lights represent the possibility for movement and change, but cost a greater amount to render and loose detail. The easiest way to tell what effect the dynamic lights are having is to test your map with the +Showbudget command. This allows you to figure out when an effect is too much and lighting effects are slowing down your map. Good use of dynamic lights can only improve your map, but they can be a costly effect.
Using Lightmaps Well
Lightmaps store nearly all the lighting information with source levels, their efficient use basically equates to efficient lighting. The key contributor to file size efficient lightmap usage is a must for anyone wishing their map to be downloaded. But if it just stores the lighting how is it used, and what makes it efficient.
The key is the lightmap scale, this determines how much information will be stored about the lighting on that face. More information stored, bigger file sizes. Small lightmap scales allow for small details in the lighting on faces but come at the cost of a bigger file. Large lightmap scales only allow for large details and little clarity but allow for smaller files. So the biggest key becomes determining when a face needs a detailed lightmap, and when it doesn't. Mostly this can be eyeballed within a compiled map in game. The key is to look for the faces that receive high contrast shadows or specific details. They are often the best candidates for low lightmap scales as the lighting detail will be pulled out. Faces with slow blends or lighting that only slightly differs may only need a large lightmap scale as the extra detail given by a lower scale would be unused and wasted. Another key apart from whether the face needs it is whether the face can take it. If you were to decrease the scale on a large face it would add substantially more to the file size. Oppositely a slight increase in scale on a large face could save a large amount of file size. Keeping faces you’re scaling up small and scaling down large faces is another solid approach to take.
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 used in Hammer. For those unfamiliar with the lightmap view in Hammer its easy to access, left click on the word Camera in the top left of your 3D view. Now from the drop down select 3D Lightmap Grid, It will show and color code the lightmaps on your faces. Yellow means a more detailed face, white is standard, and blue is larger. The hallway has wall mounted lights and a few ceiling lights as well. In the picture it’s clear to see where I increased and decreased the lightmap. The front of the pillar has an increased lightmap because of the light source on its face. To catch all the detail of the light being emitted it uses a low scale. 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, looking at the picture little to no detail or change is seen in the lightmap so their 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 maps scale for crisp beautiful shadows the expense will outweigh the benefit, instead finding the balance between increasing and decreasing the lightmaps may take a few lighting compiles and some guesswork but used correctly can enhance your map and reduce its file size.
Compiling RAD Well
Conclusion
This covers the base of all lighting effects found in standard source games. Any lighting affect that can be achieved is a mixture of all or some of these effects.