Orbital Rendering:Earthview
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.
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).
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.
|
|
|
|
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.
|
|
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
|
|
|
|
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.
|
|
|
|
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...
|
|
|
|
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.
|
|
|
|
If you download the full resolution earth and cloud textures from NASA Visible Earth and re-texture the sphere, then you can have this
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
There is nothing underneath Earthview when used in orbit.
|
|
|
|
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.
|
|
|
|
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).
|
|
|
|
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)
|
|
|
|
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
|
|
|
|
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'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)
|
|
Development
|
|
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.
|
|
|
|
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:
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
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.
|
|
