20,741
edits
Using OSM Vector Data in FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Using OSM Vector Data in FlightGear (view source)
Revision as of 20:35, 30 January 2014
, 30 January 2014→Procedural Airports (psadro_gm, zakalawe, papillon81)
(→Random Buildings Scripting Interface (Hooray, Thorsten): http://forum.flightgear.org/viewtopic.php?f=5&t=16083&hilit=#p155723) |
|||
| Line 72: | Line 72: | ||
=== Procedural Airports (psadro_gm, zakalawe, papillon81) === | === Procedural Airports (psadro_gm, zakalawe, papillon81) === | ||
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://forum.flightgear.org/viewtopic.php?p=176132#p176151 | |||
<pre> | |||
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. | |||
</pre> | |||
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). | 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). | ||