Board index FlightGear Development Scenery

Scenery development and updating.

Questions and discussion about enhancing and populating the FlightGear world.

Scenery development and updating.

Postby jam007 » Wed Jun 07, 2017 11:48 am

Reading this I remember also wondering about scenery updates and airports. Saw that a couple of years ago a X-plane user, LeifOh, improved all (?) Swedish airports. As I understand it the airport-layout are shared between FG and X-plane but the improvements LeifOh made are not in FG (maybe some are but many not). So, how does scenery updating work in FG? And how is the relationship between X-plane layouts and FG?
Is it possible to help update scenery without a server farm?
jam007
 
Posts: 579
Joined: Sun Dec 16, 2012 11:04 am
Location: Uppsala, Sweden
Callsign: LOOP
Version: 2020.4.0
OS: Ubuntu 22.04

Re: Scenery development and updating.

Postby Thorsten » Wed Jun 07, 2017 12:13 pm

I'm not sure what part of the question wasn't answered previously, but to say it again:

Terrain needs to be compiled from geodata via terragear. When someone updates X-plane, the source changes, but without compilation the result you get in-sim does not.

You can always run terragear for a limited patch of terrain. This works reasonably fast and gets you a tile with the updated airport layout, but has no adjacency information - landclasses and elevation is discontinuous at the tile boundaries, in other words you generate ugly seams.

If you want seamless terrain, the only way out is to run for a continuous landmass - a job that has historically taken weeks to months of runtime. There's a decision made by the FG developers that we won't go down the road of patchwork terrain, as this isn't future proof, so only seamless terrain (i.e. continuous landmasses) will be accepted for updates of terrasync (there's also the issue of keeping airport position data, navaid data, materials definitions etc. in sync with what is on TS which has some repository repercussions, for example updating apt.dat.gz on a git repository creates 26 MB of binary history every time we do it, so after updating 100 airports manually, we'd have 2.6 GB of pointless repository history - so updates are moderately problematic in the first place).

If you want actual updates (like incorporate new geodata sources) to make better terrain, a whole new can of worms opens up (I remember the statement that the world is so large, every pathological case one can dream of doesn't happen once but dozens of times) - the toolchain needs manual tweaking to eliminate the issues. Typically there have been several test runs for a 'large' area to get rid of these issues before a 'full' run.

Given that, re-running 'Sweden' in a seamless way would involve running Europe and Asia - unless you don't need your computer for a really long time, a computing cluster would be the tool of choice.

Now, the person who brought tons of resources into the FG terrain (Martin Spott) isn't contributing any more, so there's that. And most other people able to run scenery seem to prefer their own patches of custom scenery rather than to contribute to a global re-run.

Thus, currently there's no focus on re-running existing terrain but rather on next-generation terrain which has LOD and uses raster images rather than vector structures to encode landclasses.

You can (within the constraints) contribute to the current scenery by re-running smaller continuous landmasses - islands for instance. I believe the Azores have been updated, the Canarias are in progress,... However these efforts are expected to be obsoleted by nextgen terrain (whenever it arrives).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Scenery development and updating.

Postby jam007 » Wed Jun 07, 2017 4:05 pm

Thanks! A concise explanation.

And most other people able to run scenery seem to prefer their own patches of custom scenery rather than to contribute to a global re-run.

Does this imply that it is a reasonable way to collaborate in updating the global scenery? Spreading the work on many computers?

However these efforts are expected to be obsoleted by nextgen terrain (whenever it arrives).

I have read on the Wiki+forum about this nextgen but have not been able to form a clear picture of how it will work. Eg. How does it solve the seamlessness without requiring a computer farm?
jam007
 
Posts: 579
Joined: Sun Dec 16, 2012 11:04 am
Location: Uppsala, Sweden
Callsign: LOOP
Version: 2020.4.0
OS: Ubuntu 22.04

Re: Scenery development and updating.

Postby Thorsten » Wed Jun 07, 2017 4:21 pm

I believe seamlessness in nextgen will arrive the same way as in the current scenery - by throwing good computers at the problem for a long time.

(My answer 'a farm' was to the requirement what's needed to do it all every time within a short 3 month update cycle along with the releases - if you aim at a longer update cycle you need somewhat less).

Does this imply that it is a reasonable way to collaborate in updating the global scenery?


I'm not the expert who could outline the details, but I do know that one of the reasons Martin got frustrated and quit FG scenery is that contributors didn't join the seamless world scenery effort but created their own patches - so there did seem to be a reasonable collaborative way.

Just not yielding results quite as quickly...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Scenery development and updating.

Postby jam007 » Wed Jun 07, 2017 4:49 pm

Thorsten wrote in Wed Jun 07, 2017 4:21 pm:I'm not the expert who could outline the details, but I do know that one of the reasons Martin got frustrated and quit FG scenery is that contributors didn't join the seamless world scenery effort but created their own patches - so there did seem to be a reasonable collaborative way.

From what I have seen it seems to be quite a lot of redundant work done in FG. Hangars, scenery etc. that for sometimes good but often not very good reasons are kept from the main repositories. Must be frustrating.
But also, the main drivers behind FG seems unfocused when it comes to how and where information/help and tools are available (Wiki/forum/doc/maillist/Git/SF...). It is a quite high threshold, in learning effort and time, to contribute. This could be one of the reasons that the contributions might be "privatized".
I guess this has been thought of but anyway: Is there any work/plans on something BOINC like to make it easy to help calculating scenery?
jam007
 
Posts: 579
Joined: Sun Dec 16, 2012 11:04 am
Location: Uppsala, Sweden
Callsign: LOOP
Version: 2020.4.0
OS: Ubuntu 22.04

Re: Scenery development and updating.

Postby Thorsten » Wed Jun 07, 2017 6:39 pm

It is a quite high threshold, in learning effort and time, to contribute. This could be one of the reasons that the contributions might be "privatized".


Well, it's human nature. If I write a new shader for, say, the Shuttle, I can just leave it there - the effect I want works, end of story, I got what I wanted for my effort.

Or I can put it to the data repository. Then I actually need to re-factor it, make it configurable and fit more use cases than my own, need to integrate it with the rest of the framework, need to take care that configurations I don't use still run, document it and provide support for it. And read through forum complaints that things are poorly documented.

The incentive to put such a thing to FGData is just not existent, because it works for me. The only reason to still do it is that if everyone else also does his part for the greater good we're better off than if everyone does things for himself.

It's basic game theory, the prisoner's dilemma. No matter what the others do, you're always better off if you just do your own stuff and don't care for the common good. Yet if everyone follows that maxim, we all lose, whereas if everyone does something for the common good, we all win.

If you calculate a reasonable timeframe to learn something, it can usually be done. It took me a year to write good GLSL shaders, but it was a year of hands-on experience - no documentation can replace that. It took me two hours to learn to use the FG particle system. A month to figure out how canvas really works. A few days to learn how to use JSBSim for the flight dynamics (yeah, that was love on first sight....).

If you expect to churn out new scenery after a day, you'll be disappointed - but I believe if you take two weeks to learn it, you'll get somewhere with the tutorials provided. And maybe after a year you'll be quite good at it.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Scenery development and updating.

Postby jam007 » Wed Jun 07, 2017 9:02 pm

You just highlighted the importance to encourage people to feel part of a team.
* Learning with the help of others gives reasons to reciprocate
* Make it possible to help improve things without expert knowledge. (The scenery data base is a good example.)

Being able to give computer time for scenery generation would also be a way for users to help developers. (But then again someone has to make that possible...)
jam007
 
Posts: 579
Joined: Sun Dec 16, 2012 11:04 am
Location: Uppsala, Sweden
Callsign: LOOP
Version: 2020.4.0
OS: Ubuntu 22.04


Return to Scenery

Who is online

Users browsing this forum: No registered users and 6 guests