\chapter{VRML Terrain rendering}
\label{VRML_terrain}

Chapter~\ref{parallel-terrain-rendering} showed that a dedicated rendering
server can only
simultaneously serve a small number of independent clients because of the
server's finite computational power.  Virtual Reality Modeling Language
(VRML)~\cite{pesce-1995-VRML}, an emerging web technology and standard, enables
us to exploit the client-side rendering capabilities.  The combined
computational power of the client-server system increases in proportion to the
number of clients.  As a result, VRML is a potential solution to overcome the
limitation of a dedicated server.

In recent years, the web has been expanding rapidly both in terms of
users and capabilities.  The increase in users is partially due to
the increased number of dial-up users from Internet service providers, such
as America Online, AT\&T, etc.  The networking hardware of the dial-up users
ranges from 2400 baud modems to 128kbits ISDN lines.  The rest of the new users
are from business and education institutes.  These users have access to high
bandwidth networks, such as fiber optic networks.  This leads to a
design problem for a website to accommodate the diverse networking and
computational power of the client machines.  A common practice is to provide
both text only and graphics rich version of the web pages.  Although this is a
reasonable work around for the information oriented web pages, it can
not be employed in a 3D interactive cyberspace constructed with VRML.

In this chapter, we will discuss the advantages and disadvantages of using
VRML, instead of a custom program for rendering a 3D world.
Then we describe our design for the VRML-based terrain visualization.
Finally, we proceed to identify the problems we have encountered in
using the VRML 1.0 specification~\cite{VRML-1.0}.
Some of these problems will be eliminated by the developing new VRML
standard~\cite{VRML-2.0}, and
we will offer solutions to the other more fundamental problems using VRML
2.0.

\section{VRML}

VRML
serves as a web standard for encoding a 3D virtual world.  A VRML world enjoys
the benefits of being encoded in a web standard, such as, the guarantee of the
basic functionalities, rendered by a state-of-the-art browser and served by
scalable server.
The functionalities offered by the VRML 1.0
standard~\cite{VRML-1.0}~\cite{pesce-1995-VRML}, include:
\begin{description}
\item[basic shapes] {\tt AsciiText}, {\tt Cone}, {\tt Cube}, {\tt Cylinder},
{\tt IndexedFaceSet}, {\tt IndexedLineSet}, {\tt PointSet} and {\tt Sphere} are
the basic building blocks of a VRML world.
A polygonal object is encoded by using the {\tt IndexedFaceSet} node.
\item[geometry] {\tt LOD}, {\tt Coordinate3}, {\tt ShapeHints}, {\tt Normal}
and {\tt NormalBinding} serve as
the ``adjectives'' of the objects. {\tt LOD} node allows different levels of
detail to be used in the description of an object.  {\tt Coordinate3}
contains the set of vertices of a polygonal object.
\item[material] {\tt FontStyle}, {\tt Material}, {\tt MaterialBinding},
{\tt Texture2}, {\tt Text2Transform} and {\tt TextureCoordinate2} decorate the
virtual world just like paint in the real
world.  There are two ways to paint the virtual world.  First, a color can be
assigned to each vertex or polygon.  Second, a texture can be pasted onto a
polygon.  Texture mapping is an especially important technique because it allows
simplification of the complex object by reducing the number of vertices or
polygon to show a complex pattern.
\item[transformation] {\tt MatrixTransform}, {\tt Rotation}, {\tt Scale},
{\tt Transform} and {\tt Translation} provide a way to position, scale and
align an object with respect to the user's viewpoint and/or other objects.
\item[camera] {\tt OrthographicCamera} and {\tt PerspectiveCamera} define the
user's viewpoint and viewing characteristics.
\item[lighting] {\tt DirectionalLight}, {\tt PointLight} and {\tt SpotLight}
illuminate the world, just like lights in the real world.
\item[web accessing functions] {\tt WWWAnchor} and {\tt WWWInline} enable the
VRML world to access additional web resources.  {\tt WWWAnchor} is used to embed
links in the world to other worlds or web pages.  {\tt WWWInline} provides an
avenue to incorporate other VRML worlds into the current world.
\end{description}

When VRML was accepted by the web community, a complex three-way
symbiotic relationship was formed among the software providers,
the content providers and the consumers.  A typical life-cycle of this
relationship begins when software companies provide a multi-platform browser
and authoring tools for the standard.  A flourishing environment exists
for the content providers because they do not have to bear the high cost of
development,
maintenance, distribution and support for their custom authoring and client
software.  Since the browser allows
the user to access a wide range of exciting websites, the user is willing to buy
the browser.  The Netscape browser is a prime example of this cycle.  The role
of the software providers is more important for VRML because interactive
graphics rendering is a highly CPU intensive task.  As a result, the expertise
of the software companies to build highly optimized software to tap into the
best performance of the client machine is readily realized and appreciated by
the user.  Furthermore, the client's rendering capability of a VRML world will
improve when better hardware and software become available. 

As shown in chapter~\ref{parallel-terrain-rendering}, the server-side terrain
rendering can only handle a small number of independent clients.  However,
the rendering for VRML is done on the client machine, so the role of the server
is reduced to the preparation and delivery of the VRML world.  A standard
web server and a collection of CGI programs can accomplish this task.
In addition, the processing incurred on the server due to a particular client
is done only once because the VRML browser retains all data while the user
is touring the world.  Hence, the computation done by the server is reduced
dramatically compared to a server-side rendering.  As a result, the
server can handle more clients than a server-side terrain renderer.

Although VRML is a convenient way to present information in 3D over the
web, it has shortcomings, such as:
\begin{enumerate}
\item a VRML world is statically defined
\item the networking, computational and rendering capabilities of clients vary
dramatically
\item VRML objects waste a lot of bandwidth
\end{enumerate}
The VRML 1.0 specification, which originated from the Silicon Graphics's Open
Inventor file format, only allows a statically defined world.  This characteristic is
inherent from its roots as a file format.  A file is a complete and serial
entity.  Adding or deleting information involves creating a new file before
the deletion of the old file.  However, this philosophy is not compatible
with the trend of the web as shown by the introduction of Java and Javascript,
where dynamic presentation is the key to attract an audience.
These web programming languages also enable web designers to produce a
more flexible and powerful interface to the web.  Furthermore,
the static definition of the world implies that the client has to process
information proportional to the size of the entire world.  Consequently, this
forces the author to put an arbitrary upper bound on the size of the VRML
world that a viewer can traverse.

As mentioned in the beginning of this chapter, the diversity of the client's
networking and computation capabilities makes two different layouts, a low and
high bandwidth version, of a
single web page a necessity.  The variation of the client for VRML will be even
more apparent because of the availability and the dissimilar performance of
graphics acceleration hardware for the clients.  As a result,
techniques to adapt the VRML world for different client capabilities are needed.

