[crossfire] lighting & LOS redo.

[Mark Wedel]

Alex Schultz wrote:
> Mark Wedel wrote:
> 
>> 1) Increase number of lighting levels from 4 to 12.
>>  
>>
> Seems rather arbitrary, but seems reasonable.

  Most constants are arbitrary at some level.

  However, I came to that number for a few reasons:
a) the MAP2_COORD_OFFSET is set at 15 - I think I arrived at that number by 
figuring current map size was 33x33, and max coordinate was 64, and splitting 
the remainder came to be 15.  That actually isn't right, because for all 
purposes we care about, the map size is 25x25, (64-25)/2 = 20.

b) A glow radius 12 light would reach the map edges when the player is in the 
middle of the map (however, with circular lighting doesn't reach the corners.)

c) Always has to be some compromise - too high a value means a lot of time is 
spent looking for light sources.

> 
>> 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.

  Arguably, that isn't correct.  If you are in complete darkness (in a 
cave/mine), you won't be able to see the hand in front of your face.  That said, 
setting a basic visiblity for spaces around the player would be done in the LOS 
code.  The server still enforces LOS on light - if space is too dark, can't see it

> 
>> 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.

   Maybe.  I'd have to think more about how ambiant colored light would work, 
but putting that in wouldn't be that hard.



>> 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.

  Yes - from the server perspective, it doesn't care what the object is that is 
blocking the light - it would just look for some attribute in the object.

> 
>> 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?

  Black light is a different issue, as it probably wouldn't have the affect 
people would really want.

  But even grey lights get odd - what does a grey light mean compared to a white 
light?  That the light source isn't as bright?  That should be handled by 
glow_radius.

  the actual form of the color isn't that important - as said, the server cares 
less - it is basically taking a byte of data that is set in the object and sends 
it to the client.   But one consideration is that whatever form it is in, should 
be something that is easy to set for players.

  I don't really like the idea of english names - it is the easiest thing to do, 
but now means the server needs to have a large table of 'this color is this 
number', and the client has to have a 'this number is drawn with this rgb 
value'.  So my ideal case is a value that the server loads and can easily 
convert to an int and throw to the client, and the client can know what to do 
with that.

> 
>> 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.

  Maybe, but that 'fade value' also needs to be sent to the client.  I'm not 
actually sure how many times that would come up.  It probably wouldn't be hard, 
just not sure if it would get enough use to be worth it.

> 
> 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)

  That may be doable.  I'm not sure how useful it is to actually fade colors.

  The idea I had was something like a 'glow_radius 16', which would basicaly 
mean the first 4 spaces around it are fully lit, next one at 11, next at 10, 
etc, and only goes out 12 spaces, at which point it is still relatively bright.

  That is in a sense easier to, as it really doesn't require any extra info to 
be set to the client (as long as the client knows the max effective glow radius 
is 12, it is fine).

> 
> 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

  The gotcha there is that is now an object/image attribute and not really 
related to lighting per se.

  I'm also not sure how well any graphic support could really take advantage of 
that with the basic images - making the entire image brighter probably doesn't 
add much - ideally, you would want the image to be lighted on that info (eg, 
only the side of the tower that is getting light is brighter, then you could 
also draw shadows,etc).