New ID1 LIT Pack

[mh]

You might notice this on QuakeOne, but for anyone who missed it, I've recently been working on an updated version of my old MHColour utility, with a view to producing a debugged LIT pack. The results are in.

http://mhquake.blogspot.com/2009/05/wow-release.html

[xaGe]

Nice...

[Chip]

Waiting for the MHColour utility now. I have some maps to relight

[mh]

It's in the LIT pack.

[metlslime]

so, what exactly does your program do? I gather from the readme that it uses textures from the BSP (and skins from light entity models such as torches) to determine color. But, does it actually place new light emitters or does it merely set the color of existing light sources?

And if so, is there some distance threshold that determines whether a light gets colored by a nearby texture? And does each light only use one nearby surface to get texture color info from? Also, it looked like the sky always cast white light in the id maps, is this because you don't do skies, or is it because the light entities are generally not close enough to the sky faces to get colored?

[mh]

so, what exactly does your program do? I gather from the readme that it uses textures from the BSP (and skins from light entity models such as torches) to determine color. But, does it actually place new light emitters or does it merely set the color of existing light sources?

And if so, is there some distance threshold that determines whether a light gets colored by a nearby texture? And does each light only use one nearby surface to get texture color info from? Also, it looked like the sky always cast white light in the id maps, is this because you don't do skies, or is it because the light entities are generally not close enough to the sky faces to get colored?

Quite a lot there!

1) It doesn't actually do anything with lights at all. Instead, what it does is place new "colour points" in the map, which are then used to derive a "colour map", similar to a lightmap but just containing colour info. There are screenshots on my site of the raw colour map. This is multiplied by the original lightmap to derive the final result. The exception is light sources that have a model - these have a colour set. Otherwise, existing light sources are left alone. The colour points aren't saved out, and the original BSP is left completely untouched.

2) All surfaces are subdivided so that a large surface can potentially generate more than 1 colour point. Regular surfaces are subdivided into 64 unit blocks, water and other liquids into 128 unit blocks. The mid-point of each poly generated is used as the baseline colour point position.

3) Colour point placement depends on what the colour point is generated from. For a torch, it will just be the entities origin. For a texture, it is pushed out slightly along the surface normal so that it's in open space (this is checked to ensure). Aside from torches, the original light entities have no bearing whatsoever on placement.

4) Intensity for a colour point is generated in different ways. For torches it's the light intensity. For textures it depends on the texture size and the number of texels that contribute to the colour point. Colour is a mixture of simple averaging and a lot of jiggery-pokery and voodoo. I don't pretend that there's any rational basis for some of the choices made and methods used - in the true spirit of the original ID light.exe, "it was tweaked until it looked good".

5) Because there can be a lot more colour points in a map than there is light sources, visibility info in the map is used to speed things up.

6) I don't do skies. No technical reason not to, but I decided on balance that huge swathes of purple light in the maps might be a bit strange looking. I might add them as an option to a future release, but if so they're going to have some very heavy biasing towards white

[leileilol]

i actually lik these better than the ooooold litpack from 2001. it's not as supersaturated. Flourescent lights could give off less saturation though, and slightly more yellow.
Makes me think that there should be a way for .litgrid generation for Darkplaces to parse for lightgrids in q1bsp maps. (No, DP lacks this feature.)

I also wonder if it's possible to detect torchlight, and force some lightstyles on it anyway, with a special UnrealEngine1-style animated 'texture' to its casted light, baked into the .lit? On second thought WHY HASNT THIS FEATURE BEEN DONE IN LIGHT COMPILING TOOLS ALREADY

[scar3crow]

Lightgrids in q1bsp would be very nice, but takes a good bit of work to implement, as you have to create the grid for the q1bsp first, before you can consider doing anything with light using it... I'd love to see it though.

Good job on this mh, its both tasteful, and the application is neat.

BTW, I wouldn't mind some purpleish light outdoors, Quake is a strange place after all, I think it could work...