Paul Surgeon writes: > First we need to get away from "single line taxiways". > At the moment taxiways are handled like runways which limits them to > rectangular shapes. > > In short we need a vastly improved TaxiDraw or a new replacement. > The only hassle is that genairports cannot handle any new types of data so > that would need modifying too.
> Ideally the taxiways, aprons, gates, etc should be able to be inserted into > the scenery without the need to rebuild the scenery which as I understand it > is nearly impossible unless you own a super computer with gigs of RAM. > (See Jason Cox's hassles where he cannot even make a 1x1 degree tile with > 700+ > MB or RAM) > > Unfortunately all the 3D geometry and logic involved is time consuming and > not > trivial (at least not for my brain). Hi Paul, I keep meaning to reply to some of your (and Chris M's) posts about taxiways, but since they always seem to require a carefully considered reply I never seem to find the time. I'll try to finish and post this one. I very much belong to the 'keep putting one foot in front of the other' school of thought - TaxiDraw current aims to solve the immediate problem of being able to edit the data format that we have at the moment. Now that it is largely functionally complete for this, I'm also keen to turn towards the problem of how to represent the taxiways better in the sim. In particular, I'd like to see proper curved yellow lines at intersections, and curved edge radii at intersections, instead of the current kludge where multiple small segments can be used to approximate a curved edge at an intersection. I don't see that it really makes a huge amount of difference whether this is accomplished via a wysiwyg type approach such as editing a 3D airport model directly in an openGL capable editor, or via a more 'latex' type approach in terms of specifying the layout with a tool such as TaxiDraw, and then compiling the output with genapts/TerraGear. Somewhere along the line both approaches are going to have to solve a similar set of problems. >From here on, please bear in mind that my openGL knowledge is somewhat >rudimentary. I'm extremely open to suggestions and corrections. The main >problem that I can see is that the required texture set required to represent >even a small number of all the possible combinations gets much larger than it >is at the moment. If the yellow turn off lines start on the runway for >instance, then practically every runway segment needs to be duplicated twice, >once with turn-offs in one direction only, once with crossroads style >turnoffs. When the taxiway texture gets stretched to make different width >taxiways the centerline width will change, and may not match up well with the >widths of the intersection textures. Corners of different radii will require >a number of different grass/surface textures. All-in-all, this would greatly >increase FlightGear's use of a finite texture budget in the current 'load them >all at startup' scheme. I haven't even mentioned hold-line, gate and parking >markings. The way I see it, we need some way to combine the taxiway and apron markings with the physical surface texture. I don't know anything about doing this at runtime, and am open to ideas on this. However, I can see ways (in my mind, admittedly!) of doing it at airport generation time, using genapts. Genapts could interperate (sp?) hints from TaxiDraw in the extra codes about radiussed corners and intersection markings, and programatically generate custom textures from a mixture of airport grass, surface [concrete|asphalt], and taxiway marking textures. These generated textures to be stored with the airport, not in the base texture directory. The missing piece of the jigsaw is then dynamic texture loading. This only works if FlightGear loads and unloads textures as needed, otherwise the texture budget is blown. However, this is something desperately needed anyway, something I've been gradually looking at for a while, and something I'm keen to look at more rigorously. So it's not a stopper problem. Anyway, I'd be interested in constructive comment as the the feasability of the above proposed approach, or possibly other approaches to consider. Once again, it's currently intersections I'm interested in - I'd like to be able to turn off the runway at the end of the roll-out on a curved yellow centerline. > > In short the setup we have now sucks and there will be no near term solution. > One day someone will have a stab at it ... one day when the need becomes more > pressing and someone is bored. :) > I'm sure David would write us an excellent, feature filled TaxiDraw if he was > paid to do it full time. > I'd like to think that it's not too bad, and not too feature deficient at the moment for the job that it currently sets out to do ;-) > Just my late night rant/opinion. Your rants always seem eminently reasonable :-) Cheers - Dave _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d