Improve lightmap resolution

[mankrip]

If I recall correctly, r_ambient sets the minimum light value for the map.

[mh]

MDLs in software Quake never go below 5 but this was a performance decision rather than one for reasons of style:

Code: Select all

#define LIGHT_MIN	5		// lowest light value we'll allow, to avoid the
							//  need for inner-loop light clamping

Everything else depends on colormap lookups; if the colormap has full black in it's last row then full black is what you're going to get; if it doesn't then you won't.

There are two main conditions in GLQuake - either surf->samples is NULL or it's not. If it's NULL it just clears to black, and this covers cases where no lights hit a surface. I believe this was done for storage reasons rather than anything else (there are a surprising number of surfaces in a typical map that meet this condition) and I also understand that Quake 2 did away with it.

No reason why r_ambient can't be implemented in GLQuake and do the initial clear to it's value. Some might think that it's cheating in MP but it's client-side and in a GPL world any form of client-side cheat-protection is totally bogus - you can just recompile the executable.

[r00k]

Cheat isnt an issue with light maps, a cheater would just remove light maps totally.
im just trying to raise the base definition of BLACK to somthing less like 10% ++
I guess how GB described it, Quake has a short lightmap palette.

[mh]

r_ambient seems like what you want then; you can set the "clear to no light" step to clear to "(int) r_ambient.value << 8" instead of 0. The only tricksy thing is enabling changes at runtime; the way I did this was to have a global "lightproperty" and a "lightproperty" member of msurface_t; both ints. In R_BuildLightMap set "surf->lightproperty = lightproperty", in your check for lightmap modification add "if (surf->lightproperty != lightproperty)", and increment the global lightproperty by 1 everytime a light-related cvar changes. There are other ways that don't require rebuilding the lightmaps, but this was convenient as it enabled a lot of other cvars to be included in the system too.

[metlslime]

there is a feature called "minlight" which tells light.exe to enforce a minimum light value across the entire level. I don't know if it's a command line option or if you have to add "minlight" "x" to the worldspawn entity in your map file. From an artistic point of view, you should not use it -- it's better to hand-place additional dim lights to fill in black areas, simulating the bounce of lights off of neighboring surfaces. But if you're a programmer and just want an ugly, functional level, it works.

[goldenboy]

DM3's lighting is already ugly, and there are practically no "moody shadows" in there anyway, so a little ambient minlight won't make matters worse.

Here's a commandline I just tried (with AguirRe's light tool):

~/quake/tools/bjptools/bin/light -sunlight3 60 -light 20 -soft -extra4 dm3.bsp

Experiment with the value of -light as you see fit. Sunlight 3 is much the same thing, just applied to outdoor areas and areas close to sky only.

You can add -sunlight 250 if you want a more regular sunlight effect in the outdoor sections. Unfortunately you can't really angle the sun or do anything overly complicated, because there are a ton of point lights floating around to simulate the sun. You'd have to remove those and relight the map a little if you wanted a real improvement, but that'd require use of a map editor.

I never understood why the multiplayer community isn't just switching to Than's remake of DM3.

http://www.quaddicted.com/reviews/dm3rmx.html

[frag.machine]

there is a feature called "minlight" which tells light.exe to enforce a minimum light value across the entire level. I don't know if it's a command line option or if you have to add "minlight" "x" to the worldspawn entity in your map file. From an artistic point of view, you should not use it -- it's better to hand-place additional dim lights to fill in black areas, simulating the bounce of lights off of neighboring surfaces. But if you're a programmer and just want an ugly, functional level, it works.

I am far from a good mapper, but I always used -minlight (anything around 16 to 24 is good to simulate a full moon night) in my maps, and for spots where complete darkness are required (tunnels, dead end alleys, etc) I just put lights with negative values. Works pretty well in most of cases.

[goldenboy]

I see nothing wrong with that. Personally I stopped using global minlight, because I want the full available range. But antilights also give you pitch black.

I do use local minlights (delay 4 or something, I forget) to help light really large areas like caves and so on. I have started using antilights to reintroduce black where I want it, usually to counteract the local minlight (or if there is very bright lighting from torches etc in a room, I might place antilights in certain corners to simulate shadows).

Relying only on minlight will give you an ugly level, true. I don't contest that.

[r00k]

[quote="goldenboy"
I never understood why the multiplayer community isn't just switching to Than's remake of DM3.

http://www.quaddicted.com/reviews/dm3rmx.html[/quote]

Hmm, thanks for the link, never saw this map!