Dynamic airport generation

Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments.

several years ago (well, over half a decade...), some FG contributors experimented with extracting airport building geometry from freely available airport terminal PDF charts to automatically create buildings with the right dimensions, and they made some quite promising progress back then, see the original svg2ac discussion here: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01581.html

Objective

generating airport runways dynamically, 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.

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.

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.

Background

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 beier 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.

X-Plane has been doing that for years - and meanwhile we may have the computing power (and idle cores!) to actually consider 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.

Motivation

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 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.

Related

References