Lighting

From Valve Developer Community
Jump to: navigation, search
English (en)español (es)русский (ru)中文 (zh)
... Icon-Important.png
Abstract Mapping series Discuss your thoughts - Help us develop the articles or ideas you want

Ammunition | Animals & Creatures | Antlions | Beams & Lasers | Cables & Ropes | Clouds & Sky | Color Theory | Combat | Combine | Compression | Doors | Dust, Fog & Smoke | Elevators | Level Transitions | Environmental Lighting & Weather | Explosions | Fire | Foliage | Glass & Windows | Headcrab | Health | Ladders | Lighting | Optimization (Level Design) | Physics | Retinal scanners | Sound & Music | Special effects | Terrain | Trains | Turrets | Water | Weapons | Zombie

Lighting refers to all systems in Source which light up a level to make it look realistic. There are many areas of knowledge about lighting that a source level designer should know, most of which are accessible through this page.

Guides

An example of a well-lit room.

Types

Static Light Sources

Tip.pngTip:Static lighting is compiled into lightmaps, which illuminate brushes and models, and cubemaps, which provide static reflections. It is free to render, as additional static lights only alter that which is already being processed.
light
A static, omni-directional point light source. (e.g. a naked light bulb or flame.)
light_spot
A static, uni-directional point light source. (e.g. a torch or flashlight) The conical beam angle cannot exceed 90°.
light_environment
Provides two linked light sources:
  • A diffuse 'ambient' light (representing reflected light from clouds and the atmosphere in general) that emits from all skybox surfaces
  • A directional 'brightness' light (representing sunlight or moonlight) that is only cast in a single direction.
Both are emitted from the toolsskybox and toolsskybox2d materials wherever they are used in a map. See also Skybox.
env_particlelight
Illuminates particles produced by env_smokestack. Particles are not affected by normal lighting. Use (no more than) two of these to make env_smokestack particles appear to reflect ambient lighting.
light_directional (in all games since Left 4 Dead)
Essentially a second (or third, or…) one of the direct light from light_environment. Like light_environment's direct light, it is emitted only from brush faces textured with toolsskybox.
Confirm:this is actually static, right? and not dynamic?
Glowing Textures
Any brush surfaces with a light-emitting material (as defined in lights.rad, either the one in your mod directory or the one in sourcesdk/bin/) applied will cast volumetric light in a 180° cone.

Static Light Receivers

Brushes
The "Lightmap Scale" tool in the Hammer Face Edit Dialog can be used to control how sharp or diffuse the lightmap of a brush surface will be—an effect most noticeable between areas of high contrast, e.g. shadows. Note that, while adding extra light sources will not significantly affect performance, decreasing lightmap scale (i.e., increasing resolution) will more directly increase map file size and memory usage.
prop_static
Unlike other model entities, prop_statics are lit statically: a lighting value is stored for every vertex, and the model's collision mesh (or, optionally, reference mesh) is used to calculate lightmap shadows.
There are the following options:
  • disableshadows - Do not cast lightmap shadows
  • disablevertexlighting - Only store a single lighting value for the entire model
  • disableselfshadowing - Prevents the entity from casting shadows on itself
  • ignorenormals - Ignores normals of vertex data to calculate lighting. This is extremely useful for foliage and other thin types of vertex meshes.
  • generatelightmaps (only in Source 2013 Multiplayer) - Allows the props to use lightmaps (like world brushes) if VRAD is run with -StaticPropLighting and the prop is not bumpmapped. Lightmap resolution can be configured with lightmapresolutionx and lightmapresolutiony. Can also be manually defined with the $lightmap shader parameter, including on non-static props.
