I have received several requests for a transparent runway with a physical surface type. That request is just strange enough that we need to look back and ask, “how did we get here?”
High Level and Low Level Modeling
The “new” airport system, implemented in X-Plane 850 (with a new apt.dat spec to go with it) is based on a set of lower level drawing primitives, all of which are available via DSF. In other words, if Sergio and I can create an effect to implement the apt.dat spec, you can make this effect directly with your own art assets using a DSF overlay. This relieves pressure on the apt.dat spec to become a kitchen sink of tiny details.
The goal of apt.dat is to make a visually pleasing general rendering of airport data. DSF overlays provide a modeling facility.
Little Tricks
It turns out there are two things the apt.dat file “does” with the rendering engine that you can’t do in an overlay DSF:
-
The apt.dat file registers runways in the airport dialog box (for starting flights, positioning the airplane, etc.).
-
When the apt.dat reader places OBJs to form approach lights, it can offset their “timing base”, which is why the rabbit flashes in sequence.
(If you were to place a sequence of approach lights with rabbits in an overlay, every single light would flash at the same time because the DSF overlay format does not have a way to adjust the object’s internal timing parameter.)
The solution: the transparent runway. The idea of the transparent runway is to create with the apt.dat file the two aspects of a runway that you can’t build with a DSF overlay: the approach lights and the entry in the global airport dialog box. Transparent runways leave the drawing and surface up to you.
My thinking at the time was that the actual runway visuals and physics would be implemented together via either draped polygons or a hard OBJ.
Orthophotos and Bumps
So why do authors want a transparent but hard runway? The answer is orthophotos. With paged orthophotos, it is now possible to simply put down orthophotos for the entire airport surface area (whether as overlays or a base mesh) at some high resolution (our runways are 10 cm per pixel – I’m not sure if the whole airport area can be done at that resolution) and not have any special overlays for the runways. The transparent + hard runway would change the surface type.
I’m not sure if this is a good idea, but I’m pretty sure that this feature belongs in overlay DSFs and not the apt.dat file.
- Such a technique (varying hard surfaces independent of a larger image) is useful for more than just airports (and certainly more than just runways).
- The technique is unnecessary unless a DSF overlay is in use.
- Unlike nearly all of the rest of the apt.dat file, such an abstraction (invisible but bumpy) is much more a modeling technique and less a description of a real world runway.
I’m not sure we would even want the runway outline to be the source of hard data. If there are significant paved areas outside the runway then a few larger hard surface polygons might be more useful.
Hmmm, this discussion gave me an idea. I try to correct a overly undulating runway, to make it usable with "runways follow land contours" on. This involves making small well-tailored and -fit hard-surfaced planes and place them to fill the deep concave kinks. One problem with this is that the runway surface markings remain on the main (unusable) surface. I already requested Ben to make the markings stick with the highest hard surface, but whether he will be able to accommodate, I don't know. But for small fix-ups that are not to far higher than the main runway surface, a transparent texture may work. I have to try.