Since the current VRML world is statically defined, the entire file has to be
transferred to the client before the presentation can begin.  To reduce the
start up time for a client, a fast network connection is needed.  Once the
presentation is started, the fast network is left idle.  Hence, it is a waste
of network resources, especially for the dial-up users, who often pay for their
network connection based on their connection time and theoretical network
bandwidth.  As a result, a constant flow of information, that is, a streamed
transfer of terrain data, is more suitable for viewing a large area of terrain.
In the next section, we describe our experience in building a VRML-based
terrain visualization.

\section{Terrain Visualization using VRML}

 Before a web surfer can dive into our 3D world, he or she must go through a
gateway (a web page), which transfers the user from a 2D information oriented
space to
a 3D world.  In this section, we will present an example web interface.  This
interface demonstrates how the VRML terrain data will be consumed in general.
Then we will present the design of the server-side facilities to satisfy the
demand.

\subsection{User Interface -- an example}
\begin{figure}
\begin{center}
\begin{picture}(432,270)
\psfig{figure=web-interface.eps,width=432pt,height=270pt}
\end{picture}
\end{center}
\caption{A simple web interface for wavelet terrain visualization
\label{web-interface}}
\end{figure}
Our experimental wavelet terrain visualization server is activated through a web
page (see figure~\ref{web-interface}), which provides a convenient user
interface to our wavelet terrain
experimental server.  It consists of a brief description on how to control
the wavelet terrain parameters,
a form for the adjustable parameters and a clickable 2D map of the area for
choosing the starting position.  The operation of this
system is shown in figure~\ref{VRML-terrain-operation}.
There are two parameters that the user can adjust.  The first one is the
number of {\tt LOD} nodes used in the presentation.
The {\tt LOD} nodes are used to subdivide further the grid section,
so that the user's browser can provide the best presentation of the data
by using view volume culling (section~\ref{visible-calculation}) and
multi-resolution representation (section~\ref{terrain-multi-resolution})
to exploit the viewing characteristics.  The second parameter is the level of
accuracy of the model, which is also described in
section~\ref{wavelet-parameter}.  After all parameters are set, the user can
select a point of interest via the clickable map.  The image of the clickable map
is a 89km $\times$ 89km area of New York state, which
is internally divided into a $7 \times 7$ grid (figure~\ref{VRML-terrain-grid}).
Then parameters and the coordinate of the starting point are handed over to a
Common Gateway Interface (CGI) program, which
is spawned by the server.  The CGI program prepares one of the forty-nine
grid elements for display by sending the client a VRML file for that area.
The client spawns a VRML browser, such as VRweb or Webspace, to render the
VRML file.  In the next section, we will show the structure of the VRML
file, which is being rendered by the VRML browser.

\subsection{VRML Terrain Model}

Because the VRML browser is designed to be a generic VRML renderer, the browser
is not optimized for any specific virtual world.  A correctly structured VRML file
can capture the world's characteristics and enhance the rendering performance of
the browser for that world.
The structure of the VRML file is shown in figure~\ref{VRML-terrain-structure1}.
Each {\tt LOD} node contains four children for four different resolutions of
terrain data sets.  The first of the four sets is created with the user specified level
of accuracy as specified by the error tolerance, $A$.  The second, third and
fourth data sets are computed with error tolerance levels of $2A$,
$4A$ and $8A$, respectively.  The New York state terrain data generally loses
its characteristic features when the level of accuracy is set beyond $8A$.
The factor of two increases are chosen according
to the characteristics of the wavelet basis (see section~\ref{wavelet-parameter}
for more detail).  The children of the {\tt LOD} node are activated when the
user is in the range of 0m to 9,000m, 9,000m to 18,000m, 18,000m to 36,000m
and 36,000m to $\infty$, respectively.  The distance between the {\tt LOD} node
and the user is computed from the {\tt LOD} center.  Each {\tt WWWInline} node
contains the URL in the name field for the CGI program to retrieve the
corresponding VRML terrain data and information for the size and location of the
bounding box.  The bounding box is used by the browser to decide if a
{\tt WWWInline} node is visible or not.
To reduce the size of the terrain file,  {\tt WWWInline} nodes
with the CGI URL are used because the browser only activates visible
{\tt WWWInline} nodes.  As a result,
initially only part of the terrain file is down-loaded to the client.

\begin{figure}
\begin{center}
\begin{picture}(432,226)
\psfig{figure=vrml_terrain_operation.eps,width=432pt,height=226pt}
\end{picture}
\end{center}
\caption{The figure shows the operations of the web-based terrain
visualization \label{VRML-terrain-operation}}
\end{figure}

\begin{figure}
\begin{center}
\begin{picture}(432,432)
\psfig{figure=start_up.ps,width=432pt,height=432pt}
\end{picture}
\end{center}
\caption{The image shows the region of New York state available for
viewing and the forty-nine grid elements.  The latitude and longitude for the
upper left corner of the region is 73:22:41.41W 43:12:54.12N and the coordinates
for the lower right corner is 74:28:49.54W 42:25:26.22N.
\label{VRML-terrain-grid}}
\end{figure}

\begin{figure}
\begin{verbatim}
#VRML V1.0 ascii

Separator {
   {\tt LOD} {
      range [ 9000, 18000, 36000 ]
      center 3153.153150 579.000000 3153.153150
      {\tt WWWInline} {
         name "http://machine/cgi-bin/terrain_block_cgi?TableName=Albany
&DEM_width=128&DEM_height=128&Tolerance=5&BlockSize=64&X=0&Y=0&LODLayer=0"
         bboxCenter 3153.153150 579.000000 3153.153150
         bboxSize 6306.306300 122.000000 6306.306300
      }
      {\tt WWWInline} {
         ...
      }
      {\tt WWWInline} {
         ...
      }
      {\tt WWWInline} {
         ...
      }
   }
   {\tt LOD} {
      range [ 9000, 18000, 36000 ]
      center 9509.509500 398.000000 3153.153150
      {\tt WWWInline} {
         ...
      }
      ...
   }
   ...
}
\end{verbatim}
\caption{This is the structure for VRML terrain data with {\tt LOD} and
{\tt WWWInline} nodes.  Each {\tt LOD} node contains four {\tt WWWInline} nodes
as children.  The {\tt WWWInline} nodes incorporate the terrain data by
activating a CGI program with a specific set of parameters.
\label{VRML-terrain-structure1}}
\end{figure}

  This VRML structure means that not only a smaller VRML terrain model is
needed, but also its characteristic information is vital to the success of
the presentation.  We have shown that the {\tt WWWInline} node requires a
bounding box for the terrain model in order to function correctly.
The CGI program creates {\tt WWWInline} nodes for the terrain model
by using the meta-information of the terrain data stored in a database.  This
meta-information consists of the following information from each node:

