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 

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

Reply via email to