Earthview

Overview

Earthview is started from the menu as View -> Earthview Orbital Rendering. This brings up the configuration dialog.

The options checkboxes allow to select

whether a cloud layer should be rendered above the planet
whether the cloud layer information should be used to render cloud shadows onto the terrain
whether Earthview should take control of the atmosphere visuals and adjust them based on altitude
whether textures should be procedurally enhanced with overlay textures to provide better apparent texture resolution
whether textures should be rendered with lighting based on a normal map. Parallax effects are also computed if the normal map contains an alpha channel encoding the inverse height of the Earth's relief
whether clouds should be rendered with lighting and parallax effects. These are computed using the alpha channel of the cloud map as an input information of their vertical extension

'Start' run Earthview, 'Stop' ends the computations and removes the 3d model. Generally, using Earthview below an altitude of ~30 km / 100.000 ft is not recommended and will almost certainly not give the desired visuals.

Sliders further down can be used to adjust details. For instance, if no cloud shadows are rendered, it is possible to rotate the cloud sphere around Earth and give different places different weather (otherwise, the cloud pattern will always be the same, i.e. if a place is obscured by clouds initially, it will always be). Using Rayleigh, Mie and Density, atmosphere visuals (if Atmospheric light scattering (ALS) is on) can be adjusted. Visibility dials the amount of fogging seen on the planet.

Earthview runs without ALS, but does not provide any credible visuals of the Atmosphere.

If atmosphere visuals are rendered, Earthview interacts with the weather system in that the visibility used by Earthview and by the weather system will be the same. In the case of Advanced Weather (AW) this is an issue because both systems try to adjust atmosphere visuals. For this reason, AW needs to be ended before Earthview is started. There is no general option to do this automatically, but an automatic transition from default FG rendering and weather to Earthview is easily coded spacecraft side and implemented for the Space Shuttle.

All textures are taken from the NASA Visible Earth project - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 x 500 m per pixel) and clouds with half of that. Currently, due to size concern, all the textures distributed in FGData are of low resolution (2048p x 2048p per tile) and do not incorporate the alpha channel encoding the height. Parallax mapping for ground textures is therefore disabled. It is however possible to obtain the textures from the NASA website, process them and straightforwardly use them as a replacement. More detailed instructions to do so are given below in the section "Customization".

At highest texture resolution, visuals are generally very compelling:

A dedicated set of shaders for Earth and the cloudsphere is used to create additional effects such a enhanced specular water reflections, cloud shadows and dawnlight color changes:

Earthview can also render Aurora Borealis seen from space.

For comparison, this is the FG native terrain tweaked to render with 600 km visibility from 100 km altitude (bringing a gaming laptop to 10 fps in the process):

Requirements

Since there is no detailed terrain mesh involved and there is essentially just a single textured sphere in the field of view, performance is generally excellent even on low end graphics cards.

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.

Where this is feasible and supported by the GPU drivers, pre-compressed and mipmapped dds textures offer the fastest loading times. As such textures can not be used with many OpenSource graphics drivers, the default textures are not in dds format, but these can be generated along the lines discussed in the "Customization" section.

For high-end graphic cards, it is possible to actually force the loading of all texture tiles at once when Earthview starts. This is triggered with the command line option:

 --prop:/earthview/show-force-all=true

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.

Finally, while it is possible to use Earthview in rendering schemes other then ALS, this is neither supported nor endorsed. While they work perfectly well for the normal operations envelope of a flightsim, at high altitude the default renderer as well as Project Rembrandt do not render a realistic horizon line, plausible atmosphere visuals or the hard shadows of outer space and Earthview can not compensate for these issues. As such, when using the Compositor as the rendering pipeline, it is compulsory to default it to ALS, this is triggered on the command line by appending:

  --compositor=Compositor/als

Customization

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:

   magnet:?xt=urn:btih:6df05a15c863040fd31278dfd1f719523b639cf2&dn=EarthView.World.August-2020.06

and may also be available for download at this url:

   Earthview/

A bash script to automatically download the full per-month data from above url is available here. It downloads the dataset for every month, or it symlinks a dataset for a specified month into a specified place, see help of the script (run without arguments or with '-h'). To choose which resolution(s) to download or which image file format(s) to download the variables in the script needs to be edited. Needs an unix environment with bash and wget.

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:

   Nasa2FGearthview

