Idon't know the full answer to the scenery question, but they use a different mechanism than FS does. FS was locked in to the way that Bruce Artwick (subLogic) did it back around 1980 for the Apple II and TRS-80, until 2000. Oh, they made some changes, but it still used a tiled approach. FS2000 changed the scenery model a lot, using elevation data for the first time, but airports themselves are still flat.
Flight Gear was first released in 1997. The first version I tried (something prior to 1.0) had sloping runways, unlike the tile mechanism in FS, but was still crude. It's much more usable now, and a LOT easier to configure.
I'm actually surprised at your question - I wouldn't have described FG in such terms myself, and in fact some two years ago I wrote a long comment on the developer's list how the lack of LOD for the terrain mesh is one of our biggest problems (of course, now loading terrain from SSD into the 8GB of memory of a high-performance GPU, it ceased to be an issue again...)
But the fact remains that it is conceptually not a 'good' scheme - it just loads the terrain mesh when requested (i.e. at a distance 20% larger than current visibility). Though I believe the loading queue for the 3d renderer is of the few things that can utilize multiple cpus - I'm not sure that's the default setting though. So it seems to me others are just doing worse (?)
You can easily (dependent on your systems specs) make the terrain loading process visible - certainly something like the X-15 climbs fast enough such that when requesting 600 km arc-top visibility, you see the circle of terrain mesh expanding around you. Also, particularly 'heavy' terrain (lots of vegetation requested, or the OSM2CIty real building coverage overlay) often makes this happen at lower visibilities.
The texture resolution can be fairly coarse, because the actually visible texture at high rendering quality is a composite of six different textures and procedural noise, some of which generate details as small as a few cm - in terms of GPU memory and loading times, that's rather efficient.
Overlay objects (lights on the roads, buildings, vegetation,...) are loaded at 'their' LOD range (which the user can configure) - they're not actually visible out to infinity, but often they're introduced in up to 10 LOD groups, so the whole chunk never pops at once, there's just gradually 'more' stuff appearing when you get closer. That's why nothing seems to pop.
With shadows I'm not sure which ones you mean - cloud shadows only go out to 30 km or so (usually in reality they're not visible much farther either), vegetation shadows go out as far as the vegetation LOD range because they're just extra quads added to a tree.
There's two schools of thoughts among the developers. Some believe in HLA and distributing the computation work, others (like myself) point out that rendering is usually 95% of the work anyway, so whether you thread out the remaining 5% doesn't really matter so much and any gain you may have might well be eaten by the overhead you need to keep threads in sync.
So I believe currently some obvious things can be threaded out of the main loop (and it's also possible to do that in scripting space), but FG is a far cry from having efficient multicore utilization.
(I understand X-plane fills the other cores by running actual flight dynamics for Ai-traffic - which gives you an impression of a fully-utilized computer, but probably doesn't overly change the experience for the user so much...)
Also, city ground textures where no 3d buildings showed looked more like buildings then in fsx. In fsx, with low amount of 3d autogen the city looks like brown mud. In flightgear it took a very long time to realise that not all was 3d!!
The reason I stopped playing it back then was because of issues with the nvidia card in linux. And because of finding it difficult to manage two systems at once. (linux /win7). Also, that old 80g ide drive in it's enclosure got extremely hot. And was 90% full after the install. I decided I would try again on windows later.
Actually, if your system manages, there's the OSM2City project. You usually have to install it separately (we haven't solved how to distribute the data autoamagically) - but for many regions in the world, you get detailed cities automatically assembled building by building from OpenStreetMap data.
Having some issues with fsx at the moment. On end in right there yet, but once that's fixed next thing on the list will be larger ssd and flightgear. (and depending on performance this OSM thing as well perhaps.)
FlightGear comes with a limited set of scenery in the base package. This is to keep initial download sizes small. The base package includes the region around the featured airport for each release (which is Iceland for Flightgear 2020.x), and the area containing the airport used by the C172p tutorials (PHTO and Hawaii islands). Additional scenery can be installed by the user - this includes scenery automatically downloaded as you fly from Terrasync servers.
For examples of what scenery looks like at high-ish settings in developed regions see the high settings screenshots category. This is a useful way to check you have enabled or turned up all the scenery features, and a useful a way to check you are using the all the features of the weather & environment simulation - the article on screenshots also covers turning on various settings.
There is also a 4 DVD set available for download via BitTorrent - NOTE THIS LINK IS BAD, which can be a higher performance option for those wanting to download the entire world. And, last but not least, it can be purchased as 3 DVD set from the official FlightGear website.
On most of the mirrors, the latest scenery can be found under Scenery-2.12.0/. Downloading from mirrors is often better than the official site, because mirrors are sometimes faster and have more user capacity. Use the graphical interface to find the appropriate chunk. Be careful about confusing N with S, and E with W!!Here is how to find an airport's co-ordinates:
When downloading and synchronizing tiles on lower end machines or when having an unstable or slow Internet connection, TerraSync might cause stuttering and/or slow down FlightGear. If you encounter that there are a few ways around it:
TerraMaster is a stand alone scenery manager that can download and synchronize TerraSync scenery. It also makes it easier to maintain and get a good overview of downloaded TerraSync scenery. It is a cross platform graphical application written in Java.
TerraMaster allows the FlightGear user to manage scenery tiles easily, selecting which tiles to download, synchronize or delete, and viewing the downloaded/not yet downloaded tiles at a glance. TerraMaster is highly recommended not only for managing scenery tiles easily especially if you are downloading and managing scenery from a computer that does not have FlightGear installed. The downloaded tiles are put into a folder which can then be copied into the FlightGear directory later on to complete the scenery. It can also download tiles directly into the TerraSync directory.
Custom scenery is available for certain specific areas. They are distributed separately either due to being only part of a single landmass that has not been re-built completely, being work-in-progress, waiting to be integrated to Terrasync, their license, or because their level of detail is not suitable for low-end machines.
input_file.tgz should be substituted with the filename of the archive to be extracted (the filename should be completed with the full pathname or any other valid method so that the shell could find the correct archive).
Simply unpack the downloaded scenery into a directory of choice, using software like Winzip or 7-zip. Once done, append this directory to $FG_SCENERY. When using the FlightGear Wizard, you can do so on the first page (previous from aircraft selection). Do not forget to press the "Refresh" button on the airport selection page, when using the wizard.
FlightGear determines what scenery to use by looking at the environment variable (setting)$FG SCENERY. There can be more than one scenery path in the variable, for example one path to to TerraSync scenery and one path to custom scenery. Scenery can be overlapping and a tile will be loaded from the first path in $FG SCENERY from which it is available.
For this reason it is probably better to extract scenery files you have downloaded into a new folder, which we for the sake of this exercise will call $FOOBAR/Scenery.In this directory, create two subdirectories: /Objects and /Terrain. You should untar individual files into the /Terrain folder.
Note that the directory structure is already present in the tar archive, starting from the Scenery directory. Note that you have to extract the tar archive in the Scenery directory, not in the $FG_ROOT directory, because the Scenery directory is not present in the archive.
These objects are included in each scenery release, but as the object database is more frequently updated than the terrain, one may want to occasionally update the Object subdirectory from the scenery objects database between scenery releases.
To see the terrain below your aircraft, you have to install the respective scenery. This can happen by downloading certain bits of scenery before flying as described in the article installing scenery.
Alternatively, if you have a steady and reasonably fast internet connection, you can use TerraSync. It is a utility that automatically downloads the newest version of the needed FlightGear scenery while the simulator is running. TerraSync runs in the background (optionally as a separate process), monitors your position, and downloads (or updates) the latest scenery from the master scenery server "just in time".For some time now TerraSync has been integrated into the core FlightGear process, so there is no need to deal with TerraSync for the typical user.
The master repository for TerraSync, i.e. the online resource from which TerraSync downloads its files, is synchronized with the FlightGear Scenery Database once a day. So when using TerraSync, you will always have
3a8082e126