Design
Introduction
Rez is a terrain file parser and translator framework. Output can be a single
tile or a multiresolution tree of tiles. Rez will sample the input and produce
output files at a resolution and size controlled by you. Some of the main goals
of the framework are to be able to handle large terrain data sets, build models
unrestricted in size that can be displayed with acceptable performance over
the web, and with interactive performance over broadband networks; and to provide
a structure that is highly flexible and for which implementers can easily build
plugins to process different formats.
Rez is designed as a multi-adaptor with a central program (Rez.java) which
allows the input parser to be plugged in and the output generator to be plugged
in. There is also a GUI interface so you can plug in a GUI and an
interface for a scene generator. Example parser, tiler, GUI and scene plugin
implementations are provided. The scene generator is for creating the
main world in which the elevations are displayed plus viewpoints, tours etc.
Later there may be other type of plugins. See www.ping.com.au/3map/rez
for details and the examples of a Rez generated models and the files used to
generate it.
Scope
The intended use ranges from simple translation of GIS information to building
structures for efficient display of 3D models over the Web. Rez forms an integral
part of the 3map project, which aims to build an open platform for the delivery
of realtime 3D geospatial content and applications over broadband networks.
Rez currently performs its operations as an offline translator, but could be
incorporated into a server-side process flow for real-time processing and display
of geographical information.
Goals
Goals are to be interpreted in the context of the intended user and minimum
hardware platform.
Target usage
We are mainly concerned with creating models that can be browsed efficiently over
the internet by anyone with the target hardware platform or better.
Target hardware platform
For performance related goals the target technology in mind is a minimum recommended
graphics capability of a GeForceII 32MB and a minimum CPU of a PIII 800MHz.
The target usage bandwidth for interactive performance is a broadband network.
Main goal
The main design goal is:
To take planetary geographical data, in particular height grids and
translate into a Multiresolution form suitable for displaying in 3D over broadband
networks.
Secondary goals
Secondary goals (and future wish list!) to provide a framework to:
- Take geographical data, in particular height grids and translate into another
geographical format.
- Generate output primarily in a multiresolution tree, with level of detail
(LOD) parameters and suitable for efficient display in 3D over the web.
- Minimize performance problems such as internet latency, overlarge polygon
count, oversized textures.
- Minimize unseemly visual artifacts such as cracks or seams at tile boundaries,
tiles disappearing to reveal holes during LOD changes, blank areas appearing
when texture is being loaded.
- Provide for the visual presentation (scene generation, viewpoints, tours
etc.) if required by the client.
- Take multi-part input (e.g. multiple tiles representing the Earth), be
able to process them all in one pass, and allow plugins to handle inter-tile
issues (such as stitching).
- Provide very precise calculation of tile size and position, with at least
double precision floating point accuracy. Ensure adjoining tiles accurately
line up along shared edges.
- Be as flexible as possible - using a multi-socket design - so as to allow
plugins to be used to handle all common variations on the main goal.
Allow plugins to be plugged in to parse the given input data and plugins for
the output data generation. Provide plugins for output and other changeable
aspects sucha s GUI and scene generation.
- Provide georeferencing of the grids.
- Provide for positioning of other objects/object references correctly in
relation to the terrain model.
- Allow for transformations on the data for displaying local information
in non geo-correct form, handle precision/jitter issues or simply to enable
the visualisation of the information translated and scaled.
- Assist with the calculation of viewpoints, tours and other useful structures
that are tedious to hand-claculate.
- Provide for command line, applet and API based running of implementations.
- Error/consistency detection, notification or correction: we are not
certain to what degree the framework should/can support this.
- Allow the use of Grid computing to provide input data
- Provide for the management of a geobase and web services on the geobase
Constraints
Current sample implementations work only on gridded structures and transform
them into other gridded structures - usually Multiresolution trees of height
grids. These use an intermediate height grid format. Therefore the many widely
available height grids are perfectly suited for Rez. Other data, such as images
can be treated as grids (of pixels) and may therefore also be passed in (this
has not been tested yet). It is possible that non-gridded data may also be amenable
to 'Rezzing' but mainly if it can be parsed into the intermediate height grid.
Some current Web3D technologies (e.g. some VRML browsers) do not cater well
for switching geometry (e.g. when changing tiles in a LOD transition). There
can be very limited control over the LOD changes as well. It will be necessary
for the 3map client application to deal effectively with large LOD trees.
Analysis
The Rez framework is not restricted to terrain models but rather the generation
of static LOD structures. Therefore only those things that can be built into
the stored structures are able to address the above goals. There is still much
that can be done, such as reducing the number of files that have to be downloaded
per LOD change, compressing the data, using an efficient, minimal size format,
optimizing polygon count and optimizing texture size. Further efforts can go
into some degree of pre-stitching - there are even some implementations of fully
pre-stitched structures all pre-generated.
With Rez's provision for a user interface it is also possible to actually build
the client side display tool. In such a case the static LOD structures can be
combined with dynamic mesh techniques for client side optimisation.
In order to make efficient use of bandwidth, both the server and client need
to minimize latency through efficient protocol usage (such as reducing http
overhead), reduction of data packet size and appropriate compression/decompression.
Design Development
General
The information handled by Rez can be though of as a "world", divided into initial
tile set, which as a whole or individually are subdivided into multirezolution
tiles. Each of these things can be considered a 3D model/tile and therefore we
have a recursive structure suitable for a Composite design pattern (see GoF).
The design implementation will be therefore contain a Composite pattern as a main
structure. A GeoGraph is the top of this structure and represents any geographical
object. An abstract multirez tile interface (RezTile), tile leaves, array of tiles
and other objects will all be GeoGraphs. The main API calls (as they get developed)
will be methods on GeoGraph.
RezTile represents a level of detail: an array of tiles at one level of detail
(LOD). It is the main framework class with template methods for tiler
implementations.
A single tile (which should be a GridTile in the present incarnation of Rez)
represents one of those tiles at a LOD.
API
A set of API methods are being developed for Rez so it can be used as a component
in an application such as 3map. Possible API methods on GeoGraph:
- create
- update
- Rez it!
- texture
- position/move/geolocate
- embellish/annotate
- georeference
- add object
- add to world
Stitching
The source tiles surrounding a particular source tile being processed are accessible
for future stitching purposes through a source tile array parameter.
This stitching needs to be done in the RezTile implementation (the tiler plugin):
it needs to go across source tile boundaries, across levels and across sub-tile
boundaries. Going across sub-tile boundaries is fine with the above composite
pattern because each sub-tile array can be stitched at run/display time taking
into account visible LODS. I.E. it requires a recursive structure/knowledge
over the multiple levels and not just flat arrays on one levels, visibility calc/predictions
for tiles. Note this does not require the use of recursion in tiler implementations
- the current examples use standard iteration.
...