\chapter{Terrain Rendering Systems}
\ref{terrain-rndering-systems}

In chapter~\ref{parallel-terrain-rendering} and \ref{VRML_terrain}, we have
presented the design and implementation of custom-built and web-based
terrain rendering systems.  Although both systems deliver the same information,
the underlying architecture of the two systems is very different.  The
custom-built program transports the information by a sequence of images.  
The web-based system, on the other hand, encapsulates the information
in a VRML file.  Both systems have advantages and disadvantages.
In the following sections, we provide a qualitative comparison of
their features and characteristics of their architectures and components.
Then we will elaborate on the future system architecture of the terrain
rendering system.  Finally, we will provide a list of future research
directions.

\section{Comparison}
\label{compare}

\begin{figure}
\begin{center}
\begin{picture}(356,99)
\psfig{figure=ideal_arch.eps,width=356pt,height=99pt}
\end{picture}
\end{center}
\caption{A basic terrain rendering system implemented on a conventional
computer.\label{ideal_arch}}
\end{figure}

A basic terrain rendering system has three building blocks: a user interface,
a rendering engine; and a terrain graphics object database.  The user interface 
provides the user with easy access to the terrain information through some
controls and a display.  The use of a flexible user interface building system
enables the terrain rendering system to be adapted for different applications.
In addition, the interface is also responsible for maintaining the quality of
the presentation of the requested information as dictated by the type of
application.  
After the user interface has collected the user's inputs, a terrain rendering
engine is used to convert the terrain data into images according to the input
parameters. To accommodate the wide range of client applications, the
capabilities of the rendering engine, such as rendering speed and
techniques, must be maximized and efficient.  In order to have speedy
rendering of the terrain data, the rendering engine must be able to access
the terrain computer graphics objects efficiently.   The terrain object database
provides the storage facility for fast retrieval of the needed data in a format
that minimizes the start-up time of the rendering pipeline.  These three
components must be joined by two communication channels to form a coherent
terrain rendering system.  If this system is implemented  on a conventional
computer system, then they are tied together by the system bus and the I/O bus
as shown in figure~\ref{ideal_arch}.

\begin{figure}
\begin{center}
\begin{picture}(364,237)
\psfig{figure=imbase_arch.eps,width=364pt,height=237pt}
\end{picture}
\end{center}
\caption{The architecture of the image-based terrain rendering system
on client-server model\label{imbase_arch}}
\end{figure}

\begin{figure}
\begin{center}
\begin{picture}(344,201)
\psfig{figure=vrml_arch.eps,width=344pt,height=201pt}
\end{picture}
\end{center}
\caption{ The architecture of the VRML-based terrain rendering system
on client-server model \label{vrml_arch}}
\end{figure}

%System architecture
%need to stress that rendering on the server requires high-performance 
%server, especially if there are many users. 
%One of the main differences here is number of users. If there is only
%a small number of users, rendering on the server may be better solution
%since terrain data resolution and rendering quality is not limited by
%capabilities of client - can just use more and more processors on server.
%If there are many users, rendering on client using VRML scales much better.

Our image-based and VRML-based implementations of the terrain
rendering system extend the basic design to the client-server model by
using a computer network.  Although the resulting hardware organization
of the two systems are similar, the functional organization of the two
client-server systems is different because of the different philosophy of the
projected technology trends.  Figure~\ref{imbase_arch}
shows the architecture of a image-based terrain rendering system.  This design
assumes the client has very limited rendering capability and storage capacity,
but it is connected by a high speed network to a remote computer, which stores
and renders the terrain graphics objects into images on the client's behalf.
Since the computing resources at the server side is finite, this set-up can
only handle a fixed number of clients at a time.  However, the information
provider retains the control of the rendering engine. Hence, the provider can
improve the rendering engine by using faster hardware and a better rendering
algorithm without having to redistribute the client software.

The VRML-based system in
figure~\ref{vrml_arch} assumes that the client has a capable
rendering engine and a high speed connection to World Wide Web (WWW)
servers, where the client can access many different VRML worlds, including
our VRML earth. Because the rendering is done on the client side, the total
amount of computing resource increases proportional to the number of clients.
Therefore, the VRML-based server can handle larger number of clients
simultaneously with the same computing resources as in the image-based system.
On the other hand, the capabilities of different clients may vary, so the amount
of information packaged in the VRML file is limited by an arbitrary ``minimal
client capability'' set by the information provider.  An improvement can be
provided by allowing the client to dynamically select the amount of information
wanted, although this increases the needed computing resources per client at the
server side to construct the VRML file dynamically at the requested resolution
from a database, instead of serving a single file at a single resolution.
Since both systems must use their server to augment the clients' ability
to store and to manipulate the terrain data, high performance servers with lots
of storage space, fast I/O and network are needed to handle the workload.
In the following sections, a comparison for each of the three components,
client, network and server is provided.

