From FlightGear wiki
Jump to: navigation, search

The default FlightGear terrain rendering strategy is designed for visuals from aircraft cruise altitude. While it is 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 neither rendering nor loading the standard terrain mesh is fast enough.

Earthview is an alternative orbital rendering engine for FlightGear designed to get credible visuals in these situations. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. The quality of the terrain visuals then largely depend on the texture size used. Since there is then only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.



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

Earthview 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

'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 there is a much lower texture resolution distributed in FGData as the highest resolution set has eight textures sheets of 172 MB each which would double the current repository size. It is however easily possible to obtain the textures from the NASA website and apply them.

At highest texture resolution, visuals are generally very compelling:

Low orbit High orbit

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:

Cloud shadows in Earthview Specular water reflections and cloud shadows in Earthview

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):

X-15 over Iceland X-15 in space


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 (this is not an issue for the default texture size). Provided there is sufficient texture memory available, loading the texture sheets is another bottleneck and FG may hang for a couple of seconds while the textures appear.

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.

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.


Getting your own hires version of textures requires a few simple steps:

Note  You can skip the next 2 steps ("obtain a texture set" and "convert the texture set") and download the ready-to-use files here:
  • 8192x8192 7z-zipped: world (361.6MB) - clouds (212.8MB)
  • 16384x16384 7z-zipped: world dds (~310MB) - world png (~1GB) (Warning: Requires much more than 1GB Graphics RAM - FG crashes on my machine with 1GB GRAM)

Or you could get yourself this Bash-script to let it do the generation for you:

  • obtain a texture set

Go to Visible Earth, look into the Blue Marble section and download a texture set of your choice (there's different seasons available for instance).
Alternatively, you can download the complete set of textures here (this server is much faster!) (500MB) (500MB) (500MB) (500MB) (200MB)

In a bash, you could get it all with the following one-liner:

for p in 1 2 3 4 5 ; do wget$p -c -O raw-data-NASA.7z ; done

NASA typically delivers the hires textures with naming conventions N1 - N4 (northern hemisphere) and S1 - S4 (southern hemisphere) and Earthview follows that convention.

  • convert the texture set

Graphics cards prefer powers of two in texture sizes, so you probably want to resize the sheets to either 8192x8192 or 16384x16384. At the same time, you might want to save them in pre-compressed and mip-mapped dds format (this may require a gimp plugin) for better loading times. Do this on a machine with plenty of memory, as the graphics program may need a lot in intermediate stages.

  • assign the texture sheets

Look into $FGData/Models/Astro - this is where Earthview resides. The current texture sheets are pale_blue_aug_??.png and clouds_??.png where ?? stands for the NASA position reference.

The simple way is to assign your texture to (then they can be used 'as is'). It's easiest to open the file with the text editor, look for the lines like texture "pale_blue_aug_N1.png" and replace them with your own N1 texture. Then open earth.xml and point to your just edited 3d model via <path></path>. Do the same for cloudsphere.xml (it's entirely possible to do all this in a 3d modeling application like blender, but chances are it will get rather slow and unwieldy for such huge texture sheets).

Assigning textures as they are to the rawuv sphere creates visible seams where the texture sheets end. The solution is to add margins (like done for the texture set provided). If you edit your textures to add such margins, you don't need to use and can assign your textures to (see this forum post for the details of creating such textures)

For comparison, a 16384x16384 texture sheet in pre-compressed and mip-mapped dds format should come to 341 MB. Unless you have a substantial amount of memory, consider using less than full resolution, since you always need 4 of these textures loaded into graphics memory, and 8 if you also switch on clouds.


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.


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.