Earthview: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(35 intermediate revisions by 2 users not shown)
Line 40: Line 40:


Earthview can also render Aurora Borealis seen from space.
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):
[[File:X-15-iceland05.jpg|450px|X-15 over Iceland]] [[File:X-15-iceland03.jpg|450px|X-15 in space]]


== Requirements ==
== Requirements ==
Line 54: Line 58:


Getting your own hires version of textures requires a few simple steps:
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:
* 1024x1024 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_1k.7z world] (7.5MB) - [https://musicchris.de/download/FG/EarthView/clouds_1k.7z clouds] (5.2MB)
* 2048x2048 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_2k.7z world] (27.3MB) - [https://musicchris.de/download/FG/EarthView/clouds_2k.7z clouds] (18.9MB)
* 4096x4096 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_4k.7z world] (99.5MB) - [https://musicchris.de/download/FG/EarthView/clouds_4k.7z clouds] (64.4MB)
* 8192x8192 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_8k.7z world] (361.6MB) - [https://musicchris.de/download/FG/EarthView/clouds_8k.7z clouds] (212.8MB)
* 16384x16384 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_16k_dds.7z world] dds (~310MB) - [https://musicchris.de/download/FG/EarthView/world_16k_png.7z 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: https://github.com/chris-blues/Nasa2FGearthview}}


* obtain a texture set
* obtain a texture set
Go to [http://visibleearth.nasa.gov/ Visible Earth], look into the Blue Marble section and download a texture set of your choice (there's different seasons available for instance).
Go to [http://visibleearth.nasa.gov/ Visible Earth], look into the Blue Marble section and download a texture set of your choice (there's different seasons available for instance).<br />
Alternatively, you can download the complete set of textures here (this server is much faster!)
 
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.001 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.002 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.003 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.004 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.005 (200MB)<br />
 
In a bash, you could get it all with the following one-liner:
<syntaxhighlight lang="bash">for p in 1 2 3 4 5 ; do wget https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.00$p -c -O raw-data-NASA.7z ; done</syntaxhighlight>
 


NASA typically delivers the hires textures with naming conventions N1 - N4 (northern hemisphere) and S1 - S4 (southern hemisphere) and Earthview follows that convention.
NASA typically delivers the hires textures with naming conventions N1 - N4 (northern hemisphere) and S1 - S4 (southern hemisphere) and Earthview follows that convention.
Line 72: Line 101:
and replace them with your own N1 texture. Then open earth.xml and point to your just edited 3d model via <path>earth_unitscale_rawuv.ac</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).
and replace them with your own N1 texture. Then open earth.xml and point to your just edited 3d model via <path>earth_unitscale_rawuv.ac</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 <b>earth_unitscale_rawuv.ac</b> and can assign your textures to <b>earth_unitscale_hires.ac</b>
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 <b>earth_unitscale_rawuv.ac</b> and can assign your textures to <b>earth_unitscale_hires.ac</b> (see [https://forum.flightgear.org/viewtopic.php?f=6&t=15754&start=135#p207629 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 172 MB. Unless you have a substantial amount of memory, consider using less than full resolution.
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.


== Implementation ==
== Implementation ==
{{FGCquote
|1= Have you wondered why you can't see the terrain when you switch EarthView on? That would be because the EarthView sphere is neither where you think it is, nor as large as you think it is.
In actual reality of rendering geometry, the sphere has a radius of ~58 km and when you are at an altitude of 30.000 ft, it is only 100 m away from you. You don't realie any of this of course since the sphere is constantly repositioned. The reason that is done is because the renderer works with floating point precision, the internal unit is meters, and if you throw a distance of 6 million meters at it, all you get back is numerical garbage. For that reason, there's a far clipping distance in FG which does not render anything beyond a default of 120 km.
The fogging of the EarthSphere is likewise based on the assumption that you see a 10 km think layer of atmosphere from above, not that you're inside an atmosphere with varying aerosol density - it would never match atmosphere fog properly.
There's in fact nothing wrong with the way the horizon is created as long as you don't set a visibility exceeding the LOD bare and far camera clipping range.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=219172#p219172
  | title  = <nowiki>Re: Problem in the Atmospheric Light Scattering (ALS)</nowiki>
  | author = <nowiki>Thorsten</nowiki>
  | date  = Sep 23rd, 2014
  | added  = Sep 23rd, 2014
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= Real-time 3d rendering generically is not about rendering things as they really are, but rendering something that looks on screen like it would really be there. If you look into the details of how FG builds the sky, skydome, sun and moon most definitely are not real objects, neither are clouds, and there's very good reason for that.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=268501#p268501
  | title  = <nowiki>Re: Su-15</nowiki>
  | author = <nowiki>Thorsten</nowiki>
  | date  = Dec 14th, 2015
  | added  = Dec 14th, 2015
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= that's what real time 3d rendering is all about - since in the end it's all colors of screen pixels, it doesn't matter what the data structure behind is as long as the screen pixels look as they should. Which is why good design here is to use a fast-performing fake rather than a slow more real thing which looks practically the same on-screen.
EarthView is rendering Earth at the 'base level of the simulation' - it's an object in the scenegraph just like any other object, including the terrain mesh or your aircraft model. It's all the same - long lists of vertices with textured triangles and associated statesets. All that counts is updates the framebuffer fastest. Pixels on screen is all the reality there is to real time rendering.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=262559#p262559
  | title  = <nowiki>Re: Su-15</nowiki>
  | author = <nowiki>Thorsten</nowiki>
  | date  = Nov 1st, 2015
  | added  = Nov 1st, 2015
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= There is nothing underneath Earthview when used in orbit.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=262568#p262568
  | title  = <nowiki>Re: Su-15</nowiki>
  | author = <nowiki>Thorsten</nowiki>
  | date  = Nov 1st, 2015
  | added  = Nov 1st, 2015
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= Earthview's idea of a low visibility is &gt;80 km after all - and when it's not running (which it isn't between sessions, because you always have to start it by hand) the weather system of your choice writes visibility.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=237951#p237951
  | title  = <nowiki>Re: low visibility after trying </nowiki>
  | author = <nowiki>Thorsten</nowiki>
  | date  = Apr 5th, 2015
  | added  = Apr 5th, 2015
  | script_version = 0.23
  }}
}}


{{FGCquote
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.
|1= even Nasal-level code will end up calling C++/OSG code - which is why EarthView is using native OSG code, unlike PUI, the HUD code or the 2D panels code - in other words, using Nasal like this can even be superior to hard-coded routines in the main loop, which are now crippling the OpenGL experience for other subsystems (just look at all the AMD/ATI related rendering issues due to PUI code that interacts with some other effects/shaders).
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=262570#p262570
  | title  = <nowiki>Re: Su-15</nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Nov 1st, 2015
  | added  = Nov 1st, 2015
  | script_version = 0.23
  }}
}}


{{FGCquote
Compared to almost anything else, the performance impact of re-positioning the sphere every frame is minimal.
|1= using workarounds in Nasal space like EarthView, or overlapping efforts like ALS/AW: Nasal is there for a reason, it is used by people whose interests may be outside of core development - just look at bombable.
Under the hood, these "workarounds" still end up calling native C/C++ code at some point, and the people developing such workarounds will accumulate tons of experience along the way, experience that will also be applicable elsewhere, including native code (core development)
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=262557#p262557
  | title  = <nowiki>Re: Su-15</nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Nov 1st, 2015
  | added  = Nov 1st, 2015
  | script_version = 0.23
  }}
}}