\subsection{Client}

%Try to do a fairly quantitative comparison of requirements for client and
%server computers for each system, based on amount of data and computation 
%required for image rendering and transmission and for VRML creation and
%transmission. Also need to take into account possible use of compression,
%e.g. JPEG, MPEG or wavelet for images, wavelet for VRML.

%Another thing you may want to talk about is ease of creating the application.
%It is much easier to construct a VRML data transfer, than to write 
%client/server code, rendering code, user world and let the VRML browser do the 
%rendering, and the HTTP server handle the interface on client, etc.
%However writing your own code offers more flexibility to customize the
%application.
%Comparison for clients involves requirements for:
%- I/O and memory 
%- computation for image display or rendering capability
%Frame rate

%image-based system
%  - non-portable
%  - unlimited rendering capability used.
%  - high development effort
%Hardware
%image-based system
%   - client hardware requirement 

The terrain rendering clients have different requirements for their software
and hardware components because of the differences in the design assumptions.
The image-based client is currently implemented using
Tcl/Tk.  This client program is responsible for acquiring the user's input and
presenting the images to the user as they arrived.  The flexibility of Tcl/Tk
to create a Graphical User Interface (GUI) allows us easily to customize our
client to a specific application of the terrain information.   This client
connects to our terrain image server through a computer network using a
custom communication protocol, which is built on top of TCP/IP.
As a result, the client must use an interpreter compiled with our custom
communication widget.  Although the use of a custom widget increases the
difficult of creating, maintaining and distributing our client software, our
widget allows the possibility of integrating
various image compress techniques, such as JPEG, MPEG or more exotic Iterative
Fractal Compression (IFS)~\cite{IFS}, seamlessly.  Because our client only needs
to manipulate images, the required computer resources, such as memory and CPU
power, can be easily satisfied by most client computers.  The current client
implementation uses two 600 $\times$ 480 RGB image buffers, which consumes a
total of 1.64Mbytes of memory, to reduce flickering.  The complexity
of displaying the images, which includes receiving the images from the network,
unpacking (uncompressing) the image and transferring the images to the screen
buffer, is $O(n \times m)$, where $n$ and $m$ is the width and height of the
images. On a Sun IPC workstation using the X window system under  idea
circumstances (i.e. without considering the limitation of network bandwidth and
rendering engine throughput), the client can display four 600 $\times$ 480 RGB
frames per second on a 8bit deep screen buffer.  This performance data is
gathered by rapidly displaying two RGB images on a Sun IPC workstation.  For
new model of PC, better performance is expected. 

%The client of both systems 
%Software
% VRML-based system
%  - portable
%  - limited rendering capability
%  - commercially available
%Hardware
%VRML-based system
%  - client hardware is used.  scalable computing resources

The VRML-based client, on the other hand, is a VRML browser, which has a number
built-in user interfaces and a rendering engine.  The user must use one of the
built-in user interfaces to navigate the VRML world.  This limited set of user
interfaces confines the type of applications for which the information can
easily be used.  In VRML 2.0, the creator of a world can also customize the user
interface. 
After the user interface has collected the user's inputs, the built-in rendering
engine renders the output according to the input parameters.  The communication
between the user interface and the rendering engine is done through the system
bus, which has much higher bandwidth than any existing computer network.
Because VRML is a WWW standard for delivering
information in 3D computer graphics, a VRML browser is part of the standard
toolset for any web user.  As a result,  the information provider has no need
to create, maintain and distribute any client and/or server software.
Furthermore,
the VRML encoded information is also computer architecture independent.  This
eliminates any need to do real-time conversion of the data to a format that the
client can understand.   Therefore, the server can serve more clients with the
same resources as an image-based system.

