Game Development Reference
Figure 3.4. Horizon views. (a) A hole at the north pole. (b) The filled hole.
Compared to geometric solutions, our screen-space approach has excellent vi-
sual quality with no tessellation or geometric cracking artifacts, uses very little
memory, and is light on the CPU, requiring only the bounding rectangle compu-
tations, culling, and two draw calls. However, its fragment load can be higher
given that many fragments are discarded from extreme horizon views, 2 early-z
and hierarchical-z are disabled due to using discard , and that a ray/fragment in-
and CPUs and GPUs, we believe this is a good tradeoff.
Overlaying Vector Data
Maps often overlay vector data, i.e., points, polylines, and polygons, on top of
the globe. For example, points may represent cities, polylines may represent
driving directions, and polygons may represent countries. Either raster or vector
techniques can be used to render this data [Cozzi and Ring 11]. Raster techniques
burn vector data into image tiles with an alpha channel. These tiles are then
overlaid on top of the base map imagery. This is widely used; it keeps the
rendering code simple. However, as the viewer zooms in, aliasing can become
apparent, it is slow for dynamic data, and does not support points as viewport-
aligned labels and billboards.
To overcome these limitations, we render vector data using point, line, and
triangle primitives, which requires subdividing polylines and polygons to approxi-
mate the curvature of the globe. Given that these polygonal representations only
represent the true globe surface when infinitely subdivided, the primitives are
2 This could be reduced by using a screen-space rectangle that is the intersection of the pole's
projected rectangle and the ellipsoid's projected rectangle.