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:

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:

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.

...