Earthview: Difference between revisions

Jump to navigation Jump to search
5,339 bytes removed ,  22 March 2016
Line 77: Line 77:


== Implementation ==
== Implementation ==
{{FGCquote
|1= Have you wondered why you can't see the terrain when you switch EarthView on? That would be because the EarthView sphere is neither where you think it is, nor as large as you think it is.
In actual reality of rendering geometry, the sphere has a radius of ~58 km and when you are at an altitude of 30.000 ft, it is only 100 m away from you. You don't realie any of this of course since the sphere is constantly repositioned. The reason that is done is because the renderer works with floating point precision, the internal unit is meters, and if you throw a distance of 6 million meters at it, all you get back is numerical garbage. For that reason, there's a far clipping distance in FG which does not render anything beyond a default of 120 km.
The fogging of the EarthSphere is likewise based on the assumption that you see a 10 km think layer of atmosphere from above, not that you're inside an atmosphere with varying aerosol density - it would never match atmosphere fog properly.
There's in fact nothing wrong with the way the horizon is created as long as you don't set a visibility exceeding the LOD bare and far camera clipping range.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=219172#p219172
  | title  = <nowiki>Re: Problem in the Atmospheric Light Scattering (ALS)</nowiki>
  | author = <nowiki>Thorsten</nowiki>
  | date  = Sep 23rd, 2014
  | added  = Sep 23rd, 2014
  | script_version = 0.23
  }}
}}


{{FGCquote
Technically, Earth is rendered as a ~58 km sized sphere positioned 1/100 of the actual altitude away from the spacecraft. It's position is constantly adjusted to give the same visual size using ray optics equations, and its attitude is rotated to place you 'above' the correct latitude and longitude. For 100 km altitude, the camera is thus actually just 1000 m away from the sphere.
|1= 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
Compared to almost anything else, the performance impact of re-positioning the sphere every frame is minimal.
|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
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 word, 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= There is nothing underneath Earthview when used in orbit.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=262568#p262568
  | title  = <nowiki>Re: Su-15</nowiki>
  | author = <nowiki>Thorsten</nowiki>
  | date  = Nov 1st, 2015
  | added  = Nov 1st, 2015
  | script_version = 0.23
  }}
}}


{{FGCquote
The implementation has the negative consequence that you may not move the view point too far from the spacecraft (the ray optics illusion works for one object, but not for two simultaneously) - in particular flyby view or tower view will give you odd results with Earthview.
|1= 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
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= even Nasal-level code will end up calling C++/OSG code - which is why EarthView is using native OSG code, unlike PUI, the HUD code or the 2D panels code - in other words, using Nasal like this can even be superior to hard-coded routines in the main loop, which are now crippling the OpenGL experience for other subsystems (just look at all the AMD/ATI related rendering issues due to PUI code that interacts with some other effects/shaders).
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=262570#p262570
  | title  = <nowiki>Re: Su-15</nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Nov 1st, 2015
  | added  = Nov 1st, 2015
  | script_version = 0.23
  }}
}}
 
{{FGCquote
|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
|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 ==
== Development ==
1,360

edits

Navigation menu