InsideQC Forums

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!

I'm pretty sure this would require a new BSP format.

lightmap resolution is tied to texture samples.
16 texture pixels to 1 lightmap pixel.

You can use higher resolution textures if you don't change bsp format.
you could probably do it transparently by multiplying everything a bit and using a bigger .lit file.

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.

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.

Downsider wrote:I'm really surprised that it seems like nobody's done this yet?

Why use lightmaps when you can use shadow volumes?... Okay, so that's not perfect logic, but you get the idea.

Spike wrote:

Downsider wrote:I'm really surprised that it seems like nobody's done this yet?

Why use lightmaps when you can use shadow volumes?... Okay, so that's not perfect logic, but you get the idea.

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.

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).