Glowing Textures

From Valve Developer Community
Revision as of 22:13, 14 November 2013 by Pdan4 (talk | contribs)
Jump to: navigation, search

This is a description of the steps required to achieve a glowing texture. While there are several approaches to take, each will be covered here independently. Which one you wish to use is based entirely upon the situation of your use.

A glowing texture is one that does not require another form of light to be lit up. It can create its own lightmap independent of all lighting sources and may even create light itself. This does not mean that the surface will appear pure white, just that the face will ignore any light it would receive. This is a key feature as a "glowing" black stays black and does not get brighter. The face achieves what is called fullbright, where the texture's pixels appear exactly the same color as they were saved.

There are several different ways to create this effect available in the Source engine. The first is by using a .rad file, a file parsed and run during the vrad compile process. The second is the UnlitGeneric shader, specified in certain material's VMT. The third is the $selfillum parameter, again specified in the material's VMT. The fourth is by manipulation of the Minimum Light Level value, and the fifth is by using the info_lighting to fool a model into thinking it is brightly illuminated.

Common selfillum textures can be found in White.

.rad files

An old method, supported mostly for legacy purposes .rad files are the only form of glowing textures that generate any light. Processed only during the compile process they are a text file found in the same directory as the .VMF file or in the root directory for the game /<e-mail>/half - life 2/hl2/<name>.rad. The file is processed line per line, on each line is simply the name of the texture, the rgb value of the light, and then the brightness of the light.

example\exampletexture 128 192 96 400

When compiled there will be automatically generated lights of the specified color and brightness in front of the world brushes face. The brightness of the created lights is also affected by the density of the texture. Higher densities will produce a greater effect. The texture itself does not become fullbright but the lights in front often make it seem so. The .rad files only work properly on textures that are upon world brushes. This is because they're processed entirely during the vrad process, something models never undergo. Entities do undergo the process but cause weird errors like a static lighting effect when the entity moves or the entity ignores the light but the world around it becomes lit.

When it comes to processing the file there are three names it looks for lights.rad, <game>.rad, then <mapname>.rad. Processed in that order any texture specified in any file will be given the lighting effect. If a texture is specified in multiple places it will be overridden by the latest information, for example if both lights.rad and <game>.rad specified the same texture but <game>.rad was brighter. Then the light emitted in the compiled map would be the brighter <game>.rad version.

A .rad texture in use

UnlitGeneric textures

The UnlitGeneric shader forces the entire face to be full bright. The surface does not emit light nor does light have any visible effect on the surface. Mainly used when the texture should appear to be a light source but not wanting any light to be forced into creation. All that is required for the effect is to specify the materials shader as unlit generic. Because UnlitGenerics are their own shader they can be applied to both models and world brushes.

	$basetexture example\exampletexture

A common use is that of skybox textures, the sky is always bright and the face the texture will appear on has no form of lighting itself.

Warning.png Warning: You need to include the command $model 1 in your .vmt if your using an UnlitGeneric on a model, otherwise the surface may not show up.
A unlitgeneric texture in use

$selfillum textures

The $selfillum parameter is akin to the UnlitGeneric shader. The key difference is the flexibility selfillum grants, the selfillum parameters takes the alpha channel of the base texture and turns that into a map for how bright each pixel of the image should appear. This means partial brightness or even only small areas of brightness can exist. A partially bright face can still receive light that is added to the default light on the face. The alpha channel has to be made when creating the material but the vmt property has to exist as well.

	$basetexture exmaple\exampletexture
	$selfillum 1

This effect ends up most commonly being used when the "light" part of a texture is not the entire surfaces, such as a window on a building or an illuminated button on a computer panel.

A selfillum texture in use

Minimum Light Level values

This is not strictly a glowing texture per se, but another way that a texture can be made to appear to glow (without shedding any actual light) is by placing it on a surface that allows you to set the Minimum Light Level float value to control the minimum amount of ambient light the surface will reflect. The most common of these is func_brush. Setting the Minimum Light Level high (from 5 to 50 or more, depending on how light the texture is) will result in the textures on the brush glowing brightly.

Warning.png Warning: Increasing the Minimum Light Level can have a disproportionate effect on cubemap sampling, causing the scene to compile too brightly.
Minimum Light Level changes. From left to right: 0, 0.5, 2, 10, 25, and 50

Use of info_lighting

Models and prop_static entities can be made to glow brightly (though they do not actually emit any light) if their lighting origin key value is set to the name of an info_lighting that is placed in a lightbox isolated from the rest of the map. In the illustration below, the model to the right has been linked to an info_lighting placed in a small hollow cube with nine Light entities, each set to a brightness of 5000.

One possibly useful feature of this method of manipulating lighting is that it dynamically updates in real time. That is, if the lights in the lightbox are linked to a switch or trigger, or pre-set to pulse, flicker, or so on, the lighting on the model or prop_static will reflect these changes immediately. This might be used, for instance, to slowly darken modeled terrain to simulate the coming of evening.

Effect of linking a model to an info_lighting in a lightbox