Paul Surgeon wrote:
Well the data is available to do better taxiways.
It's called "hand drawn" data. :)
I tried to use TaxiDraw but it was too frustrating building taxiways with thousands of little rectangles just to smooth corners.
It works but it's a painful process.
Sure, the closer to reality you want to get with curves and corners, the harder it is to do with the current system, and it still doesn't look all that great because the texturing scheme gives away that there are lots of little pieces overlaying each other.
I did start coding a new taxiway and airport designer but it's long way from even the alpha stage.
I would vote for adding features to the taxidraw app. It sounds like Dave has been busy up to now just catching up with the existing format which is why he hasn't pushed forward with new stuff.
My taxiways consist of several line segments joined together by nodes.
Each node has properties such as the radius of the corner, how the center and edge lines meet the next node/intersection/runway, etc.
Also there will be a manual mode where you can draw taxiways and taxiway lines of arbitary shapes and sizes to allow for non-standard taxiways and aprons.
In short we're talking about dynamic length records and lots of them per airport.
Arbitrary polygons would be nice for many taxiway and tiedown areas. It would also be nice to specify an arbitrary polygon border of the airport property. The FG apt.dat parser can handle variable length records just fine. The rigidity of the file format comes from limitations in the x-plane parser and Robin's preference towards outputting data in fixed-column format. So we just live with that since it really doesn't hurt anything. There's no reason why we can't add our own entries that have a more dynamic format.
The hard issue with taxiways is that it would be nice to define the arbitrary concrete/asphalt areas separately from the painted lines. It would be nice from many perspectives to have these overlaid and drawn separately. The issues are 1. avoiding z-fighting with something like glPolygonOffset() but that can only work reliably if the underlying polygon structure is cut into the lines so that a line polygon always lies in the plane of an underlying surface rectangle. That get's a little hard to do. Another approach would be to cut in the yellow lines as actual geometry (i.e. make holes for them.) The down side to that is you get odd aliasing effects at a distance. Runways/taxiways are really the worst case scenario for just about any scheme you could think up. FSAA and anisotropic texture filtering definitely help minimize these problem, but are only possible to use on higher end cards.
I do not know if it's a good idea to store all the data that I can generate into the XPlane database and would they want all "our" stuff rammed in there anyway?
No, they wouldn't want our stuff, but we can either strip it out before we submit to Robin, or perhaps Robin could know to strip the stuff out himself.
On the other hand if this data was available XPlane would probably be upgraded to use it and the taxiway/airport tools could be used for both communities.
I'm sure that X-Plane would never do anything that appeared like it was thought up by FlightGear, but if it didn't appear that there was a direct link, they'd probably be ok with it. :-)
Unless of course you do a little trick that I was thinking about.
1. Find all the adjacent tiles that use the airport texture and cut them out leaving a big hole
2. Stitch in the new airport mesh
3. Fix up the holes around the edges
I haven't looked into it yet but I think it could work.
Maybe this is something that could be built into fgsd since it already has the basic framework in place for editing existing mesh.
That sounds hard ... :-|
Curt.
-- Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
