In wanting to add this feature to an engine, I'm wondering which lightmap compilers support this outputting higher resolution lightmaps and which command line switches that should be used to control said feature.
Hopefully somebody can save me a few hours of scrounging around the net; thanks!
Higher resolution lightmaps
Storing in the BSP would require a new format because the lightmap s/t calculation is hardcoded as a >> 4 in the engine, so at the very least some kind of flag to say "hey! shift by 3 instead!" would be required. You'd also need to increase the size of the blocklights array, as the current 18 x 18 is strictly based on a max surface extents that assumes left-shift by 4. Finally, the lightmap offset for each surface would also need to be changed or multiplied to reflect the bigger format. Something has to signal to the engine that these need to be done.
I like the idea of doing it in the LIT file, possibly extending the version number header integer to take a combination of flags. This way the old lighting can still be retained in the BSP (retaining compatibility with any engines that don't support the larger size), and the LIT file itself can signal to the engine that things are different.
Be aware however that doubling the lightmap resolution in either direction would have a 4 x overhead on animated and dynamic light calculations and uploads.
I like the idea of doing it in the LIT file, possibly extending the version number header integer to take a combination of flags. This way the old lighting can still be retained in the BSP (retaining compatibility with any engines that don't support the larger size), and the LIT file itself can signal to the engine that things are different.
Be aware however that doubling the lightmap resolution in either direction would have a 4 x overhead on animated and dynamic light calculations and uploads.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
LIT file sounds like a plan.
Any compilers out there support dynamic resolution lightmaps that output a nice LIT file? Or maybe some workaround involving double-resolution textures for the compiling process?
I'm aware of the "4x overhead" deal, yup.
I'm really surprised that it seems like nobody's done this yet? ! I would've been sure support like this was already added into tons of engines, but I guess I'm mistaken.
Any compilers out there support dynamic resolution lightmaps that output a nice LIT file? Or maybe some workaround involving double-resolution textures for the compiling process?
I'm aware of the "4x overhead" deal, yup.
I'm really surprised that it seems like nobody's done this yet? ! I would've been sure support like this was already added into tons of engines, but I guess I'm mistaken.
Hard edges, real-time overhead, necessary data to make them look good and work right doesn't exist in Quake maps, plenty of reasons not to use shadow volumes.Spike wrote:Why use lightmaps when you can use shadow volumes?... Okay, so that's not perfect logic, but you get the idea.Downsider wrote:I'm really surprised that it seems like nobody's done this yet?
Personally I favour a vertex lighting solution for general world light - this can be done with the data as is in a Quake map and can be blisteringly fast and without a lot of the artefacts other solutions have (although with certain artefacts of it's own).
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for