Lightmaps and how light works in compile ...
Lightmaps and how light works in compile ...
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.
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.
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).
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).
Benjamin Darling
http://www.bendarling.net/
Reflex - In development competitive arena fps combining modern tech with the speed, precision and freedom of 90's shooters.
http://www.reflexfps.net/
http://www.bendarling.net/
Reflex - In development competitive arena fps combining modern tech with the speed, precision and freedom of 90's shooters.
http://www.reflexfps.net/
..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?
Electro wrote: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).
..I asked myself the same thing after I posted... I'm not sure myself anymore... I know someone does though, lets see who...
Baker wrote: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?
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.
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.
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)
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)
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.
- 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.
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...
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...
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