Warning.pngWarning:Models use the same UVs for lightmaps as $basetexture, and the model's lightmap is affected by $basetexturetransform; as such, lightmapping on models with overlapping or tiling UVs may not appear as intended!
Additionally, lighting seams may appear on edges with non-contiguous texture UVs; this is more noticeable on lower-resolution lightmaps.
Icon-Bug.pngBug:Lightmaps for models with multiple materials do not compile properly in VRAD! A lightmap will only be compiled for the first material on the model, that is a combined version of all the UV's used by all materials.
PlacementTip.pngWorkaround: Define a pre-baked $lightmap in the VMT of the VertexLitGeneric material (can be obtained using -dumppropmaps in VRAD).
Warning.pngWarning:Model lightmaps generated with VRAD are compiled as RGB888 (24-bit SDR) PPL files which can result in noticeable color banding when brightly lit in HDR mode.
PlacementTip.pngWorkaround:
  • Define a pre-baked RGBA16161616f $lightmap in the VMT of the VertexLitGeneric material. A custom-coded compiler would be required to this accurately.
  • Increase lightmap resolution (results may vary).
  • Move light source further away from the lit surface.
Warning.pngWarning:Models using $bumpmap cannot receive lightmaps, they will fall back to vertex-lighting based upon the models' origin.
Note.pngNote:There is an in-engine check that confirms whether or not the $bumpmap parameter is defined for a material, a custom shader cannot simply use both as there are a dozen technicalities that have to be overcome.
Technical

If $bumpmap, $normalmap, or $phong is defined, the engine will not send the lightmap data to the shader.
For $bumpmap, a workaround for this is to use a differently named parameter. ($NormalTexture) to get the normal map and undefining $bumpmap.
However no static lighting data can be received by the shader, if the $bumpmap parameter is not set to anything. This refers to lights that are not named and are not inherently dynamic.
This may be prefered as the static light information is already prebaked in the lightmap, however it means you cannot receive direction information from the lights.
No light direction means no bumped lighting from the lightmap. Aka no specular highlights.
A fix for this would be modifying VRAD to spit out a lightmap that is *2 the size on the U axis and then storing an average light direction there or doing some other smart technique to 'memorize' light directions.

This in-engine check also exists for $phong, however getting around the issue is more tricky. The default value of the integer parameter will be 0 even if not set in the vmt. Thus making $phong always be defined in a way.

func_brush and other visible brush entities
Have a vrad_brush_cast_shadows keyvalue to allow them to cast (but not receive) lightmap shadows. !FGD in most games other than Portal 2 Portal 2 and Team Fortress 2 Team Fortress 2.
Blank image.pngTodo: what other games have it?

Dynamic Light Sources

Tip.pngTip:Dynamic lighting is calculated at runtime, which makes it expensive to render.
env_projectedtexture shines from a doorway.
light_dynamic
A simple, uni-directional dynamic light that can be moved, turned, and adjusted.
point_spotlight
A dynamic spotlight beam effect, with an optional dynamic light source where it hits a surface.
npc_spotlight
A spotlight NPC, similar to point_spotlight, but with the capability of tracking targets.
env_projectedtexture
A dynamic light that lights with a texture rather than a solid color and "subtracts" realistic dynamic shadows. Affects all surfaces that can accept lighting, and is used for the player's flashlight in Half-Life 2: Episode Two Half-Life 2: Episode Two .
  • In games since Portal 2 Portal 2, most visible dynamic entities can have texture projection disabled with the disableflashlight keyvalue, and they can have it toggled at runtime with the EnableReceivingFlashlight and DisableReceivingFlashlight inputs. Their shadow-casting behavior, however, must be controlled separately (see under Dynamic Shadows). In earlier games, this behavior can still be controlled via the EF_NOFLASHLIGHT effect flag (see below).
Effect flags !FGD
Most entities with a parent can have EF_BRIGHTLIGHT or EF_DIMLIGHT applied to them to have them radiate dynamic light of the appropriate brightness.

Dynamic Shadows

