Hi Yves,
The general approach that genapts uses this.
Start with a simple square polygon representing the airport area. As we
proceed and add shapes to the airport, they are subtracted from this initial
polygon. Also start with an empty polygon representing the airport shapes.
As we proceed, objects are "added" to this polygon.
Then we iterate through all the runways and taxiways for the airport. For
each 8.10 taxiway we draw the corresponding box. We "intersect" that box
with the accumulated shape polygon, so we can only cover areas that haven't
been covered already. Then we add this "intersected" shape to the airport
shape polygon and subtract it from the enclosing polygon.
We get to pick the order we process the airport surface objects, so we pick
the runways first, and probably the biggest runways before the smaller
runways. Then the bigger taxiways before the littler taxiways, etc.
Biggest/most important to smallest, least important.
In the end we have a jigsaw puzzle of all the individual shapes (so we can
texture them properly individually) as well as a master surrounding polygon
with holes cut out for all the shapes, plus a master polygon of all the
shapes. Then in the end we can cover the whole area perfectly with no
overlaps and no seams.
In addition, there is a fairly sophisticated (and I think cool) step where
we fit a natural curved surface across the airport elevation and used the
curved surface instead of raw SRTM points. This eliminates the "noise" in
the raw data and gives the airport surface a natural looking slope and
correct hills and valleys (in most cases.)
After that we generate all the light points and adjust their height based on
the fitted curved surface.
I think this approach could be updated for the 8.5 format by just generating
different polygon shapes instead of the older collection of rectangles.
The down side to the current approach is that it's hard to add markings over
the surface. Without getting into all the technical details, if you cut in
the markings into the surface structure you end up with an incredibly
complex shape with an incredible number of triangles. Bad for load speeds
and rendering speeds. If you lay the runway / taxiway markings and skid
marks over the top of the base surface, then you have a lot of issues with
z-buffer fighting and other odd graphics artifacts. Because our runway
surface is curved/sloped we just use a simple draw order trick like other
sims might use.
But maybe in the past few years people have developed better tricks and
techniques for handling this difficult problem of adding complex / arbitrary
markings to a surface in a way that looks good mostly edge on (when landing
or taxiing) and doesn't blow up your polygon count or encounter z-buffer
problems, or require odd hacks of lifting the markings high enough above the
runway that you can start to see that they are actually floating and not
attached.
Regards,
Curt.
On Fri, Sep 9, 2011 at 7:45 AM, HB-GRAL wrote:
> Am 24.08.11 17:51, schrieb Gijs de Rooy:
>
> > Btw, is the "taxiway" layer not yet implemented, or is that another
> broken thing?
> >
>
> The taxiways were broken because I first needed a way to handle the
> current 810 taxiway patchwork shapetry ...
> http://maptest.fgx.ch/screens/taxidraw.png
>
> I converted such taxiway shapes with 300 overlapping polygons and 1200
> small holes per airport to one single polygon here, and this is the
> result now on the map, i.e. EHAM:
> http://maptest.fgx.ch/screens/eham.png
>
> For now I hope that with this "cleaning" I do not miss some parts, i.e.
> where the patchwork produced completely invalid geometry, kicked away by
> grass etc.
>
> The ILS "centerlines" with valid ranges I started to calculate with a
> new library very useful for such things, just to add as a note:
> http://geographiclib.sourceforge.net/html/other.html#python
>
> Now I wrote some lazy python scripts to take lat/lon/range/heading from
> our current data to write a postgis sql dump, which gives me a valid
> table with all the ILS centerlines over the world, as line geometry for
> the map. An inconvenient way probably, but it works well ;-)
>
> Cheers, Yves
>
> PS. I am really curious how genapts "calculate" the taxiway patchworks
> and how fgfs deal with all this points. I must confess I am too lazy to
> dive into that. I am looking for an expermental way how I can create
> airport scenery without this
> "cover-an-area-with-a-number-of-different-lines". Might be ok for
> runways, but for the airport area/taxiways ... ? Maybe I miss some points.
>
>
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
