\section{Results}

\begin{figure}[h]
\begin{tabular}{cc}
	\includegraphics[width=1.5in]{images/hawaii_1.jpg} &
	\includegraphics[width=1.5in]{images/hawaii_2.jpg} \\
	\includegraphics[width=1.5in]{images/hawaii_deform_1.jpg} &
	\includegraphics[width=1.5in]{images/hawaii_deform_2.jpg}
\end{tabular}
\caption{Screenshots from the visualization of the Hawaii dataset.\label{Fig:Hawaii}}
\end{figure}

\begin{figure}[ht]
\begin{tabular}{cc}
	\includegraphics[width=1.5in]{images/yuma_2.jpg} &
	\includegraphics[width=1.5in]{images/yuma_1.jpg} \\
	\includegraphics[width=1.5in]{images/yuma_3.jpg} &
	\includegraphics[width=1.5in]{images/yuma_4.jpg}
\end{tabular}
\caption{Screenshots from the visualization of Yuma, Arizona with tire track deformation.\label{Fig:Yuma}}
\end{figure}

The following tests were performed on a machine with an Intel Core2 Quad
Q9450 processor with 8GB of DDR2 RAM and a NVIDIA GeForce GTX 275 under
Windows XP Service Pack 2, which can only utilize 3.5GB of RAM.

The data used for these results was obtained from~\cite{VTP}, which holds 10-meter elevation data of the big
island of Hawaii along with a $4096\times4096$ texture. The terrain file has dimensions of
$8193\times8193$ and was already in binary terrain (.bt) format. It was first converted into
the internal .ter file and the texture image (.jpg) was converted into a .tex file. Since
these files were so small, the preprocessing took less than five minutes. 

With this application, the user is able to
move around the scene via keyboard and mouse input. By clicking and dragging the
mouse, the user can select a single axis-aligned brush, and change the resolution of
that brush via keyboard input. Once a brush is selected with the desired resolution,
the user may create a hill or crater by raising or lowering the terrain.
Any changes to the terrain are automatically saved to the .ter file and will be
loaded back in when the application restarts. Figure~\ref{Fig:Hawaii} shows screen shots of this
application.

In order to determine how well this algorithm runs, we ran various
operations of it as illustrated in Table~\ref{Tab:results} with a frame buffer
size of $1024\times768$.  The file tested was a ten meter resolution
digital elevation map (DEM) of Hawaii of raster size $8193\times8193$
which can be freely downloaded over the Internet~\cite{VTP}. The first test was to
simply move over the terrain with no deformation occurring.  This tested
the LOD refinement algorithm used to render the terrain in real-time.
The next section of results in the table show the speeds of deformation of
the terrain in terms of frames-per-second.  Using different brush sizes,
we deformed the terrain over the same part of the dataset. For all of the brush sizes
used, the algorithm demonstrated interactive framerates. The largest brush size
used exhibited a relatively low framerate due to the increased amount of refining of the
mesh down to the deepest parts of the terrain hierarchy, which can be considered a worst-case scenario.

\begin{table}[ht]
\begin{center}
	\begin{tabular}{|l | c|}
		\hline
		\textbf{Operation} & \textbf{FPS} \\
		\hline
		Arbitrarily moving over the dataset & 48.41 \\
		\hline
		Deformation with brush of size $32\times32$ & 38.37 \\
		\hline
		Deformation with brush of size $64\times64$ & 23.54 \\
		\hline
		Deformation with brush of size $128\times128$ & 10.96 \\
		\hline
	\end{tabular}
	\caption{Average frames per second over different operations\label{Tab:results}}
\end{center}
\end{table}

Another application of the algorithm has been used for tire track deformation from a military vehicle
navigating the terrain in a dataset from Yuma Proving Ground, an Army installation in Arizona.
Screenshots are shown in Figure~\ref{Fig:Yuma}, and an example can be seen in the accompanying video.

We were unable to compare these results to any prior terrain rendering algorithms
because no algorithm supports deformation out-of-core.
