Earthview: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (try to be understandable?)
(46 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{See also|Flying on other planets}}
{{See also|Flying on other planets}}


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]] neither rendering nor loading the standard terrain mesh is fast enough.
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.


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


{{Spaceflight}}
{{Spaceflight}}
=== Overview ===
== Overview ==
[[File:menubar2.jpg|517px]]
[[File:menubar2.jpg|517px]]


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


[[File:Earthview.jpg|thumb|Earthview configuration dialog]]
[[File:Earthview menu.jpg|thumb|260px]]




Line 20: Line 20:
* whether Earthview should take control of the atmosphere visuals and adjust them based on altitude
* 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 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.
'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.
Line 29: Line 31:
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 [[A local weather system | 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.
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 [[A local weather system | 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 [http://visibleearth.nasa.gov/ 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.
All textures are taken from the [http://visibleearth.nasa.gov/ 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:
At highest texture resolution, visuals are generally very compelling:
Line 40: Line 42:


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 45: Line 51:
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.
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.  
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.


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


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 ==
== Customization ==


Getting your own hires version of textures requires a few simple steps:
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:ffd18abf3bd98ee761babc09d7c901ea1ce0c78f&dn=EarthView%20-%20Complete
 
and may also be available for download at this url:
 
    [https://curl.irmp.ucl.ac.be/~chris/upload/fg/earthview/ /earthview/]
 
* The interesting way


* obtain a texture set
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:
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).


NASA typically delivers the hires textures with naming conventions N1 - N4 (northern hemisphere) and S1 - S4 (southern hemisphere) and Earthview follows that convention.
    [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview]


* convert the texture set
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.


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.
* Remarks


* assign the texture sheets
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 [http://visibleearth.nasa.gov/ Visible Earth], look into the Blue Marble section and search for a texture set of your choice.


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.  
NASA provides different seasons for the Earth images, even one set of images 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.


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
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.
<b>texture "pale_blue_aug_N1.png"</b>
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>


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.
==== Installing and using customized textures ====


== Implementation ==
The texture tiles loaded by Earthview reside in
{{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.  
  $FGData/Models/Astro/Textures
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.
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.
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
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
  | url    = http://forum.flightgear.org/viewtopic.php?p=219172#p219172
 
  | title  = <nowiki>Re: Problem in the Atmospheric Light Scattering (ALS)</nowiki>
  $FGData/Models/Astro
  | author = <nowiki>Thorsten</nowiki>
 
  | date  = Sep 23rd, 2014
and are
  | added  = Sep 23rd, 2014
 
  | script_version = 0.23
  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 [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'''. 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 ====


{{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
* 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:
|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
  EarthView.World.January-2020.06/
|1= There is nothing underneath Earthview when used in orbit.
   EarthView.World.February-2020.06/
|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
On linux, a simple "cron" job can automatically link the content of one of these directories to '''$FGData/Models/Astro/Textures/''', like this one:
|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
  #!/bin/bash
|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).
  TEXTUREDIR="/usr/share/games/flightgear-extra/Models/Textures"
|2= {{cite web
  TIMESTAMP="2020.06"
  | url   = http://forum.flightgear.org/viewtopic.php?p=262570#p262570
  MONTH=$(date +%B)
  | title  = <nowiki>Re: Su-15</nowiki>
   WORLDRES="16384"
  | author = <nowiki>Hooray</nowiki>
  echo "Going to: $TEXTUREDIR"
  | date  = Nov 1st, 2015
  cd $TEXTUREDIR
  | added  = Nov 1st, 2015
  echo "Linking world textures of: $MONTH"
  | script_version = 0.23
  ln -s -f ../EarthView.World.${MONTH}-${TIMESTAMP}/${WORLDRES}/world_*.dds .
  }}
  ln -s -f ../EarthView.World.${MONTH}-${TIMESTAMP}/${WORLDRES}/world_*.png .
}}
  echo "done"


{{FGCquote
And you'll be flying Earth with textures matching the current month!
|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
* 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], see the original discussion on the forum [https://forum.flightgear.org/viewtopic.php?f=87&t=15754&start=375#p369043 viewtopic.php?f=87&t=15754&start=375#p369043].
|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
|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
|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 ==
== Implementation ==
{{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.
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.
|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
Compared to almost anything else, the performance impact of re-positioning the sphere every frame is minimal.
|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
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= 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
  }}
}}


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.


{{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= 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
== Development ==
|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 23:20, 12 June 2020

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 or even the UFO, 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 menu.jpg


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:

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


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:ffd18abf3bd98ee761babc09d7c901ea1ce0c78f&dn=EarthView%20-%20Complete

and may also be available for download at this url:

   /earthview/
  • 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.


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!


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.