FlightGear World Scenery 2.0

From FlightGear wiki
Jump to navigation Jump to search

The FlightGear World Scenery 2.0 was released during FSweekend November 2013. This new scenery reflects a major improvement over the existing default world scenery and has taken over five years to complete. A much higher level of detail and internal consistency characterizes this new release, in addition to the fact that it will serve as a stepping-stone for further incremental refinements.

Caution  The new scenery is currently quite heavy and FlightGear will run slower. It may even crash FlightGear if run on systems with less than 4Gb RAM or if used with the 32 bit version of FlightGear.

Source data

This FlightGear World Scenery was compiled from:

  • ViewFinderPanoramas elevation model by Jonathan de Ferranti (using terrafit.py -x 20000 -e 10),
  • VMap0 Ed.5 Worldwide Land Cover
  • CORINE Land Cover 2006v16 for Europe (Source : European Union, SOeS, CORINE Land Cover, 2006 - [1]). See [2] for the correspondance between CORINE and FG textures
  • Several custom land cover enhancements (to be listed here...)
  • The latest airports (2013.10), maintained by Robin Peel of X-Plane
  • Road, rail and rivers courses line data by OpenStreetMap [3]

Distribution

World Scenery 2.0 is available through the usual channels:

Notes

  • All object elevation were recomputed. Thus, if some objects were defined with a bad elevation or bad offset, they may have taken a bit of elevation. Use our webforms, if necessary, to fix this.
  • The new scenery is currently quite heavy and hardly runs and can lead to FG crashes if run on systems with less than 4Gb RAM and if you're not using FG 64 bits. This is being worked on, however keeping a high quality scenery with a lower count of triangles is not easy. The addition of OSM roads added a lot of new triangles, hence the fps reduction.