Tip.pngTip:Dynamic shadows are cast only by world models (NPCs, phys-props, etc), and only onto brush surfaces (from both Static and Dynamic light sources). They are calculated at runtime, so they are quite crude and relatively expensive to render.
Warning.pngWarning: In games since Left 4 Dead Left 4 Dead, the direction of a shadow is calculated on a per-entity basis, and dictated by the closest light to the entity. This is not the case in games up to (and including) Source 2013 Source 2013, unless you apply Dynamic RTT shadow angles in Source 2007 to your mod.
Warning.pngWarning:Dynamic shadows can sometimes project through walls and floors, giving away the location of players or objects. Use info_no_dynamic_shadow to get around this problem if you encounter it.
Note.pngNote:Shadows are "cast" by the visual mesh only if there is no shadowlod defined in the QC. Shadow LODs are just low detail meshes used to generate the shadow. These don't apply to shadowmapping (flashlights and other env_projectedtexture-based effects).
Note.pngNote:Dynamic shadows do not merge with each other or with lightmaps when they overlap. This can produce undesirable "doubling-up" effects when, for instance, physics props are placed on a phys prop table. You can enable and disable shadows on dynamic entities to work around this.
Note.pngNote:Dynamic shadows support translucency. If your model has varying levels of opacity, it can show up in the shadow as seen here.
Blank image.pngTodo: link broken, find another example
shadow_control
Point entity used to control Dynamic shadow projections for the entire map, including maximum distance cast, direction cast, and sharpness/diffuseness.
info_no_dynamic_shadow
Point entity used to list brush surfaces that should not receive Dynamic shadows.
Most dynamic visible entities
Have a shadowcastdist keyvalue to override how far these objects cast Dynamic shadows, a disableshadows keyvalue to control whether they cast Dynamic shadows, and EnableShadow and DisableShadow inputs to control Dynamic shadows cast by them. In games since Portal 2 Portal 2, they also have disableshadowdepth to prevent them casting shadows from env_projectedtexture.
Effect flags !FGD
Most entities with a parent can have various effect flags applied to them to regulate many of the same effects as the aforementioned keyvalues, even if they don't have those keyvalues in your version of Source.

Tyndall Effects

Tyndall effects are caused by light scattering on suspended (colloid) particles in a transparent medium. E.g., car headlights in fog.

  • Halo (Glow Sprite) effects :
  • env_sprite - entity used to create omni-directional glow or flare effects.
  • env_lightglow - an asymmetrical glow (for areas of contrasting light).
  • env_sun - adds a bright haloed spot to the Skybox to represent the position of the Sun or Moon.
  • Brush texture : models/effects/vol_light001
  • Brush texture : models/effects/vol_light002
  • Model : models/Effects/vol_light.mdl - use with prop_static.

Common Values

Brightness
Car Headlights 231 223 192
Combine lamp 147 226 240
Tungsten bulb 254 216 146
Fluorescent tube (cold) 159 237 215
Flourescent tube (warm) 255 245 145

For values to accompany the stock skybox materials, see Sky List.

Notes

  • Naming a static light makes it more expensive. Only name lights when you need to. Multiple lights sharing the same name are cheaper than lights with separate names.
  • light_dynamic is especially expensive and will not even show up on some systems
  • The basic light entities do not come with a visible representation (e.g. a lightbulb). For that, you need a prop. See HL2 Light Props for a list.
  • The basic light entities do not come with a "glow" as you'd expect to see in a foggy or misty area. To provide this, either compile and run the map with HDR enabled, or add a point_spotlight (with dynamic lighting off unless needed), env_lightglow, or env_sprite entity.
  • Maps will not be lit unless you run VRAD (or equivalent). VRAD will not run properly and will not calculate realistic light bounces unless the level is free of leaks.
  • Moving brushed-based objects will not change the way they are lit. Their lighting will be calculated only according to their positions in Hammer. (e.g. a brush in a dark room will not become bright if it is brought into a bright room.)
  • Light can be reflected off surfaces during compile, indirectly illuminating the environment around them. See $reflectivity.

Console Commands

mat_fullbright 2. The bright white physics props seem to be a bug; they are lit correctly when in motion.
mat_fullbright <0-2>
0 is normal lighting.
1 is 'full bright' lighting, where everything is 100% lit.
2 has been introduced with the Orange Box and is 'lighting only'. It replaces all textures' images with a colourless monotone, allowing you to see exactly what is lit, where, and probably how.

See also

External links