Earthview: Difference between revisions
Legoboyvdlp (talk | contribs) No edit summary |
Legoboyvdlp (talk | contribs) (→Orbital Rendering:Earthview: MailingList2Wiki) |
||
Line 3: | Line 3: | ||
{{Spaceflight}} | {{Spaceflight}} | ||
=== Orbital Rendering:Earthview === | === Orbital Rendering: Earthview === | ||
By March 16th, 2012, Thorstem Renk managed to implement a scheme for orbital terrain rendering which he had cooked up a while ago. | |||
{{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/28991398/ | | url = http://sourceforge.net/p/flightgear/mailman/message/28991398/ | ||
| title = <nowiki>[Flightgear-devel] Earthview - Orbital terrain rendering in FG</nowiki> | | title = <nowiki>[Flightgear-devel] Earthview - Orbital terrain rendering in FG, 2012</nowiki> | ||
}} | }} | ||
It was really low-tech and lived within the limitations of the current engine - just a textured sphere of 58 km diameter in the scene which was constantly repositioned using simple ray-optics to give the right impression and had a dedicated shader to never fog it and work around the high altitude light problem. The results using Celestia Level 3 texturing were quite compelling. | |||
{{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/28991398/ | | url = http://sourceforge.net/p/flightgear/mailman/message/28991398/ | ||
| title = <nowiki>[Flightgear-devel] Earthview - Orbital terrain rendering in FG | | title = <nowiki>[Flightgear-devel] Earthview - Orbital terrain rendering in FG - T Renk, 2012</nowiki> | ||
}} | }} | ||
It took 7 hours to get it to this point, less than 100 lines of Nasal, some cut and paste with the shaders - most of the time was spent stitching and converting textures. It was really dumb - one could 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). | |||
{{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/28991398/ | | url = http://sourceforge.net/p/flightgear/mailman/message/28991398/ | ||
| title = <nowiki>[Flightgear-devel] Earthview - Orbital terrain rendering in FG | | title = <nowiki>[Flightgear-devel] Earthview - Orbital terrain rendering in FG - T Renk, 201w</nowiki> | ||
}} | }} | ||
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 | 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. | Combined with the [[atmospheric light scattering]] (ALS) shader to render the atmosphere, visuals are generally rather compelling. | ||
Line 74: | Line 45: | ||
| title = <nowiki>[Flightgear-devel] Mailing List, Apr 24 2014</nowiki> | | title = <nowiki>[Flightgear-devel] Mailing List, Apr 24 2014</nowiki> | ||
}} | }} | ||
Earthview responds to the weather visibility setting and typically 80-140 km visibility work best (it won't affect any scenery loading because we're too far from the planet). Also, while rendering in ALS, manually tweaking Rayleigh and Mie constants gives a nice atmosphere effect. NASA provides textures in /much/ higher resolution - in the highest resolution texture set, Thorsten had 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 at 176 MB each. It would be nice to make higher resolution versions available for download, but obviously 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 an old computer, some get a solid 60 fps. | |||
{{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 | | title = <nowiki>[Flightgear-devel] Orbital rendering - T. Renk</nowiki> | ||
}} | }} | ||
== Requirements == | == Requirements == |
Revision as of 20:23, 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.
Space flight |
---|
in FlightGear |
Space Shuttle |
Vostok-1 |
Orbital Rendering: Earthview
By March 16th, 2012, Thorstem Renk managed to implement a scheme for orbital terrain rendering which he had cooked up a while ago. [Flightgear-devel] Earthview - Orbital terrain rendering in FG, 2012.
It was really low-tech and lived within the limitations of the current engine - just a textured sphere of 58 km diameter in the scene which was constantly repositioned using simple ray-optics to give the right impression and had a dedicated shader to never fog it and work around the high altitude light problem. The results using Celestia Level 3 texturing were quite compelling. [Flightgear-devel] Earthview - Orbital terrain rendering in FG - T Renk, 2012.
It took 7 hours to get it to this point, less than 100 lines of Nasal, some cut and paste with the shaders - most of the time was spent stitching and converting textures. It was really dumb - one could 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). [Flightgear-devel] Earthview - Orbital terrain rendering in FG - T Renk, 201w.
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.
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:
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.
Earthview responds to the weather visibility setting and typically 80-140 km visibility work best (it won't affect any scenery loading because we're too far from the planet). Also, while rendering in ALS, manually tweaking Rayleigh and Mie constants gives a nice atmosphere effect. NASA provides textures in /much/ higher resolution - in the highest resolution texture set, Thorsten had 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 at 176 MB each. It would be nice to make higher resolution versions available for download, but obviously 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 an old computer, some get a solid 60 fps.
[Flightgear-devel] Orbital rendering - T. Renk.
Requirements
[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. |
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. |
Customization
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) |
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. |
If you download the full resolution earth and cloud textures from NASA Visible Earth and re-texture the sphere, then you can have this |
Implementation
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) |
There is nothing underneath Earthview when used in orbit. |
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 |
Development
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) |
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. |