Board index FlightGear Support osgEarth

Initial FlightGear / OsgEarth integration

osgEarth renders the terrain scene by building the textured geometry at runtime from raw source imagery and elevation data.

Initial FlightGear / OsgEarth integration

Postby poweroftwo » Tue Nov 19, 2013 4:10 pm

Initial FlightGear / OsgEarth integration:

Introducing an initial osgEarth integration featuring a runtime selectable option for the terrain scene in FlightGear. Once enabled, osgEarth renders the terrain scene by building the textured geometry at runtime from raw source imagery and elevation data. Load times for an unvisited location are surprisingly fast given a respectable Internet download rate. For locations previously visited, an optimized file cache data is saved for rapid loading.

Input data can come from a variety of sources including web mapping services or local source data (e.g. geotiff) stored on disk. Once rendering is enabled, the entire FlightGear terrain scene graph is replaced along as well as the scene elevation queries. However, the native terrain implementation remains fully intact and can be restored by disabling osgEarth from its configuration dialog.

The benefits gained from this initial osgEarth integration include geo-specific imagery rendered in real-time from a variety of sources that are available worldwide; tiled terrain on demand; and high altitude views from anywhere above the earth. However, this implementation with FlightGear includes some notable limitations listed in the compromises section.

sample images:
https://plus.google.com/112064247634340 ... yc1ViabWGw

sample video:
https://plus.google.com/112064247634340 ... pn9rTithWd


Features
• osgEarth Configuration Dialog
    Menu: Environment->OsgEarth
    Enable / disable use of OsgEarth rendering at runtime. Simply disable OsgEarth to return to native implementation.
    Built-in street map layer with opacity slider that can be adjusted at runtime
    Customize brightness / contrast / gamma at runtime
• Can select source data at runtime. The default sources point to Web based services
• Fly to any airport in the world instantly. Database is paged from network or disk and built on the fly
• osgEarth currently supports these drivers:
Tile Source Drivers
    AGGLite Rasterizer
    ArcGIS Server
    Debug Display
    GDAL (Geospatial Data Abstraction Library)
    Noise
    OSG (OpenSceneGraph Loader)
    TileCache
    WorldWind TileService
    TMS (Tile Map Service)
    VPB (VirtualPlanerBuilder)
    WCS (OGC Web Coverage Service)
    WMS (OGC Web Map Service)
    XYZ
• Inherits all osgEarth functionality for future growth such as:
import shapefiles (via osgEarth) to create extrude buildings etc.
    modify or add new earth sources (on-line imagery via WMS; shapefiles, custom geotiff’s etc.)
    fgdata\Scenery\Terrain\OsgEarth\EarthFiles
    adding new sources
    fgdata\Scenery\Terrain\OsgEarth\OsgEarthSources.xml
• Default source imagery and elevation data are paged from remote sources.
    Has potential to reduce installation footprint
    Important Note: Users are bound by the particular licenses of the source data services.
      File caching
      Imagery, elevation, heightfields, and optimized KML ive’s are cached to disk for rapid load and reduced network access.
      Supports loading from file cache only when web services are not available
      Important disk space consumption warning:
      Because disk caching is enabled by default, when running, files will continuously be cached for imagery and other source data. At this time, this implementation does not monitor disk space usage and will not automatically clear space. The file cache directory can be found under the fgdata folder and is named OsgEarthCache. Simply delete the entire folder to clear the entire cache.
• Airports are cut into terrain
    Due to noise commonly found in coarse elevation sources, aircraft landing areas need to be flattened.
    Heightfield files (geotiff format) are automatically produced by FlightGear for airport locations that are near the ownship position and placed into a new osgEarth layer.
    extents are based on coordinates found in apt.dat.
    heightfield generation algorithm makes a best attempt to retain the slope of the region and usually makes the airfield usably level. Undesirable artifacts are generated for some airports (e.g. incomplete polygon tessellation around high slopes areas), particularly smaller ones that have only a single runway.
    Important Performance Note: At runtime, as new airport heightfields are generated, the terrain scene will temporarily reset as the new layer is added. The addition of a new layer to osgEarth results in a moment where the terrain scene is “blanked” and then restored. After an airport has been revisited, the blanking effect is no longer present.
