
\section{The Interactive Journey}


\subsection{ The Living Schoolbook} 

The Living Schoolbook Project is a joint project between the Northeast Parallel 
Architectures Center (NPAC), the School of Education at Syracuse University,
NYNEX, and Columbia University, on the application of high performance
computing and communications (HPCC) to K-12 education.

Several pilot projects involve designing multimedia educational
applications, including interactive simulations, which will be hosted
on computing facilities at NPAC and delivered to schools in Syracuse and
other parts of New York state via the NYNet ATM network. 

This is a prototype for the use of the National Information Infrastructure
(better known as the Information Superhighway) for education.





\subsection{ The Interactive Journey} 

As a part of the Living Schoolbook project, NPAC is developing a 
flight simulator interface to spatially-referenced multimedia information 
about New York state. 
This is an example of a Geographical Information System (GIS). 

Students will be able to take an interactive, virtual flight over dynamically 
rendered 2D and 3D views 
of the state, select landmarks or towns, and obtain multimedia information
about these places by clicking on an area, which will display
information on that area via a Web browser. 

This method could also be used for interactive journeys over other
areas, such as Mars.





\subsection{ Application Requirements} 

The goal is to provide realistic, real-time, interactive 
2D or 3D renderings of the terrain of a particular area such as
New York State or Mars. 

The data sets are very large and must be stored on a high-end server.
The results are viewed on client computers that access the server 
over the Internet. 

3D rendering is very compute-intensive and data-intensive. 
The amount of processing power available on the server and clients, 
and the amount of bandwidth available on the network connecting them,
may vary substantially. 

The basic requirement for the terrain rendering application is that it
be portable and scalable. 
The resolution and frame rate of the application should gradually be
reduced as the computing and communication resources are reduced.





\section{Web Technologies}


\subsection{ Old Technologies for the Interactive Journey} 

Initially the Interactive Journey used standard Unix client/server 
technologies running over the Internet:
\begin{itemize}
\item A graphical user interface (GUI) written in Tcl/Tk, 
      running on the client.
\item Unix socket-based client/server program to transfer data and images 
      from a server to the client. 
\item A scalable parallel rendering program, running on a high-performance 
      server, to generate real-time 3D images that are sent to the client.
\item Spatially referenced information is displayed in a Web browser 
      run by remote control using a Netscape API.
\end{itemize}





\subsection{ New Technologies for the Interactive Journey} 

The new implementations of the Interactive Journey use 
recently-developed Web technologies:
\begin{itemize}
\item Java (for 2D journey) and VRML (for 3D journey) are used to provide
      the user interface running on the client.
\item Transfer of data and images is done using standard HTTP requests
      (could also be done using sockets in Java).
\item 3D rendering is done on the client using a VRML browser. 
\item Information is displayed in a Web browser using hyperlinks from 
      Java and VRML displays.
\end{itemize}





\subsection{ Comparison of Old and New Technologies} 

{\bf Old:} Custom GUI programs (and Tcl/Tk) have to be installed on each 
	   client, users have to find and run the standalone program.  \\
{\bf New:} Java applet or VRML viewer are automatically run by just 
	   clicking on a hyperlink in the Web browser. 

{\bf Old:} Software is specific to a particular operating system. \\
{\bf New:} Software is completely portable.

{\bf Old:} Have to write routines for passing data over networks using 
	   sockets and custom client/server programs.  \\
{\bf New:} Data is passed using standard HTTP protocols.

{\bf Old:} Need to run a dedicated server for the data.  \\
{\bf New:} Data is served from a standard Web server.

{\bf Old:} Need to write complex programs to do the rendering.  \\
{\bf New:} Uses built-in rendering routines in Java and VRML.





\subsection{ Client-side vs Server-side Rendering} 

In the near future, personal computers will have powerful 
graphics acceleration hardware, to support computer games.
In that case, client-side rendering (such as VRML) should be used. 

However, current personal computers cannot do real-time 3D rendering of 
large scenes, and do not have hardware support for crucial aspects of
terrain rendering such as texture mapping. In this case, it may be
more efficient to do the rendering on a high-speed server, and just pass 
rendered images to the client.

Server-sided rendering can only be used for a very small number 
of ``priviledged'' clients without degrading performance.
Client-sided rendering has no such restrictions, but the 
quality of the rendering may be reduced due to insufficient hardware 
resources on the client.

Some combination of client and server computing, such as on-the-fly 
preprocessing by the server, may be the best option.






\subsection{ Networking Issues} 

Require about 20 frames per second for realistic animation. 
A typical frame size would be 
$640\times480$ pixels, and ideally each pixel would have
24 bits of color information. This requires 
150 Mbits per second of bandwidth 
(an order of magnitude larger than Ethernet speeds) 
to send the raw images from a 
server where it is rendered to a client for display.

The alternatives are to use on-the-fly image compression, 
or to send polygon data for the
scene (or part of the scene) to the client, and do the rendering on 
the client, which is the approach used in VRML.

Even VRML data is quite large, since current implementation uses ASCII
data format and no compression. However it is possible to use standard
text compression, such as gzip.



 


\subsection{ Image Compression} 

Images need a lot of data, and animated images hog even more 
bandwidth, so they must be compressed. 
JPEG compression has become the standard for images, 
MPEG for video. Other methods include Wavelet and Fractal compression.

JPEG decreases image quality (i.e. is lossy), 
but at compression ratios of 10:1 the image is virtually indistinguishable 
from the original, and generally 20:1 looks fine.

However JPEG compression algorithms are too slow for real-time animation
(about 0.2 seconds to compress a $320\times 200$ image on a DEC Alpha).
Fast parallel or hardware implementations could be used.
Decompression is fast, and cheap special purpose chips will soon become
standard features.

JPEG compression is used for 2D images, and can even be done on-the-fly
for accessing arbitrary sections of large satellite images.