\begin{description}
\item[UR\_x, UR\_y]  Upper right hand corner of a grid element.
\item[LL\_x, LL\_y]  Lower left hand corner of a grid element.
\item[Block\_size]   The size of the square grid element.  
\item[Databasename]  The table name for the terrain data of the grid element.
\end{description}

The coordinates are used to select the grid element for display.
The database table name is used to access the terrain data. 
The block size is used to compute the width and length of the bounding box.
To compute the center and the height of the bounding boxes for the {\tt LOD}
nodes,
the maximum and minimum height of the area is needed.  Since the bounding box
does not need to be tightly bounded in order for view volume culling to work,
we stored the maximum and minimum height at a resolution of
1.6km $\times$ 1.6km, i.e. for each group of 16 $\times$ 16 points.
As a result, the amount of effort to obtain these bounding box values is
bounded.  The additional benefit for this arrangement is to minimize the CGI
program's dependency on the terrain data's specific format and resolution,
so that the same CGI program could be used on other planetary data, for example,
Mars and Venus, where the terrain resolution varies with the remote sensing
technique and the vintage of the equipment used.

When one of the {\tt WWWInline} nodes is activated by the VRML browser, a CGI
program, which implements the wavelet terrain algorithm in
section~\ref{reconstruction}, is spawned by the server to generate the specified
VRML terrain data.  The terrain data is stored as a table of wavelet coefficients
in the database.  The CGI
program accesses this table via SQL commands.  A subset of the wavelet
coefficients is selected and passed onto the reconstruction algorithm to
reconstituted a sparse DEM.  The sparse DEM than passes through a triangulation
algorithm. The resulting polygonal information is encoded using VRML. Finally,
the VRML file is shipped to the client for presentation.
Section~\ref{reconstruction} provides more detail information on the format of
the tables and the operations on the database.  The structure
of our VRML terrain data is show in figure~\ref{VRML-terrain-structure2}.
In addition to assembling the polygonal terrain data, the CGI program is also
responsible for generating the color for each vertex and the texture map for
all the polygons.  The texture map of a VRML object can
be stored either as in-line ASCII format or in an external image file format
(JPEG~\cite{JPEG} is suggested and PNG~\cite{PNG} is strongly recommended by the
VRML specification as part of the implementation of the browser).  As a
result, our CGI program can be configured at compile time to provide either
in-line ASCII or JPEG texture.

According to the VRML specification~\cite{VRML-1.0} of the {\tt WWWInline} node,
the included information can be fetched when needed, but this is specific to the
implementation of the browser.  Furthermore, the information must be a
self-contained VRML data set.  Although the VRML specification advice is to
use the GNU compression tool, gzip, to reduce
the data size, we have yet to find a browser that can accept compressed VRML
data from a CGI program within a {\tt WWWInline} node.  This leads to long
delays in the presentation, induced by the CGI activation (latency) and
transmission delays (bandwidth).
For a supposedly interactive presentation, this is not acceptable.
After the user has viewed the terrain data from many different view points,
the client can potentially store all four different resolutions (levels of
detail) of the
same terrain data.  Consequently, the terrain data has to be kept small because
of the limited client storage and computational power.  In the next
section, we will show details of our findings.

\begin{figure}
\begin{verbatim}
#VRML V1.0 ascii

Separator {
   ShapeHints {
      vertexOrdering COUNTERCLOCKWISE
      faceType CONVEX
      creaseAngle 0.5
   }
   Material {
      diffuseColor [ ... ]
      ambientColor 0.1 0.1 0.1
   }
   Texture2 {
      filename " ... "
# or
      image ...
   }
   TextureCoordinate2 {
      point [ ... ]
   }
   Coordinate3 {
      point [ ... ]
   }
   IndexedFaceSet {
      coordIndex [ ... ]
   }
}
\end{verbatim}
\caption{This is the structure for the VRML file describing the terrain data.
The full description of the terrain data is given in five different nodes.
The {\tt ShapeHints} provides the fundamental rendering direction, such as the
order of the vertices, the type of polygon and how to shade the polygon's
edges.  {\tt Material} node contains the color values for each vertex and the
ambient light value for the whole terrain.  {\tt Texture2} node specifies the
texture for the terrain.  The texture can be stored in an image file or as
inline data.  {\tt TextureCoordinate2} is used to pin down the orientation of
the texture map, when applied to the terrain model (this node is included to
bypass a bug in Webspace on handling the texture).  {\tt Coordinate3} node
contains all the
vertices' 3D coordinates.  {\tt IndexedFaceSet} node provides the connectivity
to form the polygons from the list of vertices.
\label{VRML-terrain-structure2}}
\end{figure}

\section{Findings}
\label{VRML-findings}

In this section, we show the performance of the graphics rendering and
networking environment of VRML terrain modeling.
Most of these tests were done using the Webspace 1.1 VRML browser from Silicon
Graphics Inc~\cite{Webspace}.  Some of the screen dumps are made with VRweb,
which is a product of the join project of the Institute for Information
Processing and Computer Supported New Media (IICM), Graz University of
Technology, Austria; the National Center for Supercomputing Applications (NCSA),
University of Illinois at Urbana-Champaign and the University of
Minnesota~\cite{VRweb}.

Figure~\ref{terrain_multi_white} shows the rendering of a multi-resolution
terrain model by the Webspace browser.  The image in the upper left corner
is rendered with the terrain model of tolerance level 5.
The lower right image shows the terrain model of tolerance level 40.
The two intermediate images are the rendering of tolerance level 10 and 20
model, respectively.  The number of vertices and
polygons in the different models is shown in table~\ref{VRML-multi-info1}.
The dense model contains $128 \times 128$ elevation points from the Digital
Elevation Model (DEM) of New York state, and
its polygonal representation requires $32,258$ triangles.  The four simplified
terrain models have only 67, 50, 27 and 12 percent respectively of the number
of vertices and polygons.  Although the number of vertices and polygons in the
terrain model has been reduced drastically, the rendered images still show the
dominant features of the terrain.  In figure~\ref{terrain_multi_texture}, the
corresponding satellite image is mapped onto the terrain model.
Rendering using VRML for terrain visualization gives satisfactory images, even
for lower resolution data created using wavelets, as shown in
chapter~\ref{multi-terrain}.

\begin{figure}
\begin{center}
\begin{picture}(432,261)
\psfig{figure=multi_white.ps,width=432pt,height=261pt}
\end{picture}
\end{center}
\caption{A collection of rendered VRML terrain model colored white.
The error tolerances are $A$ (upper left), $2A$ (upper right), $4A$ (lower left)
and $8A$ (lower right), where $A = 5$.
\label{terrain_multi_white}}
\end{figure}

\begin{table}
\begin{center}
\begin{tabular}{|c|r|r|r|r|} \hline
model threshold & \multicolumn{2}{c|}{points} & \multicolumn{2}{c|}{triangles} \\
\hline
dense & 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 models.
\label{VRML-multi-info1}}
\end{table}

