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.