Earthview: Difference between revisions

The default FlightGear terrain rendering strategy is designed for visuals from aircraft cruise altitude. While it is [http://www.flightgear.org/tours/pushing-the-boundaries-the-x-15-story/ possible] to use it for altitudes up to some 100 km, the performance impact becomes increasingly prohibitive and the visuals are not overly compelling. In particular for orbiting spacecraft such as [[Vostok-1]] or the [[Space Shuttle]] or even the [[UFO]], neither rendering nor loading the standard terrain mesh is fast enough.

== Overview ==

The main requirement (especially if custom hires textures are used) is available memory and GPU texture memory. All textures are split into eight tiles, four for the northern hemisphere (N1 to N4), and four for the southern hemisphere (S1 to S4) and each tile is loaded, or unloaded, according to visibility. As such, GPU memory is efficiently used and limited graphic card memory should not be an issue for the default texture size. However, the loading of a texture tile induces some bottleneck and FG may hang for a couple of seconds, or more (depending on tile resolution), while the texture appears.  

With the maximum resolution textures (16384x16384 pixels for a world tile and 8192x8192 pixels for a cloud and a normalmap tile), expect a minute or more for the loading, around 6GB of GPU memory and 16GB of RAM to be filled. If you can afford it, there will be no other loading bottleneck afterwards. These numbers can accordingly be lowered using lower resolution tiles.

To get full advantage of Earthview, and your graphic card, you may install and use your own high resolution tiles as well as normal maps having a alpha channel to trigger parallax mapping.

==== Texture generation ====

There are two ways to obtain these textures:

* The easy way

When our resources allow for it, some users generate these textures and make them available for download. They may be obtained via torrent with this magnet link:

and may also be available for download at this url:

* The interesting way

Most likely the easy way is no longer available, or you are curious. Chris_Blues made a wonderful Bash-script that will download the NASA images and do the texture generation for you, in the correct way. It is available on github, together with the instructions on how to use it:

 

 

 

 

NASA provides different seasons available for the Earth images, even one per month. [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] allows you to chose the month for which you want to generate your set of tiles.

 

Graphics cards prefer powers of two in texture sizes, so [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] resizes the tiles to 1024x1024, 2048x2048, 4096x4096, 8192x8192 or 16384x16384 pixels. Be aware of the original image resolution, there is no much gain into using a super-sampled tile. For instance, the current cloud maps provided by NASA have a resolution of typically 10000 pixels. Using 8192x8192 sampling is the best option, the gain of super-sampling it at 16384x16384 is very small.

 

 

 

The texture tiles loaded by Earthview reside in

 

 

where $FGData depends on the installation path of flightgear-fgdata. If you only want to use "png" texture tiles, simply replace all the '''world_*.png''', '''clouds_*.png''' and '''normalmap_earth_*.png''' files by your own.

 

If you want to use "dds" mipmapped images, then you have to edit a few "ac" files to tell Earthview to use them. These configuration files reside in

 

  $FGData/Models/Astro

 

and are

 

 

On Unix systems, the program '''sed''' is your friend (but make a backup before).

 

It is possible to assign any image you fancy to be used as a tile by Earthview. For this, you can edit the file '''earth_unitscale_rawuv.ac''' to load your images, and edit '''earth.xml''' such that it points to your just edited 3d model via <path>earth_unitscale_rawuv.ac</path>. You can do the same for '''cloudsphere.xml'''. However, assigning textures in this manner, as they are to the "rawuv" sphere, creates visible seams where the texture sheets end. This is particularly visible if parallax mapping is rendered as the computation requires shifting the textures over the sphere.

 

The solution is to add margins that encompass a bit of the neighbouring tiles. This is what [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] is doing (as well as the texture set provided). These bordered tiles don't use '''earth_unitscale_rawuv.ac''' but instead '''earth_unitscale_hires.ac''', which is the default (see [https://forum.flightgear.org/viewtopic.php?f=6&t=15754&start=135#p207629 this forum post] for the original discussion). In other words, if you use [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] to generate your own textures, you do not need to change '''earth.xml''' nor '''earth_unitscale_rawuv.ac''', but you should still edit '''earth_unitscale_hires.ac''' if you want to use dds tiles.

 

 

* Since there is no limit to customization, and if you can afford 50GB of disk space, you can create a whole set of directories containing Earth textures for each month of the year, as for instance:

 

 

 

  MONTH=$(date +%B)

 

 

* You may also fancy textures from other celestial bodies, as for instance the Moon. Textures generator available here [https://github.com/eatdust/LROC2FGearthview LROC2FGearthview] and shaders there [https://github.com/eatdust/moonshaders moonshaders].