\begin{figure}
\begin{center}
\begin{picture}(432,261)
\psfig{figure=multi_texture.ps,width=432pt,height=261pt}
\end{picture}
\end{center}
\caption{A collection of texture mapped VRML terrain models.
The error tolerances are the same as figure~\ref{terrain_multi_white}
\label{terrain_multi_texture}}
\end{figure}

A VRML browser is intended to provide an interactive 3D environment to the
user.  The browser, when executed on a SGI ONYX with RealityEngineII Graphics
pipeline, maintains
detailed and fully texture-mapped terrain models on screen at all times.
In order for a browser to maintain its interactive response while running on a
low end platform, such as a personal computer or a generic workstation, it must
automatically render the image with less computationally demanding techniques.
For example, 
the browser uses a combination of different level of detail models
in the {\tt LOD} nodes to reduce the overall number of vertices and polygons.
To minimize the loss of the model's fidelity, the simplified model is used when
the area is far away from the user's viewpoint.  The more detail models are used
for the close up view.  To avoid the CPU intensive texture map manipulations,
the browser renders the image by using Gouraud shading~\cite{Foley}, when the
user is flying over the terrain.
When the image stops moving, the texture mapped models are rendered on screen.

Although the browser automatically switches among the different {\tt LOD}
children
when needed, the browser does not ensure that the objects in the different
{\tt LOD}
children resemble each other.  As a result, we must take appropriate steps 
to ensure that the models with different degrees of complexity join seamlessly.
The edge vertices of all terrain models are extracted at the highest resolution
(see section~\ref{model-joining}), while the internal vertices of the terrain
models are obtained by using the optimization technique from
section~\ref{reconstruction}.
A 2D wireframe representation of a combination of four different tolerance level
terrain models
is shown in figure~\ref{terrain_multi_model}.  The upper left
portion of the terrain model is optimized for tolerance level 5.  The lower
right portion is from tolerance level 40.  The two intermediate models are
optimized for tolerance level 10 and 20.

Since the edge vertices are excluded from the optimization process, the number
of polygons in the terrain model increases as the number of {\tt LOD} nodes
increase.  Table~\ref{VRML-LOD-tradeoffs} contains the number of vertices
and polygons in the terrain models with various numbers of {\tt LOD} nodes.
About 1,000 polygons are used to maintain a seamless connection to the
neighbors.
These additional polygons are necessary because they eliminate the artifact
shown in figure~\ref{terrain-polygon}.  The long skinny polygons appear only at
the boundaries of the model where the terrain is smooth.
Because of the limited accuracy of the floating point
representation, the rendering engine often mis-handle these long skinny
triangles during the rendering process and the result is often unexpected.
As a result, these long skinny triangles should be avoided at all costs.
One way to avoid these polygons without introducing extra polygons is by
combining all the {\tt LOD} nodes into one before the triangulation.
Any changes to the data points will require a rerun of the triangulation on the
entire node.  This requires computation resources far beyond the capabilities of
a typical server.
This has grave implications in extending the VRML terrain rendering in
section~\ref{new_VRML_terrain}.
Consequently, we accept the increases of the number of
polygons to maintain the modularity of the models.

We concluded that 4 {\tt LOD} nodes is an acceptable tradeoff for rendering a
$128 \times 128$ terrain block.

\begin{table}
\begin{center}
\begin{tabular}{|c|r|r|r|r|r|} \hline
model threshold & {\tt LOD} node(s) & \multicolumn{2}{c|}{vertices} 
& \multicolumn{2}{c|}{triangles} \\
\hline
dense & 1 &  16384 & 100\%& 32258 & 100\%\\ \hline
  & 1 & 10959 & 67\% & 21506 & 67\%\\ \cline{2-4}
5 & 4 & 11561 & 71\% & 22145 & 69\%\\ \cline{2-4}
  & 16 & 12367 & 75\% & 22793 & 71\%\\ \cline{2-4}
  & 64 & 13891 & 85\% & 23810 & 74\%\\ \hline
   & 1 & 8144 & 50\% & 15935 & 49\%\\ \cline{2-4}
10 & 4 & 9002 & 55\% & 17027 & 53\%\\ \cline{2-4}
   & 16 & 10007 & 61\% & 18073 & 56\%\\ \cline{2-4}
   & 64 & 11827 & 72\% & 19682 & 61\%\\ \hline
   & 1 & 4436 & 27\% & 8635 & 27\%\\ \cline{2-4}
20 & 4 & 5756 & 35\% & 10535 & 33\%\\ \cline{2-4}
   & 16 & 7031 & 43\% & 12121 & 38\%\\ \cline{2-4}
   & 64 & 9297 & 57\% & 14622 & 45\%\\ \hline
   & 1 & 2028 & 12\% & 3896 & 12\%\\ \cline{2-4}
40 & 4 & 3692 & 23\% & 6407 & 20\%\\ \cline{2-4}
   & 16 & 5098 & 31\% & 8255 & 26\%\\ \cline{2-4}
   & 64 & 7771 & 47\% & 11570 & 36\%\\ \hline
\end{tabular}
\end{center}
\caption{The number of vertices and triangles used in
different models with various numbers of {\tt LOD} nodes.
\label{VRML-LOD-tradeoffs}}
\end{table}

\begin{figure}
\begin{center}
\begin{picture}(360,434)
\psfig{figure=multi_model.ps,width=360pt,height=434pt}
\end{picture}
\end{center}
\caption{A terrain model formed by 4 different tolerance level models.
The top two models from left to right are created with tolerance level of $A$
and $2A$.
The bottom two models from left to right are generated with tolerance level of
$4A$ and $8A$.  All four models are joined seamlessly into one combined model.
\label{terrain_multi_model}}
\end{figure}

\begin{table}
\begin{center}
\begin{tabular}{|c|c|c|c|c|} \hline
 & \multicolumn{2}{c|}{Uncompressed} & \multicolumn{2}{c|}{Compressed} \\ \cline{2-5}
Level & colored & white & colored & white \\ \hline
0 & 2.17 & 1.63 & 0.394 & 0.327 \\ \hline
Reduction & \multicolumn{2}{c|}{25\%} & \multicolumn{2}{c|}{17\%}\\ \cline{2-5}
1 & 1.64 & 1.23 & 0.311 & 0.253 \\ \hline
Reduction & \multicolumn{2}{c|}{25\%} & \multicolumn{2}{c|}{19\%}\\ \cline{2-5}
2 & 0.980 & 0.731 & 0.200 & 0.154 \\ \hline
Reduction & \multicolumn{2}{c|}{26\%} & \multicolumn{2}{c|}{21\%}\\ \cline{2-5}
3 & 0.551 & 0.407 & 0.119 & 0.0884 \\ \hline
Reduction & \multicolumn{2}{c|}{26\%} & \multicolumn{2}{c|}{26\%}\\ \cline{2-5}
\end{tabular}
\end{center}
\caption{The comparison of the VRML terrain model file size (in Mbytes) with or without
colored vertices. \label{vertex-color}}
\end{table}