• KML 3D models (cultural features such as geo-located buildings and structures)
    Geographically located features such as building and structures will be automatically positioned and clamped to the terrain surface.
    Sample KML files are available from the Sketchup 3DWarehouse. http://sketchup.google.com/3dwarehouse
    It is advisable to be selective when choosing models to download from the 3D warehouse as quality varies. Also note that the 3D warehouse contains redundant models of the same feature.
    Place uncompressed KML folders in fgdata\Scenery\Terrain\OsgEarth\KMLFiles.
    Loading of models from KMZ archives is not currently supported. The KMZ must be uncompressed in place, in order for FlightGear to digest.
    Important Performance Note: loading of KML models is currently a technical demonstration and is not a functional replacement of the current FlightGear implementation. The addition of a high number of KML models to the input folder will substantially slow down the initial runtime loading. Unnecessarily complex models will also slow runtime rendering performance.
    The KML referenced Collada (DAE) files are optimized (i.e. LOD node added, textures compressed and embedded etc.) into fast loadable OSG “ive” files stored in the disk cache folder.


Compromises – known limitations of initial implementation
• Only a single material / landclass – (runway) is used in this implementation.
• Typical ground texture resolution is lacking compared to the native FlightGear geo typical runways and taxiways.
    Micro-texture (a.k.a. detail texture) could be utilized to improve effective ground texture resolution.
• KML loading / rendering issues
    FlightGear render non-textured models poorly
    Currently all KML found in the path are loaded regardless of their distance from the ownship’s position. To improve load performance, some type of spatially organized framework along with use of the OSG paging mechanism such as proxy nodes should be implemented.
    During initial load of a textured model, some runtime visual artifacts are produced due to OpenGL graphics conflicts. Quitting FlightGear and rerunning restores the correct state.
• Fog - works with Rembrandt, but does not otherwise
• 3D clouds – The Up vector gets out of kilter over long distances
• Need to load height fields that are nearby and page out others.
• No airport lighting in this implementation.

Growth Items
• extract buildings from FG datasets and clamp to surface
• extract airport lighting from FG datasets and clamp to surface
• utilize the osgEarth shader composition framework in order to support Rembrandt and atmospheric modeling in a more mature fashion.
• produce a coarse worldwide material map from shapefiles useful to determine surface material
• many others…
Source Code Changes
• This initial integration of osgEarth into FlightGear requires changes that are stored in the three primary git repositories (FlightGear, SimGear and FgData). Changes have also been made to the Windows FlightGear loader fgRun.

• git clone -v -b 2.12-OsgEarthIntegration git@gitorious.org:fg/simgear-osgearth.git simgear
• git clone -v -b 2.12-OsgEarthIntegration git@gitorious.org:fg/flightgear-osgearth.git flightgear
• git clone -v -b 2.12-OsgEarthIntegration git@gitorious.org:fg/fgdata-osgearth.git fgdata
• git clone -v -b 2.12-OsgEarthIntegration git@gitorious.org:fg/fgrun-osgearth.git fgrun

Additional Dependencies
• In order to incorporate osgEarth functionality, the osgEarth libraries are new additional dependencies to build the FlightGear osgEarth integrated application.
• git clone -v -b osgearth-2.5-RC3 https://github.com/gwaldron/osgearth.git osgearth


I have a Windows 64 bit patch i plan to make available shortly.

jeff Biggs
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama


Re: Initial FlightGear / OsgEarth integration

Postby Hooray » Tue Nov 19, 2013 4:22 pm

Holy cow, that's the coolest thing we've seen in the scenery/rendering department since Rembrandt !!!

I really like the video - you must have touched tons of places in SG and FG to make this work so well !
Most users here will be wondering if this is something that you are hoping to get included in 3.0 ?

Also, PLEASE DO add this to the next newsletter !
Last edited by Hooray on Tue Nov 19, 2013 6:28 pm, edited 1 time in total.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Initial FlightGear / OsgEarth integration

Postby ludomotico » Tue Nov 19, 2013 4:58 pm

Still downloading your repositories to compile the project, but I'm posting to show how excited I am for this project. Absolutely amazing.

Do you think it can be integrated in the official flightgear easily and activate this only in some areas?
User avatar
ludomotico
 
Posts: 1269
Joined: Tue Apr 24, 2012 2:01 pm
Version: nightly
OS: Windows 10

Re: Initial FlightGear / OsgEarth integration

Postby ludomotico » Tue Nov 19, 2013 5:33 pm

Some errors while compiling simgear, and their fixes:

In file simgear/scene/util/OsgEarthHeightCache.cxx:

- Line 27: fatal error: osgdb/FileNameUtils: No such file or directory", fixed by changing osgdb to osgDB
- Lines 77, 81 and 101: "expected primary-expression before ‘unsigned’". I believe this can be fixed by enclosing "unsigned int" in parenthesis: "(unsigned int)2", for example. It seems that if the line is "unsigned int(2)", gcc converts 2 to an int and then doesn't know what to do with the "unsigned"

In file simgear/scene/util/OsgEarthReadFileCallback.cxx:

