View previous topic :: View next topic |
Author |
Message |
mh

Joined: 12 Jan 2008 Posts: 909
|
|
Back to top |
|
 |
xaGe

Joined: 01 Mar 2006 Posts: 329 Location: Upstate, New York
|
Posted: Fri May 15, 2009 3:47 am Post subject: |
|
|
Nice... |
|
Back to top |
|
 |
Chip

Joined: 21 Jan 2009 Posts: 314 Location: Romania
|
Posted: Mon May 18, 2009 7:35 pm Post subject: |
|
|
Waiting for the MHColour utility now. I have some maps to relight  _________________ My Projects: Quake 1 Mods | OpenQuartz 2 | ChipQuake |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
|
Back to top |
|
 |
metlslime
Joined: 05 Feb 2008 Posts: 177
|
Posted: Tue May 19, 2009 12:37 am Post subject: |
|
|
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? |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Tue May 19, 2009 8:30 am Post subject: |
|
|
metlslime wrote: | 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 _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
leileilol

Joined: 15 Oct 2004 Posts: 1321
|
Posted: Tue May 19, 2009 9:52 am Post subject: |
|
|
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 _________________
 |
|
Back to top |
|
 |
scar3crow Inside3D Staff

Joined: 18 Jan 2005 Posts: 837 Location: Las Vegas, NV
|
Posted: Tue May 19, 2009 3:25 pm Post subject: |
|
|
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... _________________ ...and all around me was the chaos of battle and the reek of running blood.... and for the first time in my life I knew true happiness. |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2004 phpBB Group
|