Starting with X-Plane 850 (not quite beta yet), the apt.dat file will allow you to build taxiway signs into airport layouts. We’re using a simplified version of the sign-specification language from FlightGear (which shares apt.dat data) – you can read the on-going spec/discussion here.
The syntax isn’t final, but here’s a rough idea of what it will look like:
20 42.363178 -71.012238 110.0 {@R}22R-4L{@@}4L-22R
and here’s an example sign (not the same as the apt.dat example listed above):
The basic idea is: a sign has a latitude and logitude location and a heading (in this case 110, so the front of the sign is visible when parked to the east). The text of the sign is plain text – special characters are put in braces {} and special formatting starts with a @ character. @R turns the sign red, @Y yellow, etc. and @@ changes to the back side of the sign. Arrows are specified with a ^ followed by the direction, so a left-downward arrow is ^ld.
Well, the disease is pretty bad too. I spend more time than I’d like to admit to Austin deleting ads for blue pills, credit cards, and dirty websites on the XSquawkBox forums, this bog, my in-box, etc.
Unfortunately one of the side effects of all the spam floating around out there is that anti-spam software is starting to defeat normal communications.
Email is the primary means of communications within Laminar Research and we periodically lose valuable development time when one of us ends up black-listed on an anti-spam list.
Recently I’ve also been hitting cases where I either can’t return an email from a user at all (they can email me but I get spam-filtered when I reply) or the reply requires me to authenticate myself in some way (which takes away from the total volume of email I can answer and makes everyone’s responses slower).
So if you have emailed me about scenery and heard nothing it could be my horribly clogged in-box, which is months behind, but it could also be that I emailed you but was a casualty of the war on spam.
It’s the little things that often take the longest to program, or at least make developing a feature take longer than expected. But I think flight simulation has reached the point where the details are what matters.
Trivial example: if we have a runway that’s shorter than 9000 feet and about an even multiple of 1000 feet then the distance-remaining signs (every 1000 feet) from the two directions may be too close to each other or even overlap. X-Plane 850 will detect this case and generate a single two-sided distance-remaining sign (like real life), so that the signs don’t obscure each other.
If the runway length is such that merging the signs would create too much error in their measurement, or we only have a sign in one direction, there is no merge.
The 850 airport code is full of tiny details like this.
In Austin’s recent post to the news list he mentioned that we’d cleaned up a lot of code internally, making X-Plane tighter, leaner and meaner. But is this really a feature, something that you would care about as a user? I can think of at least 3 ways it directly affects the sim.
One difference between X-Plane and most other software is that you can email the authors and ask for a new feature and possibly see it within a few months. But when we evaluate feature requests, time to develop the feature is a big consideration. Having a cleaner code base means we can put new features in faster, which means everyone is a little more likely to get something new. (Of course, we can’t do every feature that is requested…this only improves the odds a little.)
Similarly, X-Plane is a subscription – so the amount of improvement you see across a version of X-Plane is directly affected by our ability to put new stuff in quickly. I’ve worked at companies with a range of policies toward code clean-up, and I’ve found that Austin’s policy of “constantly keep your house in order” (with major code cleanup on a monthly, not yearly basis) results in us being able to get a lot of cool things done without being held back.
Finally one direct result of code cleanup is often performance. For example, under the old code we really had two rendering engines. One handled DSF and ENV scenery, and the other handled airports, superimposed on top of them. Each one knew how to draw a bunch of triangles. Each one knew how to decide whether triangles needed to be drawn. Each one knew how to check whether the plane was on top of some part of the scenery (e.g. a runway or the ground).
This was bad for two reasons: first, it meant we spent twice as long working on anything – once for airports, once for scenery, and second, the two engines were not equal. It turns out the DSF/ENV engine, which is newer and has had a lot more time spent on it can out-perform the old airport rendering engine. This was an issue for 840 but is an even bigger issue for 850, where we want to make airports much more realistic.
By merging thet two and using only our better engine for both, we not only clean up our code, but airports render faster immediately. I do not have final stats on this, but the speed improvement is variable – anywhere from as little as 10% faster to as much as 50% faster depending on the view angle, airport chosen, visibility, etc. So even if you end up turning off all of the new 850 visual features and go for speed, 850 should still be an improvement.
A DSF can place polygons (beaches, facade buildings, forests), points (objects), mesh patches (terrain) and vector networks (roads). Note that while there are only four geometric types in DSF, there are now six “graphics” types. The versatile DSF polygon can be a beach, buiding or forest depending on what type of text file the DSF links to. This gives us a way to expand X-Plane scenery and invent new tricks without changing the fundamental DSF file format.
A few new graphic types will be coming to X-Plane 850, all based on polygons:
- Draped polygons overlay the terrain with a texture – useful for making custom airport pavement or fixing some terrain in a city.
- A “string of objects” follows a linear path placing objects periodically – useful for putting down airport lights or putting a row of bushes between two farm fields.
- A “ground marking” type places a painted line on the ground – useful for airport markings, for example.
In all three cases, these tricks are available in the new apt.dat version 850 based on some predefinde types (a yellow taxiway line, green taxiway centerline lights, concrete apron pavement), but are also available in the DSF in a customizable manner. This will allow you to use these powerful techniques outside the airport environment or with custom artwork.
When is up really up? X-Plane has two choices when you try to build something that goes “up” in the scenery system:
- Up can mean straight up against gravity. For scenery far away, up is no longer parallel to up nearby because the Earth is round.
- Up can also mean up in the XYZ coordinate system. This is the same as up against gravity at the center of loaded scenery, but wrong for everywhere else.
So what does X-plane use? Well, it depends on what we’re doing. Usually up against gravity is the “right thing to do”, but often XYZ up is close enough and a lot faster, so we sometimes take that shortcut for frame-rate. Here’s a rough breakdown:
- For DSF terrain meshes and objects, up means against gravity.
- For roads, forests and facades, up means XYZ up.
Now in X-Plane 850, we try to move scenery around the world rather than rebuild it. But 3-d stuff like roads and facades are only built very near the plane (which is very near the center of XYZ space), so generally speaking when a road, forest or facade is built, XYZ up is really going “XYZ” up. (If that didn’t make sense, don’t worry about it – my point is only that scenery shifts don’t affect this discussion.)
X-Plane 850 will allow a number of 3-d definition-types to interact physically with the plane: objects can specify the surface type for their hard surfaces on a per-triangle basis (e.g. grass, concrete, asphalt). Facades can have hard walls or hard roofs, and segments of roads can be hard. (This will make it possible to land on the roads again IF we can apply these attributes to our definition files.)
So how many Cessnas can sit on the edge of a fence? Well, if that fence is straight up (and I mean “XYZ” up) then none. X-Plane checks for collisions and ground contact by looking straight down (XYZ down, not against gravity) to find what is below the plane. A truly vertical triangle has no width when seen from straight above, so the plane can never sit on it.
(Lest you worry about the imprecision of this, please note that when you are on top of something, the distance from your wheels to the geometry is 0 meters, so the error between the two “ups” is 0.)
When you are making an object, remember that the object is not facing XYZ up, but rather it is slanted based on the curvature of the earth. So a perfectly vertical wall might actually not be vertical and might thus work as a hard surface . Similarly an almost vertical wall might become vertical and not work. The safe thing to do: make sure that all hard surfaces are not even close to vertical. 45-degree slopes, etc. are okay though!
For a facade, the walls cannot be hard because they will always be perfectly vertical. This presents a problem if you want to make a fence that the plane can’t pass through. One solution: use the angled roof feature of facades to curl the top of the fence in at a 45 degree angle. That segment of the fence won’t be vertical and will cause the hard walls to work properly. (In fact, hard walls in facades will be provided in 850 specifically for this purpose. For a building, the walls are vertical and the roof can be hard.)
There are costs to every feature we put in X-Plane…the obvious ones include:
- The time to code the feature.
- The time to test the feature.
- The time to recode the feature if we ever rewrite the rendering engine (which we do fairly often to try to take advantage of the latest graphics technology).
There are also some less obvious costs:
- If a feature isn’t used often, it’s more likely to end up broken without anyone noticing, reducing the overall quality of X-Plane.
- We have to keep track of our use of graphics card resources. If we add a feature (like lighting) now, perhaps this will prevent us from reliably putting a new more improtant feature in later because some scenery may be using all of the card’s resources.
For example, what if we discover that we can make crashing waves, but only on unlit beaches? If we never added lit beaches, we know this is safe. But if we do support it beaches, then perhaps there is some scenery out there for which the crashing waves won’t work because we can’t have both.
The moral of the story: laziness is good! Since every feature costs, there is sometimes an advantage to waiting until someone asks for a feature before coding it.
You may have noticed: all of the “artwork types” (objects, terrain, roads, beaches, etc.) now do textures in almost the same way – with a TEXTURE command and a TEXTURE_LIT command. (Two notable exceptions: beaches and forests can’t be lit yet. We haven’t found a case where this is a goood idea but it may happen…nuclear accident anyone?)
The idea here is to unify aspects of all art files so that when future extensions come along, they can be used everywhere. For example, some day we will have textures whose choice is controlled by datarefs. When this happens, because every art file uses a similar mechanism to find textures, we can introduce commands not only in the terrain, but also in objects, facades, roads, etc. so that any type of art can be made seasonal.
This got me thinking about whether all aspects of every artwork type should be available in every file. I think the answer is…sometimes. For example, being able to use lit textures
everywhere is a good thing. But should it be legal to make hard polygons out of every art type? Definitely not every type. Terrain’s “hardness” for example is decided inside the DSF, so the only question is “how bumpy should the ground be when it is hard”. Objects let you control these things per polygon. But if we have hardness for a facade, how would we specify hardness? Perhaps just whether the roof is hard or not…
I think that X-Plane 8.50 will have more overlap in capabilities between the various types of 3-d “stuff” (beaches, objects, roads, etc.) but we still won’t have 100% of all features in every file type. Some combinations just don’t make sense.
Two, actually…we’ll see if these behaviors show up in beta…
This is runway 4L at KBOS, from Google Maps. Note that a taxiway travels behind runway 4L on top of the blastpad.
Now compare how these look in X-plane 840 and X-Plane 850..
In X-Plane 840, the blast pad goes over the taxiways. This is fixed for 850. However you can see that the author may have been expecting this effect – there’s a lot of taxiway pavement put down around this junction. The new apt.dat format will alleviate this to some extent by allowing pavement to be shaped in arbitrary polygons, making overlapping no longer necessary.
A more subtle shift: note that the threshhold is not in the same place in 840 and 850. This is because in 840 the blastpad (like most of the runway) is built in square tiles. Since the runway is 150 feet wide, the blastpad is rounded to a mulitple of 150 feet long. In 850, the blast pad is chopped at the exact point, so the threshhold can be where it is supposed to be.
The 850 airport RFC is on the scenery site now. It may seem very vague at this point – this is intentional; the next step will be to go through the file format and make sure we have all of the features people want: the right colored lights, the right types of pavement.
So if we’re not doing that yet, what is the point of the RFC? Well, we’ve been debating “next-generation” airports (meaning a system that provides something more flexible than a set of overlapped quad-polygons) for years now, trying to weigh the alternatives. Here’s a summary of how the new scheme compares as an approach:
- The new apt.dat is a “low-level” approach. The old apt.dat format didn’t allow us to analyze the taxiway layouts to determine what represented a single taxiway – it was just concrete that we hoped looked right based on user design. The new format continues this; we give you the flexibility to make almost anything and hope you pick something good.
- Non-runway pavement is changing to bezier-curve-based polygons, for a lot of control and flexibility over the look of the layout. One advantage of bezier curves is that the sim can render the curves using more triangles on faster systems (for a nicer look) and fewer triangles on a slower system (for better framerate).
- Runway lines and markings are relatively independent of the pavement. While they can be embedded on the edge of pavement, they can also be placed anywhere you want.
Here are some things you won’t find:
- There won’t be a lot of new objects – those belong in overlay DSFs.
- There aren’t “ATC” features (e.g. names of taxiways, paths for AI planes to take) – those will be added when we’re ready to code them in the sim.
- There’s almost nothing automatic. X-Plane doesn’t analyze the apt.dat file and place signs, lines, lights, etc.
To elaborate on this last point: image for example that we’re going to spend the time to code an algorithm that generates taxiway lines that go from a parking spot to a taxiway. We could put this algorithm in WED or in the sim. If we put it in WED you can run the algorithm and then fine tune the results if you don’t like it. If we put it in the sim, then you’re stuck with the results untuned, and the algorithm has to run while you’re flying.
So in this sense the 850 apt.dat continues the direction DSF took of making a flexible low level format that leaves the ultimate decision of how the scenery looks in the hands of the author (by editing the file) rather than in the hands of the sim.
The basic idea is: a sign has a latitude and logitude location and a heading (in this case 110, so the front of the sign is visible when parked to the east). The text of the sign is plain text – special characters are put in braces {} and special formatting starts with a @ character. @R turns the sign red, @Y yellow, etc. and @@ changes to the back side of the sign. Arrows are specified with a ^ followed by the direction, so a left-downward arrow is ^ld.
