ericwa
Option to disable generating lightmaps for a face/brush
For fullbright faces, like TEX_SPECIAL in Q1/H2/HL1 mode. Not generating light maps would be cheaper than setting _minlight to 1.0, as the compiler doesn't need to allocate or write lightmaps for the face, and the game doesn't need to blend the lightmap onto the diffuse for the face.
~~Perhaps having SURF_LIGHT with brightness value set to 0 could cause BSP to not allocate lightmaps for the face.~~ Something akin to VHLT's zhlt_striprad (which only works on bmodels) would suffice.
inspired by some comments by @erysdren on the FTE discord
Q2 requires lightmaps to be written for empty faces because of some bugs with the original game and its renderer - instead of Q1 where unwritten faces are fully black, in Q2 they are fullbright but still read as full black when queried by the lighting system, so you get black entities on full-bright surfaces. Unfortunately we're stuck with that behavior for Q2 mode.
However, for custom games that don't suffer from this behavior, an opt-in method to use Q2 BSP without that limitation would be handy.
I wonder if Q1 engines widely support TEX_SPECIAL on regular tiling textures (I.e not liquids or sky) as a way of requesting fullbright.
I do worry about accidentally activating this on existing maps if we use Q2 surf flags (value=0, flags=surf_light) to activate this feature, whereas the way we’ve typically added new key/values on func_group like _fullbright 1 we can be pretty sure it’s not going to break existing maps (though the only downside of requesting it like that is you don’t get face granularity).
the way we’ve typically added new key/values on func_group like _fullbright 1 we can be pretty sure it’s not going to break existing maps (though the only downside of requesting it like that is you don’t get face granularity).
Searching the EWT code, it does look like there isn't a KV method for not compiling lightmap data for a face (I had assumed there was based upon what @erysdren was saying in the FTE discord conversation that inspired this FR). VHLT has zhlt_striprad, which strips lightmaps from a bmodel after lighting is compiled (no TEX_SPECIAL involved, and since it happens after lighting, the faces still can bounce light); a KV like that would be nice to have (even if, as Paril said, it wouldn't work in Q2, it'd still work in HL1 and probably Q1).
I thought we had a _nolight on brushes/faces to ignore any received lighting (only allow minlight, etc) but I guess not. That'd be trivial to add since we have a feature for it already at the light tool level, just not per-brush.