195 lines
7.2 KiB
Text
195 lines
7.2 KiB
Text
TerraGear Scenery Tools README
|
|
==============================
|
|
|
|
TerraGear is a collection of tools for building scenery for the
|
|
FlightGear project. Generally, the process is done in two steps:
|
|
|
|
1. Preprocessing the original raw data. This chops up the data into
|
|
the FG tiling scheme and saves it in a simple, intermediate
|
|
format.
|
|
|
|
2. Collect all the different pieces of intermediate data and
|
|
assemble them into a 3d model of the terrain.
|
|
|
|
There is currently no graphical front end for these tools so you will
|
|
need to run them from the command line. Be prepared, when building
|
|
scenery on a world wide scale, be prepared to burn through multiple
|
|
gigabytes of disk space and days or weeks of crunching. Building
|
|
smaller chunks is much more doable though.
|
|
|
|
|
|
Building the Tools
|
|
==================
|
|
|
|
These tools are primarily compiled and tested under Unix with the Gnu
|
|
C/C++ compilers. I believe they also build and run on windows with
|
|
Cygwin. If anyone has patches for supporting other platforms, I will
|
|
be happy to incorporate them.
|
|
|
|
The process for building these tools is very similar to building the
|
|
main FG source code.
|
|
|
|
1. If you are using the CVS version of the source, run the
|
|
"autogen.sh" script. If you downloaded the source tarball, then
|
|
don't.
|
|
|
|
2. Run the "configure" script, with optional arguments for setting
|
|
the install prefix, etc..
|
|
|
|
3. Run "make"
|
|
|
|
4. Run "make install"
|
|
|
|
|
|
Preprocessing Terrain
|
|
=====================
|
|
|
|
TerraGear supports several terrain data sources:
|
|
|
|
1. [Preferred] SRTM (version 3):
|
|
Void filled, 1-arc-sec and 3-arc-sec, near worldwide coverage.
|
|
|
|
https://e4ftl01.cr.usgs.gov/MEASURES/SRTMGL1.003/
|
|
|
|
a) Chop up each .zip files using "Prep/DemChop/hgtchop"
|
|
|
|
|
|
2. SRTM (version 1 & 2):
|
|
May contain voids, 1-arc-sec and 3-arc-sec, near worldwide coverage.
|
|
|
|
ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/
|
|
|
|
a) Chop up each .zip files using "Prep/DemChop/hgtchop"
|
|
|
|
|
|
The result for any of these terrain sources should be a "work" tree
|
|
with a .arr.gz file for each FG tile.
|
|
|
|
3. SRTM versions 1 & 2 come with 'voids'. These are areas where their
|
|
automated data processing system could not reliably determine the
|
|
elevation. Often this happens over water, or over mountain peaks.
|
|
There is a big chunk of the Grand Canyon missing, a big chunk of
|
|
Rhode Island, etc.
|
|
|
|
So as a partial fix I came up with a little program that will fill
|
|
in the voids from another data source. In this case the only thing
|
|
I half trust is the USGS 3 arcsec DEM data for the USA. So we
|
|
can't fix voids outside the USA right now.
|
|
|
|
In the same directory as HgtChop there is a "fillvoids"
|
|
program. You might wish to run it with something like the
|
|
following command line:
|
|
|
|
find /export/fgfs05/curt/Work/SRTM2-North_America3 -name '*.arr.gz' -exec ./fillvoids {} /stage/fgfs05/curt/Work/USGS-DEM-USA-3 \;
|
|
|
|
4. After you create the .arr.gz files you have to create a
|
|
corresponding .fit.gz file for each of these. This is a data
|
|
reduction step which fits a set of polygons to the raw terrain with
|
|
a set of constraints on the maximum error allowed relative to the
|
|
original data set, and a max/min number of allowed nodes in the
|
|
fitted set. The provided tools use a scheme that produces an
|
|
adaptive fit which means fewer polygons in smooth flat areas, and
|
|
more polygons in complex rough areas. The end result is a *much*
|
|
better fit with fewer polygons than you could achieve by just keeping
|
|
every "nth" point from the original array.
|
|
|
|
To walk through an entire tree of .arr.gz files and produce the
|
|
corresponding .fit.gz files, use the "Prep/TerraFit/terrafit.py"
|
|
utility. Please ignore the old "ArrayFit" tools which use a stupid
|
|
algorithm and are basically useless in comparison to TerraFit.
|
|
|
|
|
|
You should now have a large tree of .arr.gz files with a corresponding
|
|
.fit.gz file for each .arr.gz file. It's worth double checking the
|
|
contents of your directory and counting all files of each type to make
|
|
sure you do have a one to one match and didn't miss anything.
|
|
|
|
|
|
Generating Airports
|
|
===================
|
|
|
|
Robin Peel maintains a world wide database of airports and navaids for
|
|
the X-Plane and FlightGear projects:
|
|
|
|
http://www.x-plane.org/users/robinp/
|
|
|
|
Robin's apt.dat needs to be run through two scripts
|
|
|
|
cat apt.dat | ./xp2simpleapt.pl > basic.dat
|
|
cat apt.dat | ./xp2runway.pl > runways.dat
|
|
|
|
Compress these and copy them to $FG_ROOT/data/Airports
|
|
|
|
Now run the runways.dat through the getapt utility:
|
|
|
|
genapts --input=runways.dat --work=$FG_WORK_DIR
|
|
|
|
Note: this creates a last_apt file which shows you the airport genapts
|
|
is currently working on.
|
|
|
|
- if genapts crashes (which is possible if you try to run through the
|
|
entire runways.dat file) you can look at last_apt to see where to start
|
|
up again.
|
|
|
|
- You can start in midstream using the --start-id=KABC option to genapts.
|
|
|
|
- If you get a consistent crash on a particular airport, you probably
|
|
found a bug in genapts, or there is some degenerate information at that
|
|
airport (40 mile long runways, 2 runways spaced miles apart, etc.)
|
|
Often you can fix the data and proceed. Sometimes you can "nudge"
|
|
things around to get past a genapts bug. For instance, if you crash
|
|
consistently on a valid looking runway, try nudging the heading or
|
|
position by a least significant digit. Sometimes we can get numerical
|
|
problems with the polygon clipper and this often works around it.
|
|
|
|
Other considerations:
|
|
|
|
- Airport generation pre-depends on terrain data being prepared and ready
|
|
so airport surfaces can be built properly.
|
|
|
|
- If you prep new terrain data, you should probably rerun the airport
|
|
generation step.
|
|
|
|
|
|
Processing VMAP0 data
|
|
=====================
|
|
|
|
Most of the FlightGear terrain features come from the VMAP0 data set
|
|
available from:
|
|
|
|
http://geoengine.nima.mil/
|
|
|
|
There is a script in src/Prep/TGVPF/ called process.sh which will
|
|
generate all the VPF data for all 4 CD's. Look at the script and
|
|
understand what it's doing. I don't run it exactly as is because it
|
|
takes too long to run everything at once and if something bombs in the
|
|
middle, you generally have to start from the beginning just to be on
|
|
the safe side and avoid duplications and other potential weirdness.
|
|
|
|
I usually run each CD individual and copy the data to a separate area
|
|
when done. Then I reassemble all the VPF data in the end before
|
|
running the final tile builder.
|
|
|
|
|
|
Processing Radio Tower data
|
|
===========================
|
|
|
|
I found some very detailed, very complete, very current radio tower
|
|
data from the FCC. This even includes cell phone towers and
|
|
individual hobbyist towers. However it only has USA coverage:
|
|
|
|
http://wireless.fcc.gov/cgi-bin/wtb-datadump.pl
|
|
|
|
When you unzip this file, the good stuff is in DE.dat, I believe there
|
|
is file format information at the above url.
|
|
|
|
Run:
|
|
|
|
.../Prep/Tower/tower.pl --input=$RAW_DIR/DE.dat --outdir=$WORK_DIR/TowerObj
|
|
|
|
This creates a tree of .ind files in $WORK_DIR/TowerObj/
|
|
|
|
If you add this directory to the list of directories searched by the
|
|
build tile program, these entries should get added to the final
|
|
scenery. This of course requires the corresponding tower models to be
|
|
available in the base package.
|