\begin{table}
\begin{center}
\begin{tabular}{|r|c|c|} \hline
Number of triangles & Full detail at all time & Reduce detail during movement \\ \hline
21899 & 1.03 & 2.00 \\ \hline
16627 & 1.40 & 2.30 \\ \hline
9885 & 2.32 & 3.50 \\ \hline
5519 & 4.00 & 6.00 \\ \hline
\end{tabular}
\end{center}
\caption{The frame rate of the viewing four different level of details of a
128 $\times$ 128 VRML terrain in 600 $\times$ 480 RGB image under two
different rendering conditions.
\label{VRML-framerate}}
\end{table}

Before the user can see the virtual world, the entire VRML world must be
processed by the client computer.  The amount of memory and rendering resources
needed is directly proportional to the complexity of the world. If the entire
VRML world is completely defined by using predefined geometrical shapes,
the browser can automatically adjust the amount of detail of the various objects
to match the available rendering resource. In general, the VRML world
designer must make a decision on how much detail is included in the world.
Since the VRML world is intended to operate in isolation,  the designer has no
knowledge of, and no control over, the rendering capability of the client
computer.  Consequently, an upper bound on the amount of detail is set, such
that
the VRML audience will not lost interest because of slow rendering of a complex
world or the minimal information content of simplistic world.  This limitation
is overcome by allowing the user to select the complexity of the VRML world at
runtime to match the capability of available computing resource.  Although
a VRMl 1.0 world can be dynamically created, after the generation of  the file
is completed, its content is fixed.  The new capability of incorporating Java
program in VRML 2.0  will enable the user to adjust the content during the
presentation.  However, this increases the required server computing resource
per client to interpret the inputs to select the needed data and to encode the
information before transmitting to the client.  The frame rate of rendering four
different level of details terrain model of 128 $\times$ 128 data points
(12.8Km $\times$ 12.8Km) is given in table~\ref{VRML-framerate}.  One of the
two test, the browser was forced to render the terrain model with texture
mapping during movement.  In the other test, the browser was allows to use
Gouraud shading during movement.   This data was collected on a personal
computer using a 133MHz Pentium CPU with 32Mbytes of memory with special
rendering hardware support from 3D Lab.  The current VRML standards use ASCII
for the data format, in order to provide the
architecture neutrality feature, so even a simple VRML world has a substantial
size file and a file compression utility program is used to reduce the size of
the data before transferring to the client computer.  Due to the fact that
common file compression utility does not support data streaming, the entire
compressed VRML file must arrive and stored before the client browser can
decompress it.  Then the client must have enough disk space to store the
uncompressed VRML file during the parsing of the VRML file.  The client also
need to have enough memory to retain all graphical information at runtime.

\subsection{Network}

%Also need to compare the network speed requirements, e.g. for:
%- sending images at required frame-rate, with and without compression
%- sending VRML data with new scenes loaded on the fly, with and without
%  compression (here compression can mean compressing the VRML file or 
%  compressing the terrain data by wavelets etc.) 

\begin{table}
\begin{center}
\begin{tabular}{|c|c|c|c|} \hline
image size & PPM & PNG & JPEG \\ \hline
600 $\times$ 480 & 843 & 103 & 12.5 \\ \hline
\end{tabular}
\end{center}
\caption{The size (in Kbytes) of a typical terrain image using different image
compression techniques. \label{image-size}}

\end{table}
\begin{table}
\begin{center}
\begin{tabular}{|c|l|l|l|l|} \hline
& \multicolumn{4}{c|}{Bandwidth} \\\cline{2-5}
& 10Mbits/sec & 1Mbits/sec & 128Kbits/sec & 38.8Kbits/sec \\ \hline
%PPM & 0.659  & 6.59  & 52.7 & 174 \\ \hline
PPM &  1.52 & 0.152 & 0.0190 & 5.75$\times 10^{-3}$ \\ \hline
%PNG & 0.0804 & 0.804 & 6.44 & 21.2 \\ \hline
PNG & 12.4 & 1.24 & 0.155 & 0.0472 \\ \hline
%JPEG & 9.76 $\times10^{-3}$ & 9.76 $\times10^{-2}$ & 0.781 & 2.58 \\ \hline
JPEG & 102 & 10.2 & 1.28 & 0.388 \\ \hline
\end{tabular}
\end{center}
%\caption{The table shows the theoretical transfer time (in seconds) for
%a 600 $\times$ 480 RGB terrain image. \label{image-terrain-transfer}}
\caption{The table shows the number of 600 $\times$ 480 RGB terrain image
frames per second that can be transmitted using different image compression
formats based on the
theoretical bandwidth of the network.\label{image-net-framerate}}
\end{table}

