Earthview: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (even more content/quotes begging to be unified/rewritten some day)
No edit summary
Line 1: Line 1:
{{See also|Flying on other planets}}
Earthview is an orbital rendering engine for FlightGear designed to get credible visuals when using spacecraft such as [[Vostok-1]]. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. Since there is only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.
{{Spaceflight}}
{{Spaceflight}}
=== Orbital Rendering:Earthview ===
=== Orbital Rendering:Earthview ===
{{See also|Flying on other planets}}
 


{{FGCquote
{{FGCquote
Line 39: Line 42:
}}
}}


Earthview is an orbital rendering engine for FlightGear designed to get credible visuals when using spacecraft such as [[Vostok-1]]. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. Since there is only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.


{{FGCquote
{{FGCquote
Line 67: Line 69:
A long standing problem in FlightGear's atmosphere definition has now been addressed and JSBSim spacecraft should now be able to reach any orbital altitude within their capabilities (previously flight was restricted to be below 150 km altitude).
A long standing problem in FlightGear's atmosphere definition has now been addressed and JSBSim spacecraft should now be able to reach any orbital altitude within their capabilities (previously flight was restricted to be below 150 km altitude).


{{FGCquote
Thorsten remarked that a good way to see the blue planet from high up was to start FG using the ufo at a high altitude (around 10 million ft is quite good with the texture resolution provided), open the GUI from the View menu, push start, wait for the textures to load and admire the view.
|1= To see the blue planet from high up, start FG using the ufo at a high altitude (around 10 million ft is quite good with the texture resolution provided), open the (currently minimalistic) GUI from the View menu, push start, wait for the textures to load and admire the view.
{{cite web
|2= {{cite web
   | url    = http://sourceforge.net/p/flightgear/mailman/message/32262904/
   | url    = http://sourceforge.net/p/flightgear/mailman/message/32262904/
   | title  = <nowiki>[Flightgear-devel] Orbital rendering</nowiki>
   | title  = <nowiki>[Flightgear-devel] Mailing List, Apr 24 2014</nowiki>
  | author = <nowiki>Renk Thorsten</nowiki>
   }}  
  | date  = Apr 24th, 2014
  | added  = Apr 24th, 2014
  | script_version = 0.23
   }}
}}
}}


{{FGCquote
{{FGCquote

Revision as of 20:09, 22 December 2015

Earthview is an orbital rendering engine for FlightGear designed to get credible visuals when using spacecraft such as Vostok-1. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. Since there is only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.


Orbital Rendering:Earthview

Cquote1.png I've managed to implement a scheme for orbital terrain rendering which I had cooked up a while ago.
— Renk Thorsten (Mar 16th, 2012). [Flightgear-devel] Earthview - Orbital terrain rendering in FG.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png this is really low-tech and lives within the limitations of the current engine - just a textured sphere of 58 km diameter in the scene which is constantly repositioned using simple ray-optics to give the right impression and has a dedicated shader to never fog it and work around the high altitude light problem (see below). The results using Celestia Level 3 texturing are quite compelling
— Renk Thorsten (Mar 16th, 2012). [Flightgear-devel] Earthview - Orbital terrain rendering in FG.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png It took me 7 hours to get it to this point, less than 100 lines of Nasal, some cut-past with the shaders - most of the time I spent stitching and converting textures. Right now it is really dumb - one can go to even higher resolution texturing by investing some smartness and introducing texture management (currently Earth is effectively covered by 4096x8192, the cloud layer adds the same amount).
— Renk Thorsten (Mar 16th, 2012). [Flightgear-devel] Earthview - Orbital terrain rendering in FG.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png the Earthview orbital rendering engine. The textures for the planet are based on the NASA Visible Earth collection http://visibleearth.nasa.gov
— Renk Thorsten (Apr 24th, 2014). [Flightgear-devel] Orbital rendering.
(powered by Instant-Cquotes)
Cquote2.png


Textures are taken from the NASA Visible Earth project - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 m per pixel) and clouds with half of that. Currently there is a much lower texture resolution distributed via GIT, a mode to make the GB-sized hires textures has yet to be determined.

Combined with the atmospheric light scattering (ALS) shader to render the atmosphere, visuals are generally rather 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

A long standing problem in FlightGear's atmosphere definition has now been addressed and JSBSim spacecraft should now be able to reach any orbital altitude within their capabilities (previously flight was restricted to be below 150 km altitude).

Thorsten remarked that a good way to see the blue planet from high up was to start FG using the ufo at a high altitude (around 10 million ft is quite good with the texture resolution provided), open the GUI from the View menu, push start, wait for the textures to load and admire the view. [Flightgear-devel] Mailing List, Apr 24 2014. }}


Cquote1.png Earthview responds to the weather visibility setting and typically 80-140 km visibility work best (won't affect any scenery loading because we're too far from the planet). Also, rendering in ALS manually tweaking Rayleigh and Mie constants gives a nice atmosphere effect. NASA provides textures in /much/ higher resolution - in my highest resolution texture set I have the planet covered in 32768x16384 and the cloud layer in half of that. For such large textures, loading time is an issue (Earthview isn't excatly *cough* elegant) and pre-mipmapped compressed DDS is pretty much the only sane option - then that's 8 texture chunks a 176 MB each. It'd be nice to make higher resolution versions available for download, but I realie that's quite a bandwidth hog - if there's sufficient interest and someone knows a server... the textures are there. Provided you have the texture memory, performance should actually be pretty high - there's just two textured spheres in the scene, and even on my old computer I get a solid 60 fps.
— Renk Thorsten (Apr 24th, 2014). [Flightgear-devel] Orbital rendering.
(powered by Instant-Cquotes)
Cquote2.png

Requirements

Cquote1.png [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.
— Thorsten (Sep 30th, 2014). Re: .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— Thorsten (Sep 30th, 2014). Re: .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— Thorsten (Dec 9th, 2015). Re: Space Shuttle.
(powered by Instant-Cquotes)
Cquote2.png

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