Board index FlightGear Support osgEarth

OSGearth as default scenery?

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

OSGearth as default scenery?

Postby Trisnpod » Sun Apr 10, 2016 1:16 pm

Are there any plans for the osgearth scenery to ever replace the scenery that flight gear comes with now? I'd love to use the OSGearth but I haven't got a clue how I'd manage to install it properly.
Trisnpod
 
Posts: 36
Joined: Sat Apr 09, 2016 9:54 am
Location: Sheffield, England
Version: 2016.2.1
OS: Windows 10

Re: OSGearth as default scenery?

Postby Thorsten » Sun Apr 10, 2016 1:32 pm

No.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: OSGearth as default scenery?

Postby Trisnpod » Sun Apr 10, 2016 3:24 pm

How come, is it too big a file or something? What about having it as an option either osgearth or flight gear scenery.
I have no idea about this stuff though so I don't know how hard that would be to do, especially for free.
Trisnpod
 
Posts: 36
Joined: Sat Apr 09, 2016 9:54 am
Location: Sheffield, England
Version: 2016.2.1
OS: Windows 10

Re: OSGearth as default scenery?

Postby elgaton » Sun Apr 10, 2016 3:57 pm

There are several reasons why osgEarth won't replace the default scenery:
  1. The feature is still in development - it needs to be fully tested and integrated before being ready to land in the FlightGear official builds.
  2. It requires a good graphic card; on the contrary, some people run FG on pretty low-spec machines (even on netbooks).
  3. It requires a high-speed Internet connection to stream imagery - again, something not everyone has (for example, I'm not reached easily by high-speed Internet, and am on a sort of dialup connection most of the time).
NIATCA 2nd admin, regular ATC at LIPX and creator of the LIPX custom scenery
elgaton
 
Posts: 1106
Joined: Tue Mar 19, 2013 5:58 pm
Callsign: I-ELGA/LIPX_TW
Version: Git
OS: Windows + Arch Linux

Re: OSGearth as default scenery?

Postby Trisnpod » Sun Apr 10, 2016 4:11 pm

Thanks for the reply, seems sensible then to keep to the current scenery at the moment.
Trisnpod
 
Posts: 36
Joined: Sat Apr 09, 2016 9:54 am
Location: Sheffield, England
Version: 2016.2.1
OS: Windows 10

Re: OSGearth as default scenery?

Postby Thorsten » Sun Apr 10, 2016 4:15 pm

How come, is it too big a file or something?


The developer community don't seem convinced that it's the way to go. Right now we have a scheme in which we know for every pixel what the terrain is - we can make planes sink in water, skies slide over snow, simulate bumpiness when landing in the field, move motorbikes over roads, let clouds form over surfaces which heat up in the sun - why'd we want to replace that by a scheme in which all we get is colored pixels?

Besides, photo-scenery looks good when you view it under the same conditions it was taken - in different light or weather you get all sorts of shadows which are out of place, dusty terrain while it is raining on it and similar visual mismatches.

If you think about it, you may come to the conclusion it's not that exciting. That's certainly my conclusion.

The optional implementation of OSGEarth has basically stalled because the person who has done it has never re-submitted the patch in response to a round of comments. So it would seem nobody is really interested enough in investing the work to make it happen.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: OSGearth as default scenery?

Postby Trisnpod » Sun Apr 10, 2016 4:22 pm

Wow, didn't realise there was that much to the scenery! What do you mean by drive motorbikes over the scenery? Is that ai motorbikes?
I'd much prefer scenery that behaves realistic (and it does look pretty good anyway) and has moving AI than one that just looks good
Trisnpod
 
Posts: 36
Joined: Sat Apr 09, 2016 9:54 am
Location: Sheffield, England
Version: 2016.2.1
OS: Windows 10

Re: OSGearth as default scenery?

Postby wkitty42 » Sun Apr 10, 2016 4:32 pm

not all craft that you can control are aircraft... there are motorcycles, cars and trucks, too... no, not AI controlled, either... ones that you get in, start the engine, figure out how to do the clutch and gear changes and driving around the sim where ever you want to go :)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: OSGearth as default scenery?

Postby hamzaalloush » Sun Apr 10, 2016 4:41 pm

we need that puch, at the same time(if you have regarder voice in the mailing list) i doubt it will pass, and we already have major opponists to this here, atlease regarding Photscenery visuals at low flight level, which i agree there are plenty :)
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: OSGearth as default scenery?

Postby Thorsten » Sun Apr 10, 2016 4:58 pm

Sorry, I didn't understand most of that.

For the status of photoscenery in FG see here and for why I think it's not a very desirable state see here.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: OSGearth as default scenery?

Postby Hooray » Sun Apr 10, 2016 6:39 pm

Thorsten is basically right - however, even if there was a holistic plan in place to favor osgEarth/photoscenery-based scenery, that would not necessarily be very representative - for instance, at some point, most core developers were contemplating/expressing interest in making Rembrandt (deferred rendering) the default startup mode - equally, others wanted to enable effects/shaders by default (which would basically lock out most people without certain hardware, absent some form of dynamic feature scaling).

In summary, the osgEarth patch is great for many things, but will not be overly useful for many use-cases that Thorsten (and Curt) mentioned in the past (see the devel list for details). In fact, for the time being, osgEarth works basically like a "black box" and it would be tons of work to make that work with existing effects/shaders in FlightGear. Realistically, osgEarth/photo-scenery is mutually exclusive with quite a few other features.

That being said, there's nothing wrong with treating it as a startup/runtime (or even build time) option so that people can make up their own minds whether they want to use/support or even develop it. Since the patch/merge request was put up for review, many months have passed - and the corresponding developer did continue working on his code (see the gitlab repository for details), but poweroftwo has also stated that he'll be busy with other work, so that he won't have too much time that he can dedicate to going through the review process again.

If you are interested in photo-scenery, and if you are able to patch/rebuild FlightGear from source, there's not too much involved in giving it a try - rebasing onto next/master is a different issue, which will require some git/C++ knowledge, but otherwise it's not rocket science.

As has been said, it will look great for /some/ situations, and it will have limitations in others - however, given the current state of affairs in the scenery department, it would probably not be a bad idea to consider providing osgEarth at least as an /option/ - just like FlightGear has other features that are mutually exclusive and that have different advantages and disadvantages (think Rembrandt vs. ALS, JSBSim vs. YASim, Basic Weather vs. Advanced Weather, PUI vs. Canvas, Nasal vs. Python etc)

(I've recently been in touch with other contributors about this specifically, i.e. providing osgEarth as an /option/ in response to Martin's decision not to provide the underlying base data for seamlessly re-generating scenery, and the feelings seem to be mixed - pretty much for all the reasons that Thorsten mentioned already. However, to be fair, it does make sense to look at someone's background/expertise and nature of involvement - e.g. it is unlikely that Thorsten will be overly enthusiastic about Rembrandt, osgEarth, Python or even a 3rd party weather engine using HLA, given his own focus of involvement/contributions (ALS, EarthView, Nasal/Advanced Weather).
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: OSGearth as default scenery?

Postby Thorsten » Sun Apr 10, 2016 7:01 pm

it would probably not be a bad idea to consider providing osgEarth at least as an /option/


I don't think anyone is fundamentally opposed to that (at least not that I'm aware of) - but someone needs to provide the patch and it has to be reviewed. It's unlikely that people who aren't really interested in a feature will go out of their way to implement it.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: OSGearth as default scenery?

Postby Hooray » Sun Apr 10, 2016 7:18 pm

I don't disagree at all - while the main benefits/use-case of having photoscenery/osgEarth support in FlightGear may seem fairly narrow, or even disputable, (depending on your interests/focus), the recent mapserver/terrasync "developments" would at least suggest that supporting additional scenery schemes/engines, even if just to improve the redundancy in the scenery department (i.e. to have a fallback scheme in place), would not be such a bad move.

I mean, let's face it, even features like Rembrandt (which can safely be considered to be unmaintained these days...) still linger around in the codebase - the osgEarth branches have seen at least /some/ activity recently: https://gitlab.com/poweroftwo/flightgea ... FG3.4-Kdis

Regarding some of the other comments made previously, it is accurate that osgEarth, by default, requires an active online connection - however, osgEarth also supports pre-caching/downloading all data and storing/reading that from a custom location, e.g. in $FG_ROOT/osgEarth.
In other words, technically, it would be possible for osgEarth "tile" data to be pre-fetched and provided as part of the base package (ignoring the GPL legalities here).

For the record, the set of osgEarth patches is at least the 3rd attempt at bringing photoscenery to FlightGear, some attempts dating back to the early 2000s (San Jose, by Curt):

Image

In fact, a number of former core developers, once suggested that scenery engines be treated like FDMs, i.e. to prepare FlightGear for supporting alternate/multiple scenery engines . An idea that was rediscovered a few years later:

Worldwind Scenery
curt wrote:From a larger perspective, there's no problem building an alternate scenery engine for FlightGear. There is enough value to photo-real, that I'm not suggesting we never consider it. But there are tremendous problems and issues to overcome, not to mention the huge size of the imagery data.

Curt.



The original idea was in response to another photo-scenery project using FlightGear, which also didn't make it back into FlightGear at the time (~2004): http://marc.info/?l=flightgear-devel&m= ... 511942&w=2

http://cg.cs.uni-bonn.de/de/publikation ... -scalable/
Image
Image
Image

The pre-osgEarth set of patches were these: http://wiki.flightgear.org/FlightGear_N ... ic_scenery
Image

In other words, there's quite a bit of interest here, as well as overlapping efforts to bring photoscenery support to FlightGear, and none of the patches have made it back into FlightGear (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: OSGearth as default scenery?

Postby curt » Sun Apr 10, 2016 7:49 pm

That's the gist of it. No one is opposed to adding support for osgEarth as long as it doesn't subtract from anything else. The issue of osgEarth is slightly complicated by the fact that Jeff built it for version 3.2 or somewhere around that time frame, it never got rolled into the main codebase at the time, again for some complicated reasons, and now we are working on version 2016.2 ... there is a gap there between the osgEarth implementation and the current development version of flightgear that no one (as far as I know) has stepped forward to fill. Also this code would necessarily touch on a lot of tricky core rendering code, so understandably, our existing developers with knowledge in that area are very cautious with changes at that core level. It sounds like Jeff (the original integrator of osgEarth ran out of energy on the project, or other priorities came along, I don't know.) Every time Hooray brings up osgEarth as an example of the process going wrong, I think about still waiting for someone to come forth with patches/port to the current code base who is willing to take feedback and make adjustments.

And has been alluded to here and in many other places ... there is a tremendous amount of work and complexity that has gone into the current scenery engine that osgEarth may not be able to address ... like we know the surface characteristics of each type of land class, roughness of grass/fields vs. tree or shrub areas which affect taxing and our landing gear model. Does osgEarth handle runway and approach lighting at night or in bad weather? That's a pretty important aspect of flight sims. Can osgEarth tell flightgear if an airplane is touching down on water or land? Photoreal scenery has a challenge where all the details and all the 3 dimensionality fuzzes away into a big messy blur when you get close to the surface. Airplanes, shadows, time of day, buildings, cars are all frozen in time in the imagery ... this may or may not look weird in some areas ... like a big full size 737 painted permanently on the runway because it was there taking off when the satellite imagery was taken. Others have mentioned the online bandwidth requirement might not suite every person's situation. I don't say any of this to discourage osgEarth or be negative towards it, just to try to help craft end users expectations of what it might be able to do for them. osgEarth can lead to some very compelling vistas at altitude, and I'm sure there are many other good reasons to have it available, no one has stood in it's way or vetoed it or even discouraged it's development as far as I know.

In the end, osgEarth needs to find someone knowledgeable at the graphics level who has the time and energy to port all the changes to flightgear 2016.2 and then be willing to entertain feedback from existing knowledgeable developers and make corresponding adjustments to their work so it can fit into the overall scheme with minimal disruption.

Here are a few more tips, and I know these and others have been discussed many times previously ...

It is good to submit patches in small self contained bundles so that people who would review the changes can manage to see and understand what is going on. Dropping a big massive change that touches dozens and dozens of files in significant ways is very very difficult to review. Developers do not like to be pressured to "just do it", "just commit it" ... we are all volunteers right? Some of us have a compulsion to understand what we are doing before we are comfortable doing it. :-) There are a very small number of people on the forum who prefer to be adversarial, but FlightGear has always been a good group of people trying their best with limited resources of time and energy, so please be patient, and don't feel bad about sending reminders if something isn't getting attended to as quickly as you like. FlightGear started in late 1996, early 1997 ... so that's 19 years if I did the math right? That's enough time for many things to change. Subject matter experts can come and go. Key/core developers sometimes move on, leaving a knowledge gap. People have kids, or get married or get a new job or go to school or have all kinds of major life changes that affect how much the can or can't contribute. No one is getting paid for working on FlightGear, we are all volunteering our time. It's good to be aware of that and treat developers with kindness and grace and understanding that time and energy can often hit it's limits in our busy lives. I was something like 27-8 years old when we started FlightGear ... do the math ... a whole lot of life has happened in the meantime. I got my master degree since flightgear started, 2 wonderful daughters have made their appearance, we are on our 3rd dog who is also awesome, we've moved twice, I have had several job/career changes. Among the flightgear family there have been births, deaths, weddings, new pilots licenses, graduations, and every other major life event you could image. We are all pretty normal people doing our best to get through life and meet all the challenges that come along on all fronts ... and there is just never enough time in the day.

The FlightGear project structure isn't perfect and some people have been critical from time to time ... but it is like any system ... it actually does work when everyone is cooperating, but it can also be pulled apart and damaged by people that want to do that sort of thing. Personally, I think that together (100's of developers and probably 100's of thousands of users ... download stats report 10,000 people a week downloading FlightGear) ... together we have accomplished something pretty remarkable. It's not perfect, we still have tons of things to fix and do, be still pretty remarkable for a group of volunteers that decided one day it would be a good idea to build a brand new open-source flight simulator from scratch.

At the end of the day, treating each other well (with kindess and patience and understanding) is by far the most important thing. That is true here on the forum, and true in our real world lives and families and jobs.
curt
Administrator
 
Posts: 1168
Joined: Thu Jan 01, 1970 1:00 am
Location: Minneapolis, MN

Re: OSGearth as default scenery?

Postby Hooray » Sun Apr 10, 2016 8:26 pm

Note that Jeff did rebase/update his osgEarth related patches in response to end-users requests on the forum (against sg/fg 3.4 IIRC), he just didn't re-submit his merge requests at the same, because that was coinciding with the gitorious/sourceforge migration (IIRC).

Feature-wise it is true that there simply isn't a 1:1 mapping between the existing/default scenery engine and osgEarth - however, such a disparity is also to be found in other places with mutually-exclusive features-like those I mentioned (advanced weather supports far more functionality than basic weather does, JSBSim is much more configurable than YASim is, ALS is much more actively maintained than Rembrandt is, Rembrandt supports certain kinds of shadows that ALS does not support and vice versa).

Thus, it really isn't all that uncommon to encounter such features where there simply cannot be a clean 1:1 mapping between existing features and the new engine - in fact, even our legacy UI engine (PUI) has support for features (mappings) which are not supported by the ongoing Qt5 integration.

Equally, the new Qt5 functionality is seeing improvements in areas for which there is no mapping outside Qt5, namely no PUI/Canvas or Phi bindings to bring features like the package manager up to par with the Qt5 code.

Personally, I am not sure if it's reasonable to aim for this degree of parity given the backlog of recent additions that are basically incompatible with many/most existing legacy features. Obviously, it would be great if each and every new subsystem could support existing features, but sometimes that does not even make much sense.

That being said, osgEarth is a 3rd party library/framework, so while many of the problems outlined by Curt and Thorsten are valid, they are not necessarily "ours" to address - the first two FG related photoscenery attempts were basically home-grown and FlightGear-specific, osgEarth however is a different beast, it is using OpenSceneGraph, and is widely used by other project, including some flight simulators - thus, many of the problems that Curt and others tend to emphasize, are simply not specific to FlightGear - from an integration standpoint, it would make sense to look at FlightGear related challenges and otherwise just consider it an "option" that may may decide to build/use or not - just like we can currently make up our minds what FDM/weather system or rendering framework we are using.

The original idea of coming up with an abstract SGSceneryEngine API to allow development of different engines is a sound one, and a very compelling foundation that would FlightGear let evolve beyond its current design/limitation, totally unrelated to the current MapServer/TerraSync situation, and it fact it aligns well with plans discussed by core developers to come up with renderers for different purposes: http://wiki.flightgear.org/Supporting_m ... _renderers

Whenever competing/conflicting features are brought up for review, people tend to forget that the freedom of choice is one of the key principles in open source, and particularly in FlightGear, e.g. quoting Torsten:

Subject: FlightGear GUI hell: PUI, Canvas GUI, Mongoose, Qt5 ??
Torsten wrote:I can/will not comment on everything, just this one:
Why so smart people repeat same structure, why all freesoftware structures replicate the same fork-pararell pattern ? is a social pattern behavior? it is a free radical ramdomness? it is the time-line, or our communication system that can't guarantee nuclear success and best results/efforts?

Because There is more than one way to do it..
How many FDM do we have in FlightGear?
How many weather systems do we have?
How many web browsers, e-mail clients, operating systems are on the market?
How many different types of chocolate can you coose from in an average supermarket?
And why is this so? Because sometimes it's a matter of taste, sometimes it's because people learn and products evolve over time.

So why did I start with a HTML based user interface?
Because I wanted to control FlightGear from my iPad and my Android tablet. And from my old Netbook PC. And without building or installing software on it.
And because I believe it's much more efficient to build on an existing, well established, tested, maintained and documented code base instead of creating from scratch what is already there.
And because I am convinced that building a user interface based on Canvas/Nasal is a dead-end development.

For me, the freedom of choice is heaven, not hell. Not only when looking for chocolate in a supermarket.

Torsten
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