From one of the podcasts I listen to I just discovered Edward Burtynsky. He takes these amazing photographs of industrial landscapes – really scary post-apocalyptic images of oil refineries, chopped up cargo ships, etc. Take a few minutes to look through some of the images.
One of the side effects of working on X-Plane scenery for the last few years is that it has made me look a lot more closely at the world. Once you try to recreate the world on a computer (and watch your digital creation fall way, way short) you realize how much intricacy and detail every-day phenomena have.
So when I saw Burtynsky’s photos I immediately thought “he sees the complexity and beauty* and sadness of industrial landscapes the same way we do!”
* Beauty? I am not suggesting that the SOCAR oil fields are beautiful, a particularly good idea, or something I want more of. But I think that there can be a poetry in the image – perhaps a poetry of despair.
With the latest updates to X-Plane for iPad, you can now purchase the Apollo lunar lander game inside X-Plane.
A quick note: if you lose your preferences (and thus X-Plane thinks you have not already bought Apollo) you will not be charged a second time if you click “buy it” again. When you go to repurchase Apollo, X-Plane will notice that you already have bought the upgrade and will simply re-enable the update.
Hopefully in our next patch we will make it clear in the UI that there is no double-purchase. The upgrade to Apollo is a “persistent” in-app purchase – once you buy it, you own it forever, as you would expect. (And because the iTunes store has a copy of your receipt, you don’t lose it even if your iPad or computer’s hard drive gets wiped out.)
Also, the latest update should fix crashes on iPads that were running for a while. X-Plane was very close to the memory limit so iPads that had been running for a while wouldn’t have enough free RAM for the sim. The new patch is a little bit leaner to work around this problem.
Sometimes I get reports of a slow airplane, and I do a quick audit for performance problems. The trick to spotting performance problems is to divide and conquer: turn off various aspects of the airplane to see which aspect is really causing performance problems, then optimize that aspect.
Here are some of the specific tricks I do:
-
Change views; the panel will be drawn differently in the 2-d view, 3-d cockpit view, external view (when close or far – zoom out and the panel won’t be updated) vs. 2-d no HUD.
If the 2-d view is slow but forward-no-HUD is not, your panel is expensive. If the 3-d view is slow but 2-d is not, one of your panels may be more expensive than the other (copy them in Plane-Maker from one to the other to see) or it could be that the preparation of the cockpit texture is slow.
-
Remove 3-d objects from your plane to test the cost of OBJs. Turn down X-Plane’s texture res or shrink your textures to see if texture memory is at issue. (Some airplane textures are not affected by the texture res settings, so you may have to manually shrink them.)
-
Be sure to play with X-Plane’s rendering settings; the GPU-specific options don’t always cost “the same”. For example, per pixel lighting is more expensive when there is more translucency on screen. If your airplane has a lot of overlapping surfaces or translucency this otherwise manageable setting might become too slow.
-
If you use panel regions, try switching to regular ATTR_cockpit. Panel regions provide superior lighting effects but can take more CPU time when you have a lot of instruments.
The key is to divide the many possible causes of performance problems to isolate one thing that can be optimized.
In my previous post I tried to break an OBJ down into a few basic sections:
- Global properties of the OBJ.
- Raw Mesh Data
- Commands, which in turn set per-batch state and then draw the batches.
The performance cost of an OBJ feature often has a lot to do with where in the OBJ the command shows up, e.g. is it global or per batch.
Global properties tend to affect OBJ performance on a one-time basis. For example, if you use cockpit regions, you pay a fairly large penalty for having the panel texture be set up even if you only apply that panel texture to a single texture. Sure enough, COCKPIT_REGION is in the global properties section of an OBJ.
Per-batch properties affect the OBJ in two ways:
- Every command you see in the commands section is going to involve some CPU intervention. A very long commands section is more work for an OBJ.
- Every time there are attributes between TRIS commands, it defines a new “batch” – that is, a separate instruction to the graphics card to draw a new and distinct setup. Think of this as shutting down the factory to reconfigure the assembly line.
Generally batch count is more important than total commands. In other words, in evaluating this:
TRIS 0 300
ATTR_light_level 0 1 some_dataref
ATTR_no_blend 0.5
TRIS 300 12
the fact that there are two attributes is less interesting than the fact that there are two batches (the two TRIS commands run with different state). Even if you got rid of the no-blend attribute, you’d still have two batches because of the light-level change.
The most powerful aspect of the OBJ format is bulk data handling – that is, you have to add a huge number of triangles before the number of triangles becomes a performance problem.
For this reason, you should never use an attribute to reduce geometry count. A few examples:
- Don’t use ATTR_no_cull to reduce triangle count – simply issue the indices of the triangle twice.
- Don’t use ATTR_flat_shade to reduce vertex count – simply use more vertices with correct per-vertex normals to simulate flat shading.
- Prefer texturing to materials whenever possible.
Finally a note on weighting: for airplanes, where the total number of objects is low (a few dozen) global object properties often matter most. For example, on an airplane, choosing to use huge panel regions, or huge textures can make a big difference in performance. By comparison, batches aren’t that expensive unless you do something really crazy.
By comparison, for scenery, batches matter more; X-Plane will share the global properties of objects across hundreds or thousands of objects, but each batch hurts framerate. So when making autogen-style scenery, batches are most important.
A number of people are working on an update to Jonathan’s Blender X-Plane export scripts; this post is aimed at shedding some light on some of the recent changes to the OBJ format. X-Plane 9 introduced a number of new OBJ features (manipulators, invisible geometry and camera collisions, dataref-driven control of emissive texturing, normal maps, and a number of new light billboard options). If you simply read the new OBJ commands in the order they were added to the format, it’s just a soup of funny names. But there is some logic to how the OBJ format is extended.
The World’s Simplest OBJ
Here is a very simple OBJ file, broken up by my annotations. First we have the header and global section:
A
800
OBJ
TEXTURE great_image.dds
POINT_COUNTS 24 0 0 36
the global section describes properties universal to the entire OBJ. For example, what textures will be used to draw the object?
We picked up a few new global properties in the version 9 run:
- Normal maps are declared globally for the entire OBJ.
- The metrics of any panel regions to be used are declared globally.
We may pick up new global attributes in the future; if we do, they will be properties that apply to the entire obj.
Next comes the data section:
VT 0.449997 0.300003 0.860001 1.000000 0.000000 0.000000 0.000000 0.000000
VT 0.449997 0.300003 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000
VT 0.449997 -0.509995 0.860001 1.000000 0.000000 0.000000 1.000000 0.000000
...
IDX10 0 1 2 3 2 1 4 5 6 7
...
IDX 21
I have removed a lot of the data section, because there’s not much to be said about it. The data section contains the raw data for the meshes in your OBJ, and it hasn’t changed since the OBJ 8 format was introduced.
The third and final section is the most interesting one: the commands section.
ATTR_LOD 0 3000
ATTR_hard asphalt
TRIS 0 36
The commands section describes how the data is used in the form of serial instructions to X-Plane. Most changes to the OBJ format have come in the form of new commands. We can categorize our commands into a few buckets:
- Drawing commands create “stuff”. There aren’t very many drawing commands, and new ones don’t appear very frequently. TRIS and LINES are the main commands, but the smoke commands also fall into this category, as do the light billboard commands. The new light billboard command LIGHT_PARAM is the only new drawing command for version 9, and it probably warrants its own blog post.
- Attribute commands change how stuff is drawn – they effectively define properties for drawing on all triangles that can be modified. We picked up a number of new attributes: manipulators (controlling how the mouse works), light level control, solid camera, draw disabling, deck style hard surfaces, and panel regions. (While you must declare the panel region locations globally, a panel region is enabled for a specific batch.)
- ATTR_LOD is sort of an exception, because it defines the structure of the model (e.g. a model with LOD really contains several separate command lists, of which only one is used).
Most new extensions to the OBJ format come in the form of new attributes. Attributes generally apply to a specific mesh within your model, not to the entire model.
Note that attributes can be thought of as “per mesh” or “per batch” properties, because they affect only the batches of mesh (TRIS commands) between the attribute being turned on and turned back off again.
Where Will New Features Appear?
I try to post some of my crazier ideas regarding OBJ on the scenery system RFCs page. Looking at the extensions, we can see how these extensions will all be either global, drawing primitive, attribute, or OBJ structure extensions. (I am not promising that any of these RFCs will be implemented, just showing how the OBJ format grows.)
- Additive LOD. This is a change to the structure of an OBJ, but it doesn’t actually change the format, just the legal LOD values.
- Explicit OBJ Height. This is a global property on the OBJ.
- Global Texture Variants would be a global property on the OBJ’s textures.
- Global Object Attributes are new global properties – they move some per-batch attributes to be object-wide.
- Draped Object Geometry would be per batch.
In summary, the vast majority of proposed extensions are new per batch or per object properties.
Next: what are the implications on performance of the various sections of an OBJ?
In past posts I have tried to describe the implications of DSF base meshes, which are “fully baked”. The basic idea is: the base mesh is fully formed ahead of time as a single unit. This is a trade-off:
- The advantage is performance. The sim has no work to do except draw that base mesh as fast as possible.
- The disadvantage is flexibility. The sim has no easy way to modify that base mesh.
By comparison, DSF overlays are not fully baked – you can add 8 overlays to an area and they will all run on top of each other. There is a real performance cost to this. Compare the performance of a huge number of draped orthophotos (via .pol files, an overlay technique) with a real orthophoto base mesh cut with MeshTool. You’ll easily get 100 fps on the DSF base mesh, but you won’t come close with the overlay.
If you want to compare X-Plane to a first person shooter, consider the “cost” of overlays as one of the reasons why FPS games appear to be higher performance than general purpose flight simulators like X-Plane and MSFS. In a FPS, each level is likely to be fully baked, with only one level loaded at a time. This is equivalent to X-Plane’s DSF base mesh. The FPS game doesn’t need to manage overlays that are put together at runtime in unpredictable combinations, and this lets the FPS engine optimize for performance.
(In fact, the FPS engine might be able to optimize a second way, if third party level packs are not available. Not only can a level be ‘fully baked’, but it can be fully baked specifically for that particular rendering engine. By comparison, a DSF base mesh will run with X-Plane 8 or 9 – clearly it isn’t specifically optimized for just one version of X-Plane.)
If you look at the scenery system “overview” I wrote around the time of X-Plane 8’s release (this overview is now pretty out of date; I really need to update it) you’ll see this:
There are now two scenery formats – one for editing and one for distributing scenery. Both are new.
DSF stands for “distribution scenery file” – the idea is that DSF was meant to be a container for fully baked finished scenery, optimized for small size on DSF and fast loading, but not editing. Our internal tools use another file formatm “.xes” to contain imported global scenery data before it is baked. Originally I thought that we would provide an editor to .xes files, but that has not happened. With MeshTool, you provide input data in more common public formats like SRTM HGT or GeoTiff, and .shp (shapefiles). You can think of .shp and .tif as the editing formats for MeshTool and base DSFs.
So how do we make it easy for users to edit scenery? I believe OpenStreetMap is the answer. The common request we get from users is for a way to edit the vector source data for global scenery (or sometimes, the request is to edit the features created by vector data). In other words: how does a user edit the coastlines, water bodies, and roads? With OpenStreetMap, OSM itself becomes the “editing” format for X-Plane scenery with DSF as the final result of baking.
Last week I finally was able to post some scenery tools builds. This begins the beta period for WED 1.1 (WED with DSF overlay editing) and a release candidate period for the AC3D plugin and MeshTool. I expect the WED beta to take a while; as long as the program is reasonably functional in beta form (e.g. not losing data) there isn’t a huge rush to package it up relative to other priorities.
WED will continue to evolve as the primary visual editor for scenery. This will include editing air traffic control data for the new ATC system and editing roads once X-Plane is ready for road overlays. (See this post for why road overlays aren’t quite useful in the sim yet.)
I’m not sure what the next features for MeshTool will be – this may depend on user feedback. One thing is clear: MeshTool is not easy to use. Building a base mesh is a complex and low level process, with lots of possible pitfalls. So whatever features MeshTool develops, usability has to be a goal.
There is one more scenery tool I would like to create: a remote render farm. Right now you can make custom base meshes with MeshTool. In the future it will be possible to make edits to the source data used or global scenery (by editing OpenStreetMap itself). You can also edit the apt.dat file and submit the results to Robin.
But once you edit OSM, how do you get a new scenery pack? Using MeshTool is complex, and MeshTool is really aimed at the orthophoto crowd. Waiting 2 or 3 years for the next X-Plane release isn’t a good solution.
My idea is to set up a computer to do “remote global scenery” requests. I would set the computer up to periodically pull down new data updates and recut tiles as requested, then post them publicly. This would allow users to edit the source data and then put in a tile request to get the tiles back, without ever having to know how to make scenery. The tiles would reflect all changes from all users.
Such a service wouldn’t be of interest to the most advanced authors who want to create a truly original scenery pack, but for authors who want to fix specific problems, this process would be much simpler. I hear the question “how do I fix the lake behind my house” all the time; a remote render farm could be part of the answer.
A bug-fix release of AC3D was posted over the weekend, and now it is gone. Andy pointed out to me that I had posted a build for Windows, but not Mac and Linux, a build error on my part.
I should be able to get all of the new tools (the AC3D patch, WED 1.1 beta 1, and a MeshTool release candidate) posted this week.
It looks like the next generation of scenery tools (MeshTool 2.0, WED 1.1, and the latest distribution of “the tools”) may have higher system requirements than their predecessors for Mac users. Those requirements would be: an Intel CPU and OS X 10.5.0 or higher.
The problem at the heart of all of these changes is that the tools use CGAL (a geometry library) and the compilers Apple distributes that are compatible with 10.4 and PPC don’t work with CGAL. So I quite literally cannot compile the latest tools because of the features they offer.
I don’t know how much this affects actual authors, and I don’t know if it is possible (given an infinite amount of self-torture) to work around some of the compiler issues. At this point my plan is:
- Distribute the next-gen tools in binary form for 10.5 and x86.
- Leave links to the old tools for users who need binary PPC tools.
- Continue to make all source code available via the GIT repo.
If someone finds a way to compile these tools for older targets using the source code, I am perfectly happy to provide distribution of those binary tools or incorporate the fixes if they are manageable.
I’m hoping to have some tools posted “real soon”…
After about a week of on and off hacking, I have finally knocked down one of the major stumbling blocks to getting WED 1.1 up to beta quality: exporting UV-mapped (texture mapped) bezier polygons that cross DSF borders. It works! Well, sort of.
If you have tried to program polygon cutting algorithms, you can appreciate the difficulty of an algorithm that:
- Clips polygons robustly (including holes and other weird topology) and
- Maintains a UV mapping while doing this and
- Works with bezier curves and not just line segments.
WED now does all three! This was the ugliest and hardest part of the DSF exporter, and a big missing piece from going beta.
Of course, there is one problem: X-Plane can’t read the bezier curves.
The problem is a simple defect in how X-Plane manages DSFs.
- A valid bezier polygon, fully inside the DSF tile, may have control handles that go outside the tile.
- X-Plane can’t handle any DSF coordinates outside the tile.
Doh!
I am not sure what I will do about this, but in the short term, I fear X-Plane will remain limited. Probably the best short term option is to have WED at least flag such problematic bezier polygons; it is possible to approximate them or edit them to make the export work.
There is still a little bit more exporter code to write, including the line segment exporter (which is separate from the polygon exporter), but with luck the whole DSF export path should be cleaned up in the next few days.