Known bugs and limitations

  1. Clipping of OSM roads on water showing height glitches (due to bad coast/river lines definitions and bad clipping): clip roads against landmass or add landmass where required? Should roads over bridges get removed, even in places where a 3D bridge model is missing?
  2. (fixed_alfa) Some z-fighting (clipper is generating the correct number of contours, but the airport hole is wound as a boundary, not a hole) and/or triangles on airports (LFRH, EDWJ (partially submerged)...);
  3. (fixed_alfa) Some troubles on very dense cities (such as Paris) leading to grey-white triangles on cities - see also yellow lines @LFPG;
  4. (unfixed_alfa) Some line issues on small airfield with LTA specific runways (LFNH, LFLI...) - the small centerlines on the runways are "floating" over the runway (20 cm to 1m), leading to some gear destructions ;-) (they didn't use lines, but surfaces that are defined as transparent and borders defined as the line type. This way you limit the number of "line features"). Probably "hot" = false would solve it. See 1 2 3 4 5. Thanks Clément for noticing;
  5. Airport being located over two different tiles sometimes renders bad, leading to z-fighting (LEJR, UKKE...);
  6. (unfixed_alfa) On sharp cliffs, water sometimes climbs over the cliffs (see e000n40/e000n49/2958056 and this picture for instance). Thanks clm76 for reporting. On the same matter, clipping between river and terrain is somewhat strange, making the river "climb" over the terrain, noticeably under bridges - probably due to the presence of the roads. See this example;
  7. Terrain and ocean z-fighting such as east of EKCH. See tile 3155042 and EDWJ;
  8. The Moss Landing airport (on the coast a little bit south of KSFO) is partly submerged into the water and the airport's north end is elevated above the terrain around it. There is an area on the coast just to the north of the Moss Landing airport that is above sea level if you are up above 1000ft but is covered in water is you are on the deck. When flying over this you can see trees sticking up out of the water so the code that is placing random trees thinks this is above sea level. The old scenery didn't have either of these problems. Also if you fly over this at just the right altitude you can see this area switching back and forth between being water and land (thanks hvengel);
  9. On many airports where the taxiway signs are now taken from the apt.dat and put in the Terrain folder, the old signs still remain in the Object folder. See EDDF, ELLX;
  10. (unfixed_alfa) On ELLX there are some problems with "holes" in the pavement that flicker between grass and tarmac. I saw this (if I remember correctly) with an older development version of terragear, but this was fixed some time ago.
  11. (fixed_alfa) On EHAM some vertice seems to be inverted see this picture
  12. (fixed_alfa) At LFLI the taxiway is not correctly drawn
  13. The taxiway signs are not rendered correctly with transition shader set to its maximum in ALS. Quoting ThorstenB, "It occurs because you're using the terrain shader effect on something that isn't part of the terrain but in reality an artificial object placed onto the terrain. The terrain shader effect concludes correctly that a natural vertical surface cannot be anything but rock, so it replaces the default texture with the default steep gradient texture - which is rock. In my view, the proper solution would be to *not* render signs as part of the terrain but to let a different effect handle them (model-default.eff should do the trick for instance, but one could also run a lower quality terrain shader). If that is not acceptable a workaround is to declare the gradient texture for the signs as void.png as described in http://wiki.flightgear.org/Procedural_Texturing#The_gradient_texture which continues to use the terrain-specific effect but instructs the shader not to use a separate texture for steep gradients."
  14. sometimes some strange water width transitions, like for the Rhein - reported by ot-666
  15. (fixed_alfa) In a few airports (LEVT, LEGE are two examples), taxiways are defined in using a stack of layers: the bottom layer for the asphalt surface and the upper layer (defined as transparent) is only used to define the lines. Current tools do not support stacks of layers and the upper layer is "transparent" all the way down to the ground. See 1 and 2 This is easily fixable in the data by changing transparent layers to asphalt, but it involves a manual intervention in each airport and sending the data back to Robin. And actually, there is not anything wrong with the original data. Other airports such as LFLR do take advantage of transparent taxiways.
I am working on a true priority stack for genapt ( while bringing the design to match tg-construct ). Transparent pavement should work just like X-Plane, but the orthographic images are not.--Psadro gm (talk) 18:50, 1 March 2014 (UTC)

Fixed bugs

  • Near EHAM there is a pylon under terrain see this picture
  • Glacier landcover is missing, leading to some holes in high moutains, as seen in Switzerland (SW LSMM), Austria (south of LOWI) and Northern Norway (i.e. near ENMS);
  • Triangle winding appears inconsistent - especially when a vertex is shared by 4+ edges. Issue can be visualized here: messed up binormals and tangents This may be the root cause of the urban shader issue - reported by i4dnf. Issue understood - Winding is not the issue, duplicate nodes per triangle (zero area triangles) are possible when converting the CGAL exact triangle back to nodes using double floats.

Features enhancement

  1. Enhance landcover data for the rest of the world (OSM? vectorize US-American NLCD2006?) and add more custom scenery and fixes;
  2. Complete CORINE coverage, fix overlaps in CLC2000 and merge with CLC2006;
  3. Use latest ViewFinderPanoramas DEM's;
  4. Find a new svn hosting solution;
  5. Compute the next terrain with textures-lines option (requires pavement atlas - single texture for all road / rail / streams ) to keep framerate under control;
  6. Add some more OSM data (secondary...);
  7. Descent airports priority below roads, so roads and railroads can be shown over airports; have a proper solution for roads running over terrain classified as airfield, maybe extract administrative boundaries from apt.dat;
  8. Retry multi-thread;
  9. Enhance the "random" tree and builds placement to take OSM into account;
  10. .SPT file support - push Mathias' LOD ideas forward;
  11. Landclass border blurring - Several ideas on this - It would be really nice to be able to do it;
  12. OSM motorway_link (and the other _link) roads should probably have their own width. Perhaps grouped into a separate shapefile, or handled in ogr-decode - single lane is most likely;
  13. OSM line data simplification / preprocessing. - We've done some experimenting, and the results are promising. This should reduce the number of triangles generated. It could create longer continuous roads, which allows better control of the generated texture coordinates - so we could, theoretically, populate the roads with traffic in the future.

Related content

External link

Retrieved from "https://wiki.flightgear.org/w/index.php?title=FlightGear_World_Scenery_2.0&oldid=102094"