-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to disable generating lightmaps for a face/brush #436
Comments
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). |
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 |
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. |
We have _lightignore to make a bmodel receive minlight only |
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 havingSomething akin to VHLT'sSURF_LIGHT
with brightness value set to 0 could cause BSP to not allocate lightmaps for the face.zhlt_striprad
(which only works on bmodels) would suffice.inspired by some comments by @erysdren on the FTE discord
The text was updated successfully, but these errors were encountered: