Advanced Lighting

From Valve Developer Community
Revision as of 17:31, 31 January 2010 by JeffMOD (talk | contribs) (Info lighting: Added semicolon to fix grammar)

Jump to: navigation, search

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 shape light and a spot world light. Some values may affect one and not the other.

Glowing textures

A self-illuminating texture.
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 light source.

env_particlelight

A red light.
A 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 but rarely used due its specific nature.

Related entities

Info lighting

Info lighting.png

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.

env_lightglow

the light glow effect
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.

info_no_dynamic_shadow

An example in use
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.

env_tonemap_controller

Used to control the exposure of the HDR lighting effects. Unless used with fully implemented HDR it has little/no effect.

Smoothing groups

The cylinder on the left is not smoothed.
The cylinder in the middle is smoothed with a light map of 16.
The cylinder on the right is smoothed with a light map of 8.
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. Taking no extra cost except for adding time to rad compiles they are an essential part to final lighting effects.

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.

A lightmap scale of 4
A lightmap scale of 16
A lightmap scale of 64

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 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 (performance is unchanged). 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. Don't be afraid to split the face into segments if you need to.

Example

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 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 scales 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.

See also