Add terrain surface visualisation

[Wookey]

We currently have surface data as legs, which can be used to make a terrain grid (using terraintool to import DEM data). A proper surface using openGL would make for much better visualisations, separate surface survey/GPS data from terrain models and allow later additton of map-draping and similar features.

Related features are data reading, a DEM survex data type, DEM import, co-ordinate conversion, and overlay images, but those are subjects for separate tickets.

Some work on this has been done in 2002 and 2011, as discussed in various 'Surface data' threads at: ​http://lists.survex.com/pipermail/survex/2011-September/thread.html Since then the survex VCS has been converted from SVN to git so the links are broken.

The important bits are these commits: r2035 8ed7e813da6bb872ef3d5d5f7064c3ad16ecb921 ​https://gitorious.org/survex/survex/commit/8ed7e813da6bb872ef3d5d5f7064c3ad16ecb921 r2059 33b2094393ec862b7206d12f49c9735a53d8fb88 ​https://gitorious.org/survex/survex/commit/33b2094393ec862b7206d12f49c9735a53d8fb88

And this is Stuart's hacky patch showing that the core if this is straightforward:

[Wookey]

Hacky openGL surface visualisation (by Stuart Bennet and Wookey)

[Olly Betts]

Note that you don't want to do the rendering with QUADS - those are only generally suitable for quadrilaterals which lie exactly in a plane, but for terrain they rarely will. If you can see both sides at once, then you'll likely get visual glitches, and it's quite likely you'll be able to if you look at the edge of the terrain from a suitable angle.

We shouldn't really be using QUADS for the tubes either (and there's a FIXME to that effect), but it's harder to get a view such that you see a glitch for those.

[Olly Betts]

I've been working on this recently and [622460e4a2c7da463b1a995d58250d44bbbe5976] actually adds a UI for loading a terrain file, which is the final piece to make this usefully usable.

Currently you can load terrain from a zip file containing either an .hgt file (a format SRTM data and some other sources are available in) or a .bil file containing signed 16 bit integer data and associated metadata files (a format from ArcGIS). These two formats are essentially the same, and have the desirable attributes of being both compact and easy to parse. We may want to support other formats, but writing parsers for them ourselves is probably foolish - libgdal is probably the answer. But it's nice to have built in support for something so that libgdal isn't a hard requirement, and people can just convert other data to one of these formats using gdal themselves.

The biggest issue is that the heights from proj don't match those from GPSes, maps, etc - we need to take the geoid into account, which recent versions of proj support. It would be good to sort out doing this in a compatible way for therion and survex, but sadly my mail about this to the therion list got no response. You can probably adjust for the geoid by specifying a suitable custom coordinate system string in the .svx file, which isn't a big deal for CUCC's Austria stuff as we're already specifying a custom string.

Other than that, the main remaining limitation is that loading the terrain is rather slow (a 1 degree square of 1 arc-second data takes around a minute on my > 5 year old netbook). This is mostly down to the overhead of doing a proj coordinate conversion for every point on the grid, which we should be able to avoid (for example, by repeatedly bisecting until interpolating gives a value within a suitable tolerance of what proj gives). A degree square of 3 arc-second data takes about 1/9 the time, so 5-6 seconds. I've not tried it on a fast machine yet, but I'd guess even the 1 arc-second data is already tolerable there.

Currently each triangle is shaded a single colour, as that's easy to do and makes errors in the shading stand out better which is handy while coding it up. But once you zoom in enough to be able to see beyond the terrain grid resolution (for SRTM data, that's 90m or 30m) it starts to look grainy and eventually you can see the individual triangles - adding smooth shading is mostly a matter of calculating normals at each vertex to pass to OpenGL.

The hardest part of texture mapping aerial images or a map is probably geolocating the image - once you can convert geo coordinates to pixel offsets in the image it's pretty easy to specify the texture mapping to OpenGL. Probably supporting geotiff via some library is the way to go.

My netbook animates ~250,000 triangles of terrain without a problem. For ~2,000,000 triangles, it's not very smooth, but still usable. A modern machine should cope fine with both, and there's likely scope for optimising the use of OpenGL here.

[Olly Betts]

Annoyingly the Z-prepass doesn't work on my workstation for some reason - you can see the terrain through itself. I had a quick go at debugging, but no useful discoveries so far.

I've created #53 for texture mapping onto terrain.

[Olly Betts]

The Z-prepass issue is now #55, the geoid issue #56, smooth shading #57.

The rest is done in 1.2.18, so closing this ticket.