Intermediate Lighting: Difference between revisions
m (→[[info_no_dynamic_shadow]]: typo) |
|||
| Line 116: | Line 116: | ||
==Static Vs Dynamic== | ==Static Vs Dynamic== | ||
{{todo|discuss satic Vs Dynamic light, how and why}}{{clr}} | {{todo|discuss satic Vs Dynamic light, how and why}}{{clr}} | ||
There are many advantages, performance wise, of using static light sources over dynamic ones. Firstly as static lights are calculated using the RAD.exe during the compile process and therefore means there is less calculations needing to be done ingame. Unlike dynamic lights that have to be continually calculated and their effect rendered continually. | |||
However in real life when a light source moves, the effect it has upon the environment changes dynamically. Foe example, if a light was attached to the end of a string and was shot, it would swing about and the effects of the light intensity and shadows on various surfaces would be noticable as the light swings about. | |||
When lights are given names in the editor, during the RAD if there were two light sources shining on one surface, that surface will need to be calculated with: | |||
Light 1 & 2 ON | |||
Light 1 ON, 2 OFF | |||
Light 1 OFF, 2 ON | |||
Light 1 & 2 OFF | |||
By using names on many light entities, the length of compiling time suddenly increases quite rapidly. However, this is necessary to do if using dynamic light sources parented to something or that are switchable. If you plan to do something similar to having many light switch on and off at the same time. Name each of the light the same, as the RAD will only calculate each light being ON and OFF by its name. So if 10 light entities all have the same name, it will only calculate when all 10 are on or all 10 are off. | |||
To summerise, static lights are easy on the engine, but dynamic lights represent real-life better. | |||
==Using lightmaps well== | ==Using lightmaps well== | ||
Revision as of 02:46, 18 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 all the possible ways to create light and then move onto all the settings related to lighting. It will then finish by suggesting some common ways to implement lighting.
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. Its 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 achive visible results. Streetlights for exmaple may need brightnesses of 3000-4000.light_dynamic
An invisible light source that can change and move over time. Itsa 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 keyvalues entered. The key is that the light is only cast from the tools/toolsskybox texture. The first keyvalue, Brightness, controls direct lighting. This approximates direct sunlight. The second keyvalue, Ambient, controls indirect lighting from the sky. This is the diffuse light the 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 keyvalues from the first found light_environment to calculate the lighting.
Glowing Textures
In a few cases its 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 thats 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 affect. A mix of several affects including a flare when looking at it directly, a beam along the direction its 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, alternatley 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 precisley and fluently. Due to 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 thier all essential to creating effects with it. If its 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_enviornment 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 recive any of the dynamic shadows create by physics entities or npcs. Its used rareley 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 surface on top of each face that stores all the lighting information of a face. The stored light is then added to the face giving it brightness. The lightmap's value is the size of each pixel of light (luxel) that the lightmap stores. Smaller values means smaller luxels, thus a better resoultion and quality but higher files size and compile times.
Vrad
It is the part of the compiling process that will generate all your lighting effects, its 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 appart from experince, 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 familiraization 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 comfortabley wihtin the environment. Often a good light is made up of multiple entities, commonly theres two. One for the light, one for its source like a prop_static or a func_detail with an approriate texture.
The first step is to determine what lighting sources are avalible. Look for textures or models that would be emitting light. Filtering by the word 'light' in eithier the model or texture browser works well. Now pick one that fits the feel of the room, 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 palce it with a prop_static.
Now theres something that looks like it would emit light the next step is then to create the light its emitting. Look at the source thats been chosen, is the light going to be slightly coloured? Is it going to be only in one direction? Use the assorted light entities to create the effect and set the prooperties 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 a brightness of 200. Then look at its colour, its a very white light so confirm its 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 theres 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 your 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 its a working setup group them so they always stay together. Now if you need more lights you can copy this group.
Static Vs Dynamic
There are many advantages, performance wise, of using static light sources over dynamic ones. Firstly as static lights are calculated using the RAD.exe during the compile process and therefore means there is less calculations needing to be done ingame. Unlike dynamic lights that have to be continually calculated and their effect rendered continually.
However in real life when a light source moves, the effect it has upon the environment changes dynamically. Foe example, if a light was attached to the end of a string and was shot, it would swing about and the effects of the light intensity and shadows on various surfaces would be noticable as the light swings about.
When lights are given names in the editor, during the RAD if there were two light sources shining on one surface, that surface will need to be calculated with: Light 1 & 2 ON Light 1 ON, 2 OFF Light 1 OFF, 2 ON Light 1 & 2 OFF
By using names on many light entities, the length of compiling time suddenly increases quite rapidly. However, this is necessary to do if using dynamic light sources parented to something or that are switchable. If you plan to do something similar to having many light switch on and off at the same time. Name each of the light the same, as the RAD will only calculate each light being ON and OFF by its name. So if 10 light entities all have the same name, it will only calculate when all 10 are on or all 10 are off.
To summerise, static lights are easy on the engine, but dynamic lights represent real-life better.
Using lightmaps well
Compiling RAD Well
Conclusion
This covers the base of all lighting effects. Any lighting affect that can be achived is a mixture of all or some of these effects.