This program can generate world, clouds and normal maps with height data included in the alpha channel, and at various resolutions ranging from 1024x1024 to 16384x16384 pixels.

Remarks

Notice that all the input images are provided by NASA and any usage of the textures should be made in accordance with their distribution policy. They are directly accessible for download at Visible Earth, look into the Blue Marble section and search for a texture set of your choice.

NASA provides different seasons for the Earth images, even one set of images per month. 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 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. Similar thing holds true for heights and normalmaps (16384x16384 for them is also supersampled, so prefer at most 8192x8192 for them).

Installing and using customized textures

The texture tiles loaded by Earthview reside in

  $FGData/Models/Astro/Textures

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

 earth_*.ac

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

Remarks

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 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 this forum post for the original discussion). In other words, if you use Nasa2FGearthview to generate your own textures, you do not need to change earth.xml nor earth_unitscale_rawuv.ac. Notice that you still need to edit earth_unitscale_hires.ac (and the rest of the earth_*.ac) if you want to use dds tiles!

Open tips

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:

  EarthView.World.January-2020.06/
  EarthView.World.February-2020.06/
  ...

On linux, a simple "cron" job can automatically link the content of one of these directories to $FGData/Models/Astro/Textures/, like this one:

  #!/bin/bash
  TEXTUREDIR="/usr/share/games/flightgear-extra/Models/Textures"
  TIMESTAMP="2020.06"
  MONTH=$(date +%B)
  WORLDRES="16384"
  echo "Going to: $TEXTUREDIR"
  cd $TEXTUREDIR
  echo "Linking world textures of: $MONTH"
  ln -s -f ../EarthView.World.${MONTH}-${TIMESTAMP}/${WORLDRES}/world_*.dds .
  ln -s -f ../EarthView.World.${MONTH}-${TIMESTAMP}/${WORLDRES}/world_*.png .
  echo "done"

And you'll be flying Earth with textures matching the current month!

You may also fancy textures from other celestial bodies, as for instance the Moon. Textures generator available here LROC2FGearthview and shaders there moonshaders, see the original discussion on the forum viewtopic.php?f=87&t=15754&start=375#p369043.

Implementation

Technically, Earth is rendered as a ~58 km sized sphere positioned 1/100 of the actual altitude away from the spacecraft. It's position is constantly adjusted to give the same visual size using ray optics equations, and its attitude is rotated to place you 'above' the correct latitude and longitude. For 100 km altitude, the camera is thus actually just 1000 m away from the sphere.

Compared to almost anything else, the performance impact of re-positioning the sphere every frame is minimal.

The reason is that graphics cards operate with floating point precision, and a sphere with the real size of Earth would create (potentially architecture dependent) massive numerical problems (the default far plane clipping distance in FG is some 120.000 m). The same is in fact true for the skydome - it's actually a half dome some 20 km away from the camera, made to appear behind everything else by rendering magic. Or, in other words, we can't simply render a 'real earth' and a 'real atmosphere' because that would potentially overtax the GPU - real time rendering is always trickery of some sort.

The implementation has the negative consequence that you may not move the view point too far from the spacecraft (the ray optics illusion works for one object, but not for two simultaneously) - in particular flyby view or tower view will give you odd results with Earthview.

The real terrain engine is not technically switched off, but (assuming normal visibility settings) the terrain mesh is just too far to trigger either tile loading or rendering - as you get back from orbit, the terrain will load underneath Earthview, and if you end it at a reasonable altitude (say between 80.000 and 120.000 ft) you can go right back to the native FG terrain with minimum fuss.

Development

Earthview in its current state isn't perfect, for instance in low light it may produce mismatches with the atmosphere shader (as it's fogging model is not precisely the same, and the numerics of the projected Earth sphere doesn't always match what the atmosphere shader computes as horizon). For that reason, its visuals are developed further, but the priority is in general low as by and large the goal to have viable spaceflight visuals is met.

Over the years, there have been diverse proposals for alternative ways to render orbital visuals in a way that is more integrated with FG - the only viable alternative that has actually materialized so far seems to be Building FlightGear with osgEarth Integration, however this lacks atmosphere visuals.