Difference between revisions of "Lighting optimization"

From Valve Developer Community
Jump to: navigation, search
m (Static light: fixed sub-section formatting)
Line 19: Line 19:
  
 
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.
 
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.
 +
 +
 +
== Stop VRAD ==
 +
If you make a big hall, VRAD can stop, and launch game without lighting. Because Winwdows 32bits can use 2Go maximum by application, Source don't works in 64bits. If VRAD need more 2Giga, it stop. Use Scale Lightmap more low for reduce memory usage.
 +
 +
  
 
----
 
----
  
 
'''''[[Optimization (level design)|<< Return to Optimization (level design)]]'''''
 
'''''[[Optimization (level design)|<< Return to Optimization (level design)]]'''''

Revision as of 11:22, 31 July 2010

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 two 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!

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.


Stop VRAD

If you make a big hall, VRAD can stop, and launch game without lighting. Because Winwdows 32bits can use 2Go maximum by application, Source don't works in 64bits. If VRAD need more 2Giga, it stop. Use Scale Lightmap more low for reduce memory usage.



<< Return to Optimization (level design)