Board index FlightGear Development Scenery

Scenery Draping

Questions and discussion about enhancing and populating the FlightGear world.

Scenery Draping

Postby psadro_gm » Sun Feb 03, 2013 6:51 pm

As the current terragear is in bugfix mode, I couldn't help but look forward to more scenery improvements. There has been a lot of talk about loading more and more tiles for things like orbital (or even just high altitude) flight. The advanced weather features also would benefit from more terrain being loaded in the distance.

So, this requires some form of LOD. Some people are already investigating how to load less detailed tiles, so this topic isn't really about LOD, but one of the issues with the current architecture that will most likely get in the way of any decided upon LOD design: Airport .BTG files being 'cut out' of the scenery.

What this does, is somewhat fix the terrain LOD to the airport. We can't add / remove vertices of the underlying terrain - because there is no underlying terrain - it's patched together at scenery build time.

My idea is to generate a seamless terrain, and drape the airport data on top of it at runtime. (I believe this is similar to how x-plane works). What this means is that whatever LOD the terrain is, the airport will be draped on top of it, and follow the terrain underneath, much like placing a cloth on top of a 3d object.

I've implemented the first step to achieve this - build a seamless terrain in construct. The 'trick'. is that terrain upon which an airport will lie, MUST be smoothed - the smoothing algorithm was lifted from genapts and moved into the terragear library. When genapts buillt an airport layout, it would generate the 'hole' into which the airport BTG would be placed. I have changed this so that the 'hole' is now a polygon represented by the smoothing function genapts used to create. When this smoothing polygon is loaded into construct, it generates a regular grid of decent resolution to display the smoothed terrain. It ises the smoothing function to calculate the altitude of these points, rather than the underlying raw SRTM/Array data.

The results are shown below for LIMA:

Here's how the terrain looks:

Image

And in wireframe, you can see the regular grid:

Image

Next, I'll need to save the airport polygons into a new 2d file, and then add the capability to load and drape the polys to simgear. I've described how I plan to do this here:

http://wiki.flightgear.org/TerraGear_su ... or_Draping
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 750
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Scenery Draping

Postby Soitanen » Sun Feb 03, 2013 7:23 pm

Nice idea! X-Plane really places airport layout on start up, but I didn't find there smoothing algorithms. And sometimes on some terrains really big jumps appeared on runways. Your idea is much more realistic for airport.
Also it's nice about future support of some OSM data.
Boeing 737-300. Reworked cockpit, FDM, autopilot and much more. WIP.
Boeing 737-800. WIP. Canvas PFD and ND.
Antonov An-24B. Made from scratch. Very good FDM. 3D model by Adrian. WIP.
Project Russia (some cities, based on OSM with custom objects).
Soitanen
 
Posts: 489
Joined: Sat Jun 16, 2012 6:50 am
Location: Saint-Petersburg, Russia
Version: git
OS: Linux Mint 17

Re: Scenery Draping

Postby zakalawe » Sun Feb 03, 2013 11:08 pm

Pete, I don't know what you've discussed with Chris, but you should stop at exactly this point :)

The reason is, we already have all the data to generate the ground polygons, inside FlightGear - that's exactly how the airfield chart / ground-radar work. And we can do it adaptively (more bezier interpolation on faster machines) and also get airports editable in mostly-realtime (unless the airport boundary changes).

The trick is to make an OSG 'loader' which creates the airport geometry from the apt.dat definitions, which of course is exactly what genapts does - this is why I was working with Chris to make it fast enough to run inside the loader thread, in FG.
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Scenery Draping

Postby psadro_gm » Mon Feb 04, 2013 2:18 am

Hi James,

Sounds nice, but do we already have triangulation capabilities? To drape, we're going to need to be able to intersect each poly with the triangulated terrain very closely. I've learned that polygon offset will work but only when the polys are as close to coplanar as possible. This is something that the genapt850 parser is not very good at.

I was planning some draping experiments in terragear first to see how cpu intensive it would be. If you think that would be wasteful, I wouldn't mind collaborating to do some simple polygon draping in simgear. (Like a single textured rectangle)

I'd love to fully generate the apts at runtime. LEMD is probably the most complex layout, and genapt currently takes about 2.5 seconds to generate. I imagine it could be generated in 2 stages for LOD. 1 for runways and taxiways, which are really quick, the 2nd stage for the line data which is slower.

Pete
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 750
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Scenery Draping

Postby Hooray » Mon Feb 04, 2013 2:51 am

psadro_gm wrote in Mon Feb 04, 2013 2:18 am:I'd love to fully generate the apts at runtime.


Just so that you know, fully dynamically created airports is another really long-standing scenery related idea, that's been discussed among core developer on and off for over a decade already, including David Megginson and Andy Ross:
http://www.mail-archive.com/flightgear- ... 35539.html
Andy Ross wrote:What about a purely symbolic representation? Store just centerline
and width for each taxiway, and keep the existing polygonal
representation for "tarmac" areas. Throw out the "pre-cut" airport

This means that the tile loader will be forced to do some
computational geometry at load time to decide on the actual polygons
to be rendered by OpenGL. But that's not likely to be too much --
even the biggest airpots have no more than 30 taxiways with no more
than ~4 curves on each. Figure an individual curve has no more than
10 segments, with 6 polygons for each segment (two yellow paint, four
pavement). So that's a few thousand polygons generated and intersect
per airport loaded. Not so bad, really -- note that because it can
happen in the loader thread, and therefore make good use of the
multi-dispatch multi-core CPUs that are becoming so popular these
days.

The biggest advantage is that (if you do it with the runways too) it
means that the airports can be generated at runtime and edited by the
user without doing a terragear scenery regeneration.

Andy



http://www.mail-archive.com/flightgear- ... 03349.html
David Megginson wrote:I think that it would be possible to generate airports dynamically at
runtime by cutting a hole in the mesh, but it would be a lot of work
and no one's volunteering yet. It's something we'll want to get to
eventually.


All the best,


David


http://www.mail-archive.com/flightgear- ... 09043.html
Andy Ross wrote:How about doing the light generation at tile load time, instead of
generation time? This would have big payoffs for maintenance --
someone could fix lighting configurations without regenerating the
whole tile.

My assumption would be that this process is pretty quick -- one
hitlist computation per light -- and wouldn't impact performance
noticeably.


As was said previously, X-Plane has been doing that for years - and meanwhile we may have the computing power (and idle cores!) to actually sonsider doing that in FG, too. So it would be a great addition and would quite certainly lower the entry barrier for people doing scenery development if airport changes became directly visible without having to go through the hassle of running TG tools.
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: 11312
Joined: Tue Mar 25, 2008 8:40 am


Return to Scenery

Who is online

Users browsing this forum: No registered users and 2 guests