Hi Y'all,
I hope you'll forgive my crashing the FG-dev list...I work with Austin
on X-Plane and am working closely with Robin on the new apt.dat
revisions ("version 850") for X-Plane.
I just wanted to make a few comments on how this format has evolved that
might be of bearing to future FG development:
- After going in circles quite a few times, we've ended up with an
apt.dat that remains relatively high-level. There is almost no
customization allowed in the apt.dat 850 (which is similar to past
apt.dat files). If you say you want "taxi lights", the sim decides what
they look like.
I think that this will turn out to be a good thing for FG and for any
hope of data sharing between flight sims; it leaves you guys with a lot
of latitude to decide how to implement the various features and to
optimize the results in ways appropriate to your own technology. For
example, you aren't stuck with a requirement to allow certain parameters
just because it seemed like a good idea in X-Plane.
For X-plane we expect our authors to make truly detailed custom airports
using our regular scenery-modeling facilities, which allow for lower
level customization and tweaking. It seems to me that the success of
the apt.dat files (in that users submit layouts and they get distributed
to everyone) is partly because they are simple and high level.
- Our new unit for taxiways is a "bezier polygon" - that is a simple
polygon with holes where each segment may be a bezier curve. We chose
this because it is again high level - the number of triangles will be up
to the sim (because you can choose your level of tesolation of curves)
rather than up to the author. Looking through existing layers there is
a huge amount of inefficient overlapping pavement as authors try to
simulate curves - my previous attempts to mathematically analyze such
layouts has been a real PITA.
X-Plane currently uses the glu polygon tessolator to convert polygons
with holes into triangles, and a very simple function to turn the bezier
curves into line segments. If it turns out to be useful off to you
guys, email me off list and I can provide any needed info on doing this,
although it's pretty much a straight use of glu. (My point here is just
that hopefully the bezier polygon with holes spec isn't too hard to
implement because glu can do most of the work.)
The layout does not provide ordering for pavement. I will admit that
this is very much driven by X-plane...we found that the need to draw
layouts in the order of the apt.dat really kills framerate. So the idea
of allowing holes in pavement but not guaranteeing draw order is to
encourage authors to put down taxiway pavement just once (cutting a hole
in the "bottom" layer so it doesn't overlap the top). This should also
reduce the total amount of overlapping polygons.
From a conceptual perspective, I would argue that surfaces in an
airport do not truly overlap (or if they do, it's not something that
would affect a flight sim). For our purposes, the surface of an airport
could be thought of as a planar map, where the plane is subdivided into
polygons that are homogenous...a given point is either concrete or
asphalt, not both. So any overlapping layout should be reducable to a
non-overlapping one by subtracting the "top" polygons out of the bottom
ones via holes. So I feel safe with a non-overlapping pavement model.
By comparison, the runway model _does_ overlap and runways are ordered,
because in real life we need to put the dominating runway on top of the
non-dominating one - see KBOS 4R and 9 on google maps. :-)
- I am a big believer in not putting features into the apt.dat format
that can't be visualized...my fear is that authors wouldn't be able to
validate their work and we'd end up with junk in the database. But
there's no reason why the domain of implemented features would have to
be implemented by X-Plane alone. So I would say that if you guys want
an enum code for a new type of pavement or marking or light string other
than the initial set we're spec'ing out, talk to Robin and perhaps it
can go into his database for FG first and X-Plane could catch up.
Uh, that's all I can think of for now...feedback or flames, please email
me off list. I'd like to just end by saying that LR is not a terribly
secretive company and I think that exchange of ideas between FG and
X-Plane is positive for both sims. :-)
*cheers*
Ben
--
Scenery Home Page: http://scenery.x-plane.com/
Scenery blog: http://xplanescenery.blogspot.com/
Plugin SDK: http://www.xsquawkbox.net/xpsdk/
Scenery mailing list: [EMAIL PROTECTED]
Developer mailing list: [EMAIL PROTECTED]
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
