flightgear/SceneGeneration/SceneryGeneration.tex

%
% `SceneryGeneration.tex' -- describes the scenery generation tool pipeline
%
%  Written by Curtis Olson.  Started February, 1999.  curt@flightgear.org
%
% $Id$
%------------------------------------------------------------------------


\documentclass[12pt]{article}

\usepackage{anysize}
\papersize{11in}{8.5in}
\marginsize{1in}{1in}{1in}{1in}

\usepackage{amsmath}

\usepackage{epsfig}

\usepackage{setspace}
\onehalfspacing

\usepackage{url}


\begin{document}


\title{
  Flight Gear Scenery Generation Tools.
}


\author{
    Curtis L. Olson\\ 
    (\texttt{curt@flightgear.org})
}


\maketitle


\section{Introduction}

This document gives a brief overview of the Flight Gear scenery
generation tools and how they fit together in a pipeline to produce
the runtime scenery from the raw data.

The first sections describe how the Flight Gear Earth is subdivided
and the coordinate systems that Flight Gear uses internally.  The
remaining sections describe the tools that take diverse data sources
and produce the actual scenery.


\section{Internal Scenery Representation}

This section describes how FG represents, manipulates, and
transforms scenery internally.

Internal, all FG scenery is defined using a cartesian coordinate
system centered at the center of the earth.  Please refer to the
Flight Gear CoordinateSystem document for more information.  This
means that one of the scenery tools processing steps will be to
convert from the source data coordinate system to the internal Flight
Gear coordinate system.


\subsection{Scenery Partitioning}

Flight Gear splits the world up into tiles.  This splits up the
immense scenery data base into chunks that are managable by the run
time simulator.

Tile edges are parallel to longitude and latitude lines.  Tiles are
gauranteed to be at least 8 miles long in both width and height.  As
we move towards the poles, the tiles get narrower, so at certain
predefined latitudes, the tile with is doubled.  Figure \ref{fig:lats}
shows latitudes vs.  tile widths.  The southern hemisphere is a mirror
image of the northern hemisphere.

\begin{figure}[hbt]
 \begin{center}
  \begin{tabular}{||l|l||} \hline
    Latitude Range & Tile Width \\ \hline
    $[0, 22)$  & $\frac{1}{8}$ degree \\ \hline
    $[22, 62)$ & $\frac{1}{4}$ degree \\ \hline
    $[62, 76)$ & $\frac{1}{2}$ degree \\ \hline
    $[76, 83)$ & $1$ degree \\ \hline
    $[83, 86)$ & $2$ degrees \\ \hline
    $[86, 88)$ & $4$ degrees \\ \hline
    $[88, 89)$ & $8$ degrees \\ \hline
    $[89, 90]$ & polar cap \\ \hline
   \hline
  \end{tabular}
 \end{center}

 \caption{Latitude vs. Tile Widths.}
 \label{fig:lats}
\end{figure}


Since Flight Gear tiles are partitioned parallel to longitude and
latitude lines, they have a trapezium shape.  Figure \ref{fig:trap}
shows an exaggerated scenery area.

\begin{figure}[hbt]
  \centerline{                   
      \psfig{file=trap.eps}
  }
  \caption{Basic Tile Shape}
  \label{fig:trap}
\end{figure}

\subsection{Reference Points}

Each scenery area will have a reference point at the center of its
area.  This reference point (for purposes of avoiding floating point
precision problems) defines the origin of a local coordinate system
which.  The local coordinate system is simply translated from the
global coordinate system by the distance of the tile's center
reference point from the center of the earth.  Figure
\ref{fig:reference} demonstrates this better than I can explain it.

\begin{figure}[hbt]
  \centerline{                   
      \psfig{file=ref.eps}
  }
  \caption{Reference Points and Translations}
  \label{fig:reference}
\end{figure}

All the objects for a specific scenery area will be defined based on
this local coordinate system.  For each scenery area we define a
vector $\vec{\mathbf{a}}$ which represents the distance from the
center of the earth to the local coordinate system.


\subsection{Putting the pieces of scenery together}

To render a scene, the scenery manager will need to load all the
visible tiles.  Before rendering each tile we translate it by
$\vec{\mathbf{a}}_{current} - \vec{\mathbf{a}}_{n}$.  This moves all
the rendered tiles near to the origin, while maintaining the relative
positions and orientations.  The of moving all the tiles near the
origin before rendering them is to try to reduce floating point round
off problems.

When rendering, it is straightforward to calculate the proper view
point and up vector so that the scenery will appear right side up when
it is rendered.

\subsection{Scenery file format}

Here is a very brief overview of the flight gear scenery file format.
Some of this format will have to change in the future, so I won't put
a lot of effort here right now.  This description will be most
understandable if you reference an actual scenery tile file.  If you
have questions, please ask!

\begin{itemize}
  
\item Coordinates are in (X, Y, Z) with (0, 0, 0) being the center of
  the earth.  Units are in meters.
  
\item ``gbs'' is the ``global bounding sphere'' specified by the
  center reference point and a radius.
  
\item This is followed by a list of vertices prefaced by ``v''
  specifying the offsets of the vertices from the gbs reference point.
  
\item Then follows the list of vertex normals ``vn''.
  
\item Then the sets of triangle strips are specifed:
  
\item ``usemtl'' points to a material property record in the materials
  file and specifies the texture/color/etc. for this triangle strip.
  
\item ``bs'' specifies the bounding sphere for this particular tri
  strip (for view frustum culling)
  
\item ``t'' is the start of a tri strip and the integer numbers are
  just indices back into the vertex and vertex normal lists.

\item ``q'' is simply a continuation of the triangle strip.
\end{itemize}

I will eventually need to add texture coordinate support to this file
format, as well as a way to reference and position objects from an
external library.


\section{Scenery Generation}

This section is very fluid right now.  I have implemented a first pass
at generating scenery.  This was a good learning experience, but it
exposed several flaws and limitations in my original approach.  I am
in the midst of a complete overhaul of these tools which is intended
to address all the short comings of my first attempt.  At this point I
am simply outlining the plan.  Much of this could change as my plan
continues to smack up against reality.

With that in mind, the scenery generation tools can be subdivided into
four major categories.

\begin{itemize}

\item Libraries which provide basic functionality used by the terrain
  tools.

\item Preprocessing tools which convert data from it's original format
  (as downloaded from the net) to something that is easier for the
  scenery tools to process.

\item Scenery generation tools which assemble and massage the
  resulting input data into the Flight Gear scenery format.

\item Miscellaneous utilities

\end{itemize}

\subsection{Libraries}


\subsubsection{GPC}

GPC is the ``Generic Polygon Clipper'' library.  It is available from

\url{http://www.cs.man.ac.uk/aig/staff/alan/software}

Please be aware that the licensing terms for the gpc library clash
with the GPL and prevent the source code from being redistributed with
any GPL program.  Therefore any developers interested in building the
scenery tools will have to fetch and install this library individually
on their own systems.

\subsubsection{GFC}
 
GFC is the ``Geographic Foundation Classes'' library.  It is available
from:

\url{http://www.geog.psu.edu/~qian/gfc/index.html}

This library allows programs to process GIS shapefiles and extract out
the lon/lat coordinates of the GIS structures.

\subsubsection{DEM}

This is a library of routines distributed as part of Flight Gear.
This library has routines to parse the 3 arcsec DEM file format,
approximate the regular grid of height data, with an irregular grid,
and interpolate the elevation of any arbitrary point inside the grid.

An irregular grid can often represent the same level detail as a
regular grid with 4-6x fewer polygons.  This is very desirable in a
flight sim where both detail and rendering speed is very important.

Another feature of an irregular grid is that it carries fewer
artifacts that could provide negative training value to pilots.  For
instance a regular grid could give a pilot non-realistic cues for
determining north/south/east/west.


\subsubsection{Triangle}

Triangle can be built as a standalone binary, or as a library.  For
our uses I am choosing to build it as a library.  This library
impliments the delauney triangulation algorithm.  It takes a set of
unorder points and finds the optimal triangulation of these points.

For our use we feed in a set of unordered height values and the
triangle library will output a set of triangles that can be rendered
as terrain.

The triangle library does a few more things that are useful.  It will
subdivide triangles to ensure that they never get too long and
skinny.  It will also let you set up boundaries and holes within the
triangulation area.

\subsection{Preprocessing tools}

\subsubsection{GenAirports}

This tools inputs an ascii specification of the airports of the world
that looks like the following:

\begin{verbatim}
KORD Chicago O Hare International                       
        -087.917774 41.976778 13000 200 140 155154 14 R 668
        -087.902380 41.969040 10141 150 90 154154 09 R 668
        -087.903546 41.991918 10003 150 140 155154 14 L 668
        -087.889594 41.961618 8071 150 41 154154 04 R 668
        -087.903705 41.983954 7967 150 90 154154 09 L 668 
        -087.905138 41.989606 7500 150 39 142144 04 L 668
        -087.900410 41.990086 5341 150 180 131131 18 x 668
\end{verbatim}

For each airport, a bounding polygon is generated, and written as a
clipping record for each intersecting tile in the scenery construction
area.  The actual airport will belong to the tile containing it's
center point, but the airport will need to be clipped out of the base
terrain from any tiles it might spill over into.

\subsubsection{ShapeFile}

The ShapeFile tool will take the polygons from shapefiles (via GFC),
clip them to the appropriate tile boundares (via GPC) and write the
resulting polygons to the appropriate tile in the scenery work space.


\subsubsection{DemRaw2ascii}

This tool will input the 30 arcsec raw DEM format, split it up into 1
x 1 degree sections, and output the result into the 3 arcsec format so
it can be fed through the scenery pipeline.

\subsubsection{Dem2node}

This tool takes the raw DEM files and calls routines from libDEM.a to
create the irregular grid approximation of the original data.  The
elevation data is writen to the to the appropriate tile in the scenery
work space.

\subsection{Scenery generation tools}

Issues:

Combining height data, polygon data.

Triangulating / tri-stripping / tri-fanning.

Matching vertices and normals along edges and at corners.

Resolving conflicts in data:
  overlapping polygon areas.
  conflicting height data between airports and DEM data

Here's the basic process to create scenery:

Dump the raw data into the appropriate tile areas in the work space.
This includes height data (DEM, airport) and polygon data (airport,
hydro-data, land use data, etc.)

For each tile, run the generic clipper on each polygon in order from
highest to lowest incrementally building an accumulation ``super''
polygon that comprises a union of all polygons we've processed so far
for this tile.  For each polygon first clip against this
super-accumlation-polygon.  What's left after the clip is the new
shape of the polygon.  This is the scheme for eliminating overlapping
features on a priority basis.

For each polygon on a tile we must determine a point inside.  We need
this for the triangulation step.

For each polygon, triangulate all the height fields in the tile.
Using the triangle library we can feed in all the polygon outlines
with the corresponding interior points.  We can tell the triangulator
to start at every point except for the one we are working on and eat
away all the triangles until a polygon border is encountered.  This
leaves us with the triangulation of each polygon.

Now we have a pile of height data and the triangulation for each
polygon.  However, some of these hieght fields must be enforced
(airports) and some of this can be adjusted (base terrain).  We might
also want to think about ensuring lakes are level, and rivers don't
run up and down hills.  Anyways, with a flurry of handwaving, we have
adjusted all the heights.

The next thing we have to worry about is making sure each tile meshes
exactly with all it's neighbors.  We do this by spliting the tile up
into it's 4 edges, 4 corners, and the remaining vertices.  We write
these parts out as individual files if a neighboring tile hasn't been
processed first.  In other words, the first tile to be process gets to
define the shared edge or corner.  The neighbor must use this data if
it exists.  Then we have to reassemble the tile using any pre-existing
edges from a neighbor tiles that were processed before us and
retriangulate since our node list has changed. <whew>

Unfortunately it's not quite this simple!

We need to be careful, because we have to make sure we also preserve
the polygon connections since lakes, rivers, and even airports often
span multiple tiles.

To do this I propose a scheme of assigning a unique integer id to each
polygon.  When writing out the shared edge/corner pieces I also
associate this idea.  So rather than disassembling, sharing, and
reassembling whole tiles, we need to do this on a per-polygon basis.
More handwaving and we are off to the next step.

Now, we need to take our 3d, triangulated polygons and tri-fan or
tri-strip them for rendering efficiency.  We have been using a
freeware tool called ``stripe'' but it's a typical CSci hack job where
the author was more interested in demonstrating the theory, rather
than demonstrating bug free, robust, well written code.  Oh well.  I
think I will try to write a utility to combine triangles into fans.
This will help culling (smaller, centralized objects == better
culling) but will happen at the expense of more vertex
transformations.  I'm hoping this will result in a net gain.  Finger
crossed. :-)

Finally, we need to take our 3d, fan-ified polygons and convert them
to the FGFS scenery format and copy them from the work space directory
tree into the final scenery directory tree.

% \subsubsection{Areas}
% \subsubsection{AssemTris}
% \subsubsection{Clipper}
% \subsubsection{FixNode}
% \subsubsection{FixObj}
% \subsubsection{SplitTris}
% \subsubsection{Stripe\_w}
% \subsubsection{Tri2obj}

\subsection{Miscellaneous Utilities}

\subsubsection{DemInfo}

Reads the ``A'' record from a 3 arcsec DEM file and dumps some
pertinent information.

\subsubsection{tile-sizes.pl}

Generates the width of a 1/8 x 1/8 degree tile at various latitudes.


\end{document}


%------------------------------------------------------------------------
% $Log$
% Revision 1.1  1999/02/15 00:38:46  curt
% Initial revision.
%