Both terrain rendering systems use the network as an integral part to acquire
the terrain information.  Because of the design differences, the two system
have distinct communication pattern.  Hence, the effects of the network
latency and bandwidth are different.  The image-based system maintains a
continuous TCP/IP network
connection between the client and the server while the terrain rendering
application is running.  This network connection is used to transfer an array
of images, which contains the terrain information requested by the user.
As a result, the user only experience the latency of starting the terrain
rendering application, which incurred by the network protocol, once.
Furthermore, these images must be displayed in the order in which they are
received, and the TCP protocol guarantee the images arrived intact and in
order.  Another form of network
delay is caused by the finite bandwidth of the computer network.  In
table~\ref{image-size} is shown the size of  a 600 $\times$ 480 RGB terrain
image in three different image formats. In order for the user to see the images,
the network has to transfer this amount of information from the server to the
client.  Given various possible bandwidths of the network,
table~\ref{image-net-framerate} shows the maximum frame-rate that would be
supported by the network.

\begin{table}
\begin{center}
\begin{tabular}{|c|c|c|c|} \hline
Detail & Uncompressed & Compressed & Compression ratio \\ \hline
Very High & 2.17 & 0.394 & 5.50 \\ \hline
High & 1.64 & 0.311 & 5.27 \\ \hline
Medium & 0.980 & 0.200 & 4.90 \\ \hline
Low & 0.551 & 0.119 & 4.63 \\ \hline
\end{tabular}
\end{center}
\caption{Comparison of the VRML 128 $\times$ 128 terrain model file
size (in Mbytes) with and without compression. \label{VRML-filesize}}
\end{table}

\begin{table}
\begin{center}
\begin{tabular}{|c|r|l|l|l|l|} \hline
& & \multicolumn{4}{c|}{Bandwidth} \\\cline{3-6}
             & Detail          & 10Mbits/sec & 1Mbits/sec & 128Kbits/sec & 38.8Kbits/sec \\ \hline
             & Very High   & 1.74         & 17.4       & 139           & 458 \\ \cline{2-6}
Uncompressed & High & 1.31         & 13.1        & 105          & 346 \\ \cline{2-6}
             & Medium      & 0.784       & 7.84        & 62.7          & 207 \\ \cline{2-6}
             & Low            & 0.441      & 4.41         & 35.3        & 116 \\ \hline
             & Very High  & 0.315  & 3.15  & 25.2 & 83.2 \\ \cline{2-6}
Compressed & High    & 0.249  & 2.49 & 19.9 & 65.7 \\ \cline{2-6}
             & Medium     & 0.160 & 1.60 & 12.8 & 42.2 \\ \cline{2-6}
             & Low           & 0.0952 & 0.952 & 7.62 & 25.1 \\ \hline
\end{tabular}
\end{center}
\caption{The table shows the theoretical transfer time (in seconds) for
128 $\times$ 128 VRML terrain models with different amount of detail.
\label{VRML-color-terrain-transfer}}
\end{table}

\begin{table}
\begin{center}
\begin{tabular}{|c|c|c|c|} \hline
Detail & Uncompressed & Compressed & Compression Ratio \\ \hline
Very High & 1.53 & 0.278 & 5.50\\ \hline
High & 1.15 & 0.218 & 5.27 \\ \hline
Medium & 0.690 & 0.141 & 4.90 \\ \hline
Low & 0.389 & 0.0840 & 4.63 \\ \hline
\end{tabular}
\end{center}
\caption{An estimate file size for a VRML 128 $\times$ 128 terrain model in
binary format (in Mbytes) with and without compression.
\label{VRML-binary-filesize}}
\end{table}

\begin{table}
\begin{center}
\begin{tabular}{|c|r|l|l|l|l|} \hline
& & \multicolumn{4}{c|}{Bandwidth} \\\cline{3-6}
             & Detail          & 10Mbits/sec & 1Mbits/sec & 128Kbits/sec & 38.8Kbits/sec \\ \hline
             & Very High   & 1.22         & 12.2       & 97.9           & 323 \\ \cline{2-6}
