--- 19/Jan/98 -------------------------------

Here is an idea to implement dynamic lights (like the ones used in Quake)
to simulate explosions or moving light sources.

When a dynamic light is created it has a maximum radius. With this maximum
radius we can search all polygons that are hit by the dynamic light. So every
dynamic light maintains a list of polygons that are affected.

In turn, every polygon maintains a list of dynamic lights that hit the polygon.

The dynamic lighting itself happens on a texture from the texture cache. So
if a polygon is not visible and/or the texture is not in the cache, the dynamic
light has no effect (other than registering itself to the polygon).

If a polygon is visible and is hit by a dynamic light we need to be able to
restore the texture from the texture cache preferably without having to
recompute it completely (this would be too slow). To do this, every dynamic
light remembers the part of the texture it has changed. We don't remember
whole the texture, but just a rectangle that is large enough to store the
projected circle from the dynamic light.

Following from this it can easily be seen that the order of the dynamic
lights in every polygon is important. The last added dynamic light should
be removed first.

If there are three dynamic lights hitting the polygon and you want to change
the middle one, you will first have to restore (if the regions overlap) the
last dynamic light, then restore the middle dynamic light. Redraw the
middle dynamic light and then redraw the last dynamic light.

So this dynamic lighting system works most efficiently if there is only
one dynamic light affecting a polygon (which is a common case) but it also
works in general.

When a dynamic light moves:
    - we need to update the list of polygons and also change the list of
      dynamic lights in all polygons.
    - we also need to restore what was behind the region of the dynamic light
      for every polygon and then redraw it.

When a dynamic light changes intensity:
    - we just restore what was behind the region and redraw it again.

I think this scheme is fairly efficient because:
    - it only affects visible polygons.
    - if the dynamic light doesn't move or change intensity for a few frames
      then there is no performance penalty at all.

The inefficiencies caused by multiple dynamic lights hitting the same
polygon are not that bad because most of the time all dynamic lights will
change anyway, so you can just redraw them all.

Is this is a good method? If not, what can be done better?

If only I had some time to implement this... (hint hint :-)



--- 9/Jul/97 -------------------------------

IDEA for spherical lighting with no shadows (9/Jul/97):

	- Each light is defined as a sphere with a centerpoint, a maxium
	  radius, an intensity and a fallof ratio.
	- The sphere of every light is intersected with the plane of every
	  polygon in the sector. This defines new rectangular polygons
	  with a high-intensity point (the point of that polygon that is
	  closest to the light), an intensity and a fallof ratio (but
	  2D this time). This part of the calculations need only be done
	  the first time a light is created or if a light moves.
	- Note that these light-polygons must be clipped against the
	  original source polygon.
	- An optimization in this process would be to merge all created
	  light-polygons if their planes are the same. This is a fairly
	  common case.
	- These polygons are handled like all other polygons:
	  they are transformed, perspective projected, and clipped
	  against the view.
	- These polygons are drawn after all other polygons (but before
	  the sprites). This can be accomplished by just putting these
	  polygons last in the list. But I think it is better to just
	  make a new list for them.
	- The draw_filled_2d for a light-polygon will act differently.
	  Instead of filling from a texture, a light-filter will be
	  applied to the already drawn polygons below. We use interpolation
	  here like in the texture mapping code.
	- Sprites are considered seperately. For efficiency I would only
	  apply a constant light-level for every polygon.
	- Maybe we can support shadow-polygons. These are not visible but
	  only act to simulate shadows at specific places.
	- It should be possible to apply a constant lighting level to
	  some polygons. This can be used for simulating the visual appearance
	  of lamps and for the sky.

