Rewrite light grid code for better interpolation#1921
Rewrite light grid code for better interpolation#1921slipher wants to merge 2 commits intoDaemonEngine:for-0.56.0/syncfrom
Conversation
|
Thanks! That looks way better when deluxe mapping is disabled! |
|
I tested the rendering of worlds with |
Yes. That's why I made the second set of screenshots, which use |
Ah yes, I'm probably responsible for that disablement, based on the fact BSP grid lighting was bad and could even be considered cheat just because how much bright it was. I wonder if we can reconsider that cheat status after this PR, but BSP grid lighting may still be considered cheat because the nature of grid lighting makes light leak trough patches, while lightmap doesn't (but player models would be lit anyway, so…). It would be good to get BSP grid lighting working properly anyway. For BSP models first, and maybe as an alternative world lighting. The advantage of grid lighting over light mapping is that it may be lower on VRAM at the cost of more complexe GLSL computation, and it looks way better than vertex lighting (which is the cheapest of all, both on VRAM and GLSL computation). |
Redesign the scheme for storing light grid direction and directedness vs. ambientness information in the pixels of a 3D image. Note for context: the light grid does not store the separate directed and ambient colors; it just averages them. Before: Light dir is always stored as a normal vector. There is an "ambient part" byte which is supposed to indicate what fraction of the light is ambient and what fraction directed. After: Light dir is scaled according to how much ambient light there is. Amount of light which is ambient is determined by how long the direction vector is. Some issues with the old code which are fixed: - Wrong averaging of the directed and ambient colors. Previously directed and ambient colors were equally weighted, but ambient should have more weight since there is no dot product term which can decrease it. - Bad interpolation behavior. Example 1: if neighboring grid cells had nearly opposing directions, the resulting direction vector would be garbage. With the new code, this results in a small vector which causes most light to be automatically moved into directed instead of ambient. Example 2: if one cell has a large directed component and its neighbor has none, the directions are equally weighted despite the second one being meaningless. With the new code, directions are weighted according to how much directed light there is. - Excessive brightness when deluxe mapping is disabled, because it behaved in that case as if the normal vector were always perfectly aligned with the light direction.
The previous commit fixed excessive brightness with grid lighting when deluxe mapping is disabled by using the average expected brightness (over all directions) instead of the maximum, but it went too far and made things dim. Boost the light a bit since light directions are positively correlated with normals in practice.
2 participants
Stacked on #1910
Rewrite the way light directions and directed component size are stored and accessed from the light grid image. Fix bad behavior under interpolation and other dubious math.
Since the model lighting differences aren't that easy to see, the main reason this might be compelling to include in the release is that it fixes excessive brightness in the case that deluxe mapping is disabled.
Before/after with and without deluxe mapping: https://users.unvanquished.net/~slipher/screenshot-compare/lightgrid-rewrite/normal/viewer.html
To get some screenshots where it is easier to see differences, I also made some with
r_lightMode 2(grid lighting for everything including the world). In this set of screenshots, both sides of the comparison are also using #1920 so that grid lighting on BSP surfaces works correctly. You can see that the before side has more artifacts. https://users.unvanquished.net/~slipher/screenshot-compare/lightgrid-rewrite/lightmode2/viewer.html