Always render vertex-lit surfaces with lightMapping shader. Enables realtime lights #1867
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There are no differences in my screenshot test suite as a result of removing this. This alpha := 1 thing only existed in the `generic` shader; its absence in lightMapping is further evidence suggesting it is not needed.
Also add a static assert that the descriptions list has the right size.
Take pointer to stage instead of pointer to shader plus stage type.
Use the lightMapping GLSL shader instead of `generic` to render BSP surfaces that are vertex-lit due to an explicit `rgbGen vertex`. This makes them use the same code path as BSP surfaces where vertex lighting is automatically selected due to the absence of a lightmap. So now it is possible to render realtime lights on explicitly vertex-lit surfaces, though they are still not as bright as they should be due to DaemonEngine#1415. In the following commit, this will let us remove some ugly code used for applying the overbright factor to the `generic` shader.
VReaperV
reviewed
Oct 18, 2025
src/engine/renderer/Material.cpp
Outdated
| const bool mayUseVertexOverbright, const bool vertexLit, const bool fullbright ) { | ||
| const int variant = ( mayUseVertexOverbright ? ShaderStageVariant::VERTEX_OVERBRIGHT : 0 ) | ||
| const bool vertexLit, const bool fullbright ) { | ||
| const int variant = 0 |
There was a problem hiding this comment.
I think you can get rid of 0 |.
This is unused following the previous commit which make shaders that need overbright with `rgbGen vertex` run on the `lightMapping` shader instead of `generic`. Note: IS_LIGHT_STYLE was misnamed. It actually meant vertex overbright
slipher
force-pushed
the
vertex-dlight
branch
from
c760380 to
349ddb2
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Depends on: #1866
Use the lightMapping GLSL shader instead of
genericto render BSP surfaces that are vertex-lit due to an explicitrgbGen vertex. This makes them use the same code path as BSP surfaces where vertex lighting is automatically selected due to the absence of a lightmap.So now it is possible to render realtime lights on explicitly vertex-lit surfaces, though they are still not as bright as they should be due to #1415.A good chunk of code has been removed/simplified since we no longer need a duplicate code path for vertex lighting in the
genericshader. In the future the newly addedRSF_BSPshader flag could also help to simplify things since we could use that instead of plumbing 'is BSP surface' conditions through various places in the engine.This targets 0.56 because it has the same effect as #1417 on the station15 plants, since the
lightMappingshader never had the compatibility regression thatgenericdid w.r.t alpha discard.I have run my screenshot test suite against the shaders from master of https://github.com/UnvanquishedAssets/map-station15_src.dpkdir (and other maps as normal) and found no regressions.