[crossfire] LOS and lighting map redo

Mark Wedel mwedel at sonic.net
Wed Aug 31 01:37:55 CDT 2005


Brendan Lally wrote:
>
     
      On 8/30/05, Mark Wedel <
      
      mwedel at sonic.net
      
      > wrote:
     
     >
     
     
     >>
     
       Other thoughts;  Is there a strong desire to be able to have colored lighting
     
     >>
     
     (Red, green, whatever)?
     
     >
     
     
     >
     
     
     >
     
      Yes, and directional ones too (that propagate in a cone in a given
     
     >
     
      facing). This would be a nice easy way to make the colours of items
     
     >
     
      vary then. (instead of making a blue version of a wall, have a white
     
     >
     
      one, add a directional negative glow radius 'white' light, and a
     
     >
     
      positive glow radius directional 'blue' light, and have the client's
     
     >
     
      graphics card deal with the colouring. This would allow much more
     
     >
     
      variation in colours of objects, without adding arches. (and colour
     
     >
     
      spray done by abusing that could look pretty).
     
     
  Colors aren't as hard.  Especially if we make the rule that if a space has 
multiple light sources, the brightest one takes precedence for things like color.

  That said, it then depends on how many colors and how much bandwidth we want 
to use for lights.  If for example we say max brigthness if 15 (4 bits), that 
gives 4 bits for colors (15) and still be able to fit lighting informatin into 1 
byte.

  Directional light sources are more difficult.  I was originally thinking it 
wouldn't be hard - and for the server side of things, it actually wouldn't be 
that hard.

  The problem is communicating this to the client - we now need to tuck the 
direction someplace in the protocol.  And using a few bits, that could be done. 
  But then you get the case of suppose you have a space with multiple 
directional lightsources of varying brightnesses.

  From the server perspective, what I see calculating for each space is 1) The 
brigthness 2) the color and 3) directional information.

  Point #3 is hard to do if you have the situation I describe - multiple 
directional light sources of different color.

  So I'm thinking the directional light sources is something.  We could generate 
a bitmask of the directions, but that isn't going to give satisfactory results. 
  So you'd now need something like ability to actually have multiple light 
sources on the same space with different attributes and send that to the client.

  IMO, that is getting things more complicated (client now has to be able to 
handle all that also).

  IF the real goal is to be able to say 'make this space green', I'd almost 
think the way to go is just add a color hint object or something.  After all, 
problem with light sources would be dimming, uneven color, etc, even with 
directional light.

  However, either method still has the problem that this is an attribute of the 
space.  So not only would the wall be green, but the floor underneath it, etc, 
which probably aren't the results we want.

  I'd also be tempted to say that if the only goal is to make different color 
objects, pretty simple manipulation through image editing programs can do this 
with probably equal quality as the graphic card.  After all, the graphic card is 
just using some algorithym to do it, and I'm sure that exists in numerous functions.

  So in summary, I think adding support for different color light sources, but 
still only have circular light sources is the way to go.


>
     
     
     >
     
      _______________________________________________
     
     >
     
      crossfire mailing list
     
     >
     
     
      crossfire at metalforge.org
      
      
     >
     
     
      http://mailman.metalforge.org/mailman/listinfo/crossfire
      
      
     
    


More information about the crossfire mailing list