Virtual Planet Builder
|Scenery Core Development|
VirtualPlanetBuilder (VPB) is an OSG tool that generates native OSG data to represent terrain, usually by draping a GEO-TIFF over an elevation model.
The VPB project and code can be found here: https://github.com/openscenegraph/VirtualPlanetBuilder
If you've got an existing FlightGear build, there are some additional dependencies:
- Including NVTT. ('sudo apt-get install libnvtt-dev' - oddly VPB builds without it but then checks for the shared library at runtime...)
- GDAL (https://gdal.org/), Note that this needs to 2.4.X
- ... which requires PROJ 6 or above (https://proj.org/)
- ... which requires the sqlite3.11 or above development package (on linux - 'sudo apt-get install libsqlite3-dev')
- ... which requires PROJ 6 or above (https://proj.org/)
Note that GDAL and PROJ do not use cmake, so it builds in the source directory as follows:
./configure -prefix=/path/to/install make
VPB is built using cmake e.g.
cmake -DOSG_DIR=/path/to/OSG/install /path/to/VPB/src make
Getting Landcover Data
For CORINE data covering Europe, try here: https://land.copernicus.eu/pan-european/corine-land-cover/clc2018
For US National Landcover Database (NLCD) try here: https://www.mrlc.gov/viewer/
Choose RASTER data, which will download a geo-referenced TIF image.
Note that the mapping from landcover to materials is performed in Materials/base/landclass-mapping.xml, and currently only maps CORINE landclasses.
Getting DEM data.
The most commonly used Digital Elevation Model used is SRTM.
SRTM with 90m resolution is available here: http://srtm.csi.cgiar.org/
SRTM with 30m resolution is available here: https://lpdaac.usgs.gov/products/nasadem_hgtv001/ (Directory , Interactive search by selecting areas or points: example . To download you need a free account from here)
VPB accepts both raster and HGT files.
LoD, Mesh size and Framerate
Unlike WS2.0 which has a fixed terrain mesh, VPB provides a variety of settings that have a big impact on the eventual terrain mesh. The two main settings (the number of LoD levels, and the ratio of the LoD radius and maximum visible range), have a huge impact on the number of vertices, how the terrain looks, LoD "popping", and framerate.
To attempt to understand the relationship, a test was performed. WS30 terrain was generated for a 2x2 degree section of the European Alps bounded by (7E, 45N), and (8E, 47N), with settings as listed below. FlightGear was then run on a desktop with an NVidia GeForce GTX 1660 with 6GB of VRAM. The system appeared I/O limited as GPU utilization was around 30% and on 2GB of VRAM was used.
The following commandline options were used to place the ufo just to the NE of the Matterhorn, facing SW.
--aircraft=ufo --timeofday=morning --disable-real-weather-fetch --disable-ai-traffic --disable-random-objects --disable-random-vegetation --altitude=15000 --prop:/scenery/use-vpb=true --disable-sound --disable-ai-models --prop:/sim/rendering/texture-cache/cache-enabled=false --lat=46.021023 --lon=7.728291 --altitude=12662.75 --heading=226.0
|Dem Resolution||LoD Levels||Radius to max visible distance ratio||Lowest LoD Radius (km)||Highest LoD Range (km)||Lowest LoD Range (km)||Vertices in view||Triangles in view (M)||Framerate (M)||Frame Latency (ms)|
(a) - Using these settings there was a noticeable reduction in apparent heightmap resolution with a 30m DEM, probably because the resolution of the lowest LoD level was ~40m, compared with 20m for an 7 LoD level mesh.
(b) Using these settings, the terrain resolution was unacceptably poor.
These results suggest that using 7 LoD Levels and a radius of "3" will provide a good balance, with high terrain quality and good frame-rate.
FlightGear expects scenery in 1x1 degree tiles in a slightly different format to WS2.0. The scenery needs to be in a "vpb" directory, followed by a directory structure similar to WS20 (10x10, then 1x1 degree directories), with the final file being a 1x1 degree section with a "ws_" prefix, and in the ".osgb" format. E.g. vpb/w010n50/w004n50/ws_w004n50.osgb
Here are the options I've used to generate some scenery of the UK:
./bin/osgdem --TERRAIN \ --compressor-nvtt \ --compression-quality-highest \ --no-interpolate_imagery \ --disable-error-diffusion \ --geocentric \ -t /home/stuart/FlightGear/VPB/data/CORINE/u2018_clc2018_v2020_20u1_raster100m/DATA/U2018_CLC2018_V2020_20u1.tif \ -d /home/stuart/FlightGear/VPB/data/SRTM90/srtm_34_02.tif \ -d /home/stuart/FlightGear/VPB/data/SRTM90/srtm_35_01.tif \ -d /home/stuart/FlightGear/VPB/data/SRTM90/srtm_35_02.tif \ -d /home/stuart/FlightGear/VPB/data/SRTM90/srtm_36_01.tif \ -d /home/stuart/FlightGear/VPB/data/SRTM90/srtm_36_02.tif \ -b -4 50 -3 51 \ --PagedLOD \ -l 7 \ --radius-to-max-visible-distance-ratio 3 \ -o vpb/w010n50/w004n50/ws_w004n50.osgb
- --TERRAIN to use osgTerrain::Terrain database
- --compressor-nvtt --compression-quality-highest to generate native DDS mipmaps
- --geocentric because that's what FG uses
- -t the texture to drape (in this case CORINE)
- -d the DEM to use (in this case pieces of SRTM90)
- -b is the extents in decimal degrees: LON1 LAT1 LON2 LAT2, in this case from (-4,50) to (-3,51)
- --PagedLOD to generate PagedLOD nodes
- -l 4 the number of LOD levels to generate. At the equator, a 1x1 degree tile has a 157km diagonal. The LoD follows a quad-tree like structure, with each LOD level having 4 sub-tiles in a 2x2 array. If we want our smallest tile to have a ~10km diagonal, we need 4 LoD levels
- --radius-to-max-visible-distance-ratio is self-explanatory. We want the lowest level of LoD to be visible 20km away, so a ratio of 5 is appropriate.
- -o is the output file, in this case native OSG binary format. FG expects WS3.0 data in a vpb subdirectory, with the structure shown.