Lightmaps and how light works in compile ...

[Baker]

What is the light utility creating when it is running?

Is it generating lightmaps? Are light maps are textures stored in the .bsp?

Do lightmaps work as an overlay texture?

Would it somehow be possible to "light a map" twice and somehow load a second set of lights for day/night?

I'm a little weak on the .bsp still and don't quite understand exactly how the lighting in Quake works.

[Electro]

There are lots of different light compiling utilities.

Yes it generates the lightmaps and they're stored in the bsp.

Yes they are overlayed (multi-textured).

Storing multiple lightmaps like that would most likely require a new bsp version and cannot be added to the existing bsp without breaking compatibility (not entirely sure on this).

[xaGe]

..I would be inclined to agree... That's why glquake engines use external .lit files to load colored light info and apply it to (or layered over) the already existing Quake bsp format yes?

Storing multiple lightmaps like that would most likely require a new bsp version and cannot be added to the existing bsp without breaking compatibility (not entirely sure on this).

[Baker]

At least some engines can turn on/off external .lit support but it requires restarting the map for the change to take effect.

Are the external lit files additive to the lit information already in the map?

Or are they used as a full and total replacement of the lighting information in the map?

[xaGe]

..I asked myself the same thing after I posted... I'm not sure myself anymore... I know someone does though, lets see who...

Are the external lit files additive to the lit information already in the map?

Or are they used as a full and total replacement of the lighting information in the map?

[Baker]

..I asked myself the same thing after I posted... I'm not sure myself anymore... I know someone does though, lets see who...

Sounds like a plan

[metlslime]

1. you can set lightstyle 0 using quakec, this controls the brightness all of the static lights in the map.

2. for even more control, you could light the map twice, and give the second set of lights all the same targetname (this gives them a shared nonzero style number) and then control that style using quakec.

[metlslime]

note, you can only have four lightstyles on any given face, so by doing #2 above you've reduced your budget for all other switchable or pulsing lights in the level by 1 per face.

But, if you exceed this limit, it's not fatal, your map (may) just have some visual bugs (such as specific faces that don't seem affected by a strobing light)

[metlslime]

oh, and as for how they work:

- they are textures stored in the bsp

- each face has up to four lightmaps, one per lightstyle that touches it (based on radius of the light)

- at run time, the four lightmaps are combined to make one image, which gets uploaded into opengl

- at render time, the lightmap is multiplied by the texture, either using multitexture or multipass rendering

- if the light style ever changes (often for pulsing/strobing, rarely for switchable lights) a new lightmap is calculated and re-uploaded to opengl. This is why dynamic lighting can be slow on old cards, uploading is slow. This is also why quake3 has no real dynamic lighting.

[mh]

Hmmm - I wonder how easy it would be to change or remove the max lightstyles on a face limit? Easy enough in code alright (just change the #define to increase it) but I'm thinking in terms of compatibility.

Example: if I had a map that had - say - up to 8 lightstyles on faces, how badly would it choke an engine that didn't support this increased limit?

One way to find out, I suppose...

[Spike]

if I had a map that had - say - up to 8 lightstyles on faces, how badly would it choke an engine that didn't support this increased limit?

Funny lump size, no doubt.
The loader will reject it with an error.

[mh]

sizeof (dface_t) will be different, you're right. Bummer.