- Line 26: fatal error: osgdb/FileUtils: No such file or directory", fixed by changing osgdb to osgDB

Then, all files compile but the final library cannot be linked: "Undefined reference to `typeinfo for osgEarth::TileSourceOptions'" I also downloaded, compiled and installed osgearth from the repository you suggested. I guess I have to add -losgEarth somewhere, but I'm not familiat with CMake :(
Last edited by ludomotico on Tue Nov 19, 2013 5:39 pm, edited 1 time in total.
User avatar
ludomotico
 
Posts: 1269
Joined: Tue Apr 24, 2012 2:01 pm
Version: nightly
OS: Windows 10

Re: Initial FlightGear / OsgEarth integration

Postby Hooray » Tue Nov 19, 2013 5:37 pm

those are pretty common issues whenever Windows-based developers provide patches that weren't tested on case-sensitive OS like Linux, so no need to worry :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Initial FlightGear / OsgEarth integration

Postby Michat » Tue Nov 19, 2013 5:48 pm

Epic.
User avatar
Michat
 
Posts: 1226
Joined: Mon Jan 25, 2010 7:24 pm
Location: Spain
Version: 191b
OS: MX 21 Fluxbox oniMac

Re: Initial FlightGear / OsgEarth integration

Postby poweroftwo » Tue Nov 19, 2013 7:55 pm

Hooray,

Yes thanks, there are changes in several places in simgear and flightgear with just a few scattered in fgdata. I attempted to limit architectural changes. Thanks for embedding the youtube link.

I will plan to add to the newsletter soon.

jeff
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

Re: Initial FlightGear / OsgEarth integration

Postby poweroftwo » Tue Nov 19, 2013 8:00 pm

ludomotico,

thanks for the feedback. I just committed and pushed the syntax fixes. Unfortunately, you and I are on the same level with our understanding of CMAKE. I have previously attempted to add the dependency to osgEarth via CMAKE but failed. For the Windows implementation, I am breaking compatibility rules by using the platform specific link pragma:

// Windows specific - link with osgEarth library
#pragma comment(lib, "osgEarth.lib")
#pragma comment(lib, "osgEarthUtil.lib")
#pragma comment(lib, "osgEarthSymbology.lib")
#pragma comment(lib, "osgEarthAnnotation.lib")

I could use some help getting these to link cross platform using CMAKE.

thanks,
jeff
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

Re: Initial FlightGear / OsgEarth integration

Postby ludomotico » Tue Nov 19, 2013 9:13 pm

These commands did the trick in Linux, but some CMake native speaker may prefer modifying CMakeLists.txt to include the libraries :)

Code: Select all
cd simgear
mkdir build
cd build
cmake -DCMAKE_EXE_LINKER_FLAGS="-losgEarthUtil -losgEarth" ..
make -j 4  # I have a quadcore
sudo make install


To build flightgear:

flightgear/src/Scenery/scenery.cxx, line 38: change "osgdb" to "osgDB"
flightgear/src/Scenery/tileentry.cxx, line 122: "unsigned int" to "(unsigned int)"
flightgear/src/Viewer/OsgEarthHeightField.cxx, lines 20, 21, 22: add gdal to the path: gdal/cpl_string.h, gdal/gdal_priv.h and gdal/cpl_conv.h
flightgear/src/Viewer/OsgEarthHeightField.cxx, line 62: change "gl/GLU.h" to "GL/glu.h"

and run the same commands as before, but the the cmake -D... thing goes:

cmake -DCMAKE_EXE_LINKER_FLAGS="-losgEarthAnnotation -losgEarthUtil -losgEarth" ..

(I have not built fgrun)

Running and testing!

env LD_LIBRARY_PATH=/usr/local/lib64 fgfs --fg-root=`pwd`/fgdata --airport=LERS --aircraft=c172p --fdm=ufo

Bugfix: some directories are created without writing permissions:

chmod 755 fgdata/OsgEarthCache
chmod 755 fgdata/OsgEarthCache/GeneratedHeightFields

As I imagined, terrain resolution in my area is low and there are clouds on the terrain :) But you can switch on and off the new terrain.

Image

I tried at KSFO and one of the high reolution sources in the US, but resolution didn't improve and I got a segmentation fault after a while.

Thank you very much! The possibilities are amazing!
User avatar
ludomotico
 
Posts: 1269
Joined: Tue Apr 24, 2012 2:01 pm
Version: nightly
OS: Windows 10

Re: Initial FlightGear / OsgEarth integration

Postby Hooray » Tue Nov 19, 2013 9:20 pm