{{FGCquote
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.
|1= the renderer doesn't know or care where vertices come from - the renderer is always the same, and EarthView replaces the terrain mesh by a textured sphere
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=262568#p262568
  | title  = <nowiki>Re: Su-15</nowiki>
  | author = <nowiki>Thorsten</nowiki>
  | date  = Nov 1st, 2015
  | added  = Nov 1st, 2015
  | script_version = 0.23
  }}
}}


{{FGCquote
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.
|1= You might want to make a gradual transition in which details disappear as we get higher rather than replacing everything at once - that's the LOD system mentioned - and that's something which is currently worked on - but the end result in orbit will be a photo-textured sphere - because that's the only thing which makes any sense. Do you honestly think e.g. Outerra does not use a textured sphere from orbit?
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=262568#p262568
  | title  = <nowiki>Re: Su-15</nowiki>
  | author = <nowiki>Thorsten</nowiki>
  | date  = Nov 1st, 2015
  | added  = Nov 1st, 2015
  | script_version = 0.23
  }}
}}


{{FGCquote
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.
|1= Thorsten's approach for implementing the EarthView addon is sufficiently generic to also implement other celestial bodies like this - scenery itself is a different matter though, but the TerraGear tool chain will process pretty much any elevation data you throw at it and try to turn it into scenery (DEM for Mars being freely available)
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=250154#p250154
  | title  = <nowiki>Re: Planets</nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Jul 7th, 2015
  | added  = Jul 7th, 2015
  | script_version = 0.23
  }}
}}


