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 FGRS » Thu Nov 21, 2013 2:36 pm

Ok that's your choice.

But,is it possible to make this system compatible with different versions of Windows? To make it compatible for Win 32 as for the Win64.


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 » Thu Nov 21, 2013 4:19 pm

obviously, it's not my choice - poweroftwo is the one developing this, but just look a the default FlightGear hardware requirements, then look at the suggested Rembrandt minimums - and now look at osgEarth doing tons of background processing and requiring a fair amount of additional RAM, at some point using a 32bit system simply no longer makes sense technically, even if it's just due to RAM requirements. We've seen reports by some 32 bit users here who've been getting segfaults because they were running out of memory in certain cirumstances.

Thus, frankly, maintaining support for 32 bit Windows is definitely do-able, but not necessarily such a good idea, we don't have any good way to track RAM usage per subsystem currently - and we're seeing enough segfaults/crashes as is. Expecting 3.0 users to be using a modern 64 bit OS and having hardware matching the requirements simply makes sense, and requires less effort than specifically supporting 32 bit platforms.

That being said, nobody is stopping you from building FlightGear from source yourself - so that you can build your own binaries, including support for 32 bit Windows.
I haven't looked at the code with 32/64 bit portability in mind, but I don't think the code itself does have any real/tough 64 bit requirements, it's just that the windows binary was compiled for 64 bit.

I just don't think that we should be providing such binaries, because we cannot easily provide the corresponding degree of end-user support.
Just look at the number of postings here from people wanting to run pre-OSG versions like 1.9 still

According to some recent discussions, FG versions post 3.0 will probably have more stringent hardware requirements, e.g. support for non FBO hardware (very old Intel GMA cards) may be explicitly dropped/discontinued. And the minimum screen resolution will be 1024x768 due to GUI restrictions.

There's also been talk about requiring a more recent OpenGL/GLSL version so that OSG can do certain optimizations automatically (=better framerates). And like I said, requiring 64 bit support makes sense due to increasing memory requirements.
None of that should stop people from building custom FG versions from source, it's well documented and we're here to help you out - and it's also the first step towards contributing to the C++ code, which is why it's a good idea for the project to teach people how to build FG from source :-)
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 FGRS » Thu Nov 21, 2013 4:47 pm

Thanks very much for making this sim more and more available only to the rich people like you are.
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 » Thu Nov 21, 2013 5:21 pm

FGRS wrote in Thu Nov 21, 2013 4:47 pm:Thanks very much for making this sim more and more available only to the rich people like you are.


I don't think you really understood what I said: 1) it's not up to me, 2) technically, it makes little sense to explicitly support 32 bit OS, 3) it's up to you to build your own 32 bit version, 4) osgEarth is just an option, not enabled by default.

It really is like asking for Rembrandt to run on 2007-era hardware - it's kinda pointless, but technically possible, and nobody is stopping you from using FG in whatever form you see fit.

Would you expect your 32 bit Windows7 OS to work on a 386 PC ? This is not at all different. FlightGear needs to progress, there's lots of old cruft in the code, new features (like this one!) cannot be easily added without making this very progress. The osgEarth work was facilitated by the original OSG port back in 2006, lots of people back then were not happy about that work and the regressions resulting from it, still you can see that OSG support really is a technology-enabler here, despite the fact that FG/OSG has higher hardware requirements than FG had in the old PLIB days. So please try to understand what's going on here, and be open-minded. What used to be expensive hardware 3 years ago has become average/modest and affordable these days, and that's also going to apply to hardware needed to fully leverage Rembrandt/osgEarth support in FG.

And: building from source is not a matter of being rich, it's just a matter of having patience to learn something new, a skill that could be useful to give something back to the project BTW :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 ludomotico » Thu Nov 21, 2013 5:29 pm

FGRS wrote in Thu Nov 21, 2013 4:47 pm:Thanks very much for making this sim more and more available only to the rich people like you are.


Not only this comment is very rude, but also I completely support Hooray here.

We are not talking about rich/poor people, but about old/modern equipment and even old/new features. There is going to be lots of new features that won't work on old versions of FlightGear, and FlightGear has to move on. In fact, the very definition of "new version" is "new functions". This is a new function, so by definition it will only work on new versions of FlightGear. It is non-sense to improve FlightGear 2.10 again. It is already improved and its name is FlightGear 2.12.

A rich developer may have different computers to test his developments: an old 32 bits Windows, a new 64 bits Windows, an old 32 bits SuSE, a new 64 bits Debian... There are not rich developers in FlightGear with that many machines. In fact, I highly doubt there is any rich developer anywhere. The main reason there is not a 32 bits Windows version is because poweroftwo, Hooray or me do not own a 32 bit Windows. We cannot (and definitely, I won't) distribute an executable that we don't know if it works fine or will burn down your computer. Besides, this is a work in progress! We can only work on our machines! And they are not 32 bits because we are not rich and we cannot afford many different machines... or have the time for it!

You seem to own a 32 bits Windows, so you can make a 32 bits version and distribute to other 32 bits users. Probably, you don't need to know how to code, you will only need to press some buttons. I'm not sure which buttons because, well, I don't have a 32 bits Windows.

If this is really a problem of money and not manners, try Linux. You won't regret it.
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 » Thu Nov 21, 2013 5:35 pm

@FGRSS: go buy a blueray-DVD/USB stick and try to teach a 1995-era computer to play/open it, it won't work - for a reason.
could it be made to work ? Yeah, one guy recently even modified a c64 to read USB flash disks - does it make sense ? Only if you are into this sort of stuff.

PS: For the sake of completeness: poweroftwo only just told me that he doesn't even have a Windows computer, he is specifically booting into a Windows VM installed on Linux/Mac OS, so there you have it.
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 ajm » Thu Nov 21, 2013 6:34 pm

Firstly, this is quite an impressive feat and very interesting, well done to the originator... as for the "64 Bit computing is for rich people", I'm not sure when I last heard such an ill-informed statement (I don't tend to listen to politicians very often ;-) )

64 bit hardware is not just common but has been the norm for roughly a decade and a 64 bit OS is completely free... If you're wealthy enough to be paying for not only the hardware but also an expensive Windows licence then you've all the cash you need to enjoy using and contributing to FlightGear.
ajm
 
Posts: 258
Joined: Wed Dec 20, 2006 6:05 pm

Re: Initial FlightGear / OsgEarth integration

Postby ludomotico » Thu Nov 21, 2013 8:22 pm

Back on topic, I can confirm the current version in git compiles in Linux without any change. The CMake file is now correct and there is no need for extra options to compile simgear or fightgear. It is still necessary to use the LD_LIBRARY_PATH trick to run the simulator. This can be fixed with this command while building flightgear, but I don't know how to modify CMakeFile.txt to include this:

cmake -DCMAKE_INSTALL_RPATH="/usr/local/lib64" ..

Downloading maps is slow, maybe it is useful to create a script/external tool to pre-cache the area around an airport.
User avatar
ludomotico
 
Posts: 1269
Joined: Tue Apr 24, 2012 2:01 pm
Version: nightly
OS: Windows 10

Re: Initial FlightGear / OsgEarth integration

Postby poweroftwo » Thu Nov 21, 2013 8:34 pm

ludomotico wrote in Thu Nov 21, 2013 8:22 pm:Back on topic, I can confirm the current version in git compiles in Linux without any change. The CMake file is now correct and there is no need for extra options to compile simgear or fightgear. It is still necessary to use the LD_LIBRARY_PATH trick to run the simulator. This can be fixed with this command while building flightgear, but I don't know how to modify CMakeFile.txt to include this:

cmake -DCMAKE_INSTALL_RPATH="/usr/local/lib64" ..

Downloading maps is slow, maybe it is useful to create a script/external tool to pre-cache the area around an airport.


Glad it is building fine.

re: poor map loading speed, which source are you running? With my setup and viewpoint low to the ground at KSFO, with no file cache available, it initially takes about 60 seconds to construct a high resolution area using input source = ArcGis. Obviously internet data rate varies and mine is quite good.
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

Re: Initial FlightGear / OsgEarth integration

Postby Hooray » Thu Nov 21, 2013 8:44 pm

performance is actually pretty good here, like I mentioned previously: 60 fps, 25ms and also about 60-80 seconds for airports/areas with "streamed" data with very little lag, obviously that will differ with internet connectivity and upstream/downstream capabilities, but also your groundspeed - especially fictional aircraft like the ufo can be a real stress-test for osgEarth here :lol:

Regarding LD_LIBRARY_PATH/setting CMAKE_INSTALL_RPATH, I think that's not a real fix, the real issue is that OSG needs to be configured/built to also look up plugins in the path specified via -DCMAKE_INSTALL_PREFIX path (which happens to be /usr/local/lib64 in a system-wide installl) - this is something that happened here too - so that the caching plugin couldn't be found initially, because I happen to have multiple OSG installations. I wasn't aware that this could be also changed when building just FG, will need to check.

@poweroftwo: I suggest to discuss the necessity of an FindosgEarth.cmake file over on the osgEarth forum, simply because most projects will traditionally provide their own files, and when I checked, I found 3-4 different versions - the QGIS file worked right away, so that's what I used. But preferably, the osgEarth guys would maintain their own FindosgEarth.cmake file and provide it to projects like cmake, OSG or FlightGear.
Projects using osgEarth, like your's, shouldn't have to copy/maintain their own files unless absolutely necessary.
That should also help fix issues related to not finding certain libraries, because the osgEarth devs are likely to know what needs changing here - I still need to investigate to find a workaround in the meantime, but they should be all set by using what we've come up with so far.
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 » Thu Nov 21, 2013 8:47 pm

I really suggest you to switch to current git version 2.99 in simgear and flightgear. A merge has very few conflicts that can be solved in 5 minutes and most of them are in the CMakeFile.txt file!

This means this can be merged into current 2.99 in no time. I'm still building flightgear but no errors so far (simgear was built flawlessly after the merge) and will report after I figure out your changes in fgdata.
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 » Thu Nov 21, 2013 8:52 pm

that is great news ludomotico, thanks for looking into it - I only skimmed through the commits yesterday and found remarkably few changes between 2.12 and the osgEarth integration branch - it's really well done, very compact integration layer in size, I was planning on checking against 2.99 next - if we can pull this off, it would greatly simplify the review process for 3.0, so this is really useful and appreciated.

BTW: I think I may have found a simple fix for the LD_LIBRARY_PATH issue, currently rebuilding and testing next.
Again, thanks for helping with this!

EDIT: No, my first fix didn't quite work, but I found this: http://www.cmake.org/Wiki/CMake_RPATH_h ... full_RPATH
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 » Thu Nov 21, 2013 9:18 pm

Here is longish tour of the Cessna 337g flying from / to KSFO with osgEarth set to ArcGis. The video is taken from my Iphone 5 staring at my Mac running Windows7 using Parallels VM. It is a flight playback so you will see some fast forwards during the dull parts.

Last edited by poweroftwo on Thu Nov 21, 2013 9:26 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 ludomotico » Thu Nov 21, 2013 9:24 pm

Well, I can confirm that a

git checkout next
git merge topics/osgearth

in simgear and flightgear produces very few conflicts (4-5 files, 2-3 lines in each file), and most of them in the CMake files. I fixed nearly all of the conflicts, if not all, using the lines in current HEAD

I removed the git history in fgdata to save space, my fault, so merging fgdata was a bit more problematic. I just copied FGDATA/gui/dialogs/osgearth.xml and directory FGDAT/Scenery/Terrain/OsgEarth, and modified accordingly FGDATA/preferences.xml and FGDATA/gui/menubar.xml. Also, remember the permission issue on the cache directories. FlightGear 2.99 runs perfectly using both the traditional terrain and new osgearth. The only small bug is that the menu entry for OsgEarth shows an empty label (empty localizing string?), but it can be selected and clicked :)
Last edited by ludomotico on Thu Nov 21, 2013 9:31 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 » Thu Nov 21, 2013 9:27 pm

probably some menu got shuffled around/renamed - there's the long-standing issue of our menu hierarchy using fixed indexes ...
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