\section{Introduction}

There are three problems of planetary terrain that this work addresses.
The curved body of the planet means that for a viewer on the surface
there is a horizon that marks the boundary between what can be seen and
what cannot be seen. The terrain algorithm must ensure that the area
behind the horizon is adequately sampled so that any mountains that
affect the image are sampled. The second problem is the issue of the
large scale of the planet. This affects the z-buffering algorithm which
only maintains a limited precision buffer for determining surface depths.
The final problem is using datasets in appropriate map projections for
the area depicted. This problem commonly demonstrates itself near the
poles of planetary terrain renderers. Distortion is visible since the
underlying map projection used is meant for the equatorial region, and
yet the square mipmap filter is being applied to the distorted polar
regions of the mipmap.

We choose to adapt a planar terrain algorithm to the sphere to enable
planetary rendering. Projective Grid Mapping (PGM) is chosen since it
allows the creation of the terrain mesh entirely in GPU memory. This
obviates the need for vertex transfer between the CPU and the GPU.
PGM also generates the mesh in a view-dependent manner with gradual
detail transition moving further away from the viewer.

The GPU-resident mesh representation allows us to apply dynamic,
massively parallel operations to the terrain mesh at runtime.  In the
case of planetary data, usually the visualization involves multiple data
maps (heights and colors) that might overlap. Terrain composition as
described by Kooima\ea{KLJ*09} allows for these overlapping datasets to
be combined at runtime.  Using deferred texturing and PGM, we implement
a full planetary terrain renderer.

In order to simplify ray-sphere intersection and to create a conceptual
framework through which to solve sampling problems, described later,
we reduce ray-sphere intersection to two dimensions as a function of a
ray's angle to the line connecting the viewpoint and the sphere's center
(\Section{reduction}).

Before PGM can be applied to the sphere we must avoid sampling issues.
This is done by selecting reference spheres for ray casting, and
generating a sampling camera (\Section{refSpheres}).  The entities are
used in ray casting the sphere.

The purpose of reference spheres is to avoid sampling issues when
ray casting.  The sampling camera minimizes the number of rays that
don't contribute either because they miss or they sample the area of
the planet that does not affect the final image (\Section{sampCam}).

Finally, the ray casting step uses these entities (\Section{PGM}).
The goal is to generate positions relative to the camera to avoid
artifacts due to 32-bit floating point imprecision.  The output of PGM
are two buffers, sized to the projective grid; the positions and sphere
normals.  Positions are used as points on the sphere to be displaced later.
Sphere normals are used to determine a geographic location.

These buffers are fed into the height compositor as done by
Kooima\ea{KLJ*09}.  The mesh is then rasterized by displacing each grid
point along its composited height value.  Colors are then composited
in screen space. In order to read the data maps, map projections must
be implemented on the GPU. We formulate versions of these equations for
the GPU (\Section{mapProj}).  Finally, lighting is applied.

We demonstrate the performance of this algorithm and identify
some of its weaknesses in a simulation of a full-planet of Mars
(\Section{results}).
