Lighting optimization

From Valve Developer Community
Jump to: navigation, search

Static light

Lightmaps at work.

Static light is pre-compiled into lightmaps, which are to all intents and purposes textures. This makes it very cheap, and indeed makes individual light entities free.

There are three areas where optimisation can be performed:

Lightmap Scale

A higher Lightmap scale can cause more texture memory to be used, and can impact performance slightly when in the same scene of other materials that effect the total memory usage. Use larger scales wisely when there aren't other expensive materials within the Scene. This even takes effect when there isn't any lighting baked onto a Lightmap, therefore reducing the quality of a Lightmap in a dark area can counter for higher scales in expensive scenes. Lastly, Lightmap Quality also can effect the map file size, and compile time.

Naming lights

VRAD assumes that all named lights will be switched on or off at some point, and compiles an extra version of all lightmaps the light touches to provide for this. Not only does this bloat map size, VRAD compiles direct lighting only to reduce the number of lightmaps that need to be touched (i.e. no bounced light). Don't name static lights unless you really have to!

Number of Lights

When VRAD compiles your lighting, there is a section (direct lights) in the process log that reports the number of lights in your world. This includes lights you place in hammer as well as lights from RAD files. Reducing the number of lights can improve compiling times.

A world using 6,000 direct lights from a single plane emitting light using a RAD file may take 5 minutes or more to compile with a 2000 by 4000 box with a height of 1000 units. The same lighting effect can still be achieve using only a few lights with very high brightness values which can reduce the compiling time to one minute or less.

Dynamic light

Dynamic lights are expensive and must be carefully managed. Their number is important, but also what they are pointing at: the more complex the surfaces and numerous the models at which a dynamic light points, the more expensive it becomes. This makes them particularly unsuited to multiplayer maps where it is unclear where the action will be.

It's best, from a performance standpoint, to simply avoid dynamic light unless you notice a large parcel of your budget going unused. Players will be used to static light and won't expect anything better unless you set a precedent yourself.


If VRAD needs more RAM than you have physically installed, it will page memory to the disk and slow down your compile time greatly. Lower lightmap scales to reduce memory usage.

<< Return to Optimization (level design)