Yeah, I embedded your video here, because I'm not sure how many non-google users can actually access google + - also, the forum (and the wiki) specifically have youtube support, which can also be used to embed videos in the "newsletter".

Regarding your patches/topic branches, those are all based on 2.12, right ?
Just asking because the instructions assume fresh cloning, while most developers would probably just add another git remote and check out your branches instead.

The Windows patch is actually a great idea, even though a bit uncommon in OSS projects, I'm sure it significantly lowers the entry barrier for testers, great job!

And to give this some wider exposure on non-Windows platforms, I'd suggest to get in touch with the d&c/superbuild maintainers, which is basically a scripted solution to build FG completely from source:
http://wiki.flightgear.org/Scripted_Com ... ian/Ubuntu
http://wiki.flightgear.org/Superbuild

Another option would be asking for the build server to also build your branches, which would also be helpful, because it's using different compilers (some running in a VM):
http://wiki.flightgear.org/FlightGear_Build_Server
http://flightgear.simpits.org:8080/

As far as I know, the build server is the real workhorse behind all the RC/release machinery, so teaching it how to build FG with osgEarth support would be useful either way, if this is something that you want to see included sooner or later.

Technically, I'm not sure if we should really be writing downloaded/cached data into $FG_ROOT, because that's been considered "read-only" on most platforms as far I'm aware - $FG_HOME would seem to be a better place, even though that would be user-specific.

Regarding a real code review, there are not many active core developers around who have touched these parts of FlightGear recently, but if you bring this up on the devel list, you'll want to look out for feedback from Mathias Frohlich, Tim Moore and FredB

some CMake native speaker may prefer modifying CMakeLists.txt to include the libraries


Normally, you would want to use target_link_libraries(fgfs LIBS...) - but it would be better to use the FindOSGEarth.cmake module instead. For reference, see VTP: http://code.google.com/p/vtp/source/bro ... 358&r=7358
https://gitorious.org/seamless/seamless ... arth.cmake

The *.cmake file would need to be copied to the CMakeModules folder in SG_SRC/FG_SRC and then you only need to add find_package(osgEarth REQUIRED) to the top-level CMakeLists.txt file, and it should try to find osgEarth - in $FG_SRC/Main/CMakeLists.txt you would then add the required libs via a cmake variable (see the header of FindosgEarth.cmake): ${OSGEARTH_LIBRARY}.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Initial FlightGear / OsgEarth integration

Postby poweroftwo » Tue Nov 19, 2013 9:33 pm

ludomotico,

Thanks for the updates. I committed your latest syntax fixes for cross compatibility, but I did not yet update the gdal path fix. My 3rdparty install does not have a gdal directory. Without more research I am not certain which is the accepted standard.

It maybe that NAIP WMS is blocked at your location. If an additional world wide source becomes available we can add it to the dialog.

osgEarth supports Bing maps too but Bing requires a license key to run.
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

Re: Initial FlightGear / OsgEarth integration

Postby Hooray » Tue Nov 19, 2013 9:34 pm

IIRC, GDAL is optional when building osgEarth, so it may differ across platforms.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Initial FlightGear / OsgEarth integration

Postby poweroftwo » Tue Nov 19, 2013 10:18 pm

Hooray,

Thanks for the information on cross platform builds and CMAKE. I will investigate.

File cache location is a good point too and easily changed.
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

Re: Initial FlightGear / OsgEarth integration

Postby Hooray » Tue Nov 19, 2013 10:27 pm

I'm also currently in the process of building everything on Debian/Linux 64 bit, and taking notes to document everything, I'd suggest to move things over to the wiki though, so that everybody can contribute - I will also let you know if there are any build related changes/patches, so that you can commit those. But for now, I'd recommend to move the patching/build/installation instructions over to the wiki: http://wiki.flightgear.org/Building_Fli ... rth_plugin

Most people able to build from source, will typically already have working copies of SG_SRC/FG_SRC and FGDATA, so that they only need to add a remote repo and a new remote tracking branch, e.g.:

$SG_SRC
Code: Select all
## save all work
git stash
git checkout next

## add a new remote alias
git remote add simperative  git@gitorious.org:fg/simgear-osgearth.git

## fetch all branches
git fetch simperative

## check out a remote tracking branch named topics/osgearth
git checkout --track -b topics/osgearth simperative/2.12-OsgEarthIntegration



$FG_SRC
Code: Select all
git stash
git checkout next
git remote add simperative  git@gitorious.org:fg/flightgear-osgearth.git
git fetch simperative
git checkout --track -b topics/osgearth simperative/2.12-OsgEarthIntegration
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Next

Return to osgEarth

Who is online

Users browsing this forum: No registered users and 2 guests