When a user interacts with a complex scene, VRML browsers switch from
more computationally expensive rendering technique, texture mapping, to less
expensive Gouraud shading to maintain the interactive environment by high
frame rate and fast response.  When the user pause for a interesting scene,
the browser use a more time consuming technique for the better resulting images. 
However, different rendering techniques produce very different images
for the same terrain model, for example the switching between a uniformly
colored model (figure~\ref{terrain_multi_white}) and a
texture mapped model (figure~\ref{terrain_multi_texture}) may disorient some
users.  By adding color to each vertex, we provide a more
coherent transient image when the browser switches over to Gouraud shading.
The color of the vertices is computed by averaging the texture pixels
surrounding the vertices.   The trade-offs for this feature is the increase in
the computation of the vertex color and the increase in file size
(table~\ref{vertex-color}).  To obtain the vertex color,
the computation involves 15 floating point multiplications and 18 floating
point additions for a optimized vertex, and 3 multiplication's and 6 additions
for a original vertex.  Furthermore, the additional color values boost the
file size by approximately 25\% with or without compression.  Since all these  
costs do not increase the complexity of our algorithm, we decide to accept
penalty for the added feature.
A comparison of the textured and the corresponding colored terrain
models is shown in figures~\ref{terrain_color_00}, \ref{terrain_color_01},
\ref{terrain_color_02} and \ref{terrain_color_03}.
The four terrain models are generated with accuracy levels of $A$, $2A$, $4A$
and $8A$, respectively.  In each of the figures, the
top image is rendered with the colored terrain model.  The bottom image shows
the texture mapped terrain model.  The resolution of the texture map also
varies according to the accuracy of the model.  We use the highest resolution
($509 \times 509$ pixel for a $128 \times 128$ terrain model) texture map for
error tolerance level $A$ and $2A$ because the user is examining the terrain in
detail.  Because of the overlapping of the terrain models, the size of the
highest resolution texture is given by the formula $4 \times (n - 1)$, where $n$
is the size of the terrain model.  For the $4A$ and $8A$ terrain models,
we use half ($255 \times 255$ pixel) and quarter ($128 \times 128$ pixel)
resolution, so that the down-load time is reduced for these models.
Since it is possible of the three resolution texture to be rendered side by
side, the border of these texture maps have to be matched perfectly.  As a
result, the half and quarter texture must be have size $2 \times (n - 1)$ and
$1 \times (n - 1)$, so that the proper color is assigned to the texture border.

We assume the visible features of the terrain are correlated with its
geographical features.  For example, an area which is occupied by large bodies
of water (blue) is flat on the DEM.  Vegetation favors a specific range of
elevation
and surrounding environment, such as humidity and soil type, that are affected
by geographic features.  Since the terrain model's optimization is also based
on the geographical features of the terrain, the color model provides a
similar, but significantly less detailed visual cue.  As a result, only large
terrain features, such as large lakes and maintains are retained after switching
over to Gouraud shading technique.  However, unavoidable rendering artifacts,
such as size variation and fuzzy boundaries, are apparent.

\begin{figure}
\begin{center}
\begin{picture}(343,540)
\psfig{figure=terrain_0000_0000_00.ps,width=343pt,height=540pt}
\end{picture}
\end{center}
\caption{The top image is rendered with colored vertices using Gouraud shading.
The bottom image is rendered with texture map.  The terrain model is generated
by setting tolerance level to 5, and the resolution of the texture map is
$509 \times 509$ pixels.
\label{terrain_color_00}}
\end{figure}

\begin{figure}
\begin{center}
\begin{picture}(343,540)
\psfig{figure=terrain_0000_0000_01.ps,width=343pt,height=540pt}
\end{picture}
\end{center}
\caption{The top image is rendered with colored vertices using Gouraud shading.
The bottom image is rendered with texture map. The terrain model is generated
by setting tolerance level to 10, and the resolution of the texture map is
$509 \times 509$ pixels.
\label{terrain_color_01}}
\end{figure}

\begin{figure}
\begin{center}
\begin{picture}(343,540)
\psfig{figure=terrain_0000_0000_02.ps,width=343pt,height=540pt}
\end{picture}
\end{center}
\caption{The top image is rendered with colored vertices using Gouraud shading.
The bottom image is rendered with texture map. The terrain model is generated
by setting tolerance level to 20, and the resolution of the texture map is
$255 \times 255$ pixels.
\label{terrain_color_02}}
\end{figure}

\begin{figure}
\begin{center}
\begin{picture}(343,540)
\psfig{figure=terrain_0000_0000_03.ps,width=343pt,height=540pt}
\end{picture}
\end{center}
\caption{The top image is rendered with colored vertices using Gouraud shading.
The bottom image is rendered with texture map. The terrain model is generated
by setting tolerance level to 40, and the resolution of the texture map is
$128 \times 128$ pixels.
\label{terrain_color_03}}
\end{figure}

Since each of the {\tt WWWInline} nodes includes a complete VRML data set, we
supplied three different resolution texture maps for the terrain models.
Our experience (see section~\ref{CG_techniques}) has shown that the quality of
the rendered image of a
texture mapped model largely depends on the quality of the texture maps.
The size of these textures in assorted formats is shown in
table~\ref{VRML-texture-size}.  The ASCII encoding of the textures is
considered because it is the only texture format defined by the VRML
specification, so the browser will guarantee its handling.
Full, half and quarter resolution  texture maps are used in rendering the
bottom image of figures~\ref{terrain_color_01}, \ref{terrain_color_02}
and \ref{terrain_color_03}, respectively.  Although the speed-up
on rendering from using a smaller texture map, if any, is not significant
because
the selection of the rendering techniques does not take into account the
size of the texture map, the transfer time of the VRML data has decreased
dramatically.
The increase of the speed up of transferring the texture significantly
reduces the startup
waiting time for the user.  Since we can not consistently time the startup
to quantify the reduction of startup time because of the entangled client-server
model of the current system
(figure~\ref{VRML-terrain-operation}) and the unknown network traffic, we
demonstrate the existence of the speedup by computing the transfer time for the
texture maps using different theoretical network bandwidths
(table~\ref{VRML-texture-transfer}).  In a typical user's environment, we
expected that the aggregate network bandwidth varies between 1Mbits/sec to
38.8kbits/sec.  10Mbits/sec is the transferring rate for Asynchronous Transfer
Mode (ATM).  The factor of 3 to 4 reduction in texture
transferring time between two different resolutions is critical to the reduction
of the startup time.  However, the reported times for the
small JPEG files are too optimistic because the calculation fails to consider
the connection startup cost, i.e. it takes into account only bandwidth not
latency.  A crude latency test at the peak hours (mid-week 11:00 PST) going from
Santa Clara, California to Syracuse, New York has shown that the delay is in the
range of 4 to 11 seconds.  For the best case scenario, which the client and the
server is located in the same Local Area Network (LAN), the latency is less
than 1 second.

