[crossfire] lighting & LOS redo.

[Alex Schultz]

Mark Wedel wrote:

>1) Increase number of lighting levels from 4 to 12.
>  
>
Seems rather arbitrary, but seems reasonable.

>2) Calculate light levels as a map attribute, and not part of player LOS (this 
>will make things more efficient.)
>  
>
Yep, that seems good, though we do have to remember that even without a 
light source players have a small area around them they can see better in.

>3) Add ambient light level attribute to map header, which says what basic 
>lighting level on all spaces is (dimly lit rooms).
>  
>
Yes, this seems like a good idea, also if light color is implemented, 
might be a good idea to allow the ambient light to be colored optionally.

>4) Change meaning of darkness map header (should change name - light_threshold?) 
>- if space is below that light level, space can not be seen
>  
>
Hmm, that seems good, and should map fairly well to existing values in 
maps, however we still may need to tweak some existing maps.

>5) Have walls block light (note that the wall itself will be illuminated, so for 
>single thickness wall, this still won't look very good).  The idea was brought 
>up of walls being lit base on where the light source is relative to the player - 
>if the lightsource was on the opposite side of the wall from the player, it 
>doesn't illuminate the wall.  I think this is doable.
>  
>
This seems like a good idea to me, including deciding if it's lit by 
where the player and lightsource, which would in my opinion be very good 
to implement.

>6) Add partial blocking to terrain (or other objects) - for example, jungle 
>might have a value of 3, so everything beyond the first space is darker, 
>everything beyond the second space is darker still, and and some point, can't 
>see any further.  This is done basically by darkness.
>  
>
This seems like a good idea, also some monsters and items could be made 
partial blocking to be realistic to how they do block your view a bit, 
not really sure about that, but perhaps.

>7) Add colored lighting.  Note that this is opaque to the server - it doesn't 
>care what the color of the light is - it just passes that info to the client to 
>do with it what it wants.  Note that handling more than 1 light source/space 
>adds a bunch of complication, so my thought is the brightest light source on a 
>space is the one that is sent.  One question is then what form to use for the 
>color - using the crossfire built in colors is pretty limiting (and probably is 
>not a good enough representation).  One thought might be 6 bit RGB value, as it 
>is compact and probably still provides a good enough resolution (you're unlikely 
>to need a dim green value - I'd think that in most cases you want pretty 
>saturated values).
>  
>
Well, this would allow "black lights" that actually illuminate. I'm not 
sure such flexibility is useful or good, as we don't need to send the 
intensity of the light source in a second form at once. Perhaps we would 
be better off sending a 6 bit Hue/Saturation pair?

>8) Light source information is sent to the client, and not actual darkness of 
>each space.  The color of the light is also sent.  Light values could be 
>negative to denote that the space partially blocks the light.  Out of view light 
>sources are sent to the client if they illuminate a space the client can see. 
>Also, this will also have to be used to denote spaces that block all light (eg 
>walls)
>
This seems like a good idea to me anyways.

Also, it might be good to allow objects to specify the rate at which 
light coming from them fades. Yes, it is true that it fades at a fixed 
rate in real life, however in order to simulate something like a 
significantly elevated light source one would need to make how fast it 
fades slower.

Also, it might be interesting to make it so there are light levels 
brighter than 'fully lit', and if it's enough higher than that, then a 
partial fade-to-white/color effect could be useful and realistic. (this 
would be handled client-side, however we would need to have enough light 
levels that there is room for such)

Another feature that would be interesting, though perhaps a bit 
impractical. It would be possible to for each image, make a "lightmask" 
which would define how much it would pick up light from each direction. 
It would be difficult to get lightmasks made for every image, however it 
wouldn't be too hard to implement in the client and would make things 
look very shiny. That said, I'm not sure this last idea is worth it, 
just brainstorming a bit :-P

Alex Schultz