Lighting
Home -->
Programming Projects -->
Block Engine -->
Lighting
Block Arena uses shadow maps as
one if its lighting techniques.
These shadow maps are computed by the program
by shooting rays into the world
from light sources.
We will describe some of the pros and cons
for different lighting solutions.
No Lighting
The simplest way to deal with lighting is to have
no lighting.
So that this doesn't look completely aweful,
it is a good idea to shade each quad
bassed on its surface normal.
That is, pick 6 different brightnesses.
These will correspond to the directions
top, bottom, from, back, left, and right.
This creates contrast so edges are more pronounced.
Simple Dynamic Lighting
In Block Arena, individual 1 by 1 quads are not rendered.
Instead, n by m quads are rendered.
See the Quad Algorithm
for a description of this.
On the other hand, in a block based game that
renderes individual 1 by 1 quads, there is a simple
way to handle the lighting situation:
color each vertex sent to the graphics card.
This has the advantage of having lighting be dynamic
with no additional cost.
The color of a vertex can be updated
whenever a change occurs locally that could
affect lighting, such as the addition
or removal of a block.
Static Lighting With Shadow Maps
Since Block Arena renders n by m quads instead of
1 by 1 quads, coloring vertices for lighting is
not going to cut it.
To handle this situation,
shadow maps are used.
Every quad is assigned to a portion of a shadow
map texture.
Each 1 by 1 block face should correspond to somewhere between
a 1 by 1 and a 3 by 3 patch of texels in a shadow map.
Larger quads take up larger patches of texels, etc.
There are various issues that need to be addressed here.
For example, there is the problem of chopping a shadow map
into pieces (as if with a cookie cutter)
so each piece can be used to shade a different Quad.
Since we are only dealing with blocks, this is much less of
a headache than the full 3D-version (which is done
in a Quake-Style map creator).
Because of this issue, it would be very annoying to
impliment the ability to dynamically
add and remove blocks
(adding or removing will completely change the shadow maps).
That is, parts of shadow maps would have to be
reallocated.
Updating Lighting When Blocks Change
Regardless of whether shadow maps are being used or
vertices are being colored,
unless we are planning to recompute lighting
information every frame, we need an efficient
way to deal with lighting whenever a block is
added or removed.
If a block is added, this may cause other
blocks to be put in a shadow.
If a block is removed, this may cause light to
hit a block that was previously in a shadow.
We will describe a method for dealing
with this problem.
Given every point light and point on a block surface
close enough to the light to be affected,
consider the line segment between these points.
We may refer to the "block end" and "light end"
of this line segment.
Associate each such line segment with every position
in the world (whether there is a block there or not)
that it intersects.
If a block is added and that block intersects
one of these line segments,
then the block end of the line
segment is now in a shadow.
If a block is removed and that block intersects
a line segment, then the block end of the line
may no longer be in a shadow.
This algorithm is fast at runtime.
The downside is the huge amount of memory it requires.