In addition to the reduction of the network transfer time, the multi-resolution
texture map also reduces the amount of aggregate memory that is consumed by the
texture map
alone. When the texture map is prepared for rendering, the image is decompressed
and stored.  Assuming the terrain model consists of the entire test data set
and without using a multi-resolution texture map,
the texture map ($3333 \times 3333$ RGB pixels) requires 31.8Mbytes of memory to
store in the uncompressed format.   With JPEG multi-resolution texture map,
parts of the texture
map are stored at a lower resolution.  Hence, the total amount of memory used to
store the texture map is reduced.  Using a multi-resolution texture map
is clearly the correct approach for terrain visualization.

\begin{table}
\begin{center}
\begin{tabular}{|c|l|l|l|} \hline
 & \multicolumn{3}{c|}{Resolution} \\ \cline{2-4}
Format & full & half & quarter \\ \hline
ASCII & 2270 & 571 & 144 \\ \hline
gzip compressed ASCII & 676 & 170 & 42.6 \\ \hline
PNG & 539 & 135 & 33.9 \\ \hline
JPEG & 31.1 & 9.81 & 3.10 \\ \hline
\end{tabular}
\end{center}
\caption{The table shows the size (in Kbyte) of the texture in various VRML
texture formats.  \label{VRML-texture-size}}
\end{table}

\begin{table}
\begin{center}
\begin{tabular}{|c|c|l|l|l|l|} \hline
& & \multicolumn{4}{c|}{Bandwidth} \\\cline{3-6}
Format & Resolution & 10Mbits/sec & 1Mbits/sec & 128kbits/sec & 38.8kbits/sec \\ \hline
      & full & 1.7 & 17.7  & 142 & 468 \\ \cline{2-6}
ASCII & half & 0.446 & 4.46 & 35.7 & 118 \\ \cline{2-6}
      & quarter & 0.113 & 1.13 & 9.00 & 29.7 \\ \hline
                 & full & 0.528 & 5.28  & 42.3 & 139 \\ \cline{2-6}
gzip compressed ASCII & half & 0.133 & 1.33 & 10.6 & 35.0 \\ \cline{2-6}
                 & quarter & 0.0333 & 0.333 & 2.66 & 8.78 \\ \hline
    & full & 0.421 & 4.21  & 33.7 & 111 \\ \cline{2-6}
PNG & half & 0.105 & 1.05 & 8.44 & 27.8 \\ \cline{2-6}
    & quarter & 0.0265 & 0.265 & 2.12 & 6.99 \\ \hline
     & full & 0.0243 & 0.243  & 1.94 & 6.41 \\ \cline{2-6}
JPEG & half & 0.00766 & 0.0766 & 0.613 & 2.02 \\ \cline{2-6}
     & quarter & 0.00242 & 0.0242 & 0.194 & 0.639 \\ \hline
\end{tabular}
\end{center}
\caption{The table shows the theoretical transfer time (in seconds) for
different texture formats.  \label{VRML-texture-transfer}}
\end{table}

Besides the texture map, the terrain model also contains the height field data.
After the uniform DEM is passed through the optimization technique
of section~\ref{terrain-multi-resolution}, the optimized terrain is formed
by a collection of irregularly distributed vertices and varying size polygons.
All this information has to be encoded in VRML, and the size of the resultant
VRML file is
shown in table~\ref{VRML-terrain-size}.  In table~\ref{VRML-terrain-transfer},
we computed the theoretical transfer time for the terrain model without the
texture map.  For bandwidth of less than 1Mbits/sec, the overall transfer time for
the VRML terrain model is hopelessly slow for real-time rendering of a large
area of terrain.  Consequently, the VRML terrain visualization using VRML
has very limited usefulness.
In the next section, we will show how to exploit the new features offered by the VRML
2.0 standard to overcome these problems.

\begin{table}
\begin{center}
\begin{tabular}{|c|l|l|l|l|} \hline
&\multicolumn{4}{c|}{Tolerance level} \\ \cline{2-5}
             & 5     & 10     & 20    & 40 \\ \hline
Uncompressed & 799 & 601 & 358 & 200 \\ \hline
gzip Compressed   & 172 & 135 & 83.1 & 48.0 \\ \hline
\end{tabular}
\end{center}
\caption{The table shows the file size (in Kbyte) of 128 $\times$ 128 VRML
terrain models with different tolerance levels.  \label{VRML-terrain-size}}
\end{table}

\begin{table}
\begin{center}
\begin{tabular}{|c|c|l|l|l|l|} \hline
& & \multicolumn{4}{c|}{Bandwidth} \\\cline{3-6}
             & Tolerance & 10Mbits/sec & 1Mbits/sec & 128kbits/sec & 38.8kbits/sec \\ \hline
             & 5         & 0.624  & 6.24  & 50.0 & 165 \\ \cline{2-6}
Uncompressed & 10        & 0.470  & 4.70  & 37.6 & 124 \\ \cline{2-6}
             & 20        & 0.280  & 2.80  & 22.4 & 73.8 \\ \cline{2-6}
             & 40        & 0.156  & 1.56  & 12.5 & 41.2 \\ \hline
             & 5         & 0.134  & 1.34  & 10.8 & 35.5 \\ \cline{2-6}
gzip Compressed   & 10        & 0.105  & 1.05  & 8.44 & 27.8 \\ \cline{2-6}
             & 20        & 0.0649 & 0.649 & 5.19 & 17.1 \\ \cline{2-6}
             & 40        & 0.0375 & 0.375 & 3.00 & 9.90 \\ \hline
\end{tabular}
\end{center}
\caption{The table shows the theoretical transfer time (in seconds) for
128 $\times$ 128 VRML terrain models with different tolerance levels.
\label{VRML-terrain-transfer}}
\end{table}