Uncompressed & High & 0.920        & 9.20        & 73.6          & 243 \\ \cline{2-6}
             & Medium      & 0.552       & 5.52        & 44.2         & 146 \\ \cline{2-6}
             & Low            & 0.311      & 3.11         & 24.9        & 82.1 \\ \hline
             & Very High  & 0.222  & 2.22  & 17.8 & 58.7 \\ \cline{2-6}
Compressed & High    & 0.174  & 1.74 & 14.0 & 46.0 \\ \cline{2-6}
             & Medium     & 0.113 & 1.13 & 9.02 & 29.8 \\ \cline{2-6}
             & Low           & 0.0672 & 0.672 & 5.38 & 17.7 \\ \hline
\end{tabular}
\end{center}
\caption{The table shows the theoretical transfer time (in seconds) for
the simulated binary 128 $\times$ 128 VRML terrain models with different amount
of detail.  \label{VRML-color-terrain-transfer-binary}}
\end{table}

To maximize the number of web clients that a web server can serve
simultaneously, the VRML browsers are designed to contact the server, only when
it needs information. Before retrieving the wanted information, the VRML-based
system establishes a temporary connection to the server.  Because the VRML
browser processes the entire VRML file before rendering of its content, the user
must endure in addition to the processing delay, the full network latency of
setting-up the transient connection and transferring the VRML file.  These
delays can be minimized by eliminating unwanted details and compress the 
data file before transferring. A comparisons of the file size of different level
of detail a VRML model with and without compression is shown in
table~\ref{VRML-filesize}, and the minimal time required to transfer these
files from the server to the client is given in
table~\ref{VRML-color-terrain-transfer}.  A un-scientific timing test on
starting VRML terrain rendering system indicates less than 1 second delay for a
lightly loaded LAN and 4 to 6 second for WAN connection (see
section~\ref{VRML-findings}).  The initial step to reduce the file size
of the VRML file is to encode the information in binary format.
An estimated size of  the VRML terrain models
in binary format is given in table~\ref{VRML-binary-filesize}.  The binary
VRML file size is computed using the ratio of the ASCII vs. binary file size of
a typical image-based system terrain object.  Since the VRML binary file
contains the same information as its ASCII counterpart, the compression ratio
of the binary file using gzip should be similar to those in
table~\ref{VRML-filesize}.  With these file sizes, the communication
times for transferring the binary VRML file as shown in
table~\ref{VRML-color-terrain-transfer-binary} have marked
improvement over ASCII VRML file.

\subsection{Server}

%Comparison for servers involves computation and I/O capability to handle:
%- database access
%- converting data to images (rendering) or VRML
%- transmission of data

The differences of the design philosophy of the two systems have influence
the functionality of the servers. For the image-based system,
the server provides the client a gateway to the parallel rendering engine by
converting the viewing information into a view transformation
matrix and dispatching the resulting images to the client through the dedicated
communication channel.  The parallel rendering engine, which composed of a
number of sequential rendering pipeline and a high speed network, then uses the
view transformation matrix and the terrain data to generate the images.  The
high speed network, which connects all the sequential rendering pipeline, is
used to boardcast the viewing transformation matrix and to assemble the
resulting
images.  The terrain data is stored in distributed terrain objects database.
This database coexists on the same computation nodes as the sequential
rendering pipeline.  The overhead of accessing the terrain data involves finding
all visible terrain objects on the computing node and pass their resident memory
location to the local sequential rendering engine for rendering.  The visibility
of the terrain objects is determined by using the coarse visibility calculation
algorithm in section~\ref{parallel-rendering}.  This terrain rendering system
is implemented on a 8 nodes IBM SP2 parallel computer.
For generating 640 $\times$ 400 resolution images, this sequential rendering
pipeline has a stable frame rate of 1.7 frame per second or 200,000 polygons
per second using a $400 \times 400$ points terrain dataset.  The
parallel rendering engine combines 8 of the sequential rendering pipelines and
achieves a stable frame rate of 0.77 frames per second or 280,000 polygons per
second for an $800 \times 800$ points terrain data set.  The performance of the
parallel rendering engine is hindered by the communication cost need to
gather the 8 intermediate images to form the final images. This communication
takes 0.93 second  to complete, which is about 75\% of the total rendering time
of a image.

