Requirements

  As this is an ongoing project, it is necessary to outline the
requirements along three paths.  The first section delineates final
product requirements.  In the second section, a detailed outline
specifies current project requirements organized by functional
components.  These should be modified as necessary to reflect ongoing
needs.  Quarter-by-quarter requirements are recorded in the final
section.  These may be short-term and prototype-specific, and can be
modified as necessary during subsequent project work segments.

1 Abstract

  The project design must fulfill two sets of needs:
1) Provide an interactive Virtual Reality model of the renovated
Midtown area.

2) Provide a functional interactive environment with well-defined
interfaces with which Computer Science projects can interact.

1.1 Accurate, High-Quality Virtual Representation of Midtown

  To maximize usability, accurate representation of Midtown Atlanta
in an interactive virtual environment is a key project goal.  To ensure
the project's usefulness in the future, this model should be as accurate
and detailed as possible under current computing constraints.  The
graphics modeling segment of the project could feasibly become a joint
venture in the future through involvement of outside groups with
applicable skills and interest in this area.  Maximum mutual benefit
can be obtained from such potential interactions by tailoring the
design to this purpose.  The design must facilitate integration of new
models into the existing virtual world.  This includes the ability
to convert topological maps to virtual terrain, producint textures
and overlays from digital images of buildings, and standardizing on
modeling formats used in the virtual world. 


1.2 Platform and Networking Capabilities

  The virtual world must be accurate enough to be useful, but also small
and fast enough to be interactive without a specialized graphics
workstation.  The final product must be able to run on both Unix-based
and Windows NT platforms at interactive rates.  Virtual Midtown
network features must enable multpile users to interact within the
environment.  To achieve maximum usability, the simulation should
remain interactive when run over a 56kbps modem connection.


1.3 Agents

  To enhance the realism of the environment and to enable students to
program modules for it, an interface must be provided for creating and
animating objects within the Virtual Midtown environment.  These objects
can be dynamic parts of the world - such as doors that open and close,
or street lights that turn off and on - or autonomous agents that move
about the world according to the intelligence routines provided by the
programmer.  Standard interfaces must be designed to incorporate
these modules, regardless of which programming language they are
implemented in.  Such agents should be able to interact with the virtual
world and its users, and be able to run in single user or networked mode.  


2 Virtual Environment

2.1 Rendering

  The application must be able to render 3-D virtual environments fast
enough to be considered interactive.  This can be accomplished with
either a pre-built virtual environment library or, if this option proves
too slow for interactivity, custom-designed rendering functions.  The
system must provide as much accurate realism as is possible while still
remaining interactive on our base machine.


2.2 Calculation of View Volume

  The application must be able to select a subset of immutable objects
and render them if they are in view from the user's current position.
All dynamic objects and autonomous agents within the user's view
should also be rendered.


2.3 Level of Detail

  The final version of Virtual Midtown must be accurate to a 1 meter level
of detail, meaning that each square meter of terrain in Midtown must
have a scale representation in the Virtual Midtown environment.
This is the level of detail required to provide maximum benefit to
future applications requiring an accurate 3-D model of Midtown Atlanta.
Textures are to be used whenever possible, and bitmapped representations
should be used when necessary, according to the desired level of
detail.  Methods should be defined for applying both textures and
bitmaps to surfaces in the virtual environment.


2.4 Backgrounds

  In order to accurately represent Midtown Atlanta, it is necessary to
provide the means to render objects that will be viewable from anywhere
in the environment, such as the downtown skyline.  Methods must be
provided to display objects visible to someone at that actual position
in Midtown Atlanta but that are outside the rendered view volume.


3 Server Requirements

3.1 Hardware

  Because the server is a centralized program, its hardware requirements
are flexible.  If it becomes necessary to run the server on
high-performance hardware, this can be accommodated.


3.2 Static World

  The static world databases will be provided by the server so that all
clients may access the most recent and up-to-date models of Midtown.
Clients must be able to access the static world data as needed.


3.3 Dynamic Objects

  All autonomous agents and other mutable objects in the Virtual Midtown
representation should be tracked by the server, with their current
position and status made available to clients on the network.  The
server must keep track of as much information about dynamic objects as
is necessary to render them with the desired level of detail on the
client application.


3.4 Communication with Client

  A client must be able to establish a link to the server machine and
exchange data with it.  It is not necessary to guarantee the success of
data transfers, except that it must succeed with a probability great
enough to ensure interactivity.  Clients must be able to retrieve from
the server any relevant information about both static and dynamic
objects in their view volume.


4 Client Requirements

4.1 Rendering

  All rendering routines must be executed on the client, though their
implementation can be whatever is necessary to retain interactivity.
Object definitions are to be dynamically downloaded from the server
databases as needed.


4.2 User Interface

  The user interface must allow the user to navigate the virtual world in
an intuitive way.  Dynamic objects must also provide user interfaces for
the various behaviors which it is possible to elicit from them.  For
examplet to the environment around them.  These can be as simple as a
single movement or animation sequence or as complicated as its ability
to calculate movement allows.  


4.3 Program Interface

  Since dynamic objects form the crux of Virtual Midtown's ability to
serve as a computer science educational tool, a standard program
interface must be provided so that the basic functions of dynamic
objects can be accessed using any language.  If a universal interface is
impossible, the development of interfaces for each of the languages used
in Georgia Tech's computer science curriculum will take precedence.
Dynamic object functions should be organized to allow any external
intelligence routines to accommodate all possible behaviors for that
object.


5 Miscellaneous Requirements

5.1 Collisions

  Collisions with the static and dynamic worlds must be accounted for.
The desired level of accuracy is the maximum achievable while retaining
the interactivity requirement.  As this is not a competitive game,
leeway is allowed for computational and network latencies that my cause
flickers or jumping when users collide with dynamic objects in the
environment.  Collision detection's main goal is to keep users from
walking through walls, not to detect the contours of another object.


5.2 Inventories

  Users must be able to acquire dynamic objects and retain possession of
them when they have disconnected from the environment.  An interface
must be provided so that users can choose objects in their inventory and
perform certain allowable actions upon them.