Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses

[Mark Wedel]

Alex Schultz wrote:
>>
     
     
     >>
     
       I don't remember the details, but I don't believe they get more 
     
     >>
     
      powerful as they get farther.  However, the core of the cone certainly 
     
     >>
     
      is more potentent than the edges, and that is intentional.
     
     >
     
     
     >
     
     
     >
     
      Interesting... I just did some tests (with dragonbreath) and the center 
     
     >
     
      of the cone being more powerful at the center, it's also brighter at the 
     
     >
     
      center under my patch, however it is too bright overall. I was about to 
     
     >
     
      say that we could just tweak the spell effect's glow_radius, however 
     
     >
     
      that is already 1, so perhaps I should omit additive lighting from this 
     
     >
     
      patch and wait till we have the greater number of lighting levels (and 
     
     >
     
      perhaps floats should be allowed in an object's glow_radius in the 
     
     >
     
      process for spell effects that often overlap). Do you agree?
     
     
  Not 100% sure what you're saying.  If you are saying to store the intermediate 
results in floats, no problems there.

  If the idea is to change glow_radius (which really needs a new name) to a 
float, that could be done.  Could be a little confusing what it really means 
however (that may just be a question of documentation).  For example, if you 
have a 'brightness 0.2' object, what effect does it have if it is just by itself?

>
     
     
     >>
     
        Also, it is worth noting that the client actually takes single byte 
     
     >>
     
      values for the light level (range of 0-255).  However, the fact that 
     
     >>
     
      only 4 light levels are really recognized are sort of done in the 
     
     >>
     
      calculation - there is no good reason for that, as more light levels 
     
     >>
     
      break that.
     
     >
     
     
     >
     
     
     >
     
      Hmm... though that's currently slightly wasteful bandwidth wise, it is a 
     
     >
     
      nice thing for expanding, in that less would need to be changed in the 
     
     >
     
      lower level protocol to add more lighting levels.
     
     
  Well, right now, the server convers the 4 current light levels to an integer 
(0,64, 128, 192, 255) and sends that as the light level to the client.  So right 
now, that is somewhat wastefull, but was forward enough thinking that the 
protocl doesn't need to be changed for new light levels.

>>
     
     
     >>
     
       Best place is at load time.
     
     >
     
     
     >
     
     
     >
     
      I agree. I just don't know exactly where in the code that is :-P  as I 
     
     >
     
      haven't looked very far outside of where I've needed to look to make the 
     
     >
     
      patch so far, but it shouldn't be too hard to find.
     
     
  common/loader.l - find the glow_radius line.

>
     
     
     >
     
      Good idea, I'll begin working on implementation this conversion soon. 
     
     >
     
      However one issue is whether the radius of the lit area (area that 
     
     >
     
      doesn't round to zero) should be as far from the center as the flat side 
     
     >
     
      of the old square lighting, or should the new radius be equal to the 
     
     >
     
      radius to the corner of the old square, or should it be inbetween?
     
     >
     
      _________
     
     >
     
      |         |
     
     >
     
      |         |
     
     >
     
      |         |      As in, should the new circle fit inside the old box, 
     
     >
     
      should the old box fit inside the new circle, or somewhere inbetween?
     
     >
     
      |         |
     
     >
     
      |_________|
     
     
  The calculated field (circle) should fit inside the square - in other words, 
the corners of the square won't be illuminated.

  IMO, that will have less bad side effects - however, there is probably no 
perfect answer.  I could see that the scenario that the map designer selected a 
light level with the intention of the corner being illuminated that thus 
visible, and what I say above breaks that.

  However, there could also be a case where a map maker intentionally put 
something out of the light, and increase the range of light could break that.

  One thought I also had is that perhaps the map darkness (perhaps better 
renamed ambiant_light) represents just that - the ambiant light level of the map.

  The idea being is that something like a tavern may not be truly dark, but 
could have a somewhat dim overall look. You bring a torch in, you light up the 
area around you, but the torch range is the same as normal.

  An underground map could have an ambiant light level of 0, representing no 
light at all.

  currently, the darkness field in the map represents how far one can see 
without any other light - that is sort of an odd definition - at dusk (or during 
a full moon) it can be somewhat dark, but one can still see a long ways - just 
everything is darker during the daytime.    I think the ambiant light level 
would be a nice way to add some atmosphere to more maps.