\begin{table}
\begin{center}
\begin{tabular}{|c|r|r|r|r|} \hline
Wavelet coefficient  threshold & \multicolumn{2}{c|}{points} 
& \multicolumn{2}{c|}{triangles} \\ \hline
-1 & 16384 & 100\% & 32258 & 100\%\\ \hline
5 & 10959 & 67\% & 21506 & 67\%\\ \hline
10 & 8144 & 50\% & 15935 & 49\%\\ \hline
20 & 4436 & 27\% & 8635 & 27\%\\ \hline
40 & 2028 & 12\% & 3896 & 12\%\\ \hline
\end{tabular}
\end{center}
\caption{The number of vertices and triangles used in different model detail
of a 128 $\times$ 128 terrain model.\label{VRML-model-complexity}}
\end{table}

\begin{table}
\begin{tabular}{|l|l|l|l|} \hline
Wavelet coefficient threshold & database access & wavelet transformation
 & triangulation \\ \hline
-1 & 1.12 sec & 0.409 sec & 1.69 sec \\ \hline
5 & 0.740 sec & 0.238 sec & 0.989 sec \\ \hline
10 & 0.547 sec & 0.167 sec & 0.675 sec \\ \hline
20 & 0.333 sec & 0.0895 sec & 0.372 sec \\ \hline
40 & 0.167 sec & 0.0421 sec & 0.172 sec \\ \hline
\end{tabular}
\caption{The table shows the timing of different stages for generating
different resolution terrain models of an area of $128 \times 128$ data
points.  \label{VRML-model-time}}
\end{table}

The job of the VRML terrain server is to furnish the client with requested
terrain data.   This is accomplished by processing the user request, performing
the wavelet based terrain model optimization and encoding the optimized terrain
data.  To enable dynamic adjustment of the terrain model detail, the terrain
information is stored in a server side database.  A SQL query is used to filter
out some of the wavelet coefficients by their magnitude.  Then
the wavelet coefficients are used to reconstruct the
terrain model.  The accuracy of the reconstructed model, which is measured
by the number of vertices and polygons of the model, is proportional to the
number of coefficients used.   A reconstructed 128 $\times$ 128 points terrain
model with different wavelet coefficients selection threshold is given in
table~\ref{VRML-model-complexity}, and the time need to generate these model
is shown in table~\ref{VRML-model-time}. Finally, the reconstructed terrain
model is encoded in VRML before shipping to the client.  The VRML-based terrain
rendering system are designed to serve large number of clients, and
the server must have fast access to the terrain data.  This requires the server
machine to have excellent I/O and network bandwidth.

\section{Conclusion}

The image-based and VRML-based terrain system, each provides unique
advantages and disadvantages.  The advantages of image-based system includes
efficient use of network, high quality rendering and access to large dataset.
However, this system can only support small number of user at a time and the
relatively expensive per user equipment cost on the server side. 
The VRML-based terrain system, on the other hand, can serve large number
of users at the same time with relatively low server side per user equipment
cost.  The trade-offs is the inefficient use of the computer network and
rendering equipment, low to moderate image quality and access to small
dataset.  Because the two systems have a complementary set of design
compromises, a hybrid of the image-based and VRML-based system can offer the
best features of the two systems.

%The VRML-based is good for typical PC websufer with a dynamic VRML world.
%Custom program is used either in very low-end (WebTV) by movies like (fixed or
%limited viewing orientation application such as video game).  The resulting
%image can be very high quality.
%very high-end (scientific) user, who can afford and have the need to use
%high quality and real-time rendering.

%made reference to Window CE and Java station.

%Using a personal computer is a solitude activities because there is one
%human interface channel for each terminal.  Requiring a \$2000.0 computer
%and a phone line per user is unreasonable.  Micro-processor technology is out
%pacing the computing cycle need by a typical user.  More efficient use of CPU
%cycle is expected.  Sun Java stations and Microsoft NT OS is a going back
%toward
%centralize computing.  Future household will most likely have a expensive
%server and a collection of much cheaper client stations.  These stations have
%enough CPU power to handle most of the day to day work, but CPU intensive
%application will be run on the server and the output is sent to the client for
%display.

\begin{figure}
\begin{center}
\begin{picture}(432,317)
\psfig{figure=hybrid-terain.eps,width=432pt,height=317pt}
\end{picture}
\end{center}
\caption{The architecture of a hybrid terrain rendering system.
\label{hybrid-terain}}
\end{figure}

