Quake 2: light.exe Recomputation of BSP lighting giving very bright results
Opened this issue · 6 comments
I've been using light.exe's ability to recompute the lighting data for compiled BSPs to adjust old Quake 2 maps for use in the Remaster (as otherwise transparencies such as water surfaces and forcefields end up lit oddly), but I find that it has a tendency to make the lighting extremely bright, fullbright in some circumstances, or rarely extremely dark.
Below are some screenshots I've taken of the level risc1.bsp (What the End is For) before and after re-lighting.
This first one is the original risc1 running in KMQuake2.
This is the original risc1 running in the Remaster. The forcefield appears much more opaque here than it should do.
This one is risc1 after running light.exe on it, played in the Remaster. It has become completely fullbright, but the forcefield is now rendering much more normally. The map also renders like this in KMQuake2.
This is the log file from light.exe.
risc1-light.log
I have checked this lighting recomputation on a Quake 1 BSP (mexx1.bsp, specifically) and that worked fine, without any of the effects seen in Quake 2 BSPs.
Am I needing to apply an argument when running light on Q2 BSPs, or is this a bug?
The force field being wrong in Q2R is something I'm hoping to fix in a patch.
Re-lighting existing Q2 maps is not something I've really been focusing on development-wise, especially since ericw-tools relies pretty heavily on the intermediary .texinfo.json file for proper handling of all surfaces. It's possible it's just busted. There's a new version of arghrad that supports lit warps, that might be better for you to try if you're wanting to maintain the old look, because ericw-tools' lighting is very different than arghrad/vanilla qrad3.
Arghrad202 with -lightwarp seems to give the best results, thank you for the recommendation. Might result in a bit brighter of a map, but there's only so much you can do without the .map file.
Should I close this as Not Planned, or leave it as a "maybe when time permits" bugfix?
You can leave it up, but I can't guarantee we will ever be 1:1 parity with arghrad heh
The fullbright does look like a bug to me, I'll check it when I get a chance. In some cases, Q2 maps lit with our tools are pretty close to the classic tools.
Assuming this is the original bsp in question? http://tastyspleen.net/~quake2/baseq2/maps/risc1.bsp
I'd like to make the default look closer because it was more or less accidental but we'd have to have different "light profiles" at the command line if we change it too much.
I think the problem with the map is the option - "light" was set to "200.000000" (from map) -
I think the problem with the map is the option - "light" was set to "200.000000" (from map) -
You're right, this is what's causing it to be completely fullbright.
Original Q2 tools:
_minlightworldspawn key used 0..2 scale (see: https://github.com/id-Software/Quake-2-Tools/blob/master/bsp/qrad3/lightmap.c#L1254C49-L1254C58 )
Arghrad:
lightworldspawn key, used 0-255 scale (see: https://www.bspquakeeditor.com/arghrad/globalpost.html#ambient)- this was also additive minlight
The problem is we treat light and _minlight as aliases, and use the 0-255 scale in Q1 mode and 0-2 scale in Q2 mode, which clashes with the scale used in arghrad.
Not sure what the best option is here, we could ignore the "light" worldspawn key in Q2 mode.
Aside from that I was able to get a pretty close match for the existing lighting with the following command line:
-surflightscale 0.25 -light 0 -emissivequality high -path "D:\SteamLibrary\steamapps\common\Quake 2\rerelease\baseq2" "C:\Users\Eric\Downloads\risc1.bsp"
Original bsp:
