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 poweroftwo » Thu Nov 21, 2013 9:45 pm

ludomotico wrote in Thu Nov 21, 2013 9:24 pm: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 :)


check \fgdata\Translations\en\menu.xml and make sure that <osgearth>OsgEarth</osgearth> is present. Need to add the other translations too.
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

Re: Initial FlightGear / OsgEarth integration

Postby hvengel » Thu Nov 21, 2013 9:55 pm

Hooray wrote in 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 - especial...


How does this compare to the standard scenery on the same hardware? Better, worse or about the same.
hvengel
Retired
 
Posts: 1127
Joined: Sun Dec 24, 2006 5:35 am
Location: Minden Nevada

Re: Initial FlightGear / OsgEarth integration

Postby ludomotico » Thu Nov 21, 2013 10:10 pm

Being completely unscientific, I'd say the osgearth terrain has a performance somewhere between "the same" and "slightly better". In my case it was about 30fps in both cases, but I wasn't really paying attention to the configuration. Also, remember I was only able to get low resolution terrain (living in Europe) and the osgEarth terrain doesn't use trees, random objects... At low altitudes, the traditional terrain looks better. About 3000AGL the osgEarth terrain starts looking impressive.

@poweroftwo, now it is "family time" and I can't test any more :) Will check during the weekend.
Last edited by ludomotico on Thu Nov 21, 2013 10:28 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 10:24 pm

performance-wise, I am usually getting between 50-80 fps with the default scenery on the same hardware, depending on eye-candy settings - this seems to be "locked" to ~60 now. Keep in mind that osgEarth support disables most existing eye-candy features in its current form though.

On the other hand, frame spacing is much lower and much more steady with osgEarth running for some obscure reason - I have never really used libsvn/TerraSync post 1.90 (I think I looked at it in the rsync days), so I cannot say anything about TerraSync performance in comparison, but it seems obvious that osgEarth's threaded libcurl integration is pretty solid because it's downloading all the data without any major hiccups, it's roughly at ~ 900MB now in "OsgEarthCache" and the framerate never went lower than 55 fps here.

CPU/GPU utilization seems higher and "better" in comparison, i.e. higher utilization and less lagging - obviously without any custom shaders/effects running, so it's still apples vs. oranges.

But I don't think it's fair to compare this 1:1 to our stock scenery, because the approaches are so different, and because each approach has different advantages and shortcomings (effects, shaders, buildings, cities, vegetation), which is why I previously said that I'd love to see some constructive discussion post 3.0, to see how existing features could be decoupled and generalized, to be usable in both modes. Overall, performance really is impressive for the amount of data that is getting rendered in "real time" (well, at runtime) - and it completely confirms that we should be moving more of the TG tool chain into FG, and use more and more procedurally-created scenery.

In general, given the plethora of OSGEarth related projects and efforts, the possibilities are sheer endless now because the hard integration work is mostly done, so it will be hard to match the amount of new eye-candy features brought by supporting osgEarth from now on. Editing *.earth XML file is obviously also more straightforward than dealing with TG.
Then again, the approach is different - there are huge advantages to precompiling scenery in a distributed fashion like TG does, i.e. having "offline scenery".

My guess is that it will take at least 2-3 full release cycles for this to really "compete" with our conventional scenery creation workflow, and then it's really only an option for people who have the bandwidth and horsepower (CPU, GPU and RAM). However, professional/power users will definitely be interested in this, even in its current form.

Ironically, we haven't had any major scenery rebuild in years - and suddenly we're getting new scenery and osgEarth support at the same time :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 poweroftwo » Fri Nov 22, 2013 4:14 am

ludomotico wrote in Thu Nov 21, 2013 10:10 pm:Being completely unscientific, I'd say the osgearth terrain has a performance somewhere between "the same" and "slightly better". In my case it was about 30fps in both cases, but I wasn't really paying attention to the configuration. Also, remember I was only able to get low resolution terrain (living in Europe) and the osgEarth terrain doesn't use trees, random objects... At low altitudes, the traditional terrain looks better. About 3000AGL the osgEarth terrain starts looking impressive.

@poweroftwo, now it is "family time" and I can't test any more :) Will check during the weekend.



ludomotico, thanks, enjoy your family time.

You mentioned that you don't have high resolution imagery available in your area, but I am curious, can you successfully access ArcGis and MapQuest WMS to view high resolution data sets such as KSFO, LOWI, EHAM etc.? If so, how the load performance for areas with high resolution imagery for you?
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

Re: Initial FlightGear / OsgEarth integration

Postby Hooray » Fri Nov 22, 2013 4:58 am

@ludomotico: also, if you could push your merged 2.99 SG/FG branches to some gitorious topic branch that would be useful so that we can have a look

BTW: Just testing LOWI for the first time (without any scenery installed besides the default scenery!), so far it's been taking about 2 minutes and scenery is starting to look plausible now - there was noticeable lag during the first 45 seconds (some frames taking 1-2 seconds then), and after 3 minutes it's simply starting to look awesome - but frame rate is suddenly down to ~40 fps here and frame latency is also about 45ms now, but that's with advanced weather running ...

Image
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 » Fri Nov 22, 2013 8:33 am

Simgear 2.99: ---
Flightgear 2.99: ----

(Links removed to prevent confusion. Check this message: viewtopic.php?f=6&t=21351&start=45#p194715 )

In both repositories, use the branch topics/osgearth

Please, take into account it was a quick merge and I was careless resolving conflicts. There was two #ifdef APPLE sections I cannot test. flightgear and simgear should be updated to the last version. If you modified something in your osgearth 2.12 repositories yesterday, it was not pulled. My flightgear repository also includes that telnet code we discussed yesterday :)

The fgdata repository is more problematic since last time I pulled from the official repository was weeks ago and I modified lots of unrelated things, even removing entire aircrafts. As far as I know, osgearth only modifies these files and directories: preferences.xml, gui/menubar.xml, gui/dialogs/osgearth.xml, Translations/en/menubar.xml, Scenery/Terrain/OsgEarth. Maybe a manual modification is better than pulling from my repository.

Everything seems to be working perfectly, both traditional terrain and osgearth. Anyway, I really believe poweroftwo should be the one merging to validate the conflicts. It won't take long.

BTW, after modifying \fgdata\Translations\en\menu.xml, the menu entry has now a label

I see the terrain at LOWI exactly like Hooray's snapshot, but it took about 10 minutes to load this level of detail. I never considered my internet connection slow until now...

If someone is wondering, terrain is loaded first in low resolution and then it increases gradually.
Last edited by ludomotico on Tue Nov 26, 2013 4:48 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 poweroftwo » Fri Nov 22, 2013 10:43 pm

ludomotico wrote in Fri Nov 22, 2013 8:33 am:...
Everything seems to be working perfectly, both traditional terrain and osgearth. Anyway, I really believe poweroftwo should be the one merging to validate the conflicts. It won't take long.


ok, i will merge to 2.99. Is that the same as next?
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

Re: Initial FlightGear / OsgEarth integration

Postby poweroftwo » Fri Nov 22, 2013 10:59 pm

Has anyone tested KML loading yet? Particularly interested in how it performs in Linux.

KML loading directions can be found here:
https://drive.google.com/file/d/0B_-l3k ... sp=sharing
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

Re: Initial FlightGear / OsgEarth integration

Postby Hooray » Fri Nov 22, 2013 11:47 pm

yeah, next is 2.99 - but it's a moving target, i.e. any new features end up there (until code freeze).
Which is why we may need to pull --rebase whenever something has been committed.
Haven't yet tried KML myself.
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 » Mon Nov 25, 2013 7:01 am

Here are the links to 2.99 ("next") FG / osgEarth port ready for testing:

git clone -v -b 2.99-OsgEarthIntegration git@gitorious.org:fg/simgear-osgearth.git simgear
git clone -v -b 2.99-OsgEarthIntegration git@gitorious.org:fg/flightgear-osgearth.git flightgear

still uploading this beast...
git clone -v -b 2.99-OsgEarthIntegration git@gitorious.org:fg/fgdata-osgearth.git fgdata

but here is the minimal 2.99 fgData Patch:
https://drive.google.com/file/d/0B_-l3k5Nss9PM3RoczBIRzNNTTg/edit?usp=sharing

here is the Win64 full patch for the 2.99 build. Place in installed Flightgear directory and run to overwrite Win64 version.
https://drive.google.com/file/d/0B_-l3k5Nss9PZS1Nd05nWi1JU2c/edit?usp=sharing
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

Re: Initial FlightGear / OsgEarth integration

Postby Hooray » Mon Nov 25, 2013 5:17 pm

thanks for making these available, which will surely help simplify the review process.

Referring to the current discussion on the devel list regarding UI issues and the location of the cache folder, I agree with James' comments that something like $FG_HOME/osgEarth-cache is the way to go for the time being (ideally with some option to override this to share a single cache folder among multiple master/slave instances), but I would also want to make sure that the osgEarth option in the GUI dialog makes it clear that this will require lots of downstream bandwidth - simply because some people may -at least sometimes (i.e. when traveling/abroad)- still be online using dial-up plans which charge per bandwidth/usage.

If there's any FG specific data to be saved in the osgEarth cache, it would also seem like a good idea to add some versioning info to files affected by it - i.e. in case you are using some custom-coded serialization scheme that may change between FG versions in the future, it would be prudent to encode the FG version as part of the cache - it is my understanding that the SQLite navcache is also doing that (however, it does support keeping multiple caches around for different binaries). So, just keep in mind that under certain circumstances, $FG_HOME is shared among all FG versions installed locally - thus, the caching scheme should be aware of it.

Obviously, this is a no-brainer if all the caching/serialization is handled by osgEarth itself, and not done via FG.
Also, if there's any way to query the cache folder for its size, it would be useful to write that to a property in the global property tree.
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 » Mon Nov 25, 2013 9:55 pm

If there's any FG specific data to be saved in the osgEarth cache, it would also seem like a good idea to add some versioning info to files affected by it - i.e. in case you are using some custom-coded serialization scheme that may change between FG versions in the future, it would be prudent to encode the FG version as part of the cache - it is my understanding that the SQLite navcache is also doing that (however, it does support keeping multiple caches around for different binaries). So, just keep in mind that under certain circumstances, $FG_HOME is shared among all FG versions installed locally - thus, the caching scheme should be aware of it.


The positive is that all data are standard file cache formats for osgEarth (except for the model ive's which Flightgear handles directly) stored as osgb (OSG's modern version independent binary fast load format). So they appear to load across various versions of osgEarth and are not specific to Flightgear directly.

Stuff that currently can be found in the OsgEarthCache directory. All are considered volatile but is never automatically cleared.
    * At runtime, Flightgear produces heightfields as geotiffs of nearby airports and adds to a unique osgEarth layer
    * incoming imagery for all LODs
    * elevation data for LODs
    * KML optimized OSG ive files created from the input specified Collada dae files (optional)

Obviously, this is a no-brainer if all the caching/serialization is handled by osgEarth itself, and not done via FG.
Also, if there's any way to query the cache folder for its size, it would be useful to write that to a property in the global property tree.


It would be helpful to have the UI report current file cache directory size and maybe have a "clear" button. Something to consider.

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

Re: Initial FlightGear / OsgEarth integration

Postby pommesschranke » Tue Nov 26, 2013 3:04 am

Here are the links to 2.99 ("next") FG / osgEarth port ready for testing:


thank you!
I git cloned , compiled & installed everything (incl. fgdata) but when I start fgfs I get a "version check faild":
fgdata is 2.11.0 and I need 2.99.0

then I used the fgdata-folder that I had before and copied the "gui" folder into it,
but I cannot find the menu entry for osgEarth.

Is osgEarth enabled or disabled by default?
can I enable it via command-line or property-tree ?
pommesschranke
 
Posts: 1117
Joined: Sat Apr 27, 2013 8:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Kubuntu 22.04

Re: Initial FlightGear / OsgEarth integration

Postby poweroftwo » Tue Nov 26, 2013 3:45 am

I was not able to upload the full 2.99 fg data. So you can use the following to overwrite these few files in fg data.

but here is the minimal 2.99 fgData Patch:
https://drive.google.com/file/d/0B_-l3k ... sp=sharing
poweroftwo
 
Posts: 100
Joined: Tue Mar 05, 2013 4:35 am
Location: USA - Alabama

PreviousNext

Return to osgEarth

Who is online

Users browsing this forum: No registered users and 2 guests