== Development ==
== Development ==
{{FGCquote
|1= There's plenty of ways in which Earthview and FG could be merged into a smoother experience and I'll probably go there again eventually, but I can't really say this justifies urgent action or by itself makes a huge difference. So I'll get to it eventually, but not with high priority.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=231896#p231896
  | title  = <nowiki>Re: FG 3.4 RC2</nowiki>
  | author = <nowiki>Thorsten</nowiki>
  | date  = Feb 11th, 2015
  | added  = Feb 11th, 2015
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= This code may only reach the official repositories if the directional moonlight experiment works, or if these is some interest in using this information (for example for those who are interested in reaching the stars).
The next step is to learn about the fascinating world of the FlightGear renderer:
* https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/renderer.cxx
* https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/renderer.hxx
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=268817#p268817
  | title  = <nowiki>Re: Implementing moonlight (or not)</nowiki>
  | author = <nowiki>bugman</nowiki>
  | date  = Dec 16th, 2015
  | added  = Dec 16th, 2015
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= given that there is so much interest in spacefllight recently, it would be cool to work out what else may end up being useful sooner or later if exposed at the property tree level, i.e. to support earthview-like approaches, without having to re-implement/work around rendering logic that already resides elsewhere - even if that just means making things better configurable (or entirely optional using dedicated draw masks), while providing for a seamless transition between the corresponding approaches
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=269035#p269035
  | title  = <nowiki>Re: Implementing moonlight (or not)</nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Dec 17th, 2015
  | added  = Dec 17th, 2015
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= You got my 'reaching for the stars' reference :D  The code I'm looking at is a few of the key parts of what needs to be adapted for landing on the moon!  The ephemeris code, the lighting code, and the osg scene set up in the FG renderer.  I was thinking of exactly what needs to be done for a moon landing (or orbit) as I was looking at all of this.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=269042#p269042
  | title  = <nowiki>Re: Implementing moonlight (or not)</nowiki>
  | author = <nowiki>bugman</nowiki>
  | date  = Dec 17th, 2015
  | added  = Dec 17th, 2015
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= I've been wondering how to reduce the memory footprint of Earthview - which, if you customie it with full resolution Pale Blue Marble which come to eight textures a 21000x21000 pixels each, is an issue even when using compressed dds. Even in the current form with 4096x4096 sheets, loading times are an issue (and I've been toying with allowing simply pre-load everything upon aircraft startup based on a config flag). I've toyed with a select animation showing only the texture sheets currently used (basically, given the local horizon from low orbit, in the worst case you can see 4 texture sheets at the same time, often just a single one). However, upon trying that, it seems the whole model, including de-selected sheets, is loaded anyway. I only found that re-loading improved quite a bit. So things appear to end up in a cache no matter what. So, is there a graceful way to load only the parts of the model / the textures I currently want to show? Or should I just trust the cache to optimize things for me and not worry?
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34579255/
  | title  = <nowiki>[Flightgear-devel] Texture memory management</nowiki>
  | author = <nowiki>Thorsten Renk</nowiki>
  | date  = Oct 29th, 2015
  | added  = Oct 29th, 2015
  | script_version = 0.23
  }}
}}


