Earthview: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 41: Line 41:


== Requirements ==
== Requirements ==
{{FGCquote
|1= [System requirements] Not much as long as it fits into memory. There's only a sphere and 8 textures in the scene, that's no hard rendering task.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=219587#p219587
  | title  = <nowiki>Re: </nowiki>
  | author = <nowiki>Thorsten</nowiki>
  | date  = Sep 30th, 2014
  | added  = Sep 30th, 2014
  | script_version = 0.23
  }}
}}


{{FGCquote
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.
|1= You can get to see a maximum of 4 at once, so at least 4 have to reside in GPU memory, the rest is probably loaded just in case. For really hires (16384x16384) precompressed dds helps a lot.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=219587#p219587
  | title  = <nowiki>Re: </nowiki>
  | author = <nowiki>Thorsten</nowiki>
  | date  = Sep 30th, 2014
  | added  = Sep 30th, 2014
  | script_version = 0.23
  }}
}}


{{FGCquote
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.
|1= All visuals (including Earthview) will probably look weird without ALS as well - lots of the hard contrasts run via dedicated ALS space shaders which fall back to model-combined otherwise. Given that neither default nor Rembrandt support decent visuals in space, I'm not sure how much effort we would want to spend to make other things nice when not in ALS.
 
|2= {{cite web
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.
  | url    = http://forum.flightgear.org/viewtopic.php?p=267827#p267827
 
  | title  = <nowiki>Re: Space Shuttle</nowiki>
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.
  | author = <nowiki>Thorsten</nowiki>
  | date  = Dec 9th, 2015
  | added  = Dec 9th, 2015
  | script_version = 0.23
  }}
}}


== Customization ==
== Customization ==

Revision as of 07:50, 21 March 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

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.

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

Cquote1.png If you're interested in spaceflight, I think we really have that covered nicely and fast with EarthView these days - especially if you use the hires textures provided by NASA
— Thorsten (Dec 25th, 2014). Re: Initial FlightGear / OsgEarth integration.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png EarthView uses a sphere with 8 separate texture sheets (and I think even a similar naming convention to the NASA files...). The site you're looking for is Visible Earth, especially the Blue Marble section.
— Thorsten (Sep 30th, 2014). Re: .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png EarthView resides in /Models/Astro - the file that's loaded is specified in earth.xml - if you do your own textures, you attach them to earyh_unitscale_rawuv.ac and reference that in earth.xml , or if you create margins, you can simply replace pale_blue_aug_*.png (the naming convention has N1 to N4 and S1 to S4 which is close to what NASA uses). If you alter the texture names, you edit the *.ac file by search/replace or with your favourite model editor. Okay, I'm expecting here that if I say 're-texture that sphere' its not going to be an unsurmountable problem... that's sort of basic modelling done a few hundred times per day in the forum...
— Thorsten (Sep 30th, 2014). Re: .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Because graphics cards like powers of 2, we're actually using 16384x16384 rather than full resolution (which would choke even my high-end GPU), and here we see the virtue of precompressed dds, so if I remember one of the precompressed and mipmapped files is 172 MB.

Unless you have 8+ GB of memory, using half the resolution is probably a very good idea.

Once you are at it, notice that also the cloudsphere is available at higher resolution... makes a hell of difference.
— Thorsten (Sep 30th, 2014). Re: .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png If you download the full resolution earth and cloud textures from NASA Visible Earth and re-texture the sphere, then you can have this
— Thorsten (Mar 5th, 2015). Re: .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I reasoned that if 'texture the sphere' doesn't mean anything to a user, he probably can't do it anyway. Besides, at 16384 x 16384 texture resolution, you may run into memory and architecture limits of your machine, so there's really no one sie fits all path at the upper end - I ended up using dds textures to reduce loading time.

The models in question are Models/Astro/earth_unitscale_hires.ac, earth_unitscale_rawuv.ac and clouds_unitscale_hires.ac. The unitscale_hires are smart uv-mapped and need textures with a characteristic border to avoid seams, the rawuv has a simple mapping to which you can apply texture sheets as is.

Open with the model editor of your choice, map with the textures of your choice, done.
— Thorsten (Mar 5th, 2015). Re: .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png the simple, slightly seamy way is you download a file, resie it to a 2^n size to make life easy for the GPU, save it as png (or if you want it fancy dds) and... done. The hard way without any seams involves creating a suitable margin like in the existing textures.
— Thorsten (Sep 30th, 2014). Re: .
(powered by Instant-Cquotes)
Cquote2.png

Implementation

Cquote1.png 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.
— Thorsten (Sep 23rd, 2014). Re: Problem in the Atmospheric Light Scattering (ALS).
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— Thorsten (Dec 14th, 2015). Re: Su-15.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— Thorsten (Nov 1st, 2015). Re: Su-15.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png There is nothing underneath Earthview when used in orbit.
— Thorsten (Nov 1st, 2015). Re: Su-15.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Earthview's idea of a low visibility is >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.
— Thorsten (Apr 5th, 2015). Re: low visibility after trying .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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).
— Hooray (Nov 1st, 2015). Re: Su-15.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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)
— Hooray (Nov 1st, 2015). Re: Su-15.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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
— Thorsten (Nov 1st, 2015). Re: Su-15.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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?
— Thorsten (Nov 1st, 2015). Re: Su-15.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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)
— Hooray (Jul 7th, 2015). Re: Planets.
(powered by Instant-Cquotes)
Cquote2.png

Development

Cquote1.png 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.
— Thorsten (Feb 11th, 2015). Re: FG 3.4 RC2.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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:

Cquote2.png
Cquote1.png 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
— Hooray (Dec 17th, 2015). Re: Implementing moonlight (or not).
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png 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.
— bugman (Dec 17th, 2015). Re: Implementing moonlight (or not).
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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?
— Thorsten Renk (Oct 29th, 2015). [Flightgear-devel] Texture memory management.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— Renk Thorsten (May 2nd, 2014). [Flightgear-devel] Nightsky.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— SiriusGrey (Jan 19th, 2012). Re: New Flight Gear Terrain Engine.
(powered by Instant-Cquotes)
Cquote2.png