\section{Improvements}
As this chapter is being written, the VRML standard is advancing to version
2.0~\cite{VRML-2.0}, which was finalized on August 4, 1996.  The new VRML
specification not only corrects many shortcomings of the old standard,
such as, static definition of the 3D world, it
also provides many new features, such as sensors and scripting.  We highlight
some features that can be used to present a better VRML terrain model.
\begin{description}
\item[Background]  A realistic backdrop is provided by the Background node.
Multiple colors can be specified to simulate the sky's gradual change of
color from horizon to overhead.
\item[ElevationGrid]  The {\tt ElevationGrid} node provides a convenient way to
encode and to present a uniformly sampled 2D surface.  The surface is encoded
by a matrix
of height values in row major order.  Since the sampling location is uniformed
distributed, the connectivity information is implicitly defined.  Hence, VRML
2.0 encoding of a 2D surface is much more compact than VRML 1.0.  However,
this is no use for the low resolution irregular sparse DEM after optimization.
\item[Fog] Various atmospheric conditions, such as, fog and haze, can be
simulated by using {\tt Fog} node.  It is an essential part for the Los Angeles
fly-by tour.
\item[NavigationInfo]  The {\tt NavigationInfo} node contains the description
of the
physical properties, such as terrain following, speed and visibility, of the
viewer and viewing model.
\item[ProximitySensor]  The {\tt ProximitySensor} node permits the initiation of
actions in the VRML world based on the user position.  Hence, we can prefetch
the needed terrain data and hide the network latency and transfer time.
\item[Script]  The {\tt Script} node provides a gateway for the VRML world to
incorporate complex animations, which must be defined by a program.  The
current scripting languages suggested by the specification are Java and
Javascript.
\item[Viewpoint]  The {\tt Viewpoint} node can be used to specify a predefined
route for a tour.  Using this node, we can limit the flight characteristics of
the user's craft, so that the user can experience a smoother presentation on a
low-end platform.
\item[VisibilitySensor]  The {\tt VisibilitySensor} node identifies the visible part
of the world.  This enables us to order the prefetch process, so that the
visible terrain data is fetched with higher priority.  In addition, the
visibility sensors also permit us to selectively turn on or off the
proximity sensor to minimize the processing overhead of the VRML browser.
\end{description}

Using these VRML 2.0 features, the terrain presentation can automatically adapt
itself to suit the need of the user under the different networking and
computation capabilities of the client machines.

\subsection{The Brave New World}
\label{new_VRML_terrain}

In this section, we describe the design of a VRML 2.0 world that takes
advantages
of the viewing characteristics discussed in section~\ref{high2low-flight}.
We divide the real-life plane flight region (this is refereed to as high
altitude flight
path to low altitude flight path in section~\ref{high2low-flight}) into two
regions. A normal flight, in other words, a straight and level flight path, 
is conducted between the altitude of 1km to 19km.  A terrain following
flight is done below
1km.  The basic structure of the VRML world for both flight regions is
similar.  However, the terrain
following flight requires high accuracy of the terrain data because of the
close proximity to the terrain model.
Both worlds rely heavily on VRML sensors to provide the user's location and
orientation.
Furthermore, a scripting language is used to provide the needed
computation and network connection and to choreograph the complex sequence of
animations.

According to the viewing distance vs. altitude plots in
figure~\ref{alt-visible},
a $20 \times 20$ grid of the terrain data (figure~\ref{high-alt-visible}), where
each grid section is a 12.8km $\times$ 12.8km (128 $\times$ 128 points for a
100m resolution DEM) terrain model, is needed
for the viewing altitude of 1km (3279 ft).  The computation of the viewing
distance vs. altitude is shown in Appendix~\ref{viewing-limit}. For higher
viewing altitude (up to 19km or 62,335 ft), an $80 \times 80$ grid is required.
Although the number of polygons in each of the terrain models is reduced by the
optimization algorithm, an estimate of 0.8 million polygons is used in
the $20 \times 20$ grid, assuming each grid
section has approximately 2,000 polygons.
This amount of polygon data is far beyond the capabilities of any client
machine to provide an interactive 3D environment.  To reduce the number of
polygons in the entire world, we provide the
terrain model for the visible region and a select few other buffering grid
sections only.  We can extend this practice to emulate the earth's
curvature by removing the terrain models that are beyond the user's vision
limit.  An estimated 0.14 million polygons are needed to cover the highlighted
region in figure~\ref{high-alt-visible}.  If the complexity of the
model is still beyond the client's reach, an alternative is to
determine the grid size by the rendering capabilities of the client machine.



\begin{figure}
\begin{center}
\begin{picture}(432,372)
\psfig{figure=high-alt-visible.eps,width=432pt,height=372pt}
\end{picture}
\end{center}
\caption{Only a small part of the grid is visible to the user.  The circle
indicates the viewing limit at 1Km altitude.  The high-lighted region is the
only part of the terrain data needed by the client.
\label{high-alt-visible}}
\end{figure}

\begin{figure}
\begin{center}
\begin{picture}(360,252)
\psfig{figure=height2.eps,width=360pt,height=252pt}
\end{picture}
\end{center}
\
\begin{center}
\begin{picture}(360,252)
\psfig{figure=height1.eps,width=360pt,height=252pt}
\end{picture}
\end{center}
\caption{The two graphs show the maximum viewing distance on a clear day from
different altitudes above the earth.
%The computation is presented in Appendix~\ref{viewing-limit}.
\label{alt-visible}}
\end{figure}

In order to determine which grid sections are visible to the user,
we have install a visibility sensor for each of the grid sections.  The
visibility
sensor covers an area slightly bigger than the associated terrain model,
so that the terrain model can be added to the VRML scene graph before the
model is needed for rendering.
However, the large number of visibility sensors incur high
processing overhead on the browser.  Fortunately, the visibility sensor can be
turned on/off.  A hierarchical sensor net (figure~\ref{visibility-sensor-net})
can be used to reduce the processing overhead. 
When a parent sensor is visible, it enables all its children sensors.  When
the parent sensor is no longer visible, all its children sensors are disabled,
so that the browser need not check the children sensors against the view volume.

\begin{figure}
\begin{center}
\begin{picture}(342,162)
\psfig{figure=sensor.eps,width=342pt,height=162pt}
\end{picture}
\end{center}
\caption{Two sets of hierarchical sensor nets are shown.  The area bounded by a
red dot-line square is covered by the parent sensor.  The area bounded by a blue
square is covered by the children sensor.  Only two sets of sensors are shown
to reduce cluttering.  In a working model, all grid sections are
covered by sensors.
\label{visibility-sensor-net}}
\end{figure}

   As mentioned in chapter~\ref{viewing-characteristics}, we limit the flight
capabilities of the user's craft by allowing three type of movements,
rotation on the Y axis, forward and backward, ascending and descending.  In
addition, we need to maintain a minimal footprint on the grid, so that the
minimal amount of work is done to render the image.  Since
the VRML world (the grid) is finite, we have to emulate
some of the movements by adjusting the contents of the grid.  The rotation at
the Y axis can easily be accommodated in the square grid.  When the user turns,
some grid sections are no longer visible and are retired from the scene graph.
New grid sections are added to the scene graph, when the section becomes
visible (see
section~\ref{visible-calculation} for more detail).   The forward and backward
motion is emulated by shifting the terrain model toward or away from the user.
This can be accomplished by modifying the information in the transform node of
the affected terrain models.  Both of these motions require meticulous
bookkeeping using the scripting language to track the terrain models.
In order to simulate the earth's curvature with the flat projected VRML models,
when the user's craft is ascending or descending,
we switch on or off the visible sensors that are at the extreme edge of the
user's viewing distance according to the viewing distance vs. altitude
calculation (see Appendix~\ref{viewing-limit}).  Using the same control
mechanism from the turning motion, terrain models are added to or deleted from
the grid.  As a result, the active portion of the grid is maintained at its
minimal size for all three types of motion.

\begin{figure}
\begin{center}
\begin{picture}(432,366)
\psfig{figure=client_process.eps,width=432pt,height=366pt}
\end{picture}
\end{center}
\caption{The process of obtaining a VRML terrain model from a set of wavelet
coefficients and a texture map is shown.  The round corner boxes indicate
data.  The square boxes are processes.  The processes on the same level can be
done concurrently.  \label{client-process}}
\end{figure}

   Adding a grid section to the scene graph involves transferring to
the client and dressing up the data in VRML.  Figure~\ref{client-process} shows
the data and processes needed to form the VRML terrain model.  The terrain data
is transmitted to the
client as a set of wavelet coefficients and a texture map.  First, the client
processes the coefficients by passing them through the reconstruction algorithm
(section~\ref{reconstruction}).  This forms a list of vertices for the terrain
model.  The color of a vertex can be selected by matching the vertex coordinate
with the texture map's coordinate.  At the same time, the list of vertices is
passed onto the triangulation algorithm.  Finally, the client encodes the list
of colors,
the list of vertices, the texture map and the polygonal information in VRML
format to form a VRML terrain model.
To hide this long transferring and processing time, we use a buffer zone and
attempt to predict the user's
flight path.  The goal of shifting the
terrain models is to put the user back near the center of the buffer.
However, the forward and backward motion incurs the addition and retirement of
many terrain models at once.  The buffer zone reduces the frequency of the
scene graph adjustment induced by the forward and backward motion, so that the
client has time to prepare the new terrain models before the user flies over
that area.
We install two proximity sensors as in figure~\ref{high-alt-sensor}.  The
primary proximity sensor covers
the entire buffer zone, and is used to monitor the user's orientation.
Storing and analyzing a history of the user's movements
can be used to predict the user's flight
path.  The secondary proximity sensor, which is smaller than the buffer zone,
acts as a early warning, when the user is approaching the border.  This will
trigger the client to insert the new terrain models just before they are
needed.  After the model adjustment is done, the user's
craft is transplanted back to the center of the grid.

In addition, the client also needs texture maps to decorate the terrain models.
In section~\ref{VRML-findings}, we concluded that 
multi-resolution texture maps are essential for web-based terrain visualization.
To provide a multi-resolution texture map, we exploit the properties of wavelet
transformations once again by compressing the texture map image using wavelets
rather than the JPEG or PNG compression algorithms.
The quality of a wavelet compressed image is determined by the number of wavelet
coefficients used to reconstruct the image.
For the terrain model shown in figure~\ref{high-alt-visible},
a small subset of wavelet coefficients for
the multiresolution wavelet compressed texture maps
are sent to the client initially.
When the texture maps are used in an area close to the user,
the client requests more coefficients from the server and
these are added to the initial set to reconstruct a higher quality texture map.
Wavelet image compressors and decompressors are currently available as commercial
products~\cite{commercial-wavelet1} \cite{commercial-wavelet2}.  The details
of the implemented algorithms and the basis functions are guarded jealously by
the companies.  However, from the description of their products and our
experiments~\cite{wavlet-REU}, we
concluded that a progressive transfer of a texture map similar to the wavelet
terrain model can be realized.  However, there is a subtle different between a
multiresolution wavelet compressed image and JPEG images.  The
reduction of network traffic by using JPEG images is from the reduction of the
file size, which depends on the resolution of images and the quality setting,
as shown in section~\ref{VRML-findings}.  Since the texture maps are the 
major visual component of the presentation, we have to maintain the same
quality of the JPEG images.
For wavelet compressed image, the network
traffic is proportional to the number of wavelet coefficients transferred.
However, the size of a decompressed wavelet image is independent from the
number of coefficients used to reconstruct the image.  The amount of memory to
store all the full resolution texture maps for all the terrain models may be
overwhelming.  Using
multiresolution JPEG images with the terrain model in figure~\ref{low-alt},
only 16.9Mbytes of memory is needed (16 RGB images at 509 $\times$ 509, 20 RGB
images at 255 $\times$ 255 and 28 RGB images at 128 $\times$ 128 resolution).  
Using full resolution texture maps for the terrain models (64 RGB images at
509 $\times$ 509 resolution) requires 47.4Mbytes of memory.
As a result, a lower resolution wavelet compressed texture map must be used for
low-end clients.

\begin{figure}
\begin{center}
\begin{picture}(432,321)
\psfig{figure=high-alt-sensor.eps,width=432pt,height=321pt}
\end{picture}
\end{center}
\caption{The buffer zone is used to reduce the frequency of scene graph
adjustment, which is incurred by the forward and backward motion.  The user's
movement within this zone is monitored by the primary proximity sensor.  The
secondary sensor provides a forewarning before the new grid sectors comes
into the user's view.
\label{high-alt-sensor}}
\end{figure}

   The VRML world for the terrain following portion of the
flight uses the same working principle as in the normal flight.
However, this world is smaller, and it uses terrain data of four different
levels of accuracy.  In figure~\ref{low-alt}, an $8 \times 8$ grid (101.6Km
$\times$ 101.6Km) is deployed for 0.8Km flight altitude.  The complexity of the
terrain model is progressively reduced as the data becomes further away from
the user (table~\ref{VRML-multi-info1}).
Since the higher resolution terrain models are used in and around the
buffer zone, a more precise tracking of the user's view volume will lead to
significant reduction of the total number of polygons used in the world.
As a result, a finer grid is deployed for the two highest resolution terrain
models.  An estimate of 74,000 polygons is used to cover the visible region in
figure~\ref{low-alt}.  The buffer zone and the two proximity sensors are shown
in figure~\ref{low-alt-sensor}.  They function the same way as described in
previous paragraph.

\begin{figure}
\begin{center}
\begin{picture}(432,304)
\psfig{figure=low-alt.eps,width=432pt,height=304pt}
\end{picture}
\end{center}
\caption{This VRML world is used for the terrain following flight profile.
The resolution of the terrain model is reduced for positions further away from
the user.  In the center of the VRML world, the visible sensor grid has a
smaller grid section.  These grid sections are furnished with the high
resolution terrain data.  The smaller grid sector provides us a finer
resolution on resolving the user view volume,
so that a minimum number of high resolution grid section are used to
render the image.
\label{low-alt}}
\end{figure}

\begin{figure}
\begin{center}
\begin{picture}(432,268)
\psfig{figure=low-alt-sensor.eps,width=432pt,height=268pt}
\end{picture}
\end{center}
\caption{This shows the location of the two proximity sensor and the relative
size of the buffer zone.  \label{low-alt-sensor}}
\end{figure}


