Improve lightmap resolution

[JasonX]

How can i improve the lightmap resolution for the standard BSP format? Hmap does a good job lighting stuff, but the end result always looks like crap due to the lightmap resolution. I'm trying to create a good ambient occluded environment.

[Baker]

MH has done this in DirectQ to the best of my knowledge (the comments in the code indicate this is a feature). I don't claim that I played with that, though, so likewise I couldn't describe what he did and I don't know if it applies only to in-game dynamic light maps or the ones from the BSP somehow or both.

If I had to guess ... I'd say that DirectQ's implementation only is an enhancement of in-game dynamic lights, not an enhancement of the light map data from the BSP since those are from the compile process. Then again, this is MH so ....

[With Ben Jardrup's light.exe and probably Tyrlite there are special extra enhanced light map generation command line parameters like -soft or -extra or some such thing ... see Ben Jardrup's docs for details ... http://user.tninet.se/~xir870k/

I know that isn't hmap2 by LordHavoc ... but maybe LH added similar command line options and barring that, maybe you can use Ben Jardrup's light.exe for that stage of the compile process if LH doesn't have "soft light map" command line params in hmap2 ?]

[JasonX]

The commands are there, the problem is that the resolution is very low. The map compilers do a good job, specially hmap2, but the end result is always "damaged" in game due to the low lightmap resolution. Shadows get stretched and blurred.

[Spike]

there's a fixed 1:16 ratio between lightmap samples : sw texture samples.

if you need a higher resolution lightmap, increase the resolution of your textures by increasing the raw texture size and then shrinking them in your editor to keep the surfaces the same size (there's no way to automate this that I know of).

[Qrv]

I assume your using q1bsp, in which case, Spike's suggestion is probably the better way to try and increase the quality of the lightmap.
On the other hand, if you can get away with using q3bsp's, q3map2 allows lightmaps to be better quality by either assigning "_lightmapscale" to a bunch of brushes that you want to have the higher quality lightmap on, or you can add a very similar paramater I think to your q3 shader file for a specfic set of textures.

[JasonX]

Can i change this ratio in the engine?

[mh]

I just increased the size of the texture; the actual lightmap data in DirectQ is still 1/16 of regular textures. We looked at this for RMQ as something that might be a desirable feature, but I've resisted it for a number of reasons. First up, a lightmap of even 2x the standard resolution in each dimension would need 4x the texture memory, and it goes up exponentially from there. Now, 2x the resolution is peanuts; it's nothing for lightmaps. But you're talking about close on 64 MB of texture memory for RMQ maps, taken up by lightmaps alone. Then we gotta handle animations and dynamics, so they're gonna take say 4x the time to handle. We already got frames running at 12ms per frame with all this stuff, so say 48ms per frame worst case. Not gonna happen. (Thats why I completely changed the way RMQe does lighting - and it's very much a non-trivial change.)

The hard reality here is that Quake's lightmaps are great up to a point, but beyond tbat point they suck. Going beyond their current capabilities is going beyond the capabilities of classic lightmaps; classic lightmaps just can't realistically handle higher resolution, and if you want better you need to start looking at real time lighting solutions and deferred rendering (and the consequent bump in hardware requirements).

[goldenboy]

It seems Source allows the user to set lightmap resolution per face, while mapping.

In the end, that suffers from the same problems though because eventually mappers are just going to use higher and higher resolutions...

[metlslime]

in medal of honor (the Allied Assault era) there was a feature to set lightmap scale per face. We generally set low scale on all faces except where we wanted a nice hard shadow edge... and we tried to be conservative about how many hard shadow edges we had in the level, so that they could be consistently crisp without bloating the level size. We also went for crisper edges near the player and low res on distant, unreachable geo.

So the feature is worthwhile if the mapper using it has some sense of self-control.

[mh]

You can wing it in Quake by using a larger texture scale, but the obvious downside is that it will also affect regular textures. Separating texture scale from lightmap scale needs a BSP format change, as well as tool and engine support.

Another idea I had once was to take the 2x2, 4x4 or 8x8 source data (from before the light tool downsamples it) and write that out directly to a LIT file type thing. That needs an extension to the LIT format (a new version number and an extra header field for the scale), as well as some engine changes, but it would give you higher resolution, although with all of the texture memory overhead and dynamic update problems I mentioned earlier. It's neat though because it wouldn't require any longer to build the light data.

Some figures.

A classic id1 map with maybe 13 lightmap textures needs ~850k of texture memory (assuming coloured light).
Going to 2x the resolution in each dimension raises it to almost 3.5mb.
Going to 4x raises it to 13.5mb.
Going to 8x raises it to almost 55mb.
A big map with say 64 lightmap textures would need 256mb of texture memory at 8x.
And it's still at a lower resolution to Quake's native textures.

I still think that by the time you're doing this kind of thing, if you want to retain all the functionality of original Quake lightmaps, you're better off looking at real time solutions instead.

[r00k]

Can you use cubemapping for lightmaps?

[leileilol]

It seems Source allows the user to set lightmap resolution per face, while mapping.

In the end, that suffers from the same problems though because eventually mappers are just going to use higher and higher resolutions...

Well remember Quake's lightmap stuff is strict because it was made for a software renderer that has fixed surface caches and span routines for 16 step lightmaps, hence the reason for the stretch workaround. accellerated engines have no qualm for higher lightmap resolution, though it may be slower if you lightstyles a lot, not to mention it'll make dynamic lights smaller

[Vic]

FBSP version of q3bsp format uses 512x512 lightmaps natively. and yes, high res lightmaps do help contrary to what mh says!

[r00k]

is ther a quick and dirty way to limit lightmap color to not go BLACK?? I've seen some areas on normal ID maps that are black, but REALLY black should really never happen unless the room is >80% without lighting. Eg. im standing at pent window on dm3 and looking towards quad doorway and theres 2 edges that are BLACK. I know its a mapping fault but still, looks silly.

[leileilol]

In software rendering there's a slight intensity kick for blending lightmaps so it's never total unintentionally black. GLquake probably doesn't do this by default.