Lighting - w23/xash3d-fwgs GitHub Wiki

General

The first part of the radiosity process is the accurate calculation of direct lighting. All entity lights and the bright (5000 or greater) surface patches exactly trace lines to the individual lightmap samples. If -bounce 0 is specified, that's it for the lighting. Otherwise, the lightmap values are summed up to give the initial amount of light to be bounced around the world in the radiosity pass. ISSUES WITH BMODELS Brush models emit and absorb light like other surfaces, but they do not block light, so after normalization, a little less light lands on the nearby surfaces, because it was absorbed both by the door and the surfaces beyond it. You probably won't notice anything unless you have a row of spotlights on normal walls, then an identical one on a bmodel. ISSUES WITH WATER Light does NOT cross through water surfaces if the vis has been calculated, because the areas are in different potentially visible sets, but if you run qrad without a vis, then light will be sent through as well. (QRAD DOCUMENTATION)

Surface lighting

All textures that are on the "light emitting" list will cast light into the world, oriented down the surface normal. A value of 100-300 is reasonable for a large, dim surface, like slime, lava, or a dark sky. Lights that will illuminate large areas with a small surface area will have values of 5000 or greater. The total amount of light emitted from a surface is proportional to the surface's area, so the size of the brush face has as much effect on the light sent into the world as the light value. Surface lighting falls off with the square of distance, so if you double the height of a room, you will need to have four times the light intensity on the ceiling to get the floor the same brightness. The walls would then be much brighter near the top than they were with the smaller room as well. (QRAD DOCUMENTATION)

rad file, see Textures

  • TextureName R G B V
  • TextureName R G B
  • TextureName V
    Color and brighness (where V=Scale brightness)

info_texlights (HLRAD+)

keyvalues

  • "TextureName" R G B V
    Color and brighness (where V=Scale brightness)

light_surface (ZHLT+)

Basic info from https://developer.valvesoftware.com/wiki/Zoner%27s_Half-Life_Tools.fgd

keyvalues

  • _tex Texture name (not case sensitive)
  • "_light" R G B V Texture brightness (example: 255 255 255 80)
    V >= 80 will ensure full brightness. Colored brightness is not recommended.
  • _texcolor R G B Color (replace texture color)
    emit light as if the texture is in this color
  • _cone V Inner (bright) angle
    90 default, should be 90 for conventional texlights
  • _cone2 V Outer (fading) angle
    90 default, should be 90 for conventional texlights
  • _scale V Adjust emit scale
    1.0 default, 0.0 = no emitting
  • _chop V Grid size of sampling
    in inch; not affected by texture scale

light

https://github.com/ValveSoftware/halflife/blob/master/utils/qrad/lightmap.c#L901

They should function similar to quake 1 lights, with linear falloff instead of inverse quadratic. (QRAD DOCUMENTATION)

keyvalues

flags

  • initially dark (1) By default the light source will be turned off and can be turned on by some kind of trigger.

light_spot

The field "_cone" determines the spread of the spotlight. If not specified, a _cone of 15 will default. (QRAD DOCUMENTATION)

https://github.com/ValveSoftware/halflife/blob/master/utils/qrad/lightmap.c#L935

keyvalues

flags

  • initially dark (1) By default the light source will be turned off and can be turned on by some kind of trigger.

light_environment

Skys emit light like other surfaces, but have slightly different characteristics. They emit light from all angles, so it doesn't matter if you see a horizontal or vertical sky brush. Light also does not bounce off of a sky in the radiosity pass, if it flies out a sky texture it is just gone. (QRAD DOCUMENTATION)

keyvalues

  • "target" Target Entity name where the light will be directed to. If validly specified, "pitch", "angle", "angles" is ignored.
  • "angles" X Y Z Pitch Yaw Roll
  • "pitch" V Pitch
    Takes priotity over Pitch inside "angles"
    Legacy Pitch
  • "angle" V Angle
    Takes priotity over Angle inside "angles"
    Legacy Yaw
  • "_light" R G B V Color and brighness (where V=Scale brightness)

dynamic_light

TBD

func_wall and etc

keyvalues

  • "_minlight" Minimal Light Level

Used to set maximum lightning level for entities. Imagine a computer screen in the darkness, machine diodes or just a lamp that produces a light and need to be full-lit. Use minimum light level key to do this. It's only supports two states: '0' (normal light) and more than '0' (full bright). Set it to '1' or any other value to make brush full-lit.
Keep in mind that it does not produce light itself (in the first image I added light by myself).

func_train

For dynamic lighting (moving light) is set by effects

keyvalues

ELIGHT and DLIGHT

Specificity of ZHLT/VHLT

At least need to be implemented:

info_texlights

keyvalues

  • "TextureName" R G B V Color and brightness (where V=Scale brightness)

This entity can act as a replacement for a lights.rad file, in that it simply resides within the map as a point based entity. The usefulness of this is that each map can have its own unique ambient lighting applied to it, and those settings will travel with the map and not affect any other maps. Usage of the entity is much like that of the multimanager. To add an entry (take smart-edit off if you are using the Valve Hammer Editor/Worldcraft) and add key-value pairs in manually; the key should contain the name of the texture to apply lighting to, and the value a set of numbers representing the red green blue luminosity (brightness) of the texture, just as you would in the lights.rad file. The presence of this entity will not override the lights.rad file - both the values specified in this entity and the lights.rad file will be used by HLRAD.

Undocumented features