I have been playing with terragear to see if I can get cliffs to appear in the terrain around Sydney (Australia). There are a lot of cliffs around here, both along the sea coast and inland in the "mountains" (and thus a thriving rock-climbing community) but these cliffs don't appear in FlightGear terrain, and as far as I can tell this is because:
(1) SRTM-3 height data is an average value and thus averages out top and bottom cliff heights
(2) terragear interpolates heights between values on the SRTM-3 grid, so even with e.g. ViewfinderPanorama heights, there is a smoothing effect.
The current result of my experimentation is below:
1. Looking south along the coast south of Sydney, default FlightGear scenery
2. Same location as above, after cliffs added
3. Sydney north head (north entrance to the harbour) after adding cliffs. The current scenery for Sydney north head is wrong in too many ways to bother including for comparison (there is no massive heliport there [now removed from WED], there is no urban landcover either, the coastline is way off)
Note that images 2 and 3 use Statto's improved landcover classes, but I've not included all classes in order to save processing time. I have also used OSM coastlines (see below for why this is necessary).
These cliffs are produced as follows:
(1) Cliffs are extracted from OpenStreetMaps data using the condition "natural=cliff"
(2) ogr-decode is used on these files to create lines of cliffs in the terragear working directory in the same way as roads and rivers (line data) are currently processed by ogr-decode. That is, the cliff line is replaced by a sequence of narrow quadrilaterals, material type = Rock.
(3) A new tool "cliff-decode" which is a stripped-down version of ogr-decode is run on the same OSM data to place cliff line data in the directories containing the height data
(4) A new tool "rectify_height" is run over the height arrays. This tool assumes that all heights within a certain distance (say 100m) of a cliff will not be an accurate point height. These heights are discarded and replaced by heights interpolated from the remaining heights, performing multiple passes if necessary. The cliff lines are considered discontinuities and never interpolated across.
(5) tg-construct is run as usual, using the rectified heights if available. My modified version does not interpolate heights across the cliff lines stored in the height directories. Cliffs appear because one side of the cliff quadrilateral generated at step (2) will be just inside the top, and the other side just past the bottom and thus these points are calculated to have radically different heights. Note that almost all of the changes are in Array.cxx, which is used by rectify_height and tg-construct.
Issues and improvements that remain:
(1) Where sea cliffs don't match the coastline exactly, they will become very jagged as any point considered to be part of the sea will be set to a height of zero. So the coastline data should be as good as the cliff data.
(2) I've tried using procedural rock texturing for the cliffs (which would be cool) but they seem to become reflective. Is it possible that the shaders are not designed for viewing rock from the side?
(3) cliff-decode uses the clipper included in terragear to clip the cliff lines. However, these lines could be included in-toto as they are simply used to indicate discontinuity and there is no problem if they extend outside a bucket
(4) an order-of-magnitude speedup is available for cliff-rich areas like Sydney if bounding boxes of the cliff lines are stored to save checking against all cliffs in a bucket for every pair of points when interpolating.
I think it would be great if this code could be merged into terragear. Perhaps a "cliff" topic branch could be created if the above approach seems reasonable? Or should I submit a series of patches?