Advanced Airport Customization

Ben says: this is an exerpt of an email with a user who had some questions on how to overcome the limits of the airport system -- he had some good questions...I still need to clean this up!

> Is there a command for making efficient tiled lines? or are x-planes > line markings just stretched textures?

Yes - a bezier curve with a .lin file will do the exact same thing as the taxiway lines: they are both draped bezier curves. In fact, search for .lin files in Resources/default scenery/sim objects. The taxiway lines are implemented as .lin files that are exported in the library.

So simply put a polygon in an overlay DSF whose polygon is lib/airport/lines/1_single_taxi.lin and you get a taxi line - it looks exactly the same.

(Basically the DSF loader and apt loader both funnel into the same part of the rendering engine - those .lin files are used by the apt loader.)

So you can make your own .lin types with your own texes - they will be as good as our taxi lines.

> Further and a Bit off topic can we include a set of local default > replacement textures in a scenery pack (think RED rwy centre lines and > markings etc in Greenland)?

No. I have not created a way to modify the runway textures because

(1) I believe that their UV mapping/scheme will not be stable long enough to justify doing so...that is, we'll break them as soon as people use them and

(2) the alternate implementation is just as efficient as ours.

The alternate implementation is to

1. use a series of draped polygons (orthophoto style - that is, author provides the UV coordinates) and

2. add a "transparent" runway in the same location.

The transparent runway pavement type was in fact invented to allow authors to make their own runway art...the transparent runway provides ONLY the parts you can't build:

- approach lights. (you can add individual approach lights via a DSF overlay, but you can't set the rabbit timing sequence, etc.) - named runway ends for global airport dialog box. - visibility in non-textured map views.

Using your draped polygons will be better and worse than our implementation:

- Slightly better: you can atlas up your textures into a 1024x1024, for fewer textures. We haven't done this yet, which makes our runways lame. - Slightly worse: we put down the rubber marks and pavement in one pass. you'll have to use two polygons and LAYER_GROUP control. But then, this is a relatively small cost.

> An example of this is taxi way light density on corners. In future > control over this would be welcomed.

Well, a few things:

1. The current algorithm is bad...it's buggy, I need to fix it! 2. You can already do this, sort of, by manually placing the lights (they are OBJs) where you want them. You would simply set the curved part of the line to have no lights and build the curve yourself.

(2) may seem extreme, but the implication is that if I fix (1) and it's STILL not what you want, then you can do (2).

There is also a DSF-based "string of lights" (STR) primitive - again, look in the sim objects package to see OUR .str file. I believe that the DSF polygon paramete controls spacing, so you might be able to simply place our STR (used via the library) with your own spacing, as an intermediate option.

(Note that the spacing problem we have now will still get you - what is happening is the spacing is done in bezier parametric units, not meters. Once we fix this, the taxi lights will look better and DSF spacing control on a .str will be fixed.)