Board index FlightGear Development

Outerra Engine

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Should we switch our engine to Outerra?

Yay
26
53%
Nay
23
47%
 
Total votes : 49

Re: Outerra Engine

Postby D-ECHO » Thu Aug 04, 2016 3:49 pm

Nope didn't read the statement ;-) :-P
D-ECHO
 
Posts: 2458
Joined: Sat May 09, 2015 1:31 pm
Pronouns: Bea (she/her)
Version: next

Re: Outerra Engine

Postby chriscalef » Thu Aug 04, 2016 4:16 pm

Just out of curiosity, (I know I should probably go to the terragear department with this question...) with all the talk of the 2.0 FG terrain, does anyone know if we've stepped up our game re: the SRTM source data yet? As I recall the original FG terrain was all built using 90m SRTM data, but in 2014 I think they released 30m data for the rest of the world, and there's been 10m data for the US for quite a few years. Anybody know which dataset(s) FG is currently using?
chriscalef
 
Posts: 279
Joined: Wed Feb 20, 2013 10:28 pm

Re: Outerra Engine

Postby D-ECHO » Thu Aug 04, 2016 5:40 pm

As far as I know, terrasync is using the most recent data available for our use (license!!), so
SRTM-1 (1-Arc Second ~30m) for USA
SRTM-3 (3-Arc Seconds ~90m) for the rest of the world
SRTM v4 (I guess that's the one you're talking about) is under some CC license, making it impossible to use for the flightgear project, unfortunately :(
D-ECHO
 
Posts: 2458
Joined: Sat May 09, 2015 1:31 pm
Pronouns: Bea (she/her)
Version: next

Re: Outerra Engine

Postby Fritz » Thu Aug 04, 2016 6:04 pm

When I look at the Niagara Falls for example, it looks as if the error is much larger than 30 or 90 meters. Or, perhaps, the elevation data is correct, but the data used to crate lakes, wide rivers, and built up areas is much less precise?
Fritz
 
Posts: 283
Joined: Tue Apr 26, 2016 11:04 pm
Location: Bavaria, Germany, near ETSL
Version: 2018.3.6
OS: Windows 7 Prof.

Re: Outerra Engine

Postby Thorsten » Thu Aug 04, 2016 6:07 pm

The elevation comes from a different data set, roads and rivers (line data) from yet another one, and they're not always consistent. For reference:

The FlightGear World Scenery 2.0 was compiled from:
– ViewFinderPanoramas elevation model by Jonathan de Ferranti
– VMap0 Ed.5 worldwide land cover
– CORINE land cover 2006v16 for Europe
– Several custom land cover enhancements
– The latest airports (2013.10), maintained by Robin Peel of X-Plane
– Line data by OpenStreetMap
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Outerra Engine

Postby Fritz » Thu Aug 04, 2016 6:13 pm

Hmm, yes... now I remember flying along a deep, narrow valley in South America, where the river was correctly shown on the valley floor as a thin blue line (probably from OSM?), but a wide version of the same river was visible at least several 100 meters from where it should have been, resulting it being at a significantly higher elevation.
Fritz
 
Posts: 283
Joined: Tue Apr 26, 2016 11:04 pm
Location: Bavaria, Germany, near ETSL
Version: 2018.3.6
OS: Windows 7 Prof.

Re: Outerra Engine

Postby Nick R » Thu Aug 04, 2016 10:00 pm

I think proland looks really awesome n' all:


But I also think the next generation scenery (viewtopic.php?f=5&t=29693) will be close to being as good. At least with the texturing of the ground since we'll be able to have smooth transitions between landclasses. Not sure about roads, but that text on the ground in one of Thorsten's screenshots makes me think that we'll be able to create realistic looking roads as well as in proland. I think what I dislike the most of the current scenery is the sharp edges and corners between the landclasses.

One thing that will probably be still lacking in the next generation of scenery is a procedural mesh when you get closer to the ground for addition detail.
Hangar: fgpipistrel.org
Modelling the Pipistrel Virus SW (github, website)
Nick R
 
Posts: 173
Joined: Tue Nov 26, 2013 4:50 pm
Location: Stettler, AB, Canada
Callsign: NickR
Version: 2017.2.1
OS: Linux

Re: Outerra Engine

Postby Thorsten » Fri Aug 05, 2016 6:07 am

In all these discussions, the same things keep being conflated which need to be kept separate:

* terrain data: What is the elevation at a coordinate, what is the landcover?
* artwork: What textures and 3d models are used
* renderer: How is lighting done in the scene, how is GPU post-processing of the scene employed

If I understand the Proland website correctly, they don't give you the first two - it's a library to do the last. The data you can download from a 3rd party site under severe restrictions.

If you use Proland with the FG terrain data, you get the same misplaced roads, coastline mismatches,... you get now - because it's in the data.

Conversely, if we would use the same data (which we can't, because it manifestly is not GPL compatible) we would get the same clean placement of roads, rivers,...).

I can render an only-forest scene in FG if I go to the right place and it's going to look on par or better than what's in that video (I like our trees much better for starters, we have more diversity in the forest,...) - and I suppose I have quite a few weather and atmosphere goodies the lib doesn't have.

Then you can compare one awesome FG promotional shot with one awesome Proland promotional shot.

However, if you go elsewhere, you need different artwork - trees look different in Spain than in Finland for starers, which is why forests look different. The ground changes color and hue. The shapes of fields are different. Town layouts are different, houses look different.

Even with the best possible rendering lib in the world, you wouldn't have the artwork available - because someone has to do it in a GPL compatible way.

And that's the FG scenery in a nutshell - the renderer can do much more than you usually see, except it doesn't get consistent terrain data and it has to use stock artwork instead of hand-crafted artwork for the particular region and most of its options aren't used because nobody bothered to spend time with that region.

When you admire any promotional video, usually what you admire is the data and artwork - and you'd not get any of those if you'd actually convince anyone that FG needs a different renderer - because for both there's a viable commercial market (think of all country-specific addons for FSX or X-Plane or all commercial geodata applications...) - so you won't get them under GPL.

I doubt any of you can actually tell me how the Proland renderer differs from what we have...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Outerra Engine

Postby Thorsten » Fri Aug 05, 2016 8:14 am

As an afterthought - for the same reason, the nextgen scenery is equally likely to disappoint you. What the shader based techniques chiefly do is to add options for fine-tuning appearance - while the shader is able to do a variety of transitions between landclasses, it has to be instructed which one to use. And of course it defaults to the current scheme in the absence of such instruction.

Given that we have right now a large arsenal of tools to improve the scenery at out disposal and hardly anyone makes use of it, I'm not seeing why that should improve in the future.

There's no magical fix to good scenery - it takes work to process landclass data, and if you can't buy that work someone has to invest the time - and it takes time to do good artwork, if you can't buy it someone has to create it.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Outerra Engine

Postby Hooray » Fri Aug 05, 2016 5:01 pm

Note that even in FlightGear there is an increasing trend/tendency to do (want to) runtime generation of scenery/terrain features, such as baking textures dynamically and overlaying them as required - most of the code is actually there, it's just currently outside the SG/FG code base, i.e. much of it is part of TerraGear and was not really intended to be used at runtime, but it's now increasingly feasible to run CGAL/GDAL stuff at runtime and create/modify terrain meshes, and textures, procedurally - while using the corresponding data as input for various heuristics only - which kinda is what osgEarth is already doing.
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: Outerra Engine

Postby Thorsten » Fri Aug 05, 2016 6:15 pm

I'd be wary of creating/modifying meshes dynamically - it's a much harder job to do properly than texture compositing.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Outerra Engine

Postby Hooray » Fri Aug 05, 2016 6:48 pm

I don't disagree, the way osgEarth works, it can download GeoTIFF files (which contain DEM info) and then use that for creating a suitable mesh, it may still build so called "tile sets" and cache those to speed up things.
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

Previous

Return to Development

Who is online

Users browsing this forum: No registered users and 6 guests