In a previous post I discussed polygons, how they can be used, and a little bit about how they relate to X-Plane 850 and the new apt.dat system. I have been working on some demo scenery that will make this all clear, but the great is the enemy of the good, so rather than wait I’ll post more on this now and get the demos done as soon as I can.
There are essentially two ways to get at the new polygon code: via the apt.dat system or via an overlay DSF. When should you use apt.dat and when should you use an overlay DSF?
- If you are trying to model something that is directly in the apt.dat spec, use an apt.dat file. For example, use apt.dat if you are making blue taxiway lights.
- Use a custom overlay DSF if you are modeling outside an airport. (Do not make “fake” airports to use apt.dat features.)
- If you need a custom look not supported by apt.dat, use an overlay DSF – it’s the only way.
- Use a custom overlay DSF if you are modeling something that isn’t found in an airport, even if it looks similar. (For example, if you want blue lights to model some unique architecture in an airport, do not use apt.dat taxiway lights – your lights may look the same, but they are not the same!)
This last point is important: do not “abuse” the definitions of apt.dat files just because they look similar.
There are essentially two kinds of features in the scenery system:
- Features that do not change how they look, ever. For example, we do not change the way a textured triangle looks in an OBJ file.
- Features that are designed to model the real world. Over time, we change them to look more like the real world. For example, approach lights have changed a lot in 850 to look more like the real world ones.
This second type of feature is the one where I issue caution: if a feature in apt.dat or the sim is meant to emulate how the real world looks, we will change how it looks to improve rendering! This is why it is important not to use apt.dat feature for purposes other than they were intended for. It might be that in X-Plane 8.50 the blue taxi lights look just like some other feature you want to code. But in a future version, we might make them more realistic for an airport and they will look worse for your other application. By using apt.dat features only for their true purpose, you help us ensure that our changes to the base artwork make scenery better, not worse.
(This division of all scenery features between ones that are “stable” and ones that are “based on the real world” can also be seen in most parts of the sim. In particular, the flight model is designed with a “based on the real world” philosophy, a very controversial decision I’ll have to blog about some other time.)
Next: fixing airport terrain with polygons.
I’ve been meaning to write this blog entry for about a year now. X-Plane 8 allows the airport surface area to be sloped. Here’s some of the back story and details.
Back when Austin and I were doing the design work for teh X-Plane 8 scenery system, we made a decision to allow sloped runways. The issue is that flattening the airport area requires the sim to edit the mesh on the fly, something we wanted to avoid.
(X-Plane’s scenery system is based on removing the editing of scenery from the sim itself…”X-Plane is not a GIS”. I did some slides on this once, I’ll try to post them soon.)
Instead we decided to simply drape the airports over the terrain, no matter how it was built. We figured that the sim’s engine could handle this (as it turned out, there were bugs that were fixed in the 8.20 patch) and in real life runways are often quite sloped!
Unfortunately when theory meets practice, things can get ugly…the biggest problem we saw was that in the original set of DSFs, the underlying terrain was very bumpy, and the smoothness requirements for a plane to take off are very high. (Flattening is also necessary to match the ground height with other sims for online flight.)
So we retrofitted the X-Plane engine with terrain flattening for airports. The flattening engine is meant as a last resort, to get absolute flatness and repair an already-flattened DSF. Its goal is not visual quality, but rather speed — that is, we can’t take 10 minutes analyzing the DSF each time we load one, or the sim will freeze pretty badly. (If this requirement that the flattener be fast ever goes away, we could do a much nicer job of flattening.)
The current flattening engine has two unfortunate properties designed to keep it fast:
– It flattens an area that is larger than the airport surface area (it rounds up) and
– It flattens vertices that are in the flattening area, not whole triangles.
The first limitation means that it may crush mountains around the airport, and is not appropriate for airports that are embedded in complex, hilly terrain.
The second limitation needs more examination. If a mesh triangle is partly inside the flattening area and partly outside, then the triangle is not flattened – one vertex is moved, and the others aren’t, which cause it to be sloped.
In these pictures, the blue lights represent the airport area perimeter, but the red lights show the full area that is flattened. I have artificially set the airport elevation much higher than surrounding terrain, to make the flattening obvious. Notice how some triangles become highly sloped!
When we make the global base scenery, we use the default airports from Robin’s database. So even if you do not want to submit your custom airport layout to Robin’s database, consider submitting some kind of layout to Robin. If an airport is present in the default scenery, then the area will be pre-flattened, which makes the sim’s flattening both work better and maybe even unnecessary.
Also, you can use the 130 code in a custom airport area to increase the airport boundaries, increasing the amount of flattening. But this is a mixed blessing – as you can see the mechanism is very imprecise. If you do use a 130 code in a layout and you submit the layout to Robin, please remove any 130 boundaries that have been set to a large area to flatten an airport.
Just a gentle reminder: please do not consider anything in a beta to be final!
By this I mean: there is a risk that file formats that are new to the current sim (860) could further change during the current (860) beta run.
So…if you are working on scenery that depends on new 860 features, please do not ship your final scenery until 860 is finished! This way you can be sure you’re compatible with the final formats.
If your scenery uses 850 features and 860 breaks them, please report a bug, as 860 should handle any legal scenery that 850 handles.
(This goes for plugin datarefs too!)
X-Plane 850 introduced some new polygon features that are worth looking at. Polygons are always legal in overlays, which makes them particularly flexible.
A polygon is any DSF entity described by one or more rings of points. A polygon’s look is defined by its artwork file, which also constrains its properties. Polygons may:
– Be draped, meaning the polygon in the DSF does not have altitude information, but instead takes its height from the underlying mesh. A non-draped polygon has altitude information. (Only draped polygons should be used in overlays because a non-draped polygon might not match the base mesh correctly. You can’t know whether a user has the 7-DVD DSF scenery, or old ENV scenery, or the older US DSFs.)
– Be curved (via bezier curves). This is only legal in some polygons.
– Have holes: some polygons can have additional interior polygons cutting “holes” in them.
X-Plane 8 shipped with one original type of polygon: facades. Facades are draped polygons with no holes or curves. X-Plane builds a building along the perimeter of the polygon. Facades were used heavily in the original US DSF scenery, and are useful for airport terminals, and even possibly fences.
X-Plane 820 added two new types of polygons: beaches and forests. Beaches are non-draped, non-curved, no-holes polygons that add a strip of beach texture between land and water. As mentioned above, I don’t recommend using them in overlays because they are not draped. (They are legally allowed in overlays but the chance for ugly results is large.)
Forests may have holes and are draped, but cannot be curved; they fill in their interior with 1-4 polygon trees. We do not have any forest polygons in the current global scenery, but some users have built their own overlays to add trees to X-Plane using these polygons.
X-Plane 850 introduced the new apt.dat format with a number of new features. Rather than make the apt.dat file customizable (which would make the file format complex and change its fundamental purpose), we added new polygon types that let authors use the same facilities as apt.dat files have, but with a lot more control and flexibility. Three new polygon types implement some of the new X-Plane 8.50 apt.dat features:
1. Object chain polygons. You can make a polygon and X-Plane will string a series of objects along the polygon. The polygon is draped and may be curved, but may not have holes. X-Plane 850 uses this for taxiway lights, but this could also be used to plant trees along the edges of fields. (You could also use this to put streetlights along roads, but the road file format can do that already without adding extra polygons to the DSF.)
2. Painted line polygons. You can make a polygon and X-plane will drape a painted line along the ground. These polygons are draped and may be curved, but may not have holes. X-Plane 850 uses this for taxiway lines.
3. Draped polygons. You can make a polygon and X-Plane will fill it in with some kind of texture along the ground. These polygons are draped, may be curved, and can have holes. X-Plane uses these to make curved taxiways, but they have a lot of other possibilities since they provide a way to change the terrain.
I will comment more on draped polygons in a future blog posting, but one immediate note: before X-Plane 850 if you added an airport it was impossible to convert the terrain underneath to grass (from whatever terrain might have been present). With X-Plane 850 you can now make a draped polygon using a grass texture and a DSF overlay with the perimeter of the airport and thus “patch” the texture of the mesh to look like grass.
This technique is not as good as the grass in the native airports for four reasons:
– Draped polygon performance is slower than the mesh itself – I’ll comment about that later.
– Our DSF creation program flattens airport areas – a draped polygon doesn’t so there can be SRTM DEM noise that makes the airport area too bumpy to use.
– The DSF terrain grass can have a soft border, but right now draped polygons always have a very sharp border.
Draped polygons still represent a better option than putting the runways over the existing terrain though.
The order objects are listed in a DSF file (either the OBJ definitions or the actual OBJ instances) is not the same as the order X-Plane will draw them! X-Plane will change the order to maximize frame-rate, and the way it organizes them has changed in 850 (and will change again in futur versions).
Until X-Plane 850 there was no way to control the order of objects (although some packages do rely on X-Plane 840’s behavior and now look funny in 850). But with 850 there is a clean way to control draw order that will work well into the future.
Starting with X-Plane 850, there is a new command ATTR_layer_group…it let’s you override what part of the rendering process your object is drawn in, which is useful in a number of cases. Here’s how it works:
X-Plane draws the scenery in a series of steps or “layer groups”. Because of the way OpenGL transparency and polygon-offset affect Z buffering, X-Plane must draw the terrain first, all decals over the terrain second, 3-d buildings third, and anything translucent (clouds, smoke puffs, etc.) last. Layer groups organize all of the scenery into these catagories.
Objects are normally drawn in the “objects” layer group, which is intended for 3-d buildings, static airplanes, jetways, and anything else you might model with an OBJ. However ATTR_layer_group will let you specify that some objects be drawn earlier or later than others.
The command’s syntax is:
ATTR_layer_group objects 1
Where the name (“objects”, but others are allowed – see the OBJ spec) specifies a group, and the number makes the object be drawn after (positive numbers) or before (negative numbers). Objects with the same group and number are drawn together (in an unspecified order), but X-Plane goes by the numbers.
So for example if you want to ensure that a transparent hanger is drawn after a static plane, use ATTR_layer_group objects 1 on the hanger to draw it after all other objects. To draw some apron lines before the terminal, use ATTR_layer_group objects -1 to draw before buildings.
A few other tips:
- Try to use as few offsets as possible – e.g. try to put all “draw last” objects into the group objects/1 – rather than using a different number for each.
- Avoid using layer groups when they are not needed – they inhibit X-Plane from optimizing framerate.
- If you do not use a layer group, but do use polygon offset, X-Plane sets the layer group to objects with a negative number. This is inhibited when you specify the layer group yourself, so be sure to use a negative offset layer group for polygon offset!
- Try to organize your textures so that one texture is not used in multiple layer groups. For example, if you have translucent buildings that must be drawn later, group them in their own texture.
- Related – try to keep polygon-offset geometry (pavement markings) in their own texture and objects. Share one texture for all markings, but don’t put the markings and object together.
Here’s something a little bit surprising about the library: the EXPORT command in a library.txt file cannot replace another file in the same package.
For X-Plane 850 we added cars driving on the left side of the road for New Zealand, the UK, Japan, and other countries that drive on the wrong side of the road. Unfortunately what I did was export two road.net files from the same package – one with a region restriction (to these few countries) and a later one with none.
Consider the sum of these two statements…the result is that in New Zealand, the UK, etc. the sim will use either of the two road.net files, picking randomly.
850 will address this with a new library command. Whereas the “export” command normally provides one of multiple alternatives within a package (but replaces any lower ranked packages), the new “export_exclude” command will replace alternatives both within the same package and within lower ranked packages. Commands are treated sequentially, so an export_exclude should usually be at the top of the library.txt file.
In the distant past I blogged about the “crayon rule“, that is, thet importance of not changing textures a lot during rendering, and how authors can help X-Plane avoid changing textures.
Before X-Plane 8.50 the sim would change textures every time the pavement changed types in an apt.dat file. So if you have an airport layout that alternates concrete and asphalt pavement (the order in the apt.dat file is the drawing order!) then X-Plane would just switch and switch.
X-Plane 8.50 tries to be smarter about this and detect when it can get away with changing your layout order to reduce texture changes, improving framerate.
Here’s my warning: X-Plane is not very smart about this! We try to eliminate unneeded changes but our code isn’t that elaborate and it won’t optimize as well as you can.
The sure-fire way to improve framerate is to group your layouts by pavement type. This will give you the best framerate. If you have to overlap pavement and control the draw order, I recommend using as few groups of pavement types as possible.