{{FGCquote
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.
|1= I've been making some progress with rendering from orbit http://users.jyu.fi/~trenk/pics/earthview_new12.jpg but I'm still trying to wrap my head around what the sky does. Is there anyone who understands what I am seeing? My Windows binary of ~ a month ago shows the skydome below 310.000 ft or so, then exits it and I see fog-grey. Then comes aone of red sky (which is a rendering artefact caused by the lack of atmosphere definition, the added layer patch is not yet in this binary) but up at 1.000.000 ft, I actually get to see black skies and even sometimes stars come out when the sun is below the horizon(!). My Linux binary of 3 days ago shows fog grey all the way up from 310.000 ft to as far as I tested - no red (as expected since this was fixed), but also no black and no stars. So there is a beautiful starry sky implemented somewhere, and it'd be nice to just use it. Does anyone understand what precisely we render at high altitude and where the starry sky comes from, and can we somehow always render it above 300.000 ft? Alternatively I could give Earthview its own star sphere (to be textured freely...), but then that might hide sun and moon from the view, I don't recall where they are physically located, and having a working moon in the sky is definitely a nice feature. I realize that this is a bit of an exotic use of FG and probably not so many people want to do spaceflight, but if there's a simple way to get a nice night sky at high altitude, I would much appreciate some help.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/32291826/
  | title  = <nowiki>[Flightgear-devel] Nightsky</nowiki>
  | author = <nowiki>Renk Thorsten</nowiki>
  | date  = May 2nd, 2014
  | added  = May 2nd, 2014
  | script_version = 0.23
  }}
}}


{{FGCquote
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.
|1= I've been interested in extending Flightgear to low earth orbit and beyond for quite some time (my last crude attempt was at version 1.9...) , and agree with psadro_gm and Zan that a LoD-Terrain engine is one of the crucial steps to this goal.
Vitos, fixing the immediate rendering issues (i think Thorstens shaders might just do that) will not give you more than a foggy sphere. Loading as many tiles as you could see even from LEO in full detail is probably prohibitively memory-expensive, so a LoD system would be necessary. Putting a textured sphere under the geometry would work in first approximation, but i think it would lead to very harsh transitions between it and the detailed normal terrain.
My dream would be extending the terrain engine to work seamlessly from ground to geostationary, and produce beautiful views at every step. I realie that this is a multi-year effort. However, looking at the recent improvement in graphics and consolidation, both with the weather shaders and Rembrandt, i have now hope that it can be achieved eventually. I am particularly happy with Rembrandt, since I feel that several shader issues that would lead to horrible problems at high altitudes have now been decoupled from each other.
I'll try to get up to speed by testing out the Rembrandt branch and Thorstens shader changes, and maybe see if I can rudimentarily make them work together - the faster these two projects get into mainline, the less effort is wasted by duplicating or fixing old shaders. Next, I'd like to help with the terrain engine - trying to reach the south pole in flight gear has left me frustrated recently :/ .
I have quite some professional C++ experience and working knowledge of OpenGL, so I hope I will be able to contribute. On the other hand, I should really finish my thesis, so i might only really get fully into development for some months.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=148048#p148048
  | title  = <nowiki>Re: New Flight Gear Terrain Engine</nowiki>
  | author = <nowiki>SiriusGrey</nowiki>
  | date  = Jan 19th, 2012
  | added  = Jan 19th, 2012
  | script_version = 0.23
  }}
}}

Revision as of 21:57, 27 July 2016

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.


Overview

Menubar2.jpg

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

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 (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.

Customization

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: https://github.com/chris-blues/Nasa2FGearthview

  • 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!)

https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.001 (500MB)
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.002 (500MB)
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.003 (500MB)
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.004 (500MB)
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.005 (200MB)

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

for p in 1 2 3 4 5 ; do wget https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.00$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 earth_unitscale_rawuv.ac (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>earth_unitscale_rawuv.ac</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 earth_unitscale_rawuv.ac and can assign your textures to earth_unitscale_hires.ac (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.

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.