With X-Plane 860 there are two ways to draw stuff on the ground:
- Use an OBJ and ATTR_poly_os. This is the way most people have built custom taxiways, markings, etc.
- Use a DSF overlay with a bezier polygon (which is controlled by a .pol or .lin file).
Which should you do? Hrm…
- For any geometry that goes over a very large area, the DSF overlay with a bezier polygon is basically a requirement, because the polygon will “drape” over the ground. The OBJ might just stick out in the air.
- If your element repeats a lot, the OBJ may save memory. (OBJs are stored in memory once and used many times – bezier polygons use RAM each time they’re used.)
- If the overlay is very simple, the DSF overlay may perform better.
- It may be too expensive to build complex lines with DSF overlay lines. They’re meant for taxi-lines, not full vector graphics!
So here are a few decisions I’d make:
- Taxi lines – certainly DSF overlays if we’re not using apt.dat 850.
- Parking spot at an airport – use one large polygon with a texture, not a bunch of bezier lines.
- Use a DSF overlay for that parking spot, even if we use it 60 or 100 times. The simplicity of the overlay (vs. the compexity of starting and stopping an OBJ from drawing) outweighs the cost of using it many times.
- A very structurally complex overlay on the ground with thousands of triangles (that for some reason cannot be created with a texture) that is used a lot — well, this is an “artificial” case I’ve made up, but in this case use an OBJ.
I’ve blogged in the past about ATTR_poly_os…it’s a tricky topic. ATTR_poly_os is
a feature of the OBJ file format designed to let authors fix z-buffer thrash problems. Unfortunately, the cause of z-buffer thrash is pretty complex. To make things worse, it turns out I never finished my intended documentation on the subject. (I’m an idiot!)
The fundamental problem I think is that what we have now (ATTR_poly_os and ATTR_layer_group) provide a mechanism to correctly fix z-buffer thrash, but they don’t in any way enforce good behavior over bad behavior. The two attributes are very flexible, and if used together, can do all sorts of bad things. The problem is that ATTR_poly_os was thought up years before the layer-group mechanism, and thus they don’t really reinforce each other.
So…here are a few simple rules to help with z-buffer thrash in X-Plane 860:
- Never use the names of objects or their order in the DSF to accomplish anything. X-Plane ignores both names and orders when processing your scenery.
- Do not move your polygons above the terrain to fix z-thrash. This won’t work.
- When possible, divide your objects into ones that are 100% on-the-ground (and thus may z-thrash) and ones that are 100% 3-d above the ground (and will not thrash). I realize that more objects means slower fps…so this applies best when you have many objects and can pick how you divide them up.
- Always use ATTR_poly_os for any polygons that lie along the ground. Use the smallest number you can to fix the thrash.
- If you have an object with ATTR_poly_os geometry and non-poly_os geometry, make sure the ATTR_poly_os geometry is first!
Those five rules should keep you out of trouble.
What about ATTR_layer_group? Well, secretly X-Plane 860 will change the layer group of an object that is ATTR_poly_os for you. So as long as your object contains only offset geometry (this is what I recommend in rule 3) it wll always be drawn before the rest of the objects, preventing artifacts.
You’ll need ATTR_layer_group if you want to put objects underneath runways, or underneath taxiways, for example.
I am working on more comprehensive documentation on the topic, and appreciate any feedback on stuff that I’ve written that’s unclear…the rules are complicated!
The internal joke about WED (the new scenery editor) is that it stands for Will it Ever be Done. So I should say that, given my total inability to predict when it will be done, and how many delays and setbacks there have been, I don’t expect you to believe anything I say until I actually ship something you can run (or at least post some screenshots*). I realize that I have destroyed my credibility about ship-dates by having no ability to predict ship dates for WED.
With that in mind, I am pleased to report that today I was able to run WED with a few features working in concert:
- Multiple selection (map and hierachy view).
- Multiple undo everywhere.
- Marquee multi-selection tool on the map view.
- Tree-based hierarchy view with editable property fields.
WED still can’t do anything remotely useful, but these four features represent a huge amount of infrastructure investment. Basically my goal is to provide some of these user-interface features (multiple undo, multiple select, multiple tools, etc.) for every single type of scenery component that you can edit.
Since apt.dat contains a lot of different components (just look at all the record types in the file format) and WED will also have to edit DSFs with a wide variety of data, it made sense to me to write a generic mechanism for these features that could be used over and over again without writing new code.
So my hope is that I’m just getting over the “hump” of writing infrastructure, and soon will be able to add two dozen more types of editable things to WED (other than my simple test objects) very quickly. We’ll see if it pays off.
The plan is still for WED releases to be separate from X-Plane and to be open source (MIT/X11 license). I’ve been meaning to post in Chris’s programming blog about some of the design ideas WED employs – it makes a good laboratory. Hopefully those posts can also provide some guidance if anyone decides to modify/work on/steal the WED source code. (It is my expectation that most programmers will not want to get into the guts of how WED works, as it is a fairly complex application. I think I can make simpler interfaces to things like import/export to make extending the program simpler.)
Anyway, WED is not the only thing I am working on right now, and you don’t have to believe me, but the WED codebase is growing, and some of it even works!
* I am not posting screenshots because the program is running right now with “scab art” – that is, ugly green, red and purple boxes that will be replaced with nice PNGs once the layout settles down. I do not want to make our artists draw the UI components more than once, and I don’t want to answer 1000 emails about “Why is it so ugly” by posting the scabs, which are perfectly adequate for my own coding purposes and not intended to ship.
I can’t say enough good things about Jonathan Harris (Marginal) — his work on X-Plane has been fantastic, he is one of the most advanced third party scenery authors I know of, and when he sends us a bug report, it is usually so perfectly patched up that I’m looking at the bad line of code in minutes! (One of these days I’ll post one of his bug reports — he always isolates the bug in a simple package that makes it very clear, with no extra “stuff”.)
He emailed me a while ago with some questions about layer groups, and I saved them to rewrite into a blog entry. A little bit of background:
X-Plane 850 and 860 introduce the concept of “layer groups”, which provide a way to control the draw order of scenery to some extent. Objects naturally fall into a layer group based on their type (e.g. objects go into the “object” layer group by default, and runways always go into the runway layer group). However, some scenery elements let you customize their layer-group placement in two ways:
- By changing which layer group the element goes to entirely, or
- By providing a “bias number”, which indicates that within the catagory of scenery elements, this one must be drawn early or late.
Layer groups let you do a number of useful things:
- Make sure that polygons and objects are drawn under runways or over taxiways when needed.
- Make sure that runway markings with polygon offset are drawn before 3-d objects.
Simply changing the order of objects in the DSF is not a reliable way to control draw order! Layer groups are. You can read about layer groups in the OBJ8 spec.
With that in mind, some Q and A. (I will elaborate on my answers from what I originally sent Jonathan.)
J: I assume that objects and polygons within a single layer can be drawn in any order – ie there’s no defined drawing order between different scenery types.
B: You assume correctly! Within a layer group, X-plane is free to reorder to improve fps. So you cannot rely on the draw order of any two scenery elements without assuring that they are in different layer groups, either by using different group names, or different relative offsets.
J: But is there are defined drawing order between objects/polygons and apt.dat-generated scenery?
B: Yes because airport scenery goes into specific layer groups! (In fact, all scenery has a “default” layer it goes into, and they usually vary by type of scenery element.)
J: eg if I have an object or polygon with ATTR_layer_group runways 0 will it be guaranteed to be drawn after the runway?
B: You’re close. The runways go into the runways group so
ATTR_layer_group runways -1
will always be before runways and
ATTR_layer_group runways 1
will always be after.
ATTR_layer_group runways 0
is the default layer group for runways, so your object or polygon would be in the layer group with all of the other runways, and X-Plane would be free to change the order amongst your object and runways in any way that would optimize framerate.
J: If not, is there any other way to insert objects and/or polygons between the taxiways and the runways?
B: The numeric offset is provided for this. The “spacing” of the layer group numbers is such that you can have up to 5 groups before and after each “named” group. So anything from runways -5 to runways +5 is fair game. (In other words, you can separately control up to 5 different “layers” of elements with a well-defined order for any layer group name.)
This series of posts will discuss how the LOD system works for objects. Understanding LOD is very important for tuning the performance of custom scenery that uses either very complex objects, or a very large number of objects.
Authors View vs. X-Plane’s View
A “level of detail” for an object is a complete representation of the model with complexity changed to fit a viewing distance. In other words, LODs are copies of your objects, some of which have been simplified so they will draw faster when far away.
Each LOD for an object contains a viewing range, indicating for which range it is appropriate to use this LOD.
An X-Plane object can have LOD information, via the ATTR_LOD attribute. If it does, it may have one or more “LODs” – that is, separate representations of the same object.
If an X-Plane object has no ATTR_LOD command, X-Plane turns the entire object into one LOD by automatically calculating the viewing range based on the size of the object. (I’ll discuss this in more detail in later posts.)
This last point is important because it means that, to X-Plane, every object has at least one LOD. If an LOD is not provided by the author, one is created!
Picking an LOD
When X-Plane draws an object, it measures roughly how far away it is and picks the LOD within the object to draw. This can save some frame-rate but isn’t a cure-all.
– The cost of animation and attributes is based on the LOD drawn. So if you have an object with a lot of animation that is not visible a long way away, using a second, simpler LOD with no animation will help framerate because X-Plane won’t evaluate the animation when the complex LOD is not drawn.
– The cost of moving the texture to the graphics card is incurred no matter what LOD is picked, so you don’t save on “working set” (that is, the effective amount of VRAM X-Plane needs) with LOD. If your object has a huge texture, you pay that cost any time it is drawn.
– The cost of the number of triangles in the model is partly saved by using a simpler LOD, but it is partly global to the entire object. The problem is that all of the geometry coordinate data for objects is kept together in one giant glob. So when the tiny simple version of your model is being drawn, X-Plane may be shoveling the complex version to the card anyway.
This last point is important: making more LODs may actually increase the total amount of geometry data and make performance worse. Therefore while it may help a lot to have a second LOD that is much simpler, having 10 LODs, each slightly simpler than the last will probably hurt performance. Be sure to try your objects on a computer that doesn’t have a lot of free VRAM to see the effect of more LOD!
Don’t Draw That Object
While you can save some frame-rate by having X-Plane draw a simpler LOD, the true power of the LOD system happens when an object is so far away that none of the LODs apply. For example, if my object has 3 LODs from range 0-1000 meters, 1000-3000 meters, and 3000-6000 meters, then once the object is over 6 km away, X-Plane simply doesn’t draw it at all!
Not drawing an object is great for framerate. Not only do we save the time on the animations and attributes, but X-Plane never has to process the texture or geometry data, and that’s where the real framerate win comes from. Therefore the most important question for object LODs is “what is the maximum LOD” – that is, what is the farthest distance before X-Plane can stop drawing your object. X-Plane is pretty efficient at recognizing cases where objects, or even whole classes of objects, are simply too far away to draw.
(Consider the runway lights with the new “high detail world” setting…X-Plane places an object for every single runway/taxiway light, of which there are almost 10,000 at Chicago O’hare. But since the maximum LOD for these tiny objects is only 500m, X-Plane then eliminates the vast majority of the objects very early on and doesn’t bother to draw them, keeping framerate up.)
To draw a stupid analogy: the shorter the grocery list, the quicker your shopping. But if your grocery list has NO items and is totally EMPTY, you don’t even have to drive to the store, which really saves you time.
In the next part I will discuss world level of detail and maximum LOD didstances.
Here’s one of those little details that probably isn’t in the scenery docs but needs to be: if you are making base DSF meshes and they use water (the special terrain type “water”) it must be on the bottom of the stack of terrains – it can’t be used as an overlay!
I just finished an example scenery package that shows how to place orthophotos using .polygon files. Check out the scenery website (look under tutorials) to download the package and also read the illustrations. (This is an experiment: this is more of an annotated scenery example tha a true step-by-step tutorial.)
The basic anatomy of an orthophoto-in-a-polygon is:
- A PNG file contains the orthophoto. (In the case of our example, ksbd_alpha.png.)
- A .pol file references the PNG file and defines the physical properties and layering information. (In the case of our example, ksbd.pol.)
- An overlay DSF references the .pol file. (In our case this is +34-118.dsf.)
- The DSF overlay contains exactly one usage of the .pol file, with a polygon parameter of 65535 (a flag to indicate that texture coordinates are in the DSF) and each vertex of the polygon contains texture ST coordinates.
This pattern is actually the same design pattern that is used everywhere in the X-Plane scenery system:
- PNG files are never used directly by DSFs, they are always referenced by some kind of “definition” file, like an OBJ, .pol, .ter. Sometimes the definition file has a lot of info (like an OBJ, which contains a 3-d model), and sometimes they just contain some basic attributes (like a .ter or .pol file, which contain info for the physics engine).
- The artwork definitions are always separate from the DSF, so that they can be reused easily in a lot of DSFs.
- The DSF says where the polygon goes and the .pol file says what it looks like, just like the DSF says where an object goes and the OBJ says what it looks like.
One decision I made early on in my work on the scenery system was to stop using “magic file names”. Prior to X-Plane 8, in a number of cases it was enough to add _LIT to the end of a texture file and a lighting mask would appear. In all modern file scenery format, there is a texture command (usually TEXTURE_LIT) to add this information.
Now this is probably more confusing to new users, and certainly a little bit confusing to anyone who was used to X-Plane 7. To some extent my goal is to have most scenery files be generated automatically – we’re still a long way away from that, so my decisions to prefer extensibility to ease-of-use in the low level formats cause problemes for now. (But try the new AC3D X-Plane plugin version 3.0 – with UI to edit all X-Plane properties, does it matter anymore whether OBJ8 files are easy to read? We now have a real UI for editing X-Plane specific properties.)
In the case of file formats my concern was extensibility. There are only so many “tricks” that we can possibly cram into a file name, and the more we try to make the file name do, the less simple it becomes. When textures can only be “lit”, tagging _LIT on the end is simple, and haivng to add TEXTURE_LIT can be annoying. But since then we’ve also added layering information and physics information. Imagine ksbd_LIT_AIRPORTS_-1_GRASS.png. Now we’re getting into the domain of confusing file names.
Take a look here at some of the things we’d like to someday do for textures…seasonal textures would really make the texture names crazy. (MSFS9 accomplishes this using four seasons, which keeps the names simple…but what if we want to customize the time range for seasons?)
And dataref-controlled textures? Well, you can’t encode a dataref in a file name – the / is reserved!
So all of these text files (.OBJ, .pol, .for, .ter, etc.) provide extensibility – they let us add new features to the way that DSF content is viewed without requiring cahnges to the DSF file format itself.
Since this blog post has gone off into a philosophical rant and the real info is in the tutorial, let me drift totally off subject by mentioning that while you’re looking at tutorials, take a look at Kriss’s tutorial on OBJ8 animation using the new AC3D plugin. If you’ve tried using the old system of animation (by typing cryptic goo into the AC3D object naes) you’ll find the new plugin will let you work a lot faster!
In my previous post I discussed airports using the apt.dat and polygons and when to use custom artwork in a DSF.
One problem with the X-Plane scenery system (and a topic for another blog) is that, because scenery is fully pre-processed*, introducing a new airport won’t put grass underneath the airport surface area. (Only airports that existed at the time the global scenery was created have grass underneath them.)
To make an airport there are two types of processing you need to do to the underlying area:
- Flatten it, if it has bumps. Since our mesh comes from SRTM, which is “first return” (meaning whatever the radar bounces off of first, that’s the height of the terrain, even if it’s a tree top), it often is quite bumpy.
- Change the underlying texture to something appropriate for an airport.
With X-Plane 8.60 (in RC as of this writing) you can do both! I’ve blogged about airport flattening (and why it isn’t very good) before; today I’ll try to describe how you can fix the base terrain.
You can cover the base mesh with a draped polygon in a DSF overlay. All you need to do is:
- Create a .pol file that references a PNG for the texture and describes the resolution it will be applied at (i.e. how many pixels per meter) and
- Use that .pol file in a DSF with a polygon in the overlay to describe where to put that texture down.
In X-Plane 8.60 we provide .pol files for you for all of the basic airport terrain textures. If you open the file Resources/default scenery/820 world terrain/library.txt you will find the library listing for the global scenery terrain. Toward the bottom you will see a section like this:
EXPORT lib/g8/pol/apt_sdry_cold.pol pol/apt_sdry_cold.pol
What this means is: the library path lib/g8/pol/apt_sdry_cold.pol is apped to the file pol/apt_sdry_cold.pol in this scenery package. You will see a fairly large number of .pol files on the left. Basically these represent the basic “environments” that an airport can exist in.
So to make an overlay DSF that has wet cold grass underneath it, make an overlay DSF with a .pol file using the path “lib/g8/pol/apt_wet_cold.pol”.
EDIT: Important — there are actually four .pol files in this library that do not work!! They are:
apt_desert.pol
apt_dry.pol
apt_grass.pol
apt_sdesert.pol
You will know they don’t work because your scenery will not load with them. Basically, they are accidental hold-overs from a previous naming scheme for airport terrain, but were never deleted. Note how they name only an amount of rainfall (except for apt_grass, which tells us nothing). The rest of the files are named things like apt_sdry_cool, which gives us both temperature and rainfall. This 2-dimensional climate grid (with rainfall and temperature) is how most of the X-Plane terrains are organized.
Why use the library system to do this? Three reasons: copywrite and VRAM, and compatibility.
One advantage of using our library is that it gives you a way to use our artwork without copying our artwork. Remember that you cannot copy the X-Plane PNG files into a custom package and then sell it – it’s a violation of X-Plane’s EULA. But you don’t need to! You can simply use the .pol file and X-Plane will load up the appropriate PNG files.
This is also a win for VRAM. If the wet grass texture is being used in the base terrain (for an airport that has wet grass underneath it from the global scenery) and in your overlay DSF (via the library .pol file) X-Plane will only load one copy of the texture, saving VRAM, speeding up load time, etc. If you copied the PNG file, besides being a EULA violation under some circumstances, you’d also be wasting VRAM. So the library system is more efficient!
Finally, by using our polygons, you ensure that your base grass will match the rest of the scenery system. If we update the look of our grass, because the library .pol files reference our artwork, you will see the same thing in your airport that we have in the default ones.
(Of course my warning from last week applies: if you use a wet airport grass polygon for something other than wet airport grass, then in the future our improvements on the artwork may make your scenery look strange. With these airport polygons we are aiming for “as much like an airport as possible”, not “as much like 850 used to look as possible”!!)
* By this I mean, all the decisions about how scenery will look are made ahead of time, so the look of scenery does not respond to the combining of multiple packages by changing the underlying packages – only by superimposing the new ones on top. Thus a new apt.dat layout does not change the underlying terrain from urban and forest to grass. This is a design trade-off; full pre-processing has both good and bad aspects.
With the new version of DSF2Text and X-Plane 8.60 it is possible to overlay orthophotos on top of DSFs. I’ll get into this in more detail in a future blog post…the purpose of this post is to be a wet blanket.
Using polygons to overlay orthophotos on the base mesh might seem perfect. It’s easy to do and you can clip polygons to any shape. Perfect, right?
WRONG!!!!
There are a few major problems with overlay polygons that make them well suited to some cases but not a general purpose cure-all for orthophoto-based scenery. Here’s the fine print:
- Orthophoto polygons draw over the base mesh. In particular the base mesh is still drawn underneath the orthophoto. This means that wherever you use them, X-Plane is drawing twice! This is bad for performance…it will cut the speed of mesh drawing in half. Ouch! (This is not an issue when working on very small areas like airports, but it is an issue when working on very large areas.)
- Polygons are not built up until you fly near them. Polygons are part of the 3-d “clutter” part of the scenery not the base mesh, so we defer building them until we get near them to save memory. (This is the same as airports – look at an airport in textured map mode when far away from it — no taxiways!) But this means that if the orthophoto is huge (and thus visible far away) its absense will be quite obvious.
- Polygons burn CPU time when they are built up. For very small polygons this isn’t that noticable, but the larger the polygon, the more work X-Plane does “draping” it over the base terrain. So on single-CPU systems with large polygon orthophotos, the framerate may be adversely impacted.
Basically overlay polygons are great for texturing small areas like airports or special landmarks within a city, but are not appropriate for making wide-scale orthophoto base meshes. For that you really need to replace the base mesh DSF!
Sergio and I were discussing the future of facades today. Facades are DSF polygons that are extruded into buildings by pushing up the polygon into a roof and texturing the roof and walls from a single texture using some simple formulas. The rules for facades are very simple – we originally thought them up for the purpose of creating buildings that precisely fit a city grid no matter what the block spacing.
The problem with facades is that the rules make very simple buildings – especially the roofs. So we want more powerful facades and the question becomes: how best to do this? There are two possibilities and I mention them here because they underscore what I think is the largest overarching design decision when creating a flight simulator scenery system.
1. We could make the facade builder in X-Plane smarter (write new rules).
2. We could write a stand-alone tool that converts the DSF polygons (plus a rule file) into OBJs that are then placed directly into the overlay.
This second strategy would turn the facade from a type of scenery element into a tool for making OBJs. We would be “pre-compiling” our facades.
Here are some of the considerations:
SPACE VS SPEED
Precompiling primitives is a space-vs-speed trade-off. For any given algorithm, it’s usually faster to pre-build the entities and load them from disk than to build them in the sim. But pre-building means more files on disk, meaning bigger downloads, more DVDs, etc. Building up buildings from facades inside X-Plane is actually a form of compression.
EASE OF DEVELOPMENT
This is one criteria where I think pre-compiling scenery is a clear win: it’s easier to build a stand-alone facade-to-OBJ converter than to implement it inside X-Plane. X-Plane is a relatively unfriendly place to build scenery algorithms because it’s busy being a flight sim.
STABILITY VS UPGRADABILITY
If we make OBJs out of facades using a tool, the objects will look the same even if we create a new version of the tool. This is good in that it means that custom scenery won’t change how it looks, but it is also a limitation because improvements to facade technology require rebuilding a lot of objects to take effect.
(Another aspect of this: if the objects made from the tool use a texture, that texture can’t have its shape changed even if we make new rules, because some objects will be on users machines that were built with the old rules.)
X-Plane mostly errs on the side of pre-building scenery, and this is the one area where we really take it on the chin for that decision: the inability to easily create a new composite look from changes to some parts of the scenery. (Airports that don’t cause grass to appear under them is an example of this.)
Perhaps some good questions for weighing these options are:
1. Would an author care whether the facade looks exactly the same in the future?
2. Are there enhancements coming along in this technological area that we would not want to miss out on for older scenery?
OTHER CONSIDERATIONS
Information loss: when we turn a facade into an object, the original polygon information is lost. Is it important that we ship the actual base polygons that make up buildings, or are the OBJs that represent them good enough?
Contextual Information: often we know more about a given situation when making scenery than when displaying it. Could we do better at building up a facade inside the sim (where we have context from other scenery packages), or when creating the sim (where we have a much larger dataset)?
