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.

Re: Initial FlightGear / OsgEarth integration

Postby Hooray » Tue Nov 19, 2013 11:33 pm

okay, here's a quick patch for simgear that uses the "FindOSGearth.cmake" file from QGIS - I only tested this on Linux/Debian, I don't have any way to test this on other OS, so this may actually BREAK support for other OS (so please check prior to committing), there are a 2-3 different FindosgEarth.cmake modules available, so we may need to do some testing and integration (but the QGIS file is straightforward to change/extend):

https://github.com/qgis/QGIS/blob/maste ... ARTH.cmake
Code: Select all
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 4ed9e85..0adc0a1 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -114,6 +114,7 @@ option(ENABLE_RTI       "Set to ON to build SimGear with RTI support" OFF)
 option(ENABLE_TESTS     "Set to OFF to disable building SimGear's test applications" ON)
 option(ENABLE_SOUND     "Set to OFF to disable building SimGear's sound support" ON)
 option(ENABLE_PKGUTIL   "Set to ON to build the sg_pkgutil application (default)" ON)
+option(ENABLE_OSGEARTH  "Set to ON to build with osgEarth support (default)" ON)
 
 if (MSVC)
   GET_FILENAME_COMPONENT(PARENT_DIR ${PROJECT_BINARY_DIR} PATH)
@@ -182,7 +183,15 @@ if(SIMGEAR_HEADLESS)
 else()
     message(STATUS "SimGear mode: NORMAL")
     find_package(OpenGL REQUIRED)
-   
+
+    if(ENABLE_OSGEARTH)
+    message(STATUS "osgEarth support enabled, looking for dependencies...")
+    find_package(OSGEARTH REQUIRED)
+    if(OSGEARTH_FOUND)
+   message(STATUS "Okay, osgEarth found via CMake:${OSGEARTH_LIBRARY}")
+    endif(OSGEARTH_FOUND)
+    endif(ENABLE_OSGEARTH)
+
     if (ENABLE_SOUND)
         find_package(OpenAL REQUIRED)
         message(STATUS "Sound support: ENABLED")
@@ -395,6 +404,8 @@ endif()
 if(NOT SIMGEAR_HEADLESS)
     set( TEST_LIBS
         SimGearScene
+   ${OSGEARTH_LIBRARY}
+   ${OSGEARTHUTIL_LIBRARY}
         ${TEST_LIBS}
         ${OPENGL_LIBRARIES})
 endif()
diff --git a/simgear/CMakeLists.txt b/simgear/CMakeLists.txt
index 096d018..68ec2f0 100644
--- a/simgear/CMakeLists.txt
+++ b/simgear/CMakeLists.txt
@@ -87,7 +87,8 @@ if(SIMGEAR_SHARED)
             ${OPENSCENEGRAPH_LIBRARIES}
             ${OPENAL_LIBRARY}
             ${OPENGL_LIBRARY}
-            ${JPEG_LIBRARY})
+            ${JPEG_LIBRARY}
+       ${OSGEARTH_LIBRARY})
     
         install(TARGETS SimGearScene LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR})
     endif()
diff --git a/simgear/scene/util/CMakeLists.txt b/simgear/scene/util/CMakeLists.txt
index 4a46bad..704dcd8 100644
--- a/simgear/scene/util/CMakeLists.txt
+++ b/simgear/scene/util/CMakeLists.txt
@@ -64,6 +64,6 @@ if(ENABLE_TESTS)
 
 add_executable(test_parse_color parse_color_test.cxx )
 add_test(parse_color ${EXECUTABLE_OUTPUT_PATH}/test_parse_color)
-target_link_libraries(test_parse_color ${TEST_LIBS})
+target_link_libraries(test_parse_color  ${TEST_LIBS})
 
 endif(ENABLE_TESTS)



Apparently, osgearth/util is only used in a unit test currently ? Otherwise, it would also need to be added to the SimGearScene section.

there were some minor build warnings:

Code: Select all
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx: In constructor ‘simgear::OsgEarthHeightCache::OsgEarthHeightCache(double, unsigned int)’:
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:311: warning: ‘simgear::OsgEarthHeightCache::m_CellResolutionRad’ will be initialized after
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:296: warning:   ‘unsigned int simgear::OsgEarthHeightCache::m_MaxSize’
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:123: warning:   when initialized here
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:321: warning: ‘simgear::OsgEarthHeightCache::m_EarthMapNode’ will be initialized after
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:318: warning:   ‘osg::observer_ptr<osg::CoordinateSystemNode> simgear::OsgEarthHeightCache::m_EarthCoordinateSystemNode’
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:123: warning:   when initialized here
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:348: warning: ‘simgear::OsgEarthHeightCache::m_Contrast’ will be initialized after
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:330: warning:   ‘bool simgear::OsgEarthHeightCache::m_IsWithinTolerance’
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:123: warning:   when initialized here
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:330: warning: ‘simgear::OsgEarthHeightCache::m_IsWithinTolerance’ will be initialized after
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:305: warning:   ‘bool simgear::OsgEarthHeightCache::m_IsHeightFieldDirtyFlag’
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:123: warning:   when initialized here
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:305: warning: ‘simgear::OsgEarthHeightCache::m_IsHeightFieldDirtyFlag’ will be initialized after
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:299: warning:   ‘std::string simgear::OsgEarthHeightCache::m_OsgEarthCachePath’
/home/hooray/sources/simgear/simgear/scene/util/OsgEarthHeightCache.hxx:123: warning:   when initialized here



PS: i didn't have to make any GDAL related changes so far, but I happen to have the GDAL headers installed system-wide ...
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 Hooray » Wed Nov 20, 2013 12:01 am

Okay, here's the flightgear changes needed to make everything build/link on Debian/Linux 64bits:

(save the raw file in FG_SRC/CMakeModules: https://github.com/qgis/QGIS/blob/maste ... ARTH.cmake )
Code: Select all
diff --git a/CMakeLists.txt b/CMakeLists.txt
index ffd1018..f81b15b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -199,6 +199,7 @@ find_package(OpenGL  REQUIRED)
 find_package(OpenAL  REQUIRED)
 find_package(GDAL    REQUIRED)
 find_package(OpenSceneGraph 3.0.0 REQUIRED osgText osgSim osgDB osgParticle osgFX osgUtil osgViewer osgGA)
+find_package(OSGEARTH REQUIRED)
 
 if(ENABLE_FGADMIN)
     find_package(FLTK)
diff --git a/src/Main/CMakeLists.txt b/src/Main/CMakeLists.txt
index a70595c..df04403 100644
--- a/src/Main/CMakeLists.txt
+++ b/src/Main/CMakeLists.txt
@@ -110,6 +110,8 @@ target_link_libraries(fgfs
    ${SIMGEAR_CORE_LIBRARY_DEPENDENCIES}
    ${SIMGEAR_SCENE_LIBRARY_DEPENDENCIES}
    ${PLATFORM_LIBS}
+   ${OSGEARTH_LIBRARY}
+   ${OSGEARTHUTIL_LIBRARY}
 )
 
 install(TARGETS fgfs RUNTIME DESTINATION bin)
diff --git a/src/Viewer/OsgEarthHeightField.cxx b/src/Viewer/OsgEarthHeightField.cxx
index 94f1d9b..5911b8f 100644
--- a/src/Viewer/OsgEarthHeightField.cxx
+++ b/src/Viewer/OsgEarthHeightField.cxx
@@ -16,12 +16,12 @@
 #include <osgDB/ReadFile>
 #include <osg/MatrixTransform>
 
-#include <GL/GLU.h>
+#include <GL/glu.h>
 
-#include <cpl_string.h>
-#include <gdal_priv.h>
-#include <cpl_conv.h>
-#include <ogr_spatialref.h>
+#include <gdal/cpl_string.h>
+#include <gdal/gdal_priv.h>
+#include <gdal/cpl_conv.h>
+#include <gdal/ogr_spatialref.h>
 
 #include <simgear/scene/util/OsgEarthHeightCache.hxx>
 #include "OsgEarthHeightField.hxx"

Last edited by Hooray on Wed Nov 20, 2013 12:12 am, 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 Hooray » Wed Nov 20, 2013 12:11 am

poweroftwo wrote in Tue Nov 19, 2013 9:33 pm: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.


On Unix it seems to be right, not sure about precompiled Windows SDK packages - but how about using an #ifdef WINDOWS here ?
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 » Wed Nov 20, 2013 12:13 am

good idea. Will do.
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

Re: Initial FlightGear / OsgEarth integration

Postby f-ojac » Wed Nov 20, 2013 11:57 am

Very nice and promising...
f-ojac
 
Posts: 1304
Joined: Fri Mar 07, 2008 10:50 am
Version: GIT
OS: GNU/Linux

Re: Initial FlightGear / OsgEarth integration

Postby ludomotico » Wed Nov 20, 2013 12:23 pm

poweroftwo wrote in Tue Nov 19, 2013 9:33 pm:osgEarth supports Bing maps too but Bing requires a license key to run.


Is it possible to request a license key per user? In this case, users interested in Bing can request the license key and set it in a property or configuration file.

Besides, I agree with Hooray: you are using a directory in fgdata to cache the files, and this doesn't seem right since it is read-only on many systems. Did you fix the permissions on these directories? Remember the bug I reported yesterday: the cache directories were created with wrong permissions. This produces lots of warnings the first time you run fgfs (the downloaded tiles cannot be cached), and an irrecoverable error the second time you run fgfs with osgEarth activated.

Manually changing the directory permission fixes the issue, but I believe you must fix the bug in your code.
User avatar
ludomotico
 
Posts: 1269
Joined: Tue Apr 24, 2012 2:01 pm
Version: nightly
OS: Windows 10

Re: Initial FlightGear / OsgEarth integration

Postby stuart » Wed Nov 20, 2013 2:29 pm

Hi poweroftwo,

Just coming to this thread a bit late (I've been away from FG for the last month or so). To echo what Hooray said - this is very exciting work and a great demonstration of what we can do leveraging other Open Source software.

I'd suggest posting this to the -devel list, as that is where you'll manage to reach more of the graphical gurus that Hooray mentioned (Matthias, Tim Moore, Fred B)

Bravo!

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Initial FlightGear / OsgEarth integration

Postby TP. » Wed Nov 20, 2013 4:34 pm

Hello guys,

I have a Toshiba SATELLITE L505-12W, and it is Windows7, Pentium(R) Dual-core CPU T3400 2.10GHz.
I don't know if it can work with 64bits, can you tell me if it does, and how? :? If it is impossible can you give a link for a 32bits version of OsgEarth please? :|

Thank you.

-João
User avatar
TP.
 
Posts: 2
Joined: Fri Oct 11, 2013 7:09 pm
Location: Portugal
Callsign: TP
Version: 2.12
OS: Windows 7

Re: Initial FlightGear / OsgEarth integration

Postby Hooray » Wed Nov 20, 2013 6:17 pm

it's a 64bit CPU (just google your laptop specs) - now you only need to check if your OS is 64 bit too.
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 » Wed Nov 20, 2013 9:02 pm

Updated simgear and flightgear CMake changes per Hooray.

Would be great is someone could pull the repos and try building in Linux.

thanks,
jeff
Last edited by poweroftwo on Wed Nov 20, 2013 9:08 pm, edited 1 time in total.
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

Re: Initial FlightGear / OsgEarth integration

Postby poweroftwo » Wed Nov 20, 2013 9:04 pm

ludomotico wrote in Wed Nov 20, 2013 12:23 pm:
poweroftwo wrote in Tue Nov 19, 2013 9:33 pm:osgEarth supports Bing maps too but Bing requires a license key to run.


Is it possible to request a license key per user? In this case, users interested in Bing can request the license key and set it in a property or configuration file.

Besides, I agree with Hooray: you are using a directory in fgdata to cache the files, and this doesn't seem right since it is read-only on many systems. Did you fix the permissions on these directories? Remember the bug I reported yesterday: the cache directories were created with wrong permissions. This produces lots of warnings the first time you run fgfs (the downloaded tiles cannot be cached), and an irrecoverable error the second time you run fgfs with osgEarth activated.

Manually changing the directory permission fixes the issue, but I believe you must fix the bug in your code.



Yes, Bing keys can be requested per user. I think you can quickly get a free temporary key. Btw, the Bing Terms limit file caching so osgEarth will not save Bing file caches.

I have not yet addressed the file cache location. Will update.
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

Re: Initial FlightGear / OsgEarth integration

Postby poweroftwo » Wed Nov 20, 2013 9:07 pm

stuart wrote in Wed Nov 20, 2013 2:29 pm:Hi poweroftwo,

Just coming to this thread a bit late (I've been away from FG for the last month or so). To echo what Hooray said - this is very exciting work and a great demonstration of what we can do leveraging other Open Source software.

I'd suggest posting this to the -devel list, as that is where you'll manage to reach more of the graphical gurus that Hooray mentioned (Matthias, Tim Moore, Fred B)

Bravo!

-Stuart



Stuart,

thanks. Ok I expect to open discussions in devel sometime soon.

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

Re: Initial FlightGear / OsgEarth integration

Postby FGRS » Wed Nov 20, 2013 9:15 pm

I would like to suggest one more thing.

The system it self is just woow,but to make it available ONLY to Win 64 and FGFS 2.12 users is not really fair. It would be a very good thing to make this system more compatible for other systems,and different versions of the FG. Like Stuart said,this system really shows what can be done.. :D

Keep up good work.

Cheers.
FGRS
 
Posts: 96
Joined: Sat Nov 02, 2013 4:04 pm
Location: LQBK
Callsign: UAV001
Version: 2.8
OS: Win XP

Re: Initial FlightGear / OsgEarth integration

Postby Hooray » Wed Nov 20, 2013 10:04 pm

@FGRS: It is based on 2.12, so to be merged upstream (2.99) it will NEED to be adapted - but I wouldn't hold my breath for anything under 2.12, that simply doesn't make sense technically, and would also mean much more work, for very little gain (if any). Personally, I don't see any merit in backporting things, targeting 3.0 alone would be a great undertaking, and very worthwhile. As a community, we simply don't have the resources to provide services like of backporting, maintenance or end-user support for old versions. There's a reason why we encourage people to always run the latest stable version, and it makes sense - there are only two releases per year, it's not too much to ask people to run the latest code, otherwise we couldn't get anything done here, we don't have the manpower to pull off something like that.

@poweroftwo: Thanks for committing my proposed changes, will re-build again and report back for testing purposes.
I think there's still the issue of OSG installations not installed system-wide, requiring LD_LIBRARY_PATH magic to find the osgEarth caching plugin - like I mentioned, that's something that would need to be changed during configuration time, to ensure that OSG also searches in CMAKE_INSTALL_PREFIX, that's how it's working here ATM.

Actually, it's not such a bad idea to get forum users involved to help ensure that osgEarth support builds across all major platforms, on the other hand, developers can obviously better help with coding/integration related issues, especially if the idea is to get this reviewed in time for the 3.0 code freeze/deadline, which I really hope to be the case!

I'm not sure if there are currently any 3D rendering experts around, besides Mathias, who seems to be busy with HLA stuff - so not sure how many people we really have to help review this.

So far, I have found performance to be remarkably good: ~60 fps and 25ms, even in locations without any installed "scenery", and without TerraSync running.

If you want to see this committed for 3.0 without an overly painful review process, I suggest to keep things entirely optional and all non-default code paths (anything specific to osgEarth) disabled to make the review process more straightforward - at the moment, I don't see any osgEarth related stuff running here - so maybe you're already there, haven't looked at the code in question, but if you are really just initializing things via the "enable osgEarth" checkbox/listener, then you have done a great job and your code is much more future-proof than most existing subsystems ! :D

If that isn't yet the case, I suggest to look at the way Stuart's random buildings code and vegetation support is implemented, which should get you on the right track.

Regarding the cache, I agree that this should be improved - ideally, moved outside FGData.

On the other hand, $FG_HOME may also not be such a perfect place, especially for any complex multi-instance setups where fgfs instances are set up and synchronized in a master/slave fashion (which is fairly common among power users, or during FSWeekend/LinuxTag), that's where people would probably want to use some shared location, such as SMB/NFS shares. But for starters, $FG_HOME should be a good choice, maybe in combination with a --prop: option to override things on demand.

From a scenery development standpoint, I would love to see some form of discussion between you and the TerraGear guys, who're obviously using the pre-compiled approach to scenery generation (psadro_gm and papillon81). However, psadro_gm and Zakalawe mentioned various times that they'd love to do runtime scenery generation at some point, like you're doing it now:

Subject: Scenery Draping
psadro_gm wrote:
zakalawe wrote:Pete, I don't know what you've discussed with Chris, but you should stop at exactly this point :)

The reason is, we already have all the data to generate the ground polygons, inside FlightGear - that's exactly how the airfield chart / ground-radar work. And we can do it adaptively (more bezier interpolation on faster machines) and also get airports editable in mostly-realtime (unless the airport boundary changes).

The trick is to make an OSG 'loader' which creates the airport geometry from the apt.dat definitions, which of course is exactly what genapts does - this is why I was working with Chris to make it fast enough to run inside the loader thread, in FG.

I'd love to fully generate the apts at runtime. LEMD is probably the most complex layout, and genapt currently takes about 2.5 seconds to generate. I imagine it could be generated in 2 stages for LOD. 1 for runways and taxiways, which are really quick, the 2nd stage for the line data which is slower.

Pete


Besides, we also have guys working on improved generation of procedurally-created vegetation, road networks, bridges and buildings/cities, which are other areas that could greatly benefit from a little coordination with osgEarth support in FlightGear, to ensure that a generic approach is found over time and to avoid a "technology lock-in", like some people are complaining about related to Rembrandt.

But I realize that this is better something for post 3.0.

Overall, this really is a terrific contribution and like Stuart said, it shows the power of leveraging existing OSS solutions and integrating them with FlightGear. I think the possibilities are literally endless here, like Michat suggested earlier. We're finally at a point where hardware has become so powerful, that these things have become possible, even without using a purely pre-tesselated approach to scenery generation, and I'd love to see this pursued - TerraGear has always been a complex and "frightening" tool chain, and seeing some of it moved into fgfs as dedicated subsystems would be awesome.
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 Hooray » Thu Nov 21, 2013 4:35 am

Some more testing feedback: Under some circumstances there's the problem that aircraft may get stuck in the terrain layer, especially when using reset or when repositioning the aircraft, i.e. using a location for which no cached data is available, which is when the aircraft will be placed at MSL (presumably, not checked) and then getting stuck once the terrain is loaded and built (on top!)- I *think* this should all be possible to delay by not setting the fdm-initialized property, until there's sufficient height data available for the current position, including a range of ~1000 ft.
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

PreviousNext

Return to osgEarth

Who is online

Users browsing this forum: No registered users and 4 guests