Naming Lights: Difference between revisions
TomEdwards (talk | contribs) (copied text from Light, added more detail) |
TomEdwards (talk | contribs) mNo edit summary |
||
| Line 1: | Line 1: | ||
Giving a light entity a [[targetname]] makes [[VRAD]] compile a second [[lightmap]] "page" for the surfaces that its emitted light touches. This won't harm | Giving a light entity a [[targetname]] makes [[VRAD]] compile a second [[lightmap]] "page" for the surfaces that its emitted light touches. This won't harm in-game performance, but it will increase compile time and BSP filesize, regardless of whether the light ever receives [[input]] to change its state. | ||
However, the system can be overloaded if you try to make it handle a large number of overlapping named lights (since the number of pages needed increases exponentially). When this happens performance can be harmed and you may well see lighting anomalies. | However, the system can be overloaded if you try to make it handle a large number of overlapping named lights (since the number of pages needed increases exponentially). When this happens performance ''can'' be harmed and you may well see lighting anomalies. | ||
VRAD attempts to avoid this with its '''hard-coded limits''' of two switchable lights affecting a brush face and 32 pages in total. You can help too by giving lights that will always change state at the same time a '''shared targetname''', which makes VRAD merge their pages together. | VRAD attempts to avoid this with its '''hard-coded limits''' of two switchable lights affecting a brush face and 32 pages in total. You can help too by giving lights that will always change state at the same time a '''shared targetname''', which makes VRAD merge their pages together. | ||
{{note|To reduce the number of | {{note|To reduce the number of pages created, light from named light entities is direct and won't bounce between surfaces. This can look very crude!}} | ||
== See also == | == See also == | ||
Revision as of 04:23, 19 July 2009
Giving a light entity a targetname makes VRAD compile a second lightmap "page" for the surfaces that its emitted light touches. This won't harm in-game performance, but it will increase compile time and BSP filesize, regardless of whether the light ever receives input to change its state.
However, the system can be overloaded if you try to make it handle a large number of overlapping named lights (since the number of pages needed increases exponentially). When this happens performance can be harmed and you may well see lighting anomalies.
VRAD attempts to avoid this with its hard-coded limits of two switchable lights affecting a brush face and 32 pages in total. You can help too by giving lights that will always change state at the same time a shared targetname, which makes VRAD merge their pages together.
Note:To reduce the number of pages created, light from named light entities is direct and won't bounce between surfaces. This can look very crude!