
\section{Terrain Rendering}

\begin{slide}
\subsection{\bf Rendering of Terrain} 

Terrain rendering is a special case of 3-D volume rendering:
{\parskip=0pt
\begin{itemize}
\item The objects are static -- only the viewer moves.
\item There is only a single simply connected object -- the land surface.
\item A terrain model is basically a 2-D surface with a variable 
      elevation in the third dimension, which is much simpler than a general 
      3-D problem (sometimes called a 2.5 dimensional problem).
\end{itemize}
}

So there are a number of optimizations and simplifications
that can be made for a terrain rendering program that cannot be done
for a general purpose 3D rendering program.

Here we outline some of the techniques used to render terrain. 
Various parts can either be implemented in a terrain rendering program 
or preprocessor or done by the VRML rendering engine.

\end{slide}


\begin{slide}
\subsection{\bf Portability and Scalable Rendering} 

For best results, the rendering must be done on a high-performance 
computer or a computer with graphics hardware. 
However the renderer should be portable,
so it will run on parallel computers with different numbers of nodes, 
high-end graphics workstations, and even personal computers.

Our strategy is to make a scalable 
algorithm that will always run in near real time, 
by (gracefully) sacrificing image quality when there is less 
compute power available. 
This can be done relatively easily using polygon-based rendering by
coarsening, i.e. reducing the number of polygons used. 
% Currently an animated display can be done on a Mac, but only by using a 
% wireframe representation of the scene.

This method requires handling two interesting problem areas:
{\parskip=0pt
\begin{itemize}
\item Keeping a constant frame rate for different computers and 
      different scenes 
\item Creating optimal coarsenings of the polygons 
\end{itemize}
}

\end{slide}



\begin{slide}
\subsection{\bf Portability and Scalable Rendering} 

For best results, the rendering must be done on a high-performance 
computer or a computer with graphics hardware. 
However the renderer should be portable,
so it will run on parallel computers with different numbers of nodes, 
high-end graphics workstations, and even personal computers.

Our strategy is to make a scalable 
algorithm that will always run in near real time, 
by (gracefully) sacrificing image quality when there is less 
compute power available. 
This can be done relatively easily using polygon-based rendering by
coarsening, i.e. reducing the number of polygons used. 
% Currently an animated display can be done on a Mac, but only by using a 
% wireframe representation of the scene.

This method requires handling two interesting problem areas:
{\parskip=0pt
\begin{itemize}
\item Keeping a constant frame rate for different computers and 
      different scenes 
\item Creating optimal coarsenings of the polygons 
\end{itemize}
}

\end{slide}


\begin{slide}
\subsection{\bf Terrain Object Representation}

A terrain object is defined by an elevation (height) field and an image.
The elevation field encodes information as elevation $y$ for a
specific $(x,z)$ coordinate. The image gives the color associated with 
the coordinate. This information can be obtained from a digital elevation 
model (DEM) and a satellite image of the terrain. 

A terrain is a simply connected surface (i.e. no disjoint sections),
so terrain rendering is a special case of volume rendering, sometimes 
described as 2.5-D rather than 3-D. This allows some optimizations
to be used in the rendering process.

The terrain data set is stored as a number of two dimensional grids. 
Each grid contains a subsection of the terrain data set. 
The data is stored as triangular polygons made by triangulating the 
square mesh used as the basis of the DEM.

\end{slide}


\begin{slide}
\subsection{\bf Polygon Representation}

The terrain data can be stored at different levels of resolution.
Coarser resolution polygons can be used for terrain further from the 
viewer. This greatly reduces the computational requirement. 
%
Can do this very simply by just using a coarser mesh, but may be 
more effective to use an adaptive scheme with a very coarse 
mesh for flat regions (lakes, plains) and a less coarse 
mesh for mountains.

\begin{minipage}{4in}
% \begin{picture}(288,288)
\centerline{\psfig{figure=grid1.eps,width=3in}}
% \end{picture}
\end{minipage}
\ \
\begin{minipage}{4in}
% \begin{picture}(288,288)
\centerline{\psfig{figure=grid2.eps,width=3in}}
% \end{picture}
\end{minipage}

\end{slide}



\begin{slide}
\subsection{\bf Shading and Shadowing} 

Because the light source remains constant and terrain is virtually 
non-reflective, shading and cast shadows do not
change from one view to another. 
Thus a significant portion of the rendering process, the
computation of shadows and shading, can be done in a preprocessing step. 

Shading can be modeled as two separate processes:

{\bf Diffuse light} is uniformly reflected from surfaces,
i.e. does not depend on the angle of the surface to the viewer,
only to the light source.
\\
{\bf Ambient light} is radiated from all the objects in the scene, and
is independent of the light source.

Diffuse light is blocked in areas of shadow, so must compute the 
areas in shade (occluded from the light source).
Ambient light is not affected by shadowing.

\end{slide}


\begin{slide}
\subsection{\bf Shading Model} 

Different materials have different parameters for ambient and diffuse
reflection, which are used in a standard Lambertian shading model to
calculate the intensities for ambient and diffuse light.

\vspace{0.5em}

\begin{figure}[h]
\centerline{\psfig{figure=lighting.ps,height=1.5in}}
\end{figure}

\begin{figure}[h]
\centerline{\psfig{figure=terrain.bw.ps,width=3.75in}}
\end{figure}
\centerline{\Smallsize Example of a shaded terrain.}

\end{slide}


\begin{slide}
\subsection{\bf Shading Model} 
%  
\begin{eqnarray*}
\mbox{\Smallsize \bf Ambient light \quad} 
& I= & I_{a}k_{a} 
\\
\mbox{\Smallsize \bf Diffuse light \quad} 
& I = & I_{p} k_{d} \cos \theta = I_{p} k_{d} \, \overline{N} \cdot \overline{L} 
\\
\mbox{\Smallsize \bf Together \quad} 
& I= & I_{a}k_{a} + S_{i}I_{p} k_{d} \, \overline{N} \cdot \overline{L} 
\end{eqnarray*}
% 
{\parindent=0pt \Smallsize 
\begin{minipage}[h]{4.25in}
\begin{eqnarray*}
I & = & \mbox{total intensity} \\
I_p (I_a) & = & \mbox{diffuse (ambient) intensity} \\
k_a & = & \mbox{ambient reflection coefficient} \\
k_d & = & \mbox{diffuse reflection coefficient} \\
\overline{N} & = & \mbox{normal to the surface} \\
\overline{L} & = & \mbox{position of the sun} \\
\theta & = & \mbox{angle between sun and normal} \\
S_{i} & = & 0 \mbox{\quad {if in shadow}}\\
      & = & 1 \mbox{\quad {if not in shadow}}
\end{eqnarray*}
\end{minipage} \ \
% 
\begin{minipage}[h]{3.75in}
\begin{centering}
\psfig{figure=diffuse.eps,width=3.75in}
\end{centering}
\end{minipage} 
}

\end{slide}


\begin{slide}
\subsection{\bf Shadowing} 

A Z-buffer algorithm is used to calculate the area in shadow, 
which is identified by finding the back-facing polygons. 

\vspace{1cm}

\begin{figure}[h]
\begin{center}
\begin{picture}(300,220)
\psfig{figure=shadow.bw.eps,width=300pt,height=220pt}
\end{picture}
\end{center}
\end{figure}

\end{slide}