The hybrid system as shown in figure~\ref{hybrid-terain} consists of two
different type servers and clients. This system leverage on the maturity of
web server software and operating model by storing the terrain data 
in a database on a web server with large storage capacity, high I/O and network
performance.  This sever is connected to a rendering server by a high speed 
network, so that large quantity of data can be transferred.  These terrain data
is packaged in VRML format.  The terrain image server, a computer with
high performance multi-media support, than renders the data according
to the viewing parameter, the requested rendering quality and the rendering
instruction in the VRML file.  The resulting image is shipped to the a networked
client similar to WebTV and Sun Java stations.  This system can also serves
high performance client with single user.  For a home-based system, this
arrangement enable a efficient use for currently the most expensive household
appliance, the personal computer, and its network resources.  The current usage
model of a \$2000.0 personal computer is a solitude activities.
However, a more than 200MHz micro-processor with multi-media handling capability
is out pacing the computing resource need by a typical user.  In addition, the
network resources of the home-based system is also relatively expensive.
With the network terminal, these resources can be shared by the entire
household.

\section{Future Work}
\label{future}

The terrain rendering system can be benefited by additional research on
finding more efficient wavelet for terrain optimization, improving the
vertex placement policy for reconstructing terrain model, reducing rendering
effort by ``approximating'' some of the images and using Iterative Factual
compression for the texture map.

The current wavelet terrain optimization algorithm uses Haar wavelet to
demonstrate the concept.  Although the characteristics of the Haar wavelet is
sufficient for the terrain data on hand,  additional research is needed to find
the wavelet(s) that can be used to encode efficiently a wide range of  terrain
topology.  The new wavelet must have the mathematical characteristics of
non-overlapping and compact support.   Furthermore, the calculation for
decomposition and reconstruction can support non-power of 2 array size and
with low computation requirement.  With these properties, the wavelet terrain
optimization algorithm will be able to apply to more exotic locations, where
the formation of terrain features can be influence by asteroids and other
extraterrestrial objects. 

In additional to use a better wavelet, the terrain optimization algorithm can
also benefit from research on improving the placement policy for the vertices
of the reconstructed terrain model.  A better vertices placement increase the
accuracy of the reconstructed terrain model.  In turn, the accuracy of the
model can either be used to trade for a less complex model or to meet the
stringent data requirment of some applications.
The placement of a vertex involves identify the best location with in a small
area, such that the resulting simplified polygons model of the area is a close
approximation of the original and more complex polygonal model.  Because
the wavelet have the mathematical characteristics of non-overlapping and
compact support, the search of the vertices' best placement is confined
within the area that covered by the wavelet.  With this restructed the search
space, the emphasis is to find the best location with minimal amount of work.

Video image compression is necessary to effectively use the network
bandwidth. A side effect is that video image compression also provides a way
to handle computing resources degradation.  The MPEG video
compression~\cite{GFF}, for example,
has three type of frames, intra-coded, predictive-coded, and bi-directional
predictive-coded.  An image is intra-coded, if it is encoded by using the
information within that image only.  The predictive-coded image uses
motion-compensated prediction from a past intra-coded or predictive-coded
images.  In other words, only the difference of the previous image is sent
to reconstruct the image.  The bi-directional predictive-coded uses
motion-compensated prediction from a past and a future frame, i.e., an
interpolation of the two images can be formed.
In a computing resources rich environment, each frame is generated and
encoded with MPEG compression.  In a computing resources poor environment,
the information in bi-directional predictive-coded can be ``approximated'' 
from the viewing parameters.  Hence, a less accurate image will be generated,
but the ``approximation'' may take less CPU cycles to compute than rendering
a full image.

Iterative fractal compression is a relative new image compression technique
that have similar characteristics of wavelet compression, such as high quality
image at extreme compression ratio and prograssively refine the image quality.
In addition, the iterative fractal encoded image can also the extracted in a
different size other than the original image.  Additional investigation is
needed
to determine if this features can be exploited for speeding up the rendering of
a texture mapped polygon.  As described in section~\ref{CG_techniques}, the
process of rendering a texture mapped polygon usually involves the costly
computation of up and/or down sampling of the texture map.  Approximation
techniques that scarifies quality and/or increases memory storage are used to
speed-up rendering.  A iterative fractal encoded texture map, on the other
hand, can be extracted at the close to correct resolution just before scan
converting the polygon(s). If the screen pixel have a one-to-one mapping
relationship to the texture map pixel, then rendering process of rendering a
texture mapped polygon can be greatly simplified.  As a result, the rendering
process of the terrain model can be speed-up.

