X-Plane Scenery Blog

Moving the Blog!

2011-02-01T14:44:00.003-05:00

I am moving the X-Plane Scenery blog to: http://www.x-plane.com/blog/. You will be automatically redirected in about 15 seconds; please update your RSS feeds once you are there.

Links to specific articles will be kept in place on this blog, and will not have redirects, so you can still read them.

Various X-Plane 9 Bug Fixes

2011-01-26T11:52:00.002-05:00

A quick update on a few X-Plane 9 bug fixes we have in the works. We will hopefully cut a new beta of X-Plane 96x in the next few days.

Linux DVD recognition was unreliable and required work-arounds; my attempt to fix this in X-Plane 964 made this work, but we have a real fix.
We have a handful of hang-on-startup problems with NVidia cards and Windows 7. I am working directly with a few users to figure out what's going on, but I hope to have a work-around in a patch as soon as we ID it.
We have new installers that I need to roll into beta; they will address DVD location issues on Linux and also improve net performance.

The numbering scheme for v9 is a little bit odd at this point. Since we are putting so few changes into each build, Austin has been numbering them as "release candidates" - that is, 962 was final, then he cut a 964 and 965. 964 and 965 were both only available by checking "get betas", and both turned out to have defects. When 966 is ready, it will be available via "get betas", and we will promote it to a "real" release if it turns out our bug fixes actually fix things.

So: egg on my face for being 0 for 2 with 964 (in that both my QuickTime fix and Linux DVD fix actually made things worse).

ATC Part II - A Dilemma

2011-01-25T08:34:00.009-05:00

Here's a thought experiment for you: you have a new version of X-Plane with new global scenery, new rendering engine options, new weather, a whole fleet of new planes, and new ATC. That new ATC is rewritten to support realistic IFR flight, the AI planes participate, the system includes ground ops and it uses audio files to "talk". But the AI planes don't have real-world liveries, and they don't follow real-world schedules for major airports. What do you do?

Release this new version of X-Plane with the ATC as is, and continue to improve it in a patch.
Release this new version of X-Plane, but ship the old ATC from version 9, because while the new ATC is better, it's missing some features that some users have asked for.
Delay the release of the entire sim because ATC is missing some features that some users have asked for.

Clearly options 2 and 3 aren't options at all; you wouldn't ship the old ATC (which is clearly inferior to the new code) just because there are more features you could ship, and you wouldn't withhold the rest of the new version's features for the same reason.

No feature is ever done unless a program is dead. Austin hired me about five years ago to work on the scenery system, and it is no more done now than it was five years ago. It is a lot better than it used to be; more efficient, better looking, more realistic, etc. But the bar for what is possible keeps moving. That's part of what makes working on flight simulation software so interesting.

In yesterday's post I tried to clarify why we are using real physics in the AI ATC planes; a lot of the discussion surrounding Austin's original announcement made some assumptions about where CPU time is spent that aren't correct. This post describes how features are incrementally added to a release - without understanding release planning, Austin's description of 20 AI planes makes no sense.

Stretching the Playdough
Programs aren't just born whole, complete, never to be modified again. If there is one consistent misunderstanding of software, it's this notion that you "build" software the way you might build a bridge or a house. The truth is, software is made out of a building material that is nothing like bricks or steel, and thus the engineering practices have to be quite different.

If you build a house and decide you want a different exterior floor plan, you're pretty much hosed. No one is going to change the outer shape of a house because the materials used to build the house are not particularly pliable to modification. The cost of moving a foundation is about the same as building a new foundation, so modifications are made as minimal as possible.*

By comparison, code is a lot more like playdough than bricks or concrete. You want the master bedroom a little bigger? Great, we'll just streeeeeetch it out. Code is always modifiable after it is "finished" - if treated right, it never hardens and sets, and this is why successful programs are often on version 10. The problems a computer program tries to solve change, but code can change with them.

So my first take-away point is this: if we add a feature to a program later, it is not because the program was "incomplete" or "unfinished" before - perpetual improvement is the expected norm in a healthy computer program. In fact, perpetual improvement is desirable because it lets us match changing technology and because it lets us incorporate feedback we get from our user base.

(There's an old saw in computer software that the reason to put out version 1 is to learn what you did wrong so you can make version 2. That's a bit of an exaggeration, but the truth is that the only way to get really solid user feedback is to put something out there and then listen.)

Roadmapping

Given that we expect our software to change perpetually, how do we plan? The answer is that we need a road map for the next several steps that the software will take as it evolves. By knowing where we are going we can be reasonably well-informed on the features we code now.

A road map of features needs to be prioritized for two considerations:

What do users want first? The things we code first, we can ship first, so high priority features should go first.
What features have to be implemented first? You can't build the roof of a house first, and we couldn't have programmed orthophoto paging of DSFs until we programmed loading DSFs themselves. Sometimes the features "have" to go ina certain order for programming reasons.

ATC AI Airplanes

At this point we finally have enough common vocabulary to sanely discuss the AI airplanes for X-Plane's ATC. So far I have tried to establish that:

The AI airplanes are going to get better over time.
We will almost certainly ship ATC AI before the AI airplanes are perfect.
The order that we implement ATC features will be a mix of what we think is most important and what has to go in first for engineering reasons.

The first stage of the roadmap was to use X-Plane's built-in AI planes as AI traffic. There were a lot of reasons to do this as the first step:

The code's already there, so it let us get some airplanes moving around quickly. Inventing a fully separate system from scratch would have taken time away from the rest of ATC.
Virtually every optimization that has been suggested (and several that haven't been) can be applied to the AI ATC airplanes, so there's plenty of room to get faster. (If we thought we couldn't optimize, we might not have put the flightmodel in for AI at all.)
By sharing the flight model code with AI, the optimizations we do pay twice - to make ATC faster and to make the framerate faster for all users.
Inventing a new way to make airplanes (only for ATC) would mean two sets of editing tools, which would invariably mean worse tools in all cases.

With the AI planes running, we then have a lot of ways we can improve things. We can optimize performance. We can optimize memory use. We can increase the airplane limit. We can virtualize the flights (so far away flights exist only in the ATC DB and don't use a "real" AI plane). We can sever the 1:1 mapping of airplane model to flight. We can recycle airplanes when they get too far away to be adding anything to the user experience.

Which techniques will we do, and what will the airplane limit be? I don't know. Optimization really needs to be driven by testing - that is, we need to improve the system by measuring it to see what the next best step is, not by speculating about what problems we might hit in the future. Over time, we will repeatedly optimize and the capabilities of the system will steadily grow.

If you want to know the final specs and capabilities for the ATC system, I fear you'll have to wait until X-Plane 10 ships. When we are in development, any planning for future features is just that: a plan. As we hit real bugs and learn more about the features, the plan can, and often does change. Thus estimates of what X-Plane 10 will do won't be truly reliable until we ship.

* I should be careful here; I used to have these conversations with Sergio, who is a professional architect among other things, and he would have to correct me on a million different aspects of construction technology.

ATC Part I - Real Physics

2011-01-24T11:20:00.003-05:00

This is a repost of a reply I wrote on avsim that sort of grew out of control. In part II I will try to explain what we're doing with the ATC system and how far we will get in X-Plane 10.0. Anyway, post follows.

I will have to write a blog post to go into this in more detail later, but I think a lot of what has been written here is wrong. Y'all started under the assumptions that:

The flight model is going to be too expensive to run on AI planes and
A table based flight model would be faster.

Those are both questionable assumptions at best...pretty much everything you can conclude from that is, IMO, dubious.

(I should mention at this point that I am unaware of any "dumbing down" features in the FM right now. My understanding is that we will pre-process control inputs in a number of ways, and the frequency of the FM can be set to multiples of the framerate, but even at the lowest setting, we do a full physics integration and the plane is the sum of the physics that are applied to it. I mention this now because I am about to speculate on some optimizations that _could_ dumb down the physics model, and I want to make clear that shipping X-Plane 9 does not do this!!)

Here's the short version:

The most expensive part of the flight model is ground interaction - that is, the flight model doing collision checking with the ground and various parts of the airplane. When an airplane is "clearly in the air" (e.g. an initial test shows it has high altitude) the FM isn't very expensive; when it is near the ground, CPU time cranks up as we make sure to get the touch-down characteristics just right; same with taxiing.

So if we want to make the FM faster, there's really only one place to attack: ground interactions - it's the lions share of CPU time. There are a number of simple things we could do to improve ground interaction. For example, we could stop checking for body scrapes - since X-Plane has to handle physics correctly even if the user lands gear up and scrapes an engine, the sim normally tests the full geometry of the plane against the ground (which is not flat, even at an airport) - that adds up. If we are willing to trust that the AI planes don't screw up a landing* we could cut down ground check to only real landing gear, which would improve performance.

Now what if we did some kind of 'lo-fi' AI, whether it's table based or it simply says "move the plane forward by this much" (E.g. a sort of track-based system)? If we want the airplanes to 'sit' properly on the non-flat airport surfaces, we _still_ need to do the most expensive part of the FM - the wheel-ground collision checks. So the total savings of a 'lo-fi' AI flight model would be very small, because at best we might partly improve the performance of code that doesn't have much impact on the sim.

(To understand why you can only boost performance by attacking the biggest pigs, see here.)

However, there would be a pretty huge cost to a lo-fi flight model: we would have to code a SECOND implementation of pretty much everything we already do in the real flight model! We would have to have new flight model files to support this new alternate flight model. The opportunity cost here is in developer time...the time spent building a separate flight model could have been spent performance-tuning the real flight model...even if we had a second flight model, performance tuning time would now be divided between the two flight models, and neither would reach its optimal performance.

Besides my explanation above of why a lo-fi flight model wouldn't really be a win, two more comments:

In software development, it often pays to try the simplest thing first, see how it works, and go from there, rather than speculate how a system may perform and write a ton of code up front before you have real data. This is what we are doing...the simplest thing we can do is to run the real FM on the AI planes, and so far it looks like it's going to work reasonably. IF we hit data that says "no we have to do something radical", then we will...when the data says so, and no sooner. So far indications are that the real FM is going to be fine, and this makes sense from what we know about its performance characteristics. We also know that we have a lot of tricks we could pull to make the real FM faster for AI planes (e.g. removing engine scrape-checks, per above) before we have to go and write a whole new FM.

And finally, dude, the real FM looks good. With the real FM, the AI planes move the way big heavy airplanes should move. They track the ground perfectly. If the ground has a bump and the airplane's suspension is loose, it sways like it should. The control surfaces deploy with their real time. When you're at an airport performing ground ops, you can get really close to the AI planes, and at that point these things matter! I speculate: once you take follow an AI plane running the real FM on the ground, it'll be hard to go back to a 'synthetic' FM.

* This may not be a safe assumption...what if a microburst hits an AI plane?

Light Levels: Don't Panic

2011-01-21T11:27:00.003-05:00

One of the comments on the suburban preview screenshots I've heard in a bunch of places is "I hope it's not going to be that dark" or "could you guys add more light"?

At this point, light levels in our previews are not reflective (no pun intended) of how the sim will really look. The reason is simple: the light model is not fully debugged (who am I kidding -- it's not even remotely debugged) and it only takes one light model bug to completely throw off the light levels. So I think light levels are going to be a case where the sim's lighting looks a bit funny right up until the last bug is swatted - it's just the nature of those kinds of bugs.

To give you an idea of how much change there is in lighting from version 9 to 10, here's a short laundry list of sim changes that affect lighting:

Dynamic Exposure. X-Plane 10 reduces the effect of emissive (_LIT) textures base on the brightness of the sun. In X-Plane 9, emissive textures have the same impact regardless of time of day; thus a lighting effect that looks good at night will look too strong during the day. (In real life, you eyes would adjust for the sun and the artificial light would seem less bright.)
Linear Light Mode. This gets confusing fast, but basically, our eyes perceive light in a non-linear way; we are more sensitive to low light levels than bright light levels. Computer graphics mimick this behavior; the result is that most computer lighting models are physically incorrect in some circumstances. Using the non-linear eye-based behavior has been the norm for while because it was cheaper hardware-wise, but these days it is possible to do physically correct linear lighting. We are adding this wherever we can; the correctness varies with rendering settings since physically correct lighting is more expensive GPU-wise and we don't want to hurt fps for low-end users.
Deferred Rendering. X-Plane 10 has two rendering modes: a forward renderer (which is a lot like X-Plane 9) and a deferred renderer that supports global illumination and an HDR rendering space.* This creates a certain amount of chaos because the code for forward and deferred rendering are separate, and they seem to develop separate, unrelated lighting bugs.
Global Illumination. X-Plane 10 supports global illumination in deferred rendering mode, which means that thousands of lights can light up any part of the scenery system. Thsi means that (for the first time) an object may be lit by dozens of light sources at once. It turns out that the linear light model is a lot more important when we have more than one light source. (In fact, Alex and I realized that we needed a linear light model when looking at highways lit by streetlamps.)
New Light Billboards. X-Plane, like most flight simulators, uses billboards (textured squares that face the camera) to draw the light effects near a light source, like glare and bloom. The shape, textures, and equations for the light billboards are heavily revised in version 10.
Clouds. The weather system is being rebuilt, including new shaders for cloud puffs. Since cloud puffs aren't like solid buildings or airplanes, they have their own shaders with their own light characteristics. We are also experimenting with increased ground visibility, which affects fog.

If there's a take-away point, it's this: lighting isn't just one piece of code in X-Plane - it's the sum and interaction of a large number of features, all of which are being heavily worked over. Only when all of the features work correctly and work together in harmony will we have what appears to be sane lighting.

* Some users may confuse HDR, which just means an image with increased dynamic range for light levels, with the more common effects that games ship once they have an HDR render: bloom and tone mapping. Bloom is when bright light sources "blow out" and splat light around nearby areas; tone mapping is a technique to visualize that high dynamic range on a normal monitor - often it is used to simulate your eyes adjusting to variable light levels.

I do not think we will ship bloom in version 10.0; I experimented with it and found it had almost no value. First, there are very few scenes in a flight simulator where bloom is that useful; it seems to be a lot more useful for interior rendering, like you'd see in a first person shooter. Second, X-Plane already has a number of bloom-like effects, including halos around lights via billboards, sun glare, etc. With most of the important cases already covered by ad-hoc effects, my early experiments with bloom weren't very promising. We may revisit bloom later, but I don't think it's as important as other effects for now.

Similarly, I don't think we will have dynamic tone mapping because we will have an overall dynamic exposure control running all of the time. Again, the value of tone mapping is more obvious with first person shooters, where you can go from interior to exterior and you want the world to be 'overpoweringly bright' for a while. By comparison, pilots do their best to preserve their night vision, and the interior of an airplane is designed to match that; instruments auto-calibrate their brightness to the overall light levels, making tone mapping less important.

Next-Gen Cities

2011-01-20T10:56:00.003-05:00

A few days ago Tyler posted some pictures of the "auto-gen"* for X-Plane 10's global scenery.

First, a few notes on hardware and performance: Propsman took these pictures on a new iMac, so that's a core i5 and a Radeon HD 5000 series GPU - that is, a pretty decent system. Hardware technology continues to advance rapidly (especially on the GPU front), so there's a big difference between a 'decent' system bought today and even a hard core system from two years ago.

I don't know what your performance will be like. I do know that the system is performing well enough so far in its not-really-all-that-optimized form that we think we can ship it, and more importantly I know that we can turn the level of detail down in a number of ways to lighten the load as needed.

The most expensive feature you see here is the real-time 3-d global shadows. Heavy shadowing combined with heavy 3-d does add up and hit the system hard, but I think we'll be able to have intermediate shadow settings that should be more affordable.

X-Plane 10 will use hardware instancing if your GPU is capable of it, and it makes a big difference in the amount of 3-d you can show.

X-Plane 10 is also quite a bit more fill-rate intensive than X-Plane 9; if your GPU is having fill-rate problems with version 9, some version 10 features will be out of reach. In the past, X-Plane has been light on fill-rate, so we've had users running with cut down cards (like a GeForce 8400) without realizing that their card isn't that fast.

Some users have asked about architecture and localization. I expect we will not ship out of the box with multiple local regions; however, the library system allows us (or any third party) to provide new artwork sets for local, architecturally reasonable buildings.

Finally, it might be a bit difficult to see in these pictures (because they are focused in on the detail), but the 3-d buildings you see here work with the real-world roads. In the past, we've had a clash between the buildings and roads vs. the terrain texture. This is a problem we are solving for X-Plane 10.

* Auto-gen, meaning bulk buildings that populate the world in urban areas...whether it's really auto or gen or anything like autogen in the past is a complex discussion that will have to wait.

The Scenery Site Is Wikified

2011-01-14T10:04:00.003-05:00

This summer Tyler migrated the X-Plane scenery SDK documentation to X-Plane's main wiki. I just put in a series of redirects, so that the old URLs for the top level pages will point to the various wiki sub-categories. The wiki contains the most recent information now, as well as up-to-date download links, etc.

At some point I will try to replace the individual scenery documents (part of the library.php script) with redirects to the appropriate wiki pages; until then I will leave the old site in place.

LSD.glsl

2011-01-13T20:43:00.000-05:00

Too trippy not to post:

Fun With Servers

2011-01-10T10:48:00.004-05:00

Just an FYI: when it rains it pours. Normally betas increase load on our set of update servers. To compound this, one of them is suffering a midlife crisis^H^H^H^H^H^H^H^Hhard drive failure.* We're working on it now; hopefully it will be resolved in the next 24 hours.

EDIT: the update server is back up - our host not only swapped out the drive, but the whole box. We'll have to take it down one more time in the future, but for the most part I think we're out of the woods.

Another note on servers: Chris has restructured X-Plane for Android to separately download the art assets from our servers, rather than contain all art assets in the actual download. What he found after several painful weeks was that the Android store is not yet reliable for large apps. While the official app size limit is 50 MB, many phones have problems with their configuration that cause downloads to fail. When the user buys our app and the download fails, they get angry at us. (X-Plane may have been, until it was restructured, one of the largest Android game APKs. The other games with large amounts of 3-d content were already doing separate downloads.)

We originally wanted to build a monolithic app (everything in the APK) because we thought that this would provide the simplest, easiest configuration to maintain, and thus hassle-free installation for our users. You get the APK, you install it, you fly! Unfortunately, the Android Market isn't reliable for such a large download, so we had to re-evaluate.

The new system downloads only the core app from the Android Market and then pulls the art assets from one of our servers. So far this appears to be an improvement. If/when Google provides an integrated solution, we will probably switch back to it to simplify the process again (right now we have two points of failure: the Android Market and our server farm, which, per the above notes, sometimes does fail). But for now, we'll host the apps and try to give people the best download experience we can.

Finally, I will try to roll out at least a beta of new installers some time this week. The new installer simultaneously downloads from multiple servers, with a more efficient HTTP implementation; this should hopefully result in better download times and also lower server load per demo.

* Chris pointed out: most normal humans don't know what this ^H^H^H^H is about...it's nerd-speak for the delete key, e.g. to undo a text. ^H is control-H, which you may find works just like the delete key. Yes, I'm a huge nerd.

Plausible, Realistic, Procedural and Algorithmic

2011-01-08T17:03:00.003-05:00

Alpilotx pointed me toward a thread on the org discussing Austin's work on the weather system. The thread turned into a bit of a he-said-she-said with regards to Outerra and whether it could some day be combined with X-Plane.

This blog post will be a discussion of various general approaches to scenery and the trade-offs we have to consider, e.g. plausibility and realism, procedural vs. algorithmic and data driven design. But first, a brief note on Outerra. As I have said before, we are already aware of Outerra, so there is no need to email us. The bottom line is that we have a set of mostly done features for X-Plane 10, our goal is to finish X-Plane 10, and we are not even spending one brain cell considering putting a new rendering engine into X-Plane while we are trying to get 10.0 done.

Defining Some Terms

One of the problems with comparing scenery system approaches is that a real productized approach to scenery rarely fits into a perfect bucket or matches a single theoretical techniques. So here are some approximate terms, designed to generally describe an approach. They're not going to be perfect fits, and even the definitions will fluctuate in different contexts and forums.

We can say scenery is plausible when it looks like it might exist somewhere in the world. Plausible means that roads don't go straight up over a cliff, trees don't grow in the ocean, etc. In other words, plausible scenery is scenery where absurd things don't happen. Plausible scenery is great when you don't know what an area should look like. A lack of plausibility is often a bug.
We can say scenery is realistic when it correlates closely with what is really present at a given location on the Earth. So if there really is a lake behind my house, realistic scenery has that lake. Plausible scenery might have a lake, a forest, or something else believable for where I live (the Northeastern United States). A giant sandy desert would not be plausible for my location.
We can say scenery is procedural if the detail in the scenery comes from some kind of algorithm that produces results. For example, a fractal coastline is procedural.
We can say scenery is data driven when the detail comes from some source of external input data. Our mountains are currently data driven - that is, the mountain shape basically comes directly from the DEMs we use.
We can say scenery is artist driven if the look of the scenery comes from art assets created by an art team.
We can say scenery is algorithm driven if part of its look comes from the transformational process that converts data from one form to another.

(I'm sort of drawing a line in the sand here with procedural vs. algorithmic, but what I'm trying to contrast is a program that generates 'information' out of thin air vs. a program that creates information out of other information. For example, in X-Plane 9, European capillary roads were procedural. We had no real data, so I wrote an algorithm that made them up in a manner that was consistent with underlying terrain. In version 10, these roads will be algorithmic; we take OSM data and then do some processing to make it suitable for X-plane. This is definitely a line in the sand kind of definition.)

So Are We Plausible or Realistic?

So the first question is: is the goal of X-Plane global scenery plausibility or realism? The answer is: a bit of both. Austin's posts on the subject virtually always bring up plausibility. The reason for this is simple: he is not too worried about the amount of realism we've put into the scenery, but he is not happy with the bugs. He wants the bugs gone. So every time he and I speak, he says "and make sure it's plausible!"

But we're not going to remove realism just to fix plausibility bugs. I expect that the next global scenery render will be at least as realistic as the last - that is, we're going to use better data and we're not going to make up data where we had real information before.

There are limits to realism. We don't expect the global scenery to ever be as realistic as a custom scenery package for a small matter. But realism does matter. Part of the joy of flying in a flight simulator is seeing the real world. Where we can have more realistic global scenery, we consider it to be a win, and we are always looking to be more realistic than the last render.

Plausibility for the version 10 render is going to take two forms:

Bug fixes. Any time something screwy happens, it's not plausible. Sometimes these are code bugs that must be fixed, and sometimes they are data conflicts. For example, the water data sasys "water" but the elevation data says "hill". Combine them and you get water going up a hill. We have to write code to resolve this, somehow.
We are reworking the way cities are rendered, because even at their best, the old approach, procedural buildings with algorithmic roads over land class photos, did not look plausible, even at its very highest setting. So this is a feature request to fix a plausibility problem.

Algorithmic or Procedural

I've discussed this before (and forgotten about the post). But to expand the discussion, we need to consider not only algorithmic and procedural data processing, but whether we are driven by procedural generation, input data, assets created by artists, or some combination. (In practice, all systems require a mix of data, art assets, and procedures and algorithms, it's a question of the blend.)

I've been working on global scenery for a few years now, and over time I've come to appreciate the importance of artist input (via art assets) into any scenery process. Simply put, if you want scenery to look good, you need to make it reasonably straight forward for people who are good at making pretty pictures to control the look of your visual results. A few years ago I viewed the scenery process as strictly a question of data conversion and visualization, but now I see it as finding a way to merge art assets and data into a cogent final product, with the art assets being used in a way that the artists can control. In practice, this often means making sure that the art assets come in a format that artists are comfortable with or can learn without too much pain.

As I said in the previous post, our approach is becoming more algorithmic and less procedural as higher quality source data becomes available. (For example, we don't have to generate European roads when we can import and reprocess them.) But our approach over time has always been heavily artist driven. By this I mean: our input data is algorithmically processed into a final form that makes sense only in the context of art assets, and we have a pretty good idea of what those art assets will look like when we design the algorithms. To use roads as an example again, our task with OSM is to convert OSM road data into a road network that will visualize nicely with road art assets created by an artist.

Procedural Compression

One way to view procedural scenery is "creating lots of information from little or no information". But another way to think of it is as a compression technology. As was correctly pointed out on the org forums, you use less storage specifying the overall location of a forest than you do specifying every tree individually. The compressed form (store the forest location) can be equally plausible. It will be less realistic if the original tree locations were based on real world data, but it will be equally (unrealistic) if the original tree locations were procedurally generated. Put another way, pushing procedural processes out of the scenery generation process and into the flight simulator makes DSFs smaller.

When I first started working on X-Plane 8 DSF scenery, not only was DVD size a factor, but so was load time; we had one core and it wasn't a very fast core. Anything we could do to make loading faster, we did. Thus we pushed a lot of work into the scenery generation process, including procedural processes, to keep load time down.

Times have changed; we now have dual core machines as a baseline, and often quite a few more cores. Thus over time we are starting to move procedural processes back into the simulator, trading load time (which runs on multiple cores) for generation time and file size. So perhaps a more accurate statement would be: our scenery generation process is becoming more algorithmic and less procedural, and X-Plane itself is becoming more procedural. This is driven both by more input data (which must be processed up front) and more compute power on the host (which lets us shrink file size, and thus use DVD space for other things).

X-Plane 10

Here's how this plays out in practice in version 10:

Some (but not all) of the building placement work* has been moved into X-Plane; a bit of expensive precomputation is still done at DSF generation time.
Some (but not all) of road processing has been moved into X-Plane; a lot is still done at DSF generation time.
Where possible, we are moving from a multi-layered approach to terrain to a pixel-shader-based approach to terrain. This cuts down overdraw and uses the GPU more efficiently. (The simplest example: in X-Plane 8 and 9, cliffs have separate terrains from hills. In X-Plane 10, a single terrain sits on both the cliff and the hill and changes its appearance based on the actual slope; this texture change is computed by the GPU.)

In other words, X-Plane 10 is making the logical evolution to better balance the computing resources we have to improve plausibility and realism.

I Recognize That Scenery

2011-01-05T12:08:00.001-05:00

Thanks to Dominic for sending me this link...these guys are building an airship^H^H^H^H^Hhover^H^H^H^H, well, it's weird looking. Hrm...that airport they're landing at in the simulator looks strangely familiar.

100 Mile Visibility

2011-01-04T19:45:00.004-05:00

First, Happy New Year! As is typical, I've been quiet on the blog because things have been insanely busy here at work. Just to give you an idea of the insanity:

There will be a 9.63 relatively soon - the bug driving this is some Linux distros not finding the DVD. But we'll get a few new datarefs in there too.
We have new updaters and installers to get tested, again addressing Linux DVD issues, but also with updated web download code that should give a nice speed boost.
Chris has been working hard on Android. X-Plane for Android is pretty much the biggest APK anyone has tried to ship, and as a result we've hit a number of problems with the market that we are going to work around.
All that's just the side show; X-Plane 10 development is of course the meat and potatoes.

Now, about visibility. X-Plane 9 restricts ground visibility to 25 nm (about 46 km) in an attempt to prevent you from seeing off the edge of scenery tiles. Many users have expressed (some more persistently than I would have liked) an interest in longer range visibility. Austin recently posted a note to X-Plane.org discussing level of detail and distance management in the new weather system, and users immediately picked up on his mention of 100 nm visibility. Here's what we're thinking; all of this is subject to change as we keep working on the product.

First, visibility: you can come up with a formula for the distance to the horizon based on height above a sphere: d = sqrt((r+h)^2 - r^2) where r is the radius of the planet and h is the height above the planet. Since the Earth is roughly 6 million meters in radius, we get a visibility to the horizon of:

100 meters: 34.6 km
500 meters: 77.4 km
1000 meters: 109.5 km
10000 meters: 346.5 km

Clearly a little bit of altitude lets you see a long way.

But there's more to it than that: X-Plane has always changed the visible distance with altitude. The 25 nm limit applies to surface observations (which is what you get from a METAR). As you move up into orbit, that distance is scaled out to the horizon distance, so that you can see the whole planet from orbit. That scaling can reveal the edge of DSFs, which are blended into the planet when volumetric fog is enabled.

So here is what I think we really need to do:

We do need a larger 'surface level' maximum visibility, so that distant features are visible from the ground.
We need a scaling from ground to upper atmospheric visibility that gives us more visibility sooner; one of the problems with version 9 is that the increase of visibility is slow, which gives mid-elevations a hazy look.
In the long term, we need to load more DSFs, probably twelve instead of six. X-Plane 10 already has some improvements in how scenery shift is done, but my guess is that we can't productize this until we have a 64-bit build (since more DSFs chew more memory), so I expect this to happen in a patch.
We need to add elevation displacement to the whole-Earth planet render, so that the blend between DSFs and the planet don't have huge height gaps at high-elevation locations. I am hoping we'll have this in 10.0, but it is not coded yet. (Usually we recut the planet textures last, since they are cut off of the DSFs.)
We need to improve the quality of haze, fog and atmospherics. In real life, atmospheric scattering reduces the contrast of far away terrain. I believe that correct scattering could make a huge difference in the quality of the transition from DSF to planet, the required tex res (we need less if we scatter more), and generally it would be a big contribution to the realism of the image.
I'm not sure how much of this we'll get into 10.0; I have a prototype of Sean O'Neil's atmospheric scattering shader from GPU Gems 2 running in the sim, but I don't think it's shippable. I do hope we'll get at least some scattering in place, with improvements in patches.

That's a road map, at least. If there's a take-away point, it's this: increasing visibility is complex and involves a lot of parts of the sim and there are still significant parts that need work. So I really don't know if we'll hit some kind of hitch or problem that requires us to back off visibility.

Austin's comments about 100 nm visibility reflect what the slider in the sim happens to be set to now. It's also a design goal of the new weather system - that is, we want the new weather system to handle significantly larger distances (and have better scalability) than the old one did.

X-Plane 9 is here for Android

2010-12-20T21:26:00.004-05:00

It shipped! X-Plane Mobile is now available for Android phones - look in the Android market under "X-Plane 9".

Edit: Chris sent me this QR Code - scan it to go to the store listing.

Edit: if you either cannot see X-Plane in the Android market or you cannot download it, please first look here for trouble-shooting tips, then contact customer support (info at x-plane dot com). Please do not use the comments section of this blog for customer support; if you need help we will need to contact you one-to-one.

X-Plane for Android

2010-12-19T14:56:00.004-05:00

As some have noticed on the org and on FaceBook, Randy mentioned that we may be able to ship X-Plane Mobile for Android. Some users were quite befuddled to learn that we were aiming to ship X-Plane Mobile for Android so soon when X-Plane 10 is delayed. Here's the full story.

Chris, the third and most recent addition to the X-Plane programming team, began a port of X-Plane Mobile to Android a while ago; this was the second port of X-Plane Mobile after our port to Palm WebOS. He was able to accomplish most of the port fairly quickly; hence the video floating around the web of X-Plane on a Nexus One back in May.

Unfortunately we ran into some issues that stopped ship; it looks like Google may have them fixed shortly, hence our hope of finally shipping the app. So while Chris has spent a little bit of time recently working on the last few Android issues, our hope is to release a product that we already put development time into a while ago.

X-Plane vs. Blender Normal Maps

2010-12-14T20:50:00.003-05:00

Propsman pointed this one out to me yesterday: apparently Blender tangent-space normal maps run from a value of Z=-1 (no blue) to Z=1 (100% blue). This is not how X-Plane normal maps work; our normals go from Z=0 (no blue) to Z=1 (100% blue).

This difference is easy to miss because X-Plane has to renormalize the normal map as the last step of processing the normal map. This turns a big artifact into a small one. The general effect of using the Blender convention rather than X-Plane's is that your normal map will look 'less bumpy' for fairly extreme amounts of bump.

To fix this, simply remap the colors of your blue channel in PhotoShop or some other image editing program. Basically you'll want to set what was 50% blue to 0% blue, and keep 100% blue the same. This will extend the lighter half of the blue channel over the entire blue channel.

If you have any blue less than 50% in the image, um, that's a normal that points backward, and X-Plane doesn't support that.

Updating to OS X 10.6.x

2010-12-09T18:51:00.002-05:00

If you have a DirectX 10 or 11 class video card (that is, a GeForce 8nnn or newer or a Radeon HD card) and you're on a Mac, consider updating to OS X 10.6.x if you're still on OS X 10.5.8.

10.6 has performance enhancements in the video drivers that I suspect will benefit X-Plane 9 users, but it will really matter for X-Plane 10. We need OS X 10.6 to expose some of the OpenGL extensions that these cards have. Thus 10.6 will get you faster frame-rate, more realistic lighting, and more efficient VRAM use.

(If you have an older card, I don't know if you'll get any benefit, although I doubt you'll see a performance loss.)

Using Glass Objects in Planes

2010-11-26T15:31:00.002-05:00

X-Plane 9 allows you to categorize objects as being on the plane's outside, inside, or glass. X-Plane depends on these flags being right for a few things:

The draw order of the airplane is determined by the object types - glass is drawn last to avoid translucency artifacts.
Interior light from the plane is only spilled on the "inside" objects.
Glass objects are excluded from shadow calculations to avoid having opaque windows in the airplane shadow.

It is important that you use these flags as intended; X-Plane 10 depends on this information as well, and X-Plane 10's global spill and global shadowing algorithms are more sensitive to incorrect categorization of objects than X-Plane 9's forward renderer.

In particular, you should have glass for the airplane windows in an attached object tagged as type 'glass'; do not attach your glass to the cockpit object, which cannot be categorized as glass. If you have an old plane with glass in the cockpit, consider cutting the object in half in a 3-d editor and attaching the glass separately.

(You should also use our prop disc animation, rather than use an OBJ for prop discs; the OBJ format doesn't contain the z-buffer tricks necessary to make the prop look right.)

The Four Minute Mile

2010-11-24T11:09:00.002-05:00

Sometimes these posts get off topic, sometimes in the direction of the art of computer programming, sometimes in the nature of the industry, and sometimes with pictures of the pets. This post is going to go off a bit into the subject of project management.

Randy and Tyler posted what was becoming clear (by the lack of an already existing beta): our estimated release date for X-Plane 10 was incorrect. Software project delays are pretty common, and often when a third party add-on is delayed, the community jumps to speculate about "what's going on" inside the project and tries to infer whether the delay is an indication of serious problems.

I'd like to try to reframe the issue of delays in terms of an analogy. You ask me: how fast can you run a mile? I tell you "4 minutes and 15 seconds". I then run a mile and you time me. My time: 6 minutes, 10 seconds.* What can we learn from this episode? I think we can learn two things:

For a computer programmer, I am surprisingly fast - a six minute mile isn't to be sneezed at when you spend your days sitting on your ass in front of a monitor drinking coffee.
My ability to predict my own speed is not very good. I was pretty naive to think I could run a 4 minute mile - that's what world class athletes run. My estimate was off by a fairly big error margin.

One thing we should not conclude is that because my mile time was 2 minutes slower than estimated, that I am a slow runner. The estimate sets up an expectation, but if the estimate is wrong, it's not a useful metric of efficiency.

The same applies to X-Plane; we missed our original projected ship date because the estimation of when we would be done was not a very good estimate. This isn't good for a few reasons:

It creates uncertainty for third parties as to when a platform will change.
It makes it difficult for marketing to properly plan a roll-out.
It makes it difficult to balance the value of more features vs. an earlier release date (since we don't know how much "time" we are trading for "features" if the time estimates are wrong).

But the delay is not at all a black mark for our team - on the contrary, they're working their asses off and creating some really great work.

When looking at a project that will be delayed (because the original schedule was wrong) there's a few things you can do:

Add more people. This is quite often the wrong thing to do - please read the Mythical Man Month to understand why. Once your team is the right size, adding more warm bodies usually makes schedule delays worse and hurts efficiency.
Remove features. This is the only real way to bring in a ship date.
Move the date back.

When Austin and I were working on X-Plane 8, we hit a similar scheduling problem - what we had set out to do was going to take a lot longer than we thought. (Like X-Plane 10, we had just doubled the team size and begun a project that involved massive rewrites, which made it hard to ship until the work was fully complete. Sound familiar?) The difference? With X-Plane 8 we had contracted to ship with an external distributor for Thanksgiving, so we had to go for item 2 - we cut scope. What we cut was the world - that is, we shipped new global scenery only for the US, and the existing ENVs for the rest of the world. We also had to ship the artwork we had on hand, despite being unhappy with its quality. We didn't finish the rest of the world and graphics we were happy with for another 11 months.

Option 2, cutting scope is painful and hard. Sometimes it is the right thing to do. In the case of X-Plane, however, we have the luxury to move the date back. With that in mind, we're trying as hard as we can to keep feature-creep minimal and finish what we've already bit off, so we can get the release done and out the door.

* My mile time is not 6 minutes, 10 seconds...I would be astounded, and quite possibly in the ER if I could run that fast for any sustained amount of time.

Curved Roads

2010-11-16T16:20:00.003-05:00

At this point I can say with 99% confidence that X-Plane 10 will feature bezier curved roads. In X-Plane 9, a road is a line segment; you can simulate curved roads by using a lot of line segments, but the global scenery roads are pretty chunky.

X-Plane 10 allows for a road to be a bezier curve, allowing the specification of smooth curves with a small amount of data. This sets us up to trade off visual quality and performance using a rendering setting.

A few notes for authors:

Like all of the new v10 road features (and pretty much all of the new v10 scenery features), you don't have to use bezier curves in your roads. They are there as an option if you want them.
X-Plane 10 will not make curves for you; road data that is defined as line segments in the DSF will be rendered as line segments. (This follows the principle that DSFs contain pre-processed scenery data, and the sim shows DSFs exactly as they are written.)

Pay No Attention to the Documentation

The DSF specification alludes to bezier curved roads; this "old way" of encoding curves was never supported in the sim - all versions of X-Plane ignore this data. The "old way" was how we thought we might do curves some day.

The version 10 curve encoding is different; the "old way" will continue to be ignored in version 10. So: do not use the DSF spec to try to make curved roads now. I will post detailed documentation on curved roads once version 10 is available to authors.

A Cliff Shader

2010-11-02T17:12:00.003-04:00

I have been stingy with pictures of next-gen global scenery for one reason: it's really hard to get a nice shot of the global scenery that doesn't show unfinished features. With something like global lighting I can zoom in and show just the new trick, but with global scenery, I can't take a picture of a new house without showing a city block that looks funky due to a bug and a road that isn't finished. Posting a working shot of the global scenery where some sub-systems have bugs and artifacts would just freak everyone out.

I figure if it's obvious that the shot isn't a production shot, I can get away with posting it though.

A lot of the times when I work on the rendering engine, it is with test textures like this. Our art team does their best to hide the seams between different art assets, so that the scenery looks like one continuous world. The problem for me is that the better they do, the harder it is for me to tell if the underlying shaders are doing what they should do.

So alpilotx sent this test: it's all of the Innsbruck area painted with a test texture. What's new and interesting here is that the flat, hill, and cliff areas are all shaded by a single shader that selects between multiple textures (and rotates the textures) based on the underlying mesh.

We are adding the cliff shader to version 10 for a few reasons:

Often we can get better cliff and hill definition by processing in the shader than by painting different triangles with different textures; our ability to control the transitions using different .ter files is limited.
Using one slope-sensitive shader saves over-draw and triangle count, which makes the DSFs faster and smaller.
Some day we may have the GPU distorting mountains on the fly to make them more mountainous. If we do, we need the GPU to also apply the correct textures; if the cliff areas are precomputed then they won't respond to GPU distortion.

Will X-Plane 10 Have X?

2010-10-21T10:48:00.002-04:00

If I could have a dime for every email I have received that asks some form of "will X-Plane 10 have X" (where X is a feature or enhancement), I wouldn't need to actually work on X-Plane anymore. (If you think your email triggered this post, well, there are approximately 100 other users who have asked the same thing.)

Simply put: I have no idea and I'm not going to try to answer these questions any more. Here's why:

For as long as I have been involved with X-Plane, Laminar Research has provided free patches to the simulator throughout a major version run, and those patches have included not only performance enhancements and bug fixes, but also major new features.

So the question "will X-Plane 10 have X" can really mean one of two things:

Will X-Plane 10.0 have feature X immediately 'on the DVD'?
Will X-Plane 10.x ever have feature X in a free patch before the major version run is over.

I can answer the first question, because we are relatively locked down on what features are still on the table for 10.0 vs. what must wait, but I think it's at best confusing to do so. If a feature isn't on the DVD, it might be in a free patch within weeks; it might be available by the time you get your DVD. Whether a feature is on the DVD is of interest to us as we plan our release, but I don't think it actually makes a huge difference to users with internet connections.

Consider 64-bit - it's something we want to look at during the version 10 run but we're not going dig into it until after we get 10.0 out. So will 10.0 be 64-bit? No. But there will probably be a 64-bit patch available for free. I think you can see why I don't want to post "X-Plane 10 will not be 64 bit."

I cannot possibly answer the second question, because versions run over several years, and what we code for the end of the version run will depend on market conditions and technology that don't exist now. One of the nice things about patching X-Plane frequently is that we can revise our plans as conditions change.

Consider the question "how many cores will X-Plane 8 utilize" had you asked the question during X-Plane 8.0. When X-Plane 8.0 came out, the answer was "only one" and we had no road-map to change that. For that matter, multi-core machines were rare and exotic beasts at the time, so multi-core wasn't a priority.

Within the three years of X-Plane 8's major version run, we ended up supporting multi-core for scenery mesh loading, something that couldn't have been easily predicted at the beginning of the version run.

Finally, a note on release planning: now is absolutely not a good time to ask for features. The features that will ship in X-Plane 10.0 have already been determined, and since we'd like to ship X-Plane 10 sooner rather than later, I don't think there's anything you can say that would make us add a feature to 10.0.

All future features are going into a 10.x "bucket" for planning purposes. Since Austin, Chris and I are up to our eyeballs in code and the art team is red-lined too, we're not spending any time sifting through 10.x buckets right now. If you send us a feature request, the very best case is that we dump it in a holding list for later; the worse case is that we lose track of the request in the chaos.

That doesn't mean that we don't care about 10.x. It's just that we are very much heads down in the 10.0 release now and won't look up until it's done.

Comment Moderation

2010-10-19T16:28:00.003-04:00

Just a quick note re: comments. Recently this blog has been attacked by spammers who copy existing legitimate comments and re-post then; their user name is a link to a click-harvesting web-site. I am doing my best to mark these comments as spam and not allow them.

Besides that, I am likely to nuke any comments that contain profanity, spam, repeated requests for tech support via the blog, and off-topic comments particularly on posts that have are meant for a narrow discussion (e.g. global scenery defects).

Draped Object Geometry in X-Plane 10

2010-10-18T09:53:00.004-04:00

I have mentioned a few of the scenery engine features coming in X-Plane 10 that will be of interest to authors: global illumination, conditional parts of OBJs (to cope with variable rendering settings). There is another general feature coming that will make authoring scenery a lot easier, I hope.

X-Plane 9's rendering engine has the ability to drape geometry. Draped geometry are meshes that are 'dropped' onto the terrain and hug the underlying base mesh perfectly. The most common example of this is the runways: because the runways 'drape' the ground, the runway shows any curvature and bumps from the underlying base mesh. This is who we create sloping and non-flat runways.

Authors can drape geometry as well, using a draped polygon (.pol) primitive in an overlay. Such draped geometry is useful any time you want to add more "paint" to the ground, e.g. to put down a taxiway, parking markings, dirt, grass, a driveway for a house, you name it.

There is one case in X-Plane 9 where you cannot drape geometry: in an object. In an object, all geometry is aligned to the object, and will only interact nicely with the ground if you get lucky. For example, if you model a house with a sidewalk, the sidewalk won't "sit" on the ground if the ground turns out to be sloped. You can use ATTR_poly_os to hide the artifacts, but ATTR_poly_os really can't cope with mismatches between the OBJ and the terrain under it.

X-Plane 10 will introduce a new object attribute: ATTR_draped. Draped geometry in an object is actually draped down onto the terrain when the object is placed in the scenery. This means that the draped part of the object will hug the ground perfectly with no interference or Z thrash. You get all of the quality of a draped polygon with the convenience of an OBJ.

There are a few possible uses for ATTR_draped:

Any time a 3-d model needs some ground details attached to it, e.g. the driveway near a house, draped geometry provides a good fit with the ground and good alignment with the object.
Any time you want to include a pre-made ground decal (E.g. a painted parking spot on a taxiway), the ground detail can be modeled as an object using draped geometry.

ATTR_draped will facilitate creating and sharing custom details for airports and streamline the authoring process.

Scenery Compatibility and Version 10

2010-10-16T07:34:00.004-04:00

This is my expectation for scenery compatibility in X-Plane 10:

Scenery based on DSFs, OBJs, and other version 8/9 file formats should work with X-Plane 10 unmodified.

This includes orthophoto scenery based on DSFs - we're not throwing that code out.

The new rendering engine features for version 10 (and there are a lot of them) are extensions - new ways to render things, new types of art assets.

I do believe that we may drop support for ENV scenery files in version 10. We've had DSF for six years now, and ENV's capabilities (a 500m mesh, very limited orthophoto resolution) aren't useful to today's users. You can use DSF2Text/XGrinder to extract custom object placements from an ENV for use in a new overlay.

We may also drop support for OBJ version 2. (Yes, we still load OBJs version 2.) OBJ version 2 is the OBJ file format from X-Plane 6, the one before OBJ 7. If you have any old OBJs (version 2 or 700) you can use XGrinder to automatically batch convert them to OBJ8.

Coping With Variable Rendering Options In X-Plane 10

2010-10-10T16:54:00.004-04:00

X-Plane 10 will have rendering options for global illumination and global shadows. This leaves one question: what if the user has these features disabled?

The plan for version 10 is this: the OBJ file format will have some extensions to allow conditional commands based on rendering settings. A few notes on these conditional commands:

They will only be based on rendering settings.
They will be evaluated once when the object is loaded. (If rendering settings change, the object will be reloaded.)

The idea is to be able to change which lit texture you use or remove a set of shadow polygons depending on rendering settings.

The conditionals are evaluated once at load time so that the object can be fully optimized based on the particular set of conditionals used. For example, if your drop shadow (with ATTR_poly_os) is fully removed at load time (because global shadows are on) your object now has fewer attributes, which is good for frame-rate.

This is very different from ANIM_hide. The hide animation may or may not hide depending on datarefs; to keep this fast, you cannot "hide" an attribute, only triangles. This means you "pay" for your atttributes no matter what.

The motivation for both designs is this: if the set of attributes in a file never changes (e.g. they are either conditionally removed at file load once, or they are always present regardless of animation) then we can optimize the attributes of an object once knowing how they relate to each other, to create the leanest, meanest OBJ.

No One Has All of X-Plane 10

2010-10-07T09:19:00.002-04:00

I commented on this before, but, like the Funniest Joke in the World, no one team member has all of X-Plane 10. We're all working away madly at our own parts, separately. This means that if one of us has code or art that isn't quite ready for prime-time, it hopefully doesn't slow anyone else down too much.

I mention this because I see a lot of commentary on the X-Plane 10 preview pictures where the comment is analyzing a part of the picture that actually isn't X-Plane 10 at all! Those pictures are coming right off of developer machines, and that developer probably has some new stuff and some old stuff. Not only does the developer probably not have everyone else's parts of X-Plane, but that developer probably has everything except his own work turned off or way down to keep sim load time down. I don't fly with 20 AI planes when I work on scenery, and Austin doesn't load full scenery at max res when he works on the flight model.

So when you look at the screenshots, just bear in mind that they are showing one new piece of technology pretty well, and pretty much everything else on screen is going to be hit or miss.

Orthophotos Are Not Going Away

2010-10-06T22:39:00.002-04:00

I mean to blog this a while ago, and Austin has moved on to new missives about the future of X-Plane, but:

A while ago Austin posted to the news list describing our approach to global scenery (that is, the scenery that ships with the sim), and he said some, well, rather disrespectful things toward orthophotos:

Orthophotos are garbage. I see this all the time. I am zooming along in an airplane looking that rooftops of WalMarts painted flat onto the ground. And the rooftops are blurry. And pixelated. And with a magenta or purple tint. And with big blurry shears right through the middle of them when they fall between offset satellite passes. It looks just terrible.

So first let me point out a few obvious things:

There was never any chance that the global scenery would be based on orthophotos - not in v8, not in v9, not in v10. Simply put, we can't ship you 900 DVDs in a dump-truck. Orthophotos of any reasonable quality are too large for covering the entire world in the base X-Plane product. This is not a change or new to v10.
X-Plane is very capable of handling third party orthophoto scenery. We invested a bunch of engineering in this in the v9 run, and that code is not going away in v10. X-Plane will page orthophotos on multiple cores so that you get smooth flight and crisp images. If you want to see some orthophoto that don't look blurry or pixelated, look here.
DSF-based scenery that works in X-Plane 9 will work in X-Plane 10, unmodified. We are not getting rid of any modern scenery file formats.

Beating Ourselves Up

Austin continues in his rant^H^H^H^Hdiscussion, with this:

Then, to make the 2-dimensional, blurry, pixellated, mis-colored, distorted roof of a WalMart painted on the ground look even worse, if you throw in some REAL roads or auto-generated buildings, they invariably fall ACROSS the roof of the WalMart painted on the ground, compounding the wretched orthophoto with an Escher-like rendering-error. This looks terrible, and is not even plausible.

This is a critique of the version 8 and 9 global scenery. In fact, it is an observation of the fundamental problem with the urban global scenery: we never found a way to synchronize the real-world-driven and real-world derived 3-d scenery (real roads with plausible buildings and forests in between) with the photo-based land-class textures running underneath.

Ironically, this is not a problem with orthophotos (that is, specific photos placed in the world where they belong) per se. It's really a problem with how to combine 3-d with land class textures. I don't believe anyone has solved this problem yet for global scenery; if you look at FSX, there isn't a lot of real world vector data to interfere with the land classes and their autogen.

In fact, orthophotos can look very good when they are combined with 3-d in a correlated way. For example, take a look at this screenshot of FlyTampa's KBUF . They are using an orthophoto but they are putting matching 3-d on top of it, which makes things look good close up.

The Global Scenery Problem

I'll leave you with this thought: the problem for the version 10 global scenery is to combine:

the plausibility that you get from having synchronized 3-d and ground textures.
the detail we've come to expect in photo-based scenery textures.
the realism you get from using real vector data for the real world.

The current global scenery manages points 2 and 3 but fails pretty badly on point 1. That is what we are trying to address in X-Plane 10.

Do You Ever Feel Like the Planet Is Falling Apart?

2010-10-03T18:53:00.002-04:00

Put this in the "sometimes bugs make pretty pictures" category...

Tuning the Rasterizer

2010-10-03T08:48:00.002-04:00

I'm not sure anyone cares about this kind of thing, but...

These are pictures of a test of the rasterizer. The rasterizer is code in both the DSF creator* and X-Plane that converts polygons into lines or boxes. What good is that? We use it to:

Plant trees inside a polygonal forest in a DSF.
Process all of the elevation points inside a polygonal water body when making a DSF.

Etc., etc. These were from a performance test rasterizing the Mississippi delta at 1201 x 1201; because the vector data is insanely detailed (something like 2 million line segments I think) it's a good test of performance. The blue lines represent a line fit, but the white lines are a "box fit" - that is, they ensure that not only are they "inside" the water, but the area above and below them are too.

* Programming geeks can use this code - it's in PolyRasterUtils.

A Global Scenery Squawk List

2010-10-02T11:09:00.003-04:00

This post is a bit of an experiment...we'll see how it goes. When we cut the global scenery, we do a number of validations: we manually inspect some of the DSF tiles, we examine the Earth orbit textures (which are derived from the DSFs) as a quick way to look roughly at all of the tiles, we have a number of internal consistency checks in the generator, and we can compare our output to some of the input data (e.g. did we lose all of our water) to look for gross bugs. But we don't have enough resources to manually examine all 18,000+ tiles in detail inside X-Plane.

So: if you have found a defect in a global scenery tile in version 9, please list the tile in the comments section of this post. I will try to give these "previously broken" tiles priority in manual inspection.

Note that the bugs we can expect in version 10 will be very different than in version 9 because we've really changed the global scenery generation process in nearly every important way. The underlying algorithms are heavily rewritten and data sources are very different. The goal here is to simply find areas that might have a higher probability of weirdness.

Let me try to be clear about what constitutes a broken tile and what does not. Please read this definition six or seven times before you post a comment.

Do not report bugs of inaccurate data. If your favorite road is missing, or the coastline is in the wrong place, don't report that here. That is not a defect in the rendering process; rather it is a limitation in the source data. I am not trying to collect a list of data inadequacies. We have already selected the new data for the new render. "Stuff is in the wrong place" is not a bug for this list!
Really weird patterns are of interest. For example: I have seen some reports of very long thin bars of land going perfectly north along the edge of the tile, or a comb of mountain and valley, again perfectly vertical. These are bugs in the production process and I do want to know about them!
Do not report errors in the placement of the 3-d layers (trees, roads, etc.). Since the 3-d layer is being completely rebuilt for version 10, none of these defects will be present in version 10. (They'll be replaced with a totally new set of weird behaviors!)
If an airport is too bumpy to use (with "flatten " turned off in the sim), report this only if the terrain around the airport is grass. Basically the grass means that we tried to "fix" the airport in the v9 render and failed. If there is no grass (the airport is over forest or city) and it is bumpy, do not report it - that means it was added to apt.dat later.
Do not report mismatches between the airport shape and the grassy patch; this is just the apt.dat file being updated.

If you have something to report (basically incorrect flattening of grassy airport areas and really weird coastline/terrain bugs that are clearly programming errors) please include three pieces of information:

The DSF tile, e.g. +42-072
The nearest ICAO of an airport near the bug (e.g. KBED)
A very short description of what went wrong (e.g. "tall thin vertical lakes running through the entire DSF").

Please only post defects of the above nature in the comments section of this blog post; to keep things clean I am going to nuke any off-topic comments on this post.

EDIT: see the first Squawk, Arista's report on LOWS. This is a perfect report: it includes the DSF tile, the ICAOs, a brief but clear description, and it is a bug in how we process the data, not the data itself.

Airport Layouts: Your Cutoff is 10/10/10

2010-09-30T14:57:00.003-04:00

If you are planning on submitting an airport layout to Robin so that it is used to flatten terrain in the X-Plane 10 global scenery, please submit the layout to Robin no later than October 10th, 2010 (that is, 10/10/10).

If you have an incomplete but useful layout (e.g. the airport border is in place but not the taxiway signs, you can still submit it; we only consider border outlines and the pavement itself when flattening, not markings.

You do need both the border outline and all existing pavement. The reason for this is that the airport border is used to change the land class to grass, but water is only converted to land (if we have a coastline error) base on real pavement.

More info on airport layouts and how to submit data to Robin can be found here.

WED Roadmap

2010-09-30T13:11:00.002-04:00

I posted a quick tip on how to create fence-like facades in WED. Basically WED doesn't handle fences and other non-closed polygons very well, but you can work-around this. A future version will address this more completely.

This is my thinking on the WED roadmap:

WED 1.1 will relatively ship soon, without cosmetic and usability improvements. At this point the basic bugs (import/export) are fixed, so best to get out a finished, stable build so that people can at least edit overlays.
A future version will provide editing ATC layout information for X-Plane 10. This shouldn't be too hard to get working, as we already have this in WED now so that we can develop test data for the new ATC system.
A future version will provide usability enhancements (e.g. previews of facades, etc.). I don't have a ton of code done for this yet, but it's important for everyone using WED for pretty much any purpose.
A future version will provide road editing since X-Plane 10 can drape roads.

I don't know what order those 3 feature will come in, but they will all happen relatively soon after version 10 ships I think.

A Better WED Beta (and friends)

2010-09-23T23:33:00.005-04:00

On my way back from South Carolina a few weeks ago I had some time in the airport to fix the WorldEditor 1.1 export bugs. All of the reports pointed to a single cluster of bugs that are hopefully now fixed in beta 2, and today I finally had time to get the betas posted.

I also cut a new build of MeshTool (2.0RC2) while I was doing builds; this fixes a bug when using orthophotos with varying physics.

So first: you can get the new WED 1.1 beta 2 and MeshTool 2.0 RC 2 on the tools page on the wiki.

The wiki? Yeah. Tyler has been helping me migrate the scenery tools to here. At this point I believe that all of the content on scenery.x-plane.com is now duplicated on the wiki (which also has additional articles).

WED Bugs

If you should find additional WED bugs, after you get over your initial surprise, please file bugs in the scenery tools bugbase. Please do not email me bug reports. WED has to take second priority to version 10 work, so I don't have time to process bug reports now, and I will lose them. The bug base keeps your bug safe, keeps a record of what happened to it, and can take attachments.

Please do provide the minimal materials to reproduce the bug; simple packages with an earth.wed file are great. Thanks to all of the WED users who filed bugs with repro cases - this made it very easy to retest the export code.

My Polygon is Poly-Gone

It is illegal to have DSF polygons (or airport polygons) cross themselves; finally with beta 2, WED actually makes this case fairly easy to detect.

If a polygon cannot be exported (because it is self-intersecting), an error message will indicate that some polygons were skipped, and those polygons are selected.
If you pick "Error-Check Polygons" from the Edit menu, then for every polygon that has a self-intersection, an OBJ is added at the precise point of the self-intersection. Simply select and zoom in on those OBJs - they act as marker pins to show the problem. Delete the OBJs once you have untangled your polygon.

(I did experiment with error checking on the fly, e.g. simply showing red dots in the intersection points as you drag and resize the polygon, but the math is too slow. I am using CGAL to check bezier polygon intersections, and their algorithm is absolutely rock solid, but it can take up to a quarter of a second to recheck the polygon, which is too slow for interactive editing.)

UPDATE: beta 2 hangs when processing beziers. What is very odd is that this happens on the clean release code but not the working copy of WED I fixed the bugs in. Hence, when I checked all of the bug reports, they all passed. I have reopened all bezier-related bugs. I have not yet located the build environment differences causing the problem.

UPDATE 2: the hang on bezier processing was due to a bad compile configuration for a library WED uses, and was Mac specific. Having fixed this, I have recompiled and reposted WED beta 2 for Mac. If you already grabbed WED, re-download it, and make sure you get the version dated September 24th. You can tell you have the right one because the "compiled on" date in the about box will say "Sep 24 2010 19:34:09".

Performance Tuning and Future Proofing

2010-09-23T17:46:00.000-04:00

I wrote up some performance tuning notes for OBJs on the wiki. A few notes on how these rules will change with version 10:

Everything on that note applies to version 10 too. If you've tuned your model for version 9, that effort will be worth it in version 10.
A few rules are even more important in version 10 than before. In particular, I've done a lot of performance tuning for OBJ drawing, but you don't get those wins if you use ATTRibutes. Clean your objects out for maximum speed.
One special case: objects with very small vertex count are sometimes extra fast in version 10. For example, in version 9, a tree with 8 vertices and no attributes is horribly slow. In version 10, this tree will be quite fast. So in version 9 you might make the tree have 64 vertices and look nicer; in version 10 by keeping the tree lean and mean, you get a speed improvement.

Use Every Pixel of Your Normal Maps

2010-09-23T13:22:00.003-04:00

Normal maps are expensive. A 2048 x 2048 normal map takes 22 MB of VRAM! So make sure you get every bit of image quality you can out of it. Two things to consider:

Normal maps are uncompressed (because texture compression really screws up the normal map). So per-pixel detail will be preserved. Use it!
VRAM is allocated for an alpha channel whether you use one or not. This is because the cards need 32-bit pixels for performance. So include an alpha channel in your normal maps and use it to modulate shininess; this can help create the illusion of different materials.

For scenery objects, do not include an alpha channel if you don't need it. When textures are compressed, the alpha channel does take more VRAM, and X-Plane will hit a faster rendering path for textures with no alpha channel.

Revisiting Texture Compression

2010-09-21T14:35:00.002-04:00

For quite a while now, I have been advocating in favor of DDS compression. I am pretty damned obstinate, but eventually if enough people yell at me, I get a clue. I have come to appreciate that there are some cases where DDS compression is not a net win; this blog post explains when it happens and what we might do in X-Plane 10 to work around this.

DDS - The Good, The Bad, the Ugly

DDS is a file format that contains image data pre-mipmapped (that is, the smaller versions of the image that the video driver needs are included) in a format that may or may not be compressed. DDS is virtually always used with a compressed image format (like DXT1 or DXT5). This has three positive effects for X-Plane:

Because the image is already compressed, we save CPU time when loading the texture that would be spent compressing while X-Plane is running.
Because small versions of the image (the "mipmap pyramid") is already in the file, we save time down-sizing the image with the CPU, another win for load time.
Because the image is compressed ahead of time, it can be compressed with a slow high quality compressor rather than a fast low quality compressor, so relative to other compressed images we get an image quality improvement.

The bad is that the DDS file does not contain the original uncompressed file. If the user unchecks "compress textures to save VRAM", DDS files remain compressed. If the image file contains details that don't compress well, they're going to get splatted and stay splatted.

What If VRAM Grew On Trees?

My original heavy arguments for DDS were based on the idea that VRAM is a limited commodity; if we don't compress textures, the user runs out of VRAM faster and has to go down a level of resolution...and once that happens, everything starts to look ugly.

But what if the user has 1 GB of VRAM? At this point, we've limited the maximum quality the user can see because we don't have the original uncompressed image anymore, only the DDS/DXT version. This can be frustrating to authors who spent a lot of time on their textures.

If you ship PNGs with your airplane or scenery, turning off texture compression will reveal this beautiful, uncompressed image, but now when texture compression is on, the compression will be done by the video driver, and that will look extra ugly.

The Best Of Both Worlds

This is my thinking for version 10. (These are just musings, we haven't coded this yet.) Currently DDS are preferred to PNG files. We could relax the load rules in version 10 to prefer PNG over DDS when texture compression is off and DDS over PNG when it is on. This would allow authors to ship both PNGs and DDS files and have the right one be picked for the scenario: the pre-compressed one when texture compression is on and the uncompressed one when compression is off.

Feature Requests for X-Plane 10

2010-09-20T09:04:00.004-04:00

Yesterday I got a bit cheeky regarding feature requests for X-Plane 10. Here are a few slightly more serious thoughts regarding the feature request process.

The major features that we are putting into X-Plane 10 were decided, for the most part, a long time ago. Those who we met in France two years ago won't be surprised by the major items on the list: weather, ATC, airports, and new scenery, new shaders. For that kind of major feature work, we have to start an initiative very early on. Heck - global sun shadows (which I believe we will ship in v10, God willing) were in the works before version 9.0 shipped - it took that long to get an implementation that was useful! (In fact, the v9.0 version was not released because the quality was bad, which is why I am always nervous about announcing features in advance; it ain't over until it's over.)

So while it's exciting to see so many people discussing X-Plane 10, realistically if a feature is a "big" feature and we haven't started it now, it's not going into 10.0. That train left the station over a year ago.

There have also been two complicating factors that have cropped up during the X-Plane 9 run:

Microsoft closed ACES, which definitely changes what we want our next major release to look like.
The iPhone came along - until the first iPhone release, we had no idea that it would be such a big product.

While we have to plan our big features in advance, the market we are going to ship into changes during development.

So bear with us - a lot of what I see are good ideas that we will get to soon, even if they don't go in the initial roll-out.

Feature Requests for Reality

2010-09-19T16:56:00.005-04:00

With X-Plane 10 on the way, it seems that the various X-Plane forums are just filled with users listing off their favorite feature requests. If there is one uniting theme for these requests, it is this: they are pretty much all requests for X-Plane to more accurately model some neglected aspect of reality.

I would like this relationship to be two-way, with give-and-take. It doesn't seem fair that in every case, we should have to change X-Plane to model reality. So I humbly submit to the X-Plane user community: my requests for changes to reality to ease X-Plane development.

No Wind Near Water

My first request is a simple one: can we simply not have any more wind over the ocean? Ocean waves are hard to model. They are non-sinusoidal, they don't repeat, they're refractive, and they go for miles. If we could simply eliminate the wind, then we could model the ocean as a nice calm glassy lake, which would be quite a bit simpler to get right.

Only One Building

My second request is a modest one: from now on, I would like everyone to live in the same type of uniform house. It can be a nice house (several stories, with a pool in the house), but everyone's house should be the same. We have some new instancing technology for version 10; it reaches peak efficiency when a single building is repeated ad infinitum. So if you could all agree on a single house type, it would be good for everyone framerate wise.

(I realize that some of you in subdivisions in the US that already do this; hopefully the rest of the world can take a hint.)

No More Intersecting Roads

Alex and I have spent just a crazy amount of time trying to cope with what to do when two roads intersect. So my third request is: no more intersecting roads. I would like all roads to cross each other by some kind of overpass. This will eliminate a lot of artifacts.

In fact, for extra credit, if all roads could be aligned to be precisely north-south or east-west in a grid, that would be good for RAM use.

No Variation in Climate

This one isn't so important for me, but I think the art team might appreciate it. It turns out that different parts of the world have different temperature variations and rainfall, and that in turns makes the local color of grass, trees, etc. a bit different. This just makes work for our artists - they have to draw everything several times for the different climates. It would help us out a lot if you could all live in places with the same annual rainfall and temperature variation.

(Just in case this climate thing turns out to be true, I suggest everyone settle on the "hot dry" climate pattern - we have pretty good textures for that.)

Pave the Bay

Finally, when in doubt, use asphalt. We have some new shaders in version 10 that will make asphalt look pretty good.

Anyway, this is my list - I am sure the other X-Plane developers will have other requests. (I suspect Austin's life would be made easier if weather was always CAVOK, and Chris's life would be greatly simplified if there weren't any other airplanes in the sky.)

Do you have any hints as to when this new version of reality might be released, or what its minimum system requirements are?

More Airplanes

2010-09-16T09:21:00.003-04:00

Quick airplane links:

Carenado's Mooney M20 J is out, available on the X-Plane.org store.
Javier's T34c Mentor is out, available at X-Aviation.com.

Pictures available in both links.

Multicore and Version 10

2010-08-31T15:52:00.002-04:00

Over the last two years, we've been working on the X-Plane rendering engine, setting up the code to take advantage of multiple cores when possible. Most of these changes are in X-Plane 9 already: multi-core creation of 3-d scenery, multi-core loading of scenery, multi-core loading of textures.

X-Plane 10 will leverage this work, pushing even more work to multiple cores. And yet, nine women cannot have a baby in one month. The ultimate limit on framerate will be based on the performance of one core pushing data to your graphics card.

So how many cores do you need, and is it better to have a few fast cores or more slow cores?

I can't give you a firm answer, because I don't know how important money is to you, I don't know which rendering settings you care most about, and X-Plane 10 isn't finalized. (And even if it was, we often improve performance in patches.) But I can suggest our attitude to how cores are used.

A Graphic Analogy

With graphics cards, the companies target different markets. The "enthusiast" market is the top end, where money is no object and maximum performance is the goal. Below that you have "performance" cards (a good value for the money but not as fast) and "mainstream" (which by video game standards means "slower than snot" - main stream users don't need fast 3-d graphics to check email).

When it comes to rendering features, we expect X-Plane to be efficient enough to meet the performance expectations of a given slice of the market. In other words, if you have bought a top-level graphics card, we need to be efficient enough to let you run at 8x FSAA on a huge screen with per pixel lighting - that's what is expected of the enthusiast crowd and that's what the cards are built for.

But if you have a mainstream card and get 5 fps with per pixel lighting, well, too bad. You've got a cheap, low powered card, you need to dial down the sim. Here our goal is only to give you a way to run X-Plane at all. (And frankly, if X-Plane could run at 60 fps on a mainstream card, it means the max rendering settings don't take advantage of top end hardware!)

Core Considerations

At this point we expect pretty much any modern computer to have at least two cores, and users with single core machines are going to have to make serious graphic quality sacrifices to run X-Plane. (This is already true for version 9.)

When it comes to version 10, I think we will categorize "a lot of cores" (e.g. 4, 6, or more) as enthusiast - some of the top level rendering options may not function well with less than four cores, but dual core machines should at least run decently with some rendering options enabled.

How far we go toward utilizing really high core count (Austin upgraded to the new Mac Pro and now has 8 hyper-threaded i7s) I don't yet know. My guess is that we will get at least some measurable benefit from up to 8 cores.

Trading off clock speed for core count is a difficult choice. Obviously if you had a choice of one core that was twice as fast as a 2-core CPU, you'd take the speed - you're getting the same total computing power but the clock speed can help frame-rate. But the trade-off is almost never formulated like this, and it's too soon to have hard data from the sim itself.

For what it's worth, the latest generation of CPUs is really fast, so it is unlikely that you'd upgrade to a new CPU and not get some serious benefit, whether it comes in cores or clock-speed. The users I have heard from with new iMacs seem quite happy with their machines.

How Specific Should a Bug Report Be?

2010-08-30T10:41:00.004-04:00

I got this bug report from Austin this morning (found in the in-development version 10 code):
yter bug

0: go to kcae with no scenery installed at all
1: open the 777
2: go to aircraft:aircraft and situations
3: go to second tab
4: set total num acf to 1
5: go to first tab
6: select 'carrier catshot'
7: release the brakes, with throttle at idle
8: enjoy the cat.. ease the plane gently onto the water, gear down, pwer off
9: note that the water is 'hard'... the yter is telling us that we are on land not water. hit brakes. stop. u r walking on water!

The first thing to note is how specific and small each step is. These steps are much more precise than most of the bug reports we get. And yet, they must be that specific - the bug was so tweaky that skipping virtually any of those steps will cause it to not appear.

The biggest problem I see with bug reports sent to me is the use of "any", e.g. "open any aircraft". That's not very specific! And Murphy's law says: the one airplane I pick will just happen to be the one airplane that you haven't tried and happens to not show the bug for some strange reason.

So always be absolutely specific. When we ask for tiny steps, it's not that we don't know how to use the sim - it's just that we need to use the sim exactly the same way you did!

EDIT: bug report pages.

For X-Plane.
For the scenery tools.
For the plugin SDK.

Be sure you understand which bug base you should be using (E.g. are you reporting a bug against the plugin SDK, the sim itself, or a scenery tool like WorldEditor.) If you don't know what program you are filing a bug against, you probably shouldn't file a bug at all - just contact tech support.

WED Export Bugs

2010-08-27T16:05:00.004-04:00

There's a real difference between a useless beta (e.g. what we have with WED now) and a useful one. While the purpose of a beta program is to fix bugs, a beta can be useful if the features users must have work. I don't think I will have time to finalize WED 2.0 this year, but I do think I will be able to fix the really nasty bugs, the ones that make it useless.

To that end I have fixed a number of crash-on-export bugs. To the users who filed complete crash-on-export bug reports: thank you! It was quite an education to see what was in some of these projects polygon-structure-wise.

If you filed a WED export bug, I may have requested feedback if you didn't include the WED file. Basically I would like the minimal materials to fully reproduce the bug by opening the package and picking "Export to DSF". For many packs this is just the Earth.wed file, although sometimes textures or text files may be necessary.

A number of the crash bugs are caused by degenerate polygons. For example, if your polygon crosses itself in an X shape, not only is this illegal in X-Plane, but it also drives the exporter crazy. With the next beta, WED will select polygons that failed to export to help you locate such problems.

Does Sponge Bob Square Pants Need Wake Turbulence Separation

2010-08-26T16:23:00.002-04:00

I am down in South Carolina with Austin and Chris, working on integration issues with the new ATC system for X-Plane 10. One issue Chris is working on now: how do you fit the wide open design options of Plane-Maker into the narrow FAA categories for aircraft. If someone builds a rocket powered lighter-than-air piano with a tilt-rotor and a lift fan, how many miles of separation does that aircraft need from the 747 in front of it? What SRS category is Sponge-Bob Square-Pants, or a Steinway piano, or Snoopy's dog house? (And don't even get me started on some of the weird creations Propsman has sent me!)

Our current solution is to analyze the structure of the plane and use the most conservative criteria available. If your aircraft weighs a lot, it's a heavy, no matter how you built it. If it has jet engines, it's a jet, etc. This way airplanes modeled after real life will get correct categorization, and custom designs will at least receive some kind of vaguely sane handling.

GA Aircraft Abound

2010-08-23T10:44:00.000-04:00

X-Aviation has released the Duchess, pics here.

Carenado is coming to X-Plane, initial pics here.

X-Plane 10 and Global Illumination

2010-08-21T08:19:00.000-04:00

Thanks to my foolish use of unprotected directories, we have basically announced that X-Plane 10 will feature global illumination. Here is some basic information on global illumination.

What Is Global Illumination?

Global illumination is the ability of any part of an airplane or scenery system to cast light on any other part of the scenery system or airplane. In X-Plane 9, the only lights in the sim that ever actually cast cast light anywhere else are:

The sun.
The airplane's landing light. (Even if your plane has many landing light billboards, there is only one spill effect.)
Three 3-d lights in the 3-d cockpit.

This list was kept short due to the high cost per pixel of each light on all rendering.

When X-Plane 10's global illumination is enabled, a "spill" light attached to any OBJ can shine light on anything near it. Since any OBJ can have a spill light, this means we can have light sources on airplanes, scenery, cars, whatever you want. The spill effects any 3-d scenery nearby, even from another scenery pack.

This kind of still effect can be simulated in X-Plane 9 by careful use of LIT textures. However, real global illumination works between art assets created by separate authors. You can drive your custom airplane up to a custom airport and the landing and logo lights on the airplane will cast light on the terminal; the apron lights from the terminal will cast light on the airplane.

Furthermore, global illumination is fully dynamic - as objects animate or move, the lighting effects are correctly applied in 3-d. This makes effects possible that cannot easily be created using LIT textures.

Requirements for Global Illumination

Like most new rendering tricks in version 10, global illumination will be a rendering option that can be optionally enabled by users who have a video card meeting hardware requirements. In the case of global illumination, that requirement is a DirectX-10 generation video card, e.g. any Radeon HD , nVidia GeForce 8000 or 9000 series, and "100" series (100,200,300,400 series).

For authors: global illumination is applied using named and parametrized lights on your OBJ. Anywhere you can attach a light billboard, you can attach a spill effect as well, with some tuning constants for how wide you want the light, etc.

It will be possible to create two versions of your LIT textures, one to be used when global illumination is enabled, and one when it is disabled. Thus if you are baking lighting into your textures with a 3-d modeling program, you can simply re-bake the lit texture with some lights disabled and add 3-d lights to your model. The result is an airplane with real 3-d lighting where possible, and a close approximation via baking otherwise.

Global illumination can be added to a model incrementally; existing art content will work normally with global illumination enabled or disabled, so authors can choose to add a few light spill effects or add a large number, as time permits.

The Cost of Global Illumination

Global illumination isn't going to be free. The main cost is an increase in VRAM use and fill-rate. The cost of global illumination is mostly a one-time cost to put X-Plane into a new rendering mode. (Graphics nerds: global illumination is implemented via deferred rendering.) The incremental cost of lights isn't that high, although a scene with a lot of lights will have impact.

My expectation is that users with new, highly capable high-end graphics cards will be able to run global illumination easily, but will lose some of the other benefits of fill rate. (For example, running at 2560 x 1024 + 4x FSAA is a lot more painful with global illumination than without.)

Global illumination also introduces two artifacts, both of which I am trying to minimize as best as I can. These artifacts are a function of deferred rendering - all games that use deferred rendering have to address these problems:

The lighting calculations are shared between multiple translucent surfaces, which can create some strange effects. For example, if a translucent window is in shadow, the scenery behind the window will appear to be in shadow too.
Traditional full-screen anti-aliasing is not available with deferred rendering. We should be able to offer a simulation of 4x FSAA as well as some kind of cheaper FSAA-approximation, but the cost will be quite a bit higher in fill rate than the 16x-style CSAA available now.

(Hardware-based FSAA can make a number of optimizations like CSAA to optimize throughput; this is how such high multiples as 16x are possible. Since our implementation is similar to "super sampling" and costs a real 4x in performance, 4x will be the highest setting.)

Why Global Illumination

Of the new X-Plane 10 rendering engine features (and there are a fair number of them), global illumination is certainly the one that has the most impact on the structure of the rendering engine. With global illumination, X-Plane effectively has two separate modes ("forward" rendering, which is the only mode X-Plane 9 has, and "deferred" rendering, which produces global illumination).

One of the reasons to get global illumination done earlier than other features was that implementing global illumination required rewriting or modifying nearly every piece of low level rendering code. Now that the work is in place, we can safely add new features and test them in both modes.

Global illumination also meets two requirements:

Sergio has long observed the central importance of lighting and shadows in the look of X-Plane; at some point more polygons and better textures still look synthetic without a realistic illumination model. Global illumination makes a more realistic lighting model possible at night. Airports represent an environment that can hopefully take advantage of such capabilities in a big way.
As hardware becomes more powerful, authors have to do more work to create content that takes full advantage of the rendering engine. We are reaching a point where artist's time is going to be a limiting factor as well as hardware and engine capabilities. Global illumination thus kills two birds with one stone: it makes the rendering engine's output look better, but it also makes the whole scene look better with less work by the artist.
(For example, when baking lighting into a model, the author must plan the model's texture UV map to guarantee unique texture space for all spill effects. When lighting effects are dynamic, the author can simply texture so the model looks good without worrying about baking requirements.)

X-Plane 10: What Has Been Posted So Far

2010-08-20T07:41:00.003-04:00

There have been a few posts about X-Plane 10 in a few random places; here is a summary of all of the version 10 material that's been previewed so far, and some notes on what is actually being shown.

First we had Paul's Oshkosh 2010 video:

I think this has been made clear already, but:

The base simulator shown here is not X-Plane 10, it is X-Plane 9.
Many of the airplanes shown here will be released for X-Plane 10.
This is not showing the new X-Plane weather system or global lighting.
Some of the content shown here are third party add-ons, available today for X-Plane 9.

The main purpose of this video was to show X-Plane off at Oshkosh; at the time we didn't have X-Plane 10 in a state where we could do an exclusive version 10 preview.

Then I accidentally leaked two test videos of global illumination. This was strictly accidental: I was looking for a cheap way to post a large video for Austin and Propsman late at night and didn't think anyone would sift through 191 zip files to find two obscurely named videos. I was wrong, and someone found them on the org. I appreciate that participants in the ensuing discussion withheld judgment; these were early test videos and don't represent the final feature in any useful way. They do, however show off some of what global lighting will mean.

This is the Cirrus Jet with landing lights implemented via global illumination. We get two distinct landing lights that cast specular hilights on the fuselage. As the door animates, it opens "into the light".
This is the Avanti Piaggio with strobes and beacons implemented via global illumination. The strobes cast light both on the fuselage and on the runway below the plane.

This second movie is typical of the kinds of tests I do: the beacon lighting is just awful - a gross huge red light splatted on the plane for test purposes. When I get the rendering engine code working I usually hand the feature off to Propsman or Sergio to tune the textures and art constants. In this case, the videos are pre-tuning.

Austin has posted three screen-shots of X-Plane 10-related content:

This is Javier's new shuttle, which I believe will ship in version 10. I believe this shot may have been taken in X-Plane 9. So this is not the new weather system.
Some of these screenshots and Paul's video were shot in X-Plane 9. By the time the new airplanes are finished, they will not be usable in version 9 - they will be version 10 only.
Propsman has done work on the lighting system. It can be subtle to see what's going on here because the old runway lights looked pretty good too, but most of these billboard lights are actually rebuilt.
This night shot shows global illumination in the scenery system. The glow on the highway pavement is not rendered; it comes from the 3-d lamps along the side of the road. Similarly, the car headlights spill light on the pavement and each other as they drive. (Note how the highway lines are visible in the headlight spill even when there is no streetlight.)
One difficult problem with rendering a lit highway at night is that the lighting from street lamps on a highway tend to spill light on the surrounding terrain, an effect that is impossible to create with a LIT texture. If you look at the right side of the main highway at the bottom of the picture, you'll see that the street light is casting light on the grass to the right of the highway too.

I think that that's all we have posted. At least, it's all I am aware of. I will go into some of the details of global illumination in another post.

Removing Add-Ons is a Diagnostic Step

2010-08-19T10:30:00.002-04:00

When we get bug reports or tech support requests, the first thing we usually recommend is: remove third party add-ons (plugins, scenery, airplanes).

This is not intended as a cure, only a diagnostic! The goal of removing add-ons is to identify whether a problem occurs due to an interaction with a particular third party add-on or within the base simulator package.

If an add-on induces the problem, we can then look at whether the add-on had problems on old versions of X-Plane. (If not, we can look at how we broke third party compatibility, and fix it.) If the add-on has always had problems, we can look at the content or contact the author.

If the problem is in the base simulator, we can compare results from a number of different users; the base simulator gets used a lot, particularly in demo downloads, so defects that aren't reported frequently are typically due to configuration issues like new drivers.

So if tech support asks you to remove add-ons, don't despair - it's just a diagnostic step, not a cure.

Sometimes You Can't Change Aircraft-Based Datarefs

2010-08-18T17:33:00.003-04:00

A month ago the blog was quiet because there was a lot I couldn't talk about; now it's quiet because I am up to my eyeballs in X-Plane 10. I'll try to get out a few posts I've been meaning to write, but it's definitely crunch time.

I have received a number of emails from plugin developers who wanted to know if they could modify some of the sim/aircraft datarefs, or why modifying them had no effect/an unintended effect.

The short answer is this: in some cases X-Plane will pre-process and cache data that comes from the .acf file. In this case, a sim/aircraft dataref (most of these come from the .acf file) can be read, but writing it will have no effect because the sim has already had its one look at the dataref.

This is a design limitation; it was never the intention of the SDK to allow complete Plane-Maker-level editing of the aircraft on the fly in the sim.

An Older Build for Regression Testing

2010-08-05T15:24:00.002-04:00

I'm never thrilled about posting bug-swatting info on this blog; the blog is (among other things) a temporal snapshot of what's going on in X-Plane, as well as an archive; it's my hope that we'll get this problem sorted out soon, at which point this blog post will do nothing but confuse. But I digress.

There have been a number of reports from users of the sim hanging on startup with this configuration:

A 64-bit Windows (usually Vista or 7).
A modern ATI card running Catalyst 10-6 or 10-7 drivers.
X-Plane 9.62rc2.
Usually a core i7 type system.

However, I haven't been able to reproduce this, and neither has ATI.

I don't know what the problem is, but a number of variables have changed in this equation that need to be isolated: new sim, new video drivers, newer operating systems.

So if you have this configuration and can't run the sim, despite removing all third party add-ons, please download this time demo. If you can run the 945 time demo but cannot run 962, please let me know by email, and we'll isolate a defect in the sim. I have heard from some users that they can run 940, but no confirmation that 945 runs.

Procedural Or Algorithmic

2010-08-02T17:08:00.003-04:00

A quick thought on procedural vs. algorithmic scenery: there was some discussion on the X-Plane dev list about procedural terrain; the Outerra screen shots have stirred up interest.

There is a fundamental difference between what you see with Outerra and what we do with our global scenery:

Typically procedural scenery is based on the idea of 'amplifying data' - that is, making a little bit of data look more interesting by applying a recursive algorithm to "generate" detail.
Algorithmic scenery involves taking a large amount of unique input data and translating it; the detail comes from not losing information in the source data.

The key difference is whether the resulting scenery comes from a process that "creates" information through a 'procedure' or "translates" information.

Our scenery process does a bit of both, but we are more in the algorithmic camp than procedural camp; the global scenery is produced from hundreds of GB of input data, and we are constantly looking for better input data to create more interesting and accurate output scenery.

In fact, I would say that we are becoming more algorithmic and less procedural. In version 9, the urban roads in non-US cities are "procedural" - an algorithm generates them from the terrain data, an algorithm, and some random noise. For version 10, we are importing OSM.

One thing I have noticed in the work on version 10 global scenery is that we've finally crossed a line. With version 9, the question was 'what is the best data we can get'. With version 9, the question is 'how much information can we keep'; we've reached a point where the resolution of our input data is so much higher than what can go on DVD, that it's a question of filtering down, not synthesizing up the resolution.

Facade Tuning and Tips

2010-07-28T09:48:00.002-04:00

I have updated some of the facade documentation on the wiki with new performance tips for using facades.

A few quick notes:

Your facades must be counter-clockwise (when viewed from above). Do not repeat the first point; X-Plane will "close" your building for you. (A four sided building should have four points, not five.)
If you turn off two-sided facade drawing and your walls look wrong (and your roof disappears) your facade is wound in the wrong direction.

The performance tips go into a fair amount of detail about saving memory. Most of X-Plane's rendering fall into two categories:

Shared meshes (objects), where the geometry of the object is saved once and used lots of times. Objects usually hurt frame-rate by consuming CPU time, because for each drawing of the object, we have to do some setup to draw that shared geometry in a different location. (Version ten should feature some major improvements in object efficiency.)
Non-shared meshes (everything else), where every single "instance" of a tree, facade, forest, etc. is uniquely constructed in memory. Non-shared messages are very fast (because we can submit a huge pile of non-shared messages to the video card in one shot) but they consume a lot of memory (because we pay for RAM per building/tree, not just once). Typically non-shared meshes are limited by virtual address space, not by framerate.

Facades are non-shared meshes, so the performance tips focus on how to limit the amount of RAM needed to represent your facade.

Let Your Eyes Adjust

2010-07-24T13:45:00.000-04:00

This is a feature I looked at putting into X-Plane 9, but it turned out that it affects so many different parts of the sim (and has to be done all-or-nothing) that it got kicked to v10. Consider these two pictures of the default B777 (the lighting was not adjusted, only the time of day):

The night image looks pretty, but what's wrong with the day image? The answer is: the small panel post lights in the night image are still casting a fair amount of light in the day image. And the result looks silly. But why?

The answer is: in real life your pupils would contract in the sun, letting in less light. The sun is really rather bright, so the daytime panel would still look normal, but the apparent power of those posts lights would be a lot less, because your eyes are less sensitive. In other words, the relative strength of the sun and post lights is wrong in the second image.

Computer monitors don't have a huge dynamic range for how much brightness they can put out. So we can't hope to display the absolute brightness of the scene correctly. Instead we need to make everything brighter at night (to simulate your night vision) and dimmer during the day, like this:

In this set of images, the night image is matched precisely to the previous one, but as the sun comes out, the apparent brightness of all lit textures has been scaled down to simulate the effect of your eye becoming less sensitive due to the flood of sunlight.

What's good about the compensated image is that the weird artifacts from the post lights are gone; the relative strength of the post lights is really low in relative terms.

What happened to the EFIS and moving map? The answer is that they too are not as apparently bright relative to the sun as they would be at night.

There is one hitch here: plenty of real airplanes have light sensors for various avionics; the avionics will automatically turn up their brightness during the day. So it is possible (I am no expert on the 777) that in the real plane, as the sun rises, you might not have to adjust your instrument brightness; the sensor would do it for you. The pictures above illustrate what you would see if no automatic adjustment is made.

Auto-adjustment presents a challenge: currently two wrongs make a right. We don't auto-adjust the brightness of instruments, but we don't simulate the apparent visual brightness relative to the sun, and the result are instruments that look adequately bright at all times of day without user adjustment.

I think in the productized version of this feature, authors will have two options for anything lit:

Tie the lit instrument/texture to an auto-adjusting rheostat (e.g. brightness 1 + auto adjustment) or
Tie the lit instrument to the "raw" rheostat (e.g. brightness 1).

The tricky part will be finding the right mapping for legacy airplanes into the new system.

Performance of Panel Texture vs. 3-d Cockpit

2010-07-23T09:51:00.001-04:00

I sometimes get questions from authors considering how much to rely on a 2-d panel mapped to 3-d via the panel texture vs. a true 3-d panel. I can't comment on what will look best, but I can comment on the relative performance characteristics of both techniques, and the answer might surprise you: in some cases you'll get better performance by modeling directly in 3-d.

The 2-D Way

When you use the panel texture to make an object, X-Plane goes through a lot of steps to create the final result:

Your panel has to be rendered in 2-d. We atlas your panel textures, but we don't necessarily order them optimally - we don't know the optimal order. Each generic instrument is at least one batch, perhaps even two. Those batches have very low vertex count, and the vertices are stored non-optimally on the CPU. There may be a fair number of texture changes between instruments.
If you use ATTR_cockpit_region, we then go back and do the same thing...again! Why? Well, we need your panel's raw color ("albedo" to graphics nerds) and the emissive light given off by anything self-lit separately, so that we can do correct 3-d lighting.
Both of these are rendered to an off-screen texture that the video driver will feeel obligated to preserve at all costs, putting pressure on VRAM.
Only when all that is done do we begin drawing your object, with the usual batches to change to panel texture and change back, perform animations, etc.

If this seems expensive, that's because it is. Periodically users send me airplanes to look at their performance, and lately I've been seeing a lot more problems with 2-d panels (that fuel 3-d cockpits) being the performance bottleneck, not the 3-d modeling itself.

The 3-d Way

What if we want to go 3-d? Well, we're going to "eat" a lot more of what your 3-d pit already has:

You'll need a lot more animations to move all of those parts.
You'll need new batches with ATTR_lit_level to dial up and down various lighting levels.

But you do get some advantages:

Geometry in objects is processed about as optimally as we possibly can. All of that work we've done on the rendering engine to make OBJs fast is available in your cockpit. So you can increase 3-d detail 'for free'.
Your lit geometry can be drawn in a single pass (we don't need to prepare two separate lit textures). So for example a needle would take three batches via the panel-texture route (a batch to rotate the needle for albedo, a second batch to draw the rotated night needle, and a third batch to draw the resulting texture in 3-d) but only one if you use the OBJ directly.
Since you organize your textures for OBJs, you can guarantee that all of the cockpit stuff is together, saving texture thrash.
You can use normal maps to add per pixel detail to your cockpit; panel textured geometry cannot be normal mapped.

A Balancing Act

Given the high cost of panel texture relative to native OBJ drawing, you'd think going native OBJ would be a no-brainer, right? Well, not quite.

A needle is an easy case: you can model a needle using a rotation animation, so your implementation in an OBJ and our generic instrument are quite similar. Same with the throttle lever generic instrument.

But what about a "glass pie indicator"? What about a moving map? What about a rotary?

There are some generic instruments that have "movement" for which there is no equivalent OBJ technique. With these generics, the generic instrument/panel code may be able to render the generic quite a bit more directly than your OBJ can simulate the same effect.

This is my suggestion on a cut-off: if you can directly model a generic instrument with an OBJ (needles, throttles, and other "simple moving things"), consider 3-d. If you would have to use a lot of extra texture space, copies of your mesh, or a lot of show-hides, use the panel texture.

Your goal should not be to eliminate the use of panel texture. But if you can cut panel texture down to a single 1024 x 1024 region from a larger area, you'll probably see a performance win or a reduction in your airplane's system requirements.

Performance Test First

Final thought: before you invest months in a complex cockpit design, mock up the "work-load" X-Plane must do and performance test it! For an OBJ, simply make one moving instrument and duplicate the mesh to get the number of expected animations. For the panel, drag out a bunch of instruments, make custom textures and just paint junk into them with photoshop. The goal is to make X-Plane do the same amount of work as it will in the final version. Then fly your test panel on target computers and observe performance.

Why Don't the Cars Work Quite Right in Replay?

2010-07-17T22:05:00.003-04:00

The short answer is: to save memory.

The cars and replay seem to be a case of damned-if-we-do, damned-if-we-don't. If we don't stop the cars and reverse them in replay, we get piles of bug reports. If we do try to replay the traffic, we get bug reports too.

The current implementation is a bit strange: when you replay traffic, the cars will go back a bit in time, but at some point they will just stop and refuse to reverse any more. What's going on?

The answer is that the cars have the memory of a goldfish. They simply don't remember where they came from. Each car knows what "link" it is on, and about when it got onto that link and how fast it is going. (A link is a single straight piece of road.) So when we go into replay, we can easily move the cars along their links as time goes forward and backward.

But when we reach a time earlier than when the car entered the current link, the car has know idea how it got there, so it is forced to stop.

This is a simple case of not wanting to burn four tons of memory on a feature that is mainly visual. To replay the cars, we would have to accumulate a history of every link a car has been on as it drives. For 20,000 cars and a sim that's been running a while, that's a lot of memory to burn just in case you happen to hit the replay button.

In fact it gets worse. The cars are kept in a data structure that tells us who needs to make a driving decision and when.* This structure is optimized for the cars moving forward in time. We'd have to make and maintain an entire second copy of this structure to move the cars backward; again burning CPU and memory while you fly just in case you might hit a replay.

So instead we just provide replay on the current link.

* Programming nerds: the cars are in a priority queue by time to next navigation decision. I consider this to be very clever.

Games Vs. Platforms

2010-07-15T14:33:00.004-04:00

Previously I blogged about the difference between integrated first person shooters (FPS) and flight simulators, and how these differences mean that FPS tend to adopt new graphics technology significantly ahead of flight simulators. One of the major differences is that a FPS often will have its content packaged with the rendering engine in a single, unified product, while a general purpose flight simulator is expected to cope with third party content.

The need to be a platform for external content doesn't just impact our ability to optimize for "special cases" (e.g. we can't assume anything about third party); it also puts more pressure on the rendering engine to be robust in the case of error.

X-Plane has low level and high level scenery abstractions.

Low level: an OBJ is low level. You give us a textured mesh, and we draw it. We don't process the mesh, we don't interpret it, we just draw what you made in Blender, AC3D, etc.
High level: a forest. You tell us the outline of the forest's area and give us some trees and we fill in the forest, picking trees and placing them.

Now there is always the risk that third party content can look stupid. If you model an airplane and you use 4 quads for each engine, your airplane is going to look bad, and there's nothing the rendering engine can do to fix that.

But with higher level abstractions, the problem is more subtle. If the input data to a high level abstraction has a problem, X-Plane's rendering might look bad. But what constitutes a problem?

In the case of forests, if the polygonal area of a forest is too thin (along certain axes) we will fail to put any trees into the polygon. Exactly what represents too thin isn't particularly well documented or even easy to measure. This is difficult for third parties, because they don't have an explicit set of guidelines for "you will make the rendering engine grumpy if you do X."

This is the kind of thing that, in an integrated FPS, is much easier to cope with. The art team tries a technique, and if it looks bad, they email the rendering engine coder. The coders then either fix the rendering engine or tell the artist "don't do that".

In our case, we need to be more robust in the case of input data problems because we can't tell everyone who tries X-Plane "don't do that", particularly when the edge cases may change with rendering engine improvements. So whereas a rendering engine feature in an integrated FPS might be useful if it looks good when used in a few usage cases , a rendering engine feature in X-Plane is only useful when it looks good under most usage cases.

OSM Tilings

2010-07-11T11:55:00.004-04:00

This is two pictures of "tilings" of OpenStreetMap for use in global scenery. I downloaded a OSM new planet extract about a month ago; in the 11 months since I last grabbed it, the data size has grown 56%! The new, larger file required some changes to my extracting code. After much debugging, I was able to see this in QGIS:

The first picture is 1x1 tiles, which are derived from the second picture (10x10s). You'll see some "ragged" edges. This is because the cutting scheme leaves whole roads of interest in one piece even outside the tiling bounds. Later, more sophisticated code crops the road when the actual DSF is built.

The OSM processing tools are part of the open source scenery tools; I will get my changes checked in to source control over the next few days, although my code is only one of dozens of programs for bulk processing OSM.

64-Bit? It's On the Radar

2010-07-08T11:51:00.003-04:00

I've been working on road processing today; one of the tricky problems with OSM data is that, because an OSM map is often a collection of vectors from separate authors, the results can be a huge number of very small segments, as nearby road features from different data sources cross each other. (Basically you get "thrash" between the two vectors from different sources and our tools solve this by adding a huge number of extra vertices.)

I am trying to run this data through an algorithm called Iterative Snap Rounding (ISR) to reduce this mess of vertices, and for the purpose of this blog article there's one thing you need to know about ISR: it is really, really slow. So for the next few minutes, I figured I'd start poking at some of the issues that came up at the X-Plane Congress in France this summer.

One question that came up was whether/when X-Plane will go 64 bit. Here's my current thinking:

We can't drop 32-bit X-Plane. Too many users have a 32 bit operating system, or a 32-bit CPU. One thing I have been resisting for X-Plane 10 is a ratcheting up of the system requirements to only top-end game machines. While 64 bit is becoming more prevalent and has the potential to be a big win for users who load the sim up with third party add-ons and have a high-end graphics card, plenty of people buy a computer first and then discover X-Plane. Those users will often have a system that is low end (by X-Plane standards).

If we start cranking the system requirements (you have to have 64-bit, you have to have a DX10 class graphics card, you have to have 2 GB of RAM) then more users who might discover X-Plane won't even be able to run the demo, and that will be bad for X-Plane's growth.

So the question is not "when will we switch from 32-to-64 bit" - it is "when will we support both 32 and 64 bit."

I think we will get there during the version 10 run, but I don't think it's that likely that we'll ship 64 bit right out of the box. 64 bit is more of a performance enhancement* than a new feature. The features we have strong motivation to get into 10.0 are:

Anything that raises the system requirements, because we don't want to raise system requirements after we ship in a free update.
Anything that enhances the authoring SDK, where it might be useful for authors to know that every version of X-Plane 10 has a feature.
Of course, we want to ship any feature that looks really good and gets people excited.
Foundation features that support other featuers have to go in first. So some enhancements that will ship in 10.0 are there because without them other tech couldn't be rolled out.

64 bit is important, but it is a feature that only helps some of the user base, and helps by making the sim more expandable; the sim is still usable without it. So we'll get there, but new features are a zero sum game so I think 64 bit is more likely to be a free patch than in-the-box.

(At this point I expect the various 64-bit OS users who have been asking for a 64-bit app for years to flame the heck out of me and point out that I am a cranky old bastard who doesn't realize that 64 bit is now everywhere and totally pervasive and that this is therefore the most important thing we could possibly do. Before you dig in, hang on one second, let me put on my asbestos flame-retardant jacket. Okay...fire away. :-)

Oops...ISR just finished...with a seg fault. Gotta go!

* As a performance enhancement, 64 bit is a weird one; because a 64-bit app uses more memory for pointer-based structures, the same data structures become larger, thrashing on-chip caches more. The real benefit to 64 bits is to allow X-Plane to use more than 3 GB of physical RAM.

A MeshTool Bug

2010-07-07T10:59:00.004-04:00

To put it mildly, I am buried. If you have emailed me in the last few weeks, I apologize, but basically whatever is going on, I can't look at it for at least a few more weeks. The four posts for June is an indication of work-load. In particular, since a lot of what I am working on is v10, it is under the radar until we do some kind of more formal announcements.

I did find a little bit of time last night to fix a MeshTool bug (thanks to the users who found this - it was a tricky one!). There will be a MeshTool RC2 to fix the bug: if you use only "wet" orthophotos (that is, orthophotos that have water-like physics) but not "dry" ones, the orthophotos are not exported at all.

I realize that the entire schema for creating mixed wet/dry orthophotos in MeshTool is byzantine at best. Basically you have to manually build the set of GIS files to create this effect, and even with examples in the README it is still pretty hard to do. I hope to automate this a bit in a future version of MeshTool but for now I need to finish version 2.0 as is. I'll try to cut a new RC within the week.

Also a slight side note: MeshTool contains some hidden commands to let you build road grids inside MeshTool. This was never documented or supported; the code came from a merge of Andrew McGreggor's work on New Zealand. Starting with RC2, exporting roads will simply not do anything.

The problem is that I did not separate MeshTool from the rest of the scenery code, and the rest of the scenery code is transitioning toward version 10 roads (which do you no good now as v10 isn't released). If you are successfully using the hidden road code in MeshTool, email me and I can advise you on how to cut your own build. If you are trying to use the hidden road code but not succeeding, please use another tool like Jonathan Harris' XPOSM.

In the long term we will end up with "draped" roads in overlays - that is, roads that do not depend on the shape of the mesh. Thus you will be able to simply write road data into an overlay file (or someday draw it in WorldEditor). But we're not there yet.

Tyler has made a lot of progress moving the scenery documentation to the wiki. Once I find some time to give him more feedback we will be able to complete this process. Hopefully this will make it easier to keep the documentation updated.

DDS Has No Gamma (Which is Very Sad)

2010-06-28T23:07:00.002-04:00

A few years ago I blogged about gamma correction for png files. Here's the very, very short version:

PC and Mac monitors are calibrated differently. Dark tones on a PC appear darker than on a Mac. The curve of how colors are mapped to the monitor is the gamma correction curve, typically expressed as a number like 1.8 for Mac and 2.2 for PC. The higher the number, the more Gothic your dark tones.
A png file can have a gamma value written into the file, which tells X-Plane (and anyone else) what kind of monitor the png was drawn on. This lets X-Plane brighten a png from a Mac when you are on a PC, and darken a png from a PC when you are on a Mac.
If you leave off the gamma value on your png, we assume 1.8 (Mac) which can be bad if you're a PC author.

While this is confusing, it was an improvement over the BMP situation (where everything was set up for a Mac and PC users had to simply crank their monitor brightness).

In version 9 we added a gamma correction setting to X-Plane. The setting you enter in the rendering settings is how "dark" your monitor is (bigger number = darker). We then attempt to compensate by lightening the textures more; thus a bigger number results in a lighter looking X-Plane (because you told us your monitor was dark and we tried to "fix it").

There are two other developments since the original png situation which have unfortunately been a step backward in terms of X-Plane color correction.

DDS and Gamma

The handling of DDS and gamma is, to put it mildly, quite problematic. The problem is two-fold:

DDS doesn't actually have gamma information, so we can't tag DDSes as having originated on Macs and PCs. So we assume a DDS is authored at a gamma of 1.8 (Mac). I think DDSTool correctly does a gamma correction when grinding files at other gammas.
(If you are a real graphics programmer, please do not read this next sentence.) X-Plane attempts to adjust the color of the DDS in its compressed form. This is a big hack designed to keep framerate high, but it's really not a very good idea. The result can be color distortion when a DDS is viewed at 2.2 gamma.

So that's not good, but what happened next made things a lot worse.

Apple Goes Gothic

Apple adopted the sRGB color profile for OS X 10.6, which has a gamma curve of about 2.2. So now the situation with DDS is particularly ugly:

All DDS are authored at a gamma of 1.8.
All users are moving toward a display gamma of 2.2.
X-Plane thus has to always color correct, but its color correction is low quality for performance reasons.

This is...very sad.

There are two things we can do about this:

In the short term, we can provide post-decompression color correction. This will cost a (hopefully) small amount of framerate and improve color fidelity for users with 2.2 gamma. This is the kind of thing that any user with a modern card would want, but that we might make optional for users with very old hardware.
In the long term, we can provide a gamma calibration in the text files that wrap DDS files so that authors can mark their DDS as already being 2.2. This will mean that for most users X-Plane won't have to do any color correction at all.

Lighting Rheostats in X-Plane 9

2010-06-21T12:05:00.003-04:00

There were a few threads regarding lighting rheostats in X-Plane 9. Here's a short version of the issue and why we're not changing X-Plane 9's behavior.

X-Plane 9's policy toward lighting rheostats is a little bit arbitrary. The sim will pre-position every lighting rheostat in the cockpit to 75% intensity on sim startup, and from that point on, we never touch them. We do not reset them when you load a new plane or reset your flight.

The result of this is that when you load a new airplane, it "inherits" the rheostat positions of the last airplane loaded. This can cause a problem if the newly loaded plane doesn't have controls to adjust the lights (e.g. it has no instruments on the 2-d panel or manipulators on the 3-d panel, and there is no keyboard shortcut defined). A plane can be "stuck dark".

It would be nice if X-Plane would pre-initialize the lighting rheostats on startup, but X-Plane deos not have enough information to do this. For example, on plane load, the instrument brightness should be set fairly high (so a glass cockpit can be read during the day) but the flood lights should be fairly low (to prevent loss of night vision). But X-Plane has no idea which rheostats control instruments and which control floods. So if we wanted to correctly initialize the cockpit, we wouldn't have enough information.

To make it more complicated, some airplane authors have taken it upon themselves to initialize the cockpit via plugin code. If X-Plane were to start changing the rheostats at startup, it might undo some of what these plugins have done.

Given the difficulty of maintaining compatibility and the lack of a "correct" set of values, we decided not to change the behavior in 9.50 or 9.55.

If there's any take-away point for airplane authors, I think it is this: provide controls for the lighting rheostats that you use in your airplane. Otherwise the user can't turn the lights on if they are off for any reason. You can control the lighting rheostats with a generic instrument, manipulator, or the built-in instruments.

Ugly Glow

There is a separate issue that sometimes comes up: X-Plane panels can look bad when the flood lights are turned all the way up during the day. A panel can look very red and washed out, for example.

This problem comes from a mismatch of real-world lighting levels. In the real world, the sun is approximately four gajillion times more powerful than the little dome lights in an airplane. So when the sun is out, the dome light isn't visible even if it's turned all the way up. The dome light only looks bright when your eyes have adjusted to a no-sun condition.

What X-Plane should do (and may do in the future) is scale all cockpit lights relative to the overall daytime brightness, which would effectively dim the effect of flood lights during the day. Simply turning down flood lights when a flight is started during the day is not a full solution, as the user can simply turn them right back up again and end up with an unrealistic scene.

Suffice it to say, I think we will address these things in a v10 time frame, not a v9 time frame; in the short term it's better to have airplanes continue to function as the author intended.

Moving the Scenery Site

2010-06-11T14:49:00.003-04:00

We have Tyler working for us again for the summer (last summer he did a very nice and much needed rework of the X-Plane manual), and among his projects is cleaning up the mess that is scenery documentation.

We are moving the scenery documentation from their own dedicated site to the X-Plane wiki. As of this writing, as you can tell, it's a work in progress. There are a few reasons why we decided to consolidate to the wiki:

The scenery website is the very best of 1995 technology - unmanaged php in a big mess of files. We wanted to get the site under some kind of content management system, and MediaWiki is already working well for us for other docs.
There is a lot of overlap between modeling techniques for scenery and modeling techniques for airplanes, so having all of the third party authoring docs in one place makes sense.

It'll be a few more weeks before everything is organized.

Tyler is also reviewing all of the documentation. I have had a lot of trouble trying to document the scenery system, partly because I have been working on it for years, and thus I have no sense of what people don't know. Since Tyler hadn't done any scenery work before, he was able to read the documents and go "hey Ben, you keep talking about X but you never defined what it is." The resulting edits should make the docs a lot clearer.

What is the Difference between ANIM_hide and ATTR_draw_disable?

2010-06-09T10:48:00.003-04:00

In order to understand the difference between hiding geometry and disabling drawing, you need to understand that an OBJ triangle can serve many purposes. Broadly, those purposes are:

Drawing (the most basic use).
Collision detection, of which we have three flavors: collision of the plane with the object ("hard surfaces", or "physics"), collision of the mouse with the panel (manipulators, or clickable triangles) and collisions of the camera with the airplane ("solid camera", which constrains the camera).

Any given triangle can be drawn and/or used to check for any of these collisions*; attributes change what the triangle is used for.

By default, all triangles are drawn; ATTR_draw_disable marks future triangles as not being drawn. This allows you to make a triangle that is used only for collisions. Examples might include a "hot spot" in front of a region on the panel (the hot spot might be easier to click than a small switch) and an invisible simple mesh to constrain the camera.

By comparison, ANIM_hide effectively removes some triangles from your model (temporarily) for all uses - drawing and collision detection of any kind. If a door is hidden, it's not only not drawn, but it's not going to stop the camera moving through it either.

Some key points to these distinctions:

Categorizing what a triangle is used for (drawing, various flavors of collisions) is static - that is, it is always the same for the object and never changes with datarefs or animation. This is intentional for performance reasons!
Animation to hide triangles affects the triangle in every way consistently - drawing and collisions.

Generally, you will get better performance improvements by removing categories from a triangle than by hiding it. (That is, it is better to not have manipulators on your cockpit, so it isn't mouse-click collision-checked, than to hide it.) But the purpose of ATTR_draw_disable and ANIM_hide are different enough that which you use will be determined by the effect you are trying to create.

Finally, note that hiding an object completely (that is, the object does no drawing) does not provide the maximum performance benefit of not having an object at all. ANIM_hide was created to allow authors to create clever effects, not as a performance enhancer!

* This is not quite accurate: airplane-object collision checks are only available in scenery objects, and camera/airplane or mouse/panel collision checks are only available in the cockpit object.

Plugin-Based Prop Discs

2010-05-25T21:24:00.002-04:00

I was discussing plugin-controlled prop discs with a third party developer. The developer wanted to know if custom prop disc control would end up inside Plane-Maker. It may end up doing so, but I don't think this would be nearly as useful as it would seem. What follows is my explanation to him of why this is.

Let me draw an analogy: when it comes to systems modeling, using a plugin is to Plane-Maker as using Blender is to using Plane-Maker.

Users who cannot use Blender are frustrated because they cannot make something as nice as those who are building planes out of OBJs. Sometimes they ask for more features in Plane-Maker, like: more stations! This new editing mode! Make the UI better!

But...you tell me: will Plane-Maker's UI ever be as flexible and powerful as Blender? And if it ever did get to be that good, would that have turned out to be a good use of LR's time, when Blender is already available?

The motivation for OBJ-based airplane geometry via third party tools is that what users want to do cannot be easily generalized into a few simple cases. Every plane is different, so a truly flexible platform is needed.

The prop disc (and other systems modeling problems) are the same way. In developing the prop disc graphics, I spoke with a number of third party developers who had already tried to push prop discs as far as they could go, were using plugins, were drawing themselves, as well as 25 other crazy hacks. I also spoke to our internal art team. And what I found was: no one had any consensus on how the prop disc system should work. Everyone wanted to tune a very specific set of behaviors to their peculiar art assets.

That's what drove me to put it into a plugin. When we need an equation or a strategy we reach the point where we need more flexibility than Plane-Maker can exhibit. A plugin can encapsulate a strategy or technique in a way that Plane-Maker radio buttons cannot.

Consider what would happen if custom prop disc parameters were built into Plane-Maker. Everyone would have to wait until Austin implemented the prop disc algorithm they wanted. How would this be bad? Let me count the ways?

How many algorithms do you think Austin has time to code? Not more than he has fingers on his right hand. Only the five lucky third party developers who get their algorithm coded will be happy with this.
Austin code exactly what you want? Don't get your hopes up.
, what you asked for wasn't what you wanted? We can't change the behavior now, that would break compatibility!
oh...your email got eaten by a spam filter? Too bad...no custom prop disc for you!
Sorry, we don't have a release vehicle lined up for the next 3 months. You'll have to wait.

This problem is already happening across pretty much every aspect of systems modeling: airplane have unique, quirky systems which are usually useful for exactly one plane. It is not even remotely sustainable for X-Plane to code these things one at a time with a set of check-boxes. We might as well have a pop-up menu for every airplane ever invented, and simulate every single airplane inside the sim itself. Imagine the development costs...if a single high quality MSFS add-on sells for $30-$50...

Think of the prop disc via plugins situation (and the strobe lights are the same way) as an experiment in generic instruments for systems. By transitioning to a generic abstaction for instruments we've let a lot more users do exactly what they want with a small, high performance piece of code. The original instrument strategy (one of everything) reached a point where we simply couldn't meet user needs in a cost-effective manner.

Additive Lighting Does Not Require Alpha

2010-05-23T11:54:00.002-04:00

In X-Plane there are two fundamental ways that a texture can be painted "over" a background image:

Blending, whereby the alpha channel of the new top layer decides how much we see the top layer vs. the background.
Additive Lighting, whereby the new texture makes the background lighter.

Blending is more common. For example, if you build an OBJ, the object appears "in front of" the terrain via blending. With blending, you put the color of your new layer in the RGB channels and use the alpha channel to indicate opacity. 1.0 alpha = 100% opaque, 0.0 alpha = 0% opaque, and alpha in between will create a blend. If you omit an alpha channel, X-Plane will treat the entire layer as 100% opaque.

When a layer is applied using additive lighting, the resulting color is the sum of the background plus the new color, clamped to the maximum brightness we can show on screen. Additive lighting is good for simulating effects that really "add light". Some examples of additive lighting in X-Plane:

All lighting billboards are drawn additively.
Instrument overlays are additive if you pick the appropriate mode in Plane-Maker. (The option is labeled "glass" for generics, since most glass instruments work by adding light to a nearly black screen.)
The emissive (_lit) texture of an object is added to the albedo (daytime) texture using additive lighting.

Now just a little bit of math. In RGB color terms, black = 0,0,0 and white = 1,1,1. So if we add a pure black texture to a background additively we get:

new_r = old_r + overlay = old_r + 0 = old_r
new_g = old_g + overlay = old_g + 0 = old_g
new_b = old_b + overlay = old_b + 0 = old_b

In other words,when using additive light, adding "black" does nothing, preserving the background.

And this brings me to my main point: any time you have additive lighting you don't need an alpha channel. You can simply make your additive lighting texture black for the parts you want to be "transparent".

This is why I generally recommend that emissive _LIT textures for objects not have an alpha channel. In fact, for "back-lit" and "additive" instruments (these are instruments that use a second emissive _LIT texture) Plane-Maker will indicate a warning if the texture has an alpha channel. If you have a texture that is applied additively, you don't need alpha.

At this point you might be wondering: Ben, if additive lighting doesn't require alpha, and all lighting billboards are drawn additively, why the heck is there an alpha channel for custom lights?

The short answer is: there probably doesn't need to be one; the original setup for lighting billboards inherited a number of idioms from older versions of X-Plane, going back to versions where lighting billboards were not additive* (and thus alpha was necessary).

The long answer is: the alpha channel is often as a general "intensity" control to turn the light up and down in amplitude, while the RGB channels are often re-interpreted in strange ways. So while RGBA color is not necessary from a graphics standpoint, it is handy that there are four color channels in the custom lights because that gives us one more parameter to play with when designing really compicated lights (like VASIs).

* Note that lighting billboards that aren't additive don't look very good...hence Austin switched to additive billboards.

Why Does X-Plane Require TEXTURE_LIT?

2010-05-22T21:15:00.003-04:00

Back in olden times (read: X-Plane 6) X-Plane would look for file names with special extensions to enable special features. For example, in many cases appending the suffix _LIT to your texture name specified that you wanted a second emissive texture attached to your scenery.*

Then I showed up and started replacing the "find by extension" scheme with specific commands in configuration files to induce special behavior. On pretty much all of the modern text file formats, you need to use TEXTURE_LIT to specify your emissive texture, and once you use this command, you can use any suffix you want.

Why the change? I had three reasons:

Features by file naming convention is ugly. That's just an aesthetic decision by me, and most users find file extensions simpler, so if this was the only reason, I'd be a bit of a jerk.
File naming conventions don't grow over time. With file naming conventions, additional features would mean truly crazy conventions. Consider terrain files, where any terrain can be loaded with wrapped or clamped edges. (Wrapped edges are appropriate for repeating tiles of "land class" and clamped edges are appropriate for orthophotos.) We would end up with my_texture, my_texture_LIT, my_texture_wrapped, my_texture_wrapped_LIT, etc. What about the scale of the texture? What if we implement seasons? my_texture_2000_2000_wrapped_summer_LIT.png it is.*
By putting features in text files, we leave room for future expansion, and we have a lot more room to attach data to an image or control shading.
Probably most important: going to disk and loading lots of images is slow, so X-Plane loads images in the background while you fly. But checking the disk to see if my_texture_LIT exists is a disk operation too, and it is potentially one that we have to do immediately to understand our art assets. By having information about art assets in the text files and not file naming conventions, we can read one text file, rather than searching for all possible combinations of file extensions.

With X-Plane 9 we're starting to see enough complexity in shading configurations and options that file names would be a non-starter. Consider some of the new features in version 9: normal maps and paged orthophotos. X-Plane 10 will introduce even more rendering and shading capabilities. These configuration options are better kept in a text file than a file name.

* Actually, Sergio and Austin were heading in that direction. Note that the names of the old ENV land classes were in the form CropCool0_000.dds. What are all the numbers? I don't know, but Sergio had a plan to use them to select lots of different textures. This scheme was never implemented.

DSF Will Be Extended, Not Replaced

2010-05-21T15:31:00.002-04:00

Austin attended the French X-Plane Congress last weekend; in response to some questions I have received, I want to clarify what is planned for DSF and X-Plane 10.

X-Plane 10 will extend DSF scenery capabilities by providing a number of new art asset types, as well as extensions to existing art asset file formats. We will not be changing the DSF file format or breaking compatibility with existing DSF scenery. If your DSF scenery works with version 9, I expect that it will work with version 10 as is.

(In fact, it looks like we do not even need to add new DSF extensions; DSF was designed to be a generic container for geometry data and properties, so we can usually extend X-Plane's scenery system by simply defining new art asset classes and properties.)

An example will illustrate what I mean by extending the art assets, not DSF.

In X-Plane 9, you create a forest (whether in a base mesh or overlay DSF) by creating a DSF polygon referencing a .for (forest) art asset. X-Plane will render this by filling the area inside the polygon with lots of trees.

In X-Plane 10, you will be able to optionally tell X-Plane to put the trees only on the edge of the polygon, rather than filling the entire inside. (This feature will be controlled by using values on the polygon parameter that are larger than 255, at least I think.) This will mean that you can use .for files and DSF polygon not only to create forest areas, but also to create rows of trees along the edges of roads or fields. A row of trees made by a .for file and DSF polygon will render much faster than a large number of individual OBJ-based trees.

This kind of art asset extension is similar to what we have already seen; X-Plane 850 introduced three new art asset types (.str object strings, .lin line paint, and .pol draped polygons) that all produced new rendering tricks using DSF polygons. These art assets were added to provide high performance rendering of airport surface areas. The new art assets didn't require any change to DSF because the representation of the position of these art assets is something DSF has always done: simple polygons.

DSF won't last forever, but at least for X-Plane 10 it looks like we can do a third full cycle of the sim using DSF as our base container format for scenery position data.

Where Has All My VRAM Gone?

2010-05-15T12:15:00.001-04:00

In the past I have suggested that there is a limit to the value of additional VRAM when buying a graphics card. When I posted this, Nicholas from the org emailed me to point out that with third party add-ons VRAM was a lot more important.

At the time I wasn't really convinced, but I've finally come around; it takes a while for the trend to get back to me. (I just don't have time to look at everyone's add-ons the way I used to 4 or 5 years ago.) It seems clear that airplane authors (and to some extent scenery authors) are using VRAM pretty aggressively. If you want to use third party add-ons and you care about texture res and texture sharpness, spring for some VRAM. It doesn't cost as much as it used to, and authors are starting to use it.

What Lives in VRAM

Bear in mind that in any discussion of how your video card operates, anything I post is informed speculation. The driver provides an abstraction (OpenGL) of what the hardware does, and a lot of the bookkeeping isn't visible to X-Plane at all. So what I am describing is typical of past video drivers that we have had insight to in the past, but it's not universal, and it's not at all guaranteed. (X-plane can't demand any of this behavior of the video driver.)

In order of how "stuck" in VRAM things are we have:

Video memory used for on-screen rendering. Depending on rendering settings you can lose anywhere from 12 to 24 MB of VRAM per million pixels on screen. So if you're running at 1920 x 1200, you might be using 50 MB of VRAM just for the screen. If you use FSAA, you're going to chew up VRAM even more aggressively. (Costs vary depending on the scheme; you might lose 4-16 MB x the FSAA level per million pixels on screen, depending on your GPU and driver.)
Off-screen rendering for things like the water reflections, the panels, the cloud shadows, the airplane shadow, etc. These don't have to be in VRAM all of the time, but they have to be in VRAM almost all of the time. Because they are created by the GPU, the driver tries hard not to move these out of VRAM. You might lose 6 to 16 MB of VRAM for these, depending on the airplane you use and settings. (Given 4 1024x1024 panel regions, the panel will chew up 32 MB!)
Textures end up in VRAM, but only when they are used. The key here is "working set". Only texures that are drawn need to be in VRAM, so over time stuff that isn't on screen will be removed from VRAM. This is why when you see "600 MB of texture memory" in the rendering settings, there is no need to panic. The working set is usually much smaller.
OBJ geometry actually lives in VRAM too, sometimes. Again this is a working set issue; objects that aren't drawn don't get cached there.
Textures from airplanes and scenery packages that are not loaded don't ever end up VRAM or even system memory; we only load what we need. Paged orthophotos have their resolution reduced while you fly, which makes their VRAM footprint quite small, even when drawn.

There are a few things authors and users are doing now that use up a lot of VRAM.

Monitors have gotten bigger; the VRAM used for the screen itself can never be swapped out, so the advent of the 1920x1200 LCD has taken its toll.
Since the panel texture is drawn off-screen, the panel texture is in an expensive category of VRAM use. Authors can limit the cost of this by using a single 1024x1024 panel region texture, if possible.
There is a hidden cost here: we pack together instrument textures into "atlases" to help with performance. The problem is that we pack for fit. Some of your instruments may be hidden but loaded into VRAM anyway because they sit in the same atlas texture as other instruments that are drawn. Thus you may be paying for the VRAM used by your entire panel even if a lot of it is hidden.
Because a lot of this VRAM is going to airplanes, reducing texture resolution doesn't have as much impact as it used to; X-Plane tries to keep the user's plane's resolution as high as possible since it is viewed up close. The panel cannot have its resolution reduced at all.

But It Works Sometimes

I think what drives users crazy about VRAM exhaustion is that X-Plane will sometimes run smoothly, and then fail later. And sometimes really strange things, like moving X-Plane to the background, then the foreground, or changing liveries or rendering settings in a trivial way, will change performance.

I have discussed this a bit in past posts. But the key here is "working set":

In any one frame, we can access everything that is permanently in VRAM, plus as much data as we can put through the PCIe bus from the CPU to the GPU.
We only need to access data in the working set (what is on screen).
Some of VRAM is permanently used (e.g. memory for the screen itself).
We lose PCIe bandwidth to both drawing from main memory (terrain is in your system memory and must go over the PCIe bus per frame) and from bandwidth spent juggling textures.

So the actual maximum throughput will have a lot to do with whether the video driver makes good decision about what lives in VRAM and what does not.

But how does the video card know what should be in VRAM? The answer is that it has to guess. It looks at frames going by and tries to use heuristics (that is computer-science geek speak for "carefully formulated wild guesses") to decide what goes in VRAM and what does not. When the heuristics happen to make good decision, your video card kicks ass. And when it does not, your framerate tanks.

The only way to guarantee good framerate is to use so little VRAM that everything that needs to be in VRAM can be in VRAM, without depending on the video driver to make lucky guesses with its juggling.

And this helps us understand why strange things like livery reloads and backgrounding the sim can affect framerate (for better or worse). These operations seriously reshuffle VRAM - either by deleting textures and loading new ones, or by forcing everything out of VRAM so the video driver must try to repack video RAM all over again.

Unfortunately as a user this means that there's not much you can do about this as a user. The main things would be: reduce screen size or FSAA or texture resolution, use fewer add-ons, or get more VRAM. Those peak bursts of framerate you see, they're not going to be sustainable .

REXPlane

2010-05-14T12:00:00.004-04:00

REX is here for X-Plane. That's really exciting to me because REX is a very successful add-on to FS X, and it's been understandably difficult for us to convince companies that have a functioning and profitable business model on FS X to jump over to X-Plane, which requires building new capabilities in-house, starting at the bottom of the learning curve, and developing new processes. I hope these guys have a ton of success. Heck, I'd buy the product just because REXPlane is such an awesome name!

What surprises me is that we haven't seen more ports of airport scenery. These packages can be partly converted mechanically using Jonathan Harris' FS2XPlane tools, and in the case of an airport, the potential for recycling is huge - that is, the largest part of the development process is modeling, creating textures, and connecting the two. Since X-Plane can use these art assets with minimal mods, it seems like a very viable type of port.

Water Reflections Use the CPU

2010-05-12T17:21:00.003-04:00

A slightly surprising note about X-Plane's rendering settings: increased detail in the water reflections mostly increases load on the CPU! Here's what is going on.

X-Plane's water reflections are a two-step process:

A (simplified) version of the world is drawn into a texture .
That texture is used (and perturbed) to draw the surface of the water.

The water reflection detail setting affects a number of this: the size of the texture used to draw the world, the level of simplification of the world drawn into the texture, and I think some details about the shader used to draw the water surface itself.

Of these factors, the biggest impact on frame-rate is almost always simplification of the world as drawn into the water texture. At its most detailed ("complete" reflections) that rendering is almost identical to the main sim rendering, and thus reflective water should cut your framerate in half!

In particular, the big hit of drawing the world a second time is that it means drawing objects a second time. Thus the higher the reflection setting, the more objects are being drawn. In a scenario where objects are already the main drag on frame-rate, using complete water reflections will make this even worse.

There are two things to conclude from this:

A bigger, faster CPU won't let you turn up the water reflection detail. Most decent GPUs handle the shader-side just fine. It's the objects that are the problem.
You shouldn't turn up the water reflection all the way unless you're taking screenshots. It just doesn't add much visual improvement for the fps hit.*

* This is one of those cases where I ask myself: why did I let the setting go up this high?

Draping

2010-05-12T16:31:00.004-04:00

I'm trying to post weird in-development screenshots as I get them because, well, sometimes they are entertaining, in a nerdy sort of way.

This is experimental test code for road draping.

The idea will be to let X-Plane "drape" the road over the base mesh, so that an overlay can contain customized roads that work with any base mesh.

The Wonderfully Filthy

2010-05-12T13:31:00.000-04:00

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.

You Only Have to buy Apollo Once

2010-05-11T13:28:00.003-04:00

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.

Why Is My Airplane Slow?

2010-05-10T09:50:00.002-04:00

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.

Zen and the Art of OBJ 2: Performance

2010-05-09T14:15:00.000-04:00

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.

Zen and the Art of OBJ 1: The Anatomy of an OBJ

2010-05-08T13:42:00.005-04:00

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?

Baking and Overlays

2010-04-30T10:13:00.003-04:00

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.

What's Next for Scenery Tools

2010-04-28T11:53:00.002-04:00

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.

New Tools This Week

2010-04-20T12:38:00.001-04:00

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.

System Requirements for Scenery Tools

2010-04-16T13:32:00.003-04:00

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"...

What an Evil Disaster

2010-04-09T19:45:00.000-04:00

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.

Two-Sided Drawing and Up-Normals

2010-04-09T11:33:00.002-04:00

Meshes in X-Plane, whether modeled in an OBJ, or generated as the results of other "3-d clutter" (road .net files, .for forest files, etc.) can be either one or two sided. So first: two-sided geometry is bad in most cases.

In order to understand why two sided geometry is bad, we must consider the alternative. The alternative to two-sided geometry is to simply create each triangle twice, with one facing in each direction. We can do this in an OBJ without making new vertices - because vertices are referenced by indices, we only need more indices, and indices are cheap.

Thus we have an alternative to two sided geometry, namely "doubled" one-sided geometry.

The first problem with two sided geometry is performance: for a small number of triangles, it is must faster to simply emit additional indices than to change the drawing mode to two-sided drawing on the CPU.

Thus in an object it is virtually never a good idea to use two-sided geometry. That ATTRibute will always be worse.

What about for the other clutter? Forests are currently always two-sided, but that's okay; X-Plane enables two sided drawing just once, then draws a huge number of trees. Same with roads. For facades, there is a cost to using two sided geometry, so only use it for facades that must be two sided, like fences; do not use it for buildings.

Now the second problem with two sided geometry is lighting: X-Plane does not calculate lighting values separately for the two sides of the two-sided geometry. So if you have directionally lit models with two sided geometry, the lighting will look wrong. This is the second reason to use doubled geometry instead.

Things Are Starting To Look Up

There is a work-around to this problem of incorrect lighting on two-sided geometry: "up normals". With up normals, the normal vector for the triangle (which is used to determine how light "bounces" off the triangle) is set to face straight up. The result is a triangle with brightest lighting at high noon, regardless of which way the triangle actually faces.

The good: the triangle looks the same on both sides and has sort of a "flat" lighting - it doesn't look wrong when the sun is setting. The bad: the triangle has "flat" lighting - it looks non-3d.

We use up normals for forests because the forests are made of two-quad trees...the trees look less fake if directional lighting hints don't make the two quads as obvious. You can simulate this in ac3d using the "make up normal" command for vegetation quads you put in your own models.

For roads, the geometry is two-sided, so we use up normals to avoid having the back of a road element look funny. Some day we may do something more sophisticated.

Fixing Facade Lighting

Facade lighting behavior will be changed in the next 950 release candidate. Before 950, facades would receive up normals, always. Starting in 950, facades will get correct normals if they are one sided and up normals if they are two-sided. This avoids artifacts with two-sided facades, but will make one-sided closed buildings look much better.

Ray Tracing is the Technology of the Future...

2010-04-08T13:49:00.002-04:00

...and it always will be!

Seriously, first, let's be clear: my opinions do not matter! X-Plane is a small program in a large market (game/graphics hardware) and as I've said before, flight simulators are not the early adopters of new tech. So (and this is a huge relief to me) I can do my job without correctly predicting the future of computer graphics.

Keep that in mind as I mouth off regarding ray tracing - I'm just some guy throwing tomatoes from the balcony. X-Plane doesn't have skin in the game, and if I prove to be totally wrong, we'll write a ray tracer when the tech scales to be flight simulator ready, and you can point to this post and have a good laugh.

With that in mind, I don't see ray tracing as being particularly interesting for games. I could make arguments that rasterization* is significantly more effecient, and will keep moving the bar each time ray tracing catches up. I could argue that "tricks" like environment mapping, shadow mapping, deferred rendering, and SSAO have continued to move effects into the rasterization space that we would have thought to be ray-tracing-only. (Heck, ray tracing doesn't even do ambient occlusion particularly well unless you are willing to burn truly insane amounts of computing power.) I could argue that there is a networking effect: GPU vendors make rasterization faster because games use it, and games use it because the GPU makers have made it fast. That's a hard cycle to break with a totally different technology.

I don't really have the stature in the world of computer graphics to say such things. Fortunately John Carmack does. Read what he has to say. I think he's spot on in pointing out that rasterization has fundamental efficiencies over ray tracing, and ray tracing doesn't offer enough real usefulness to overcome the efficiency gap and the established media pipe-line.

The interview is from 2008; a few months ago Intel announced that first-generation Larrabee hardware wouldn't be video cards at all. For all effective purposes from a game/flight simulator perspective, they basically never shipped. So as you read Carmack's contents re: Intel, you can have a good chuckle that Intels claims have proven hollow due to the lack of actual hardware to run on.

I will be happy to be proven wrong by ray tracing, or any other awesome new technology. But I am by disposition skeptical until I see it running "for real", e.g. in a real game that competes with modern games written via rasterization. Recoding old games or showing tech demos doesn't convince me, because you can recode an old game even if your throughput is 1/20th of rasterization, and you can hide a lot of sins in a tech demo.

Heck, while I'm putting my foot in my mouth, here's another one: unlimited detail. Any time someone announces the death of the triangle, I become skeptical. And their claim of processing "unlimited point cloud data in real time" strikes me as an over-simplification. Perhaps they can create a smooth level of detail experience with excellent paging characteristics (which is great!) but the detail isn't unlimited. The data is limited by your input data source, your production system, the limits of your hardware, etc. Those are the same limits that a mesh LOD system has now. In other words, what they are doing may be significantly more efficient, but they haven't made the impossible possible.

That is my general complaint with most of the "anti-rasterization" claims - they assume that mesh/rasterization systems are coded by stupid people - and yet most of the interesting algorithms for rasterization, like shadow mapping and SSAO, are quite clever. Consider these images: saying that rasterization doesn't produce nice images while showing Half Life 2 (2004, for the X-Box 360) is like saying that cars are not fuel efficient because a 1963 Cadillac got 8 mpg. The infinite detail sample images show a lot of repeated geometry, something that renderers today already do very well, if that's what was desirable (which it isn't).

Finally, is in favor of sparse voxel octrees (SVOs). SVOs strike me as the most probable of the various non-mesh-rasterization ideas floating around, and an idea that might be useful for flight simulators in some cases. To me what makes SVOs practical (and in defense of the unlimited detail folks, their algorithm potentially does this too) is that it can be mix-and-matched with existing rasterization technology, so that you only pay for the new tech where it does you some good.

* Rasterization is the process of drawing on the screen by filling in the pixels covered by a triangle with some shading.

Ray Tracing: Shoot Before You Fly

2010-04-04T14:05:00.003-04:00

I'll take a break from iPad drivel for a few posts; at least one or two of you don't already own one. (Seriously, it's simply easier to blog about X-Plane for iPad because it is already released; a lot of cool things for the desktop are still in develpment.)

In response to my comments on water reflections in X-Plane 950, some users brought up ray tracing.

My immediate thought is: I will start to think more seriously about ray tracing once it becomes the main technology behind first person shooters (FPS).

Improvements in rendering technology come to FPS before flight simulators (and this is true for the combat sims and MSFS series too, not just us). Global shadows, deferred rendering, screens-space ambient occlusion...the cool new tricks get tried out on FPS; by the time they make it into a flight simulator the technology has moved from "clever idea" to "standard issue."

Consider that X-Plane now finally has per-pixel lighting. Why didn't we have it when the FPS first did? Well, one reason is that the FPS were cheating. If you look at the papers suggesting how to program per-pixel lighting, at the time there were all sorts of clever techniques involving baking specular reflections into cube maps and other such work-arounds to improve performance. These were necessary because titles at the time were doing per-pixel lighting on hardware that could barely handle it. X-Plane's approach (as well as other modern games) is to simply program per pixel lighting and trust that your GeForce 8800 or Radeon 4870 has plenty of shader power.

I believe that the reason for the gap between FPS and flight simulators come from two sources:

Viewpoint. You can put the camera quite literally anywhere in a flight simulator, and thus the world needs to look good from virtually any position. By comparison, if your game involves a six foot player walking on the ground (and sometimes jumping 10 feet in the air) you know a lot about what the user will never see, and you can pull a lot of tricks to reduce the performance cost of your world based on this knowledge. (This kind of optimization applies to racing games too.
To give one simple example of the kind of optimization a shooter can make that a flight simulator cannot, consider "portal culling". A portal-culled world is one where the visibility of distinct regions have been precomputed. A trivial example is a house. Each room is only visible through the doors of the other rooms.* Thus when you are walking through a room, virtually no other room is being drawn at all. The entire world is only 20 by 20 meters. Thus the developers know that they have the entire hardware "budget" of computing power to dedicate to that one room and can load it up with effects, even if they are still expensive.
(A further advantage of portal culling is a balance of effects. Because rooms are not drawn together in arbitrary combinations, the developers may find ways to cheat on the lighting or shadowing effects, and they know nothing will "clutter" the world and ruin the cheats.)**
Often the FPS will have pre-built content, rather than user-configurable content. Schemes like portal culling (above) only work when you know everything about the world ahead of time and can calculate what is visible where. The same goes for many careful cheats on visual effects.
But a flight simulator is more like a platform: users add content from lots of different sources, and the flight simulator rendering engine has to be able to render an effect correctly no matter what the input. This means the scope of cheating is a lot smaller.
Consider for example water reflections. In a title with pre-made content, the artists can go into the world in advance and mark items as "reflects", "doesn't reflect", reducing the amount of drawing necessary for water reflections. The artist simply has to look around the world and say "ah - this mountain is no where near a lake - no one will notice it."
X-Plane can't make this optimization. We have no idea where there will be water, or airports, or you might be flying, or where there might be another multiplayer plane. We know nothing. Everything is subject to change with custom scenery. So we can't cheat - we have to do a lot of work for reflections, some of which might be wasted. (But it would be too expensive in CPU power to figure out what is wasted while flying.)

Putting it all together, my commentary on ray-tracing is this: the FPS will be able to integrate small amounts of ray tracing first, because they will be in a position to deploy it tactically, using it only where it is really necessary, in hybrid ray-trace + rasterized engines. They'll be able to exclude big parts of the scene from the ray tracing pass, improving performance. They'll be able to "dumb down" the quality of the ray trace in ways that you can't see, again improving performance. The result of all of this will be some ray tracing in FPS when the hardware is just barely ready.

For a flight simulator, it will take longer, because we'll need hardware that can do a lot more ray tracing work. We won't know as much about our world, which comes from third party content, so we won't be able to eliminate visually unimportant ray traces. Like deferred rendering, shadow mapping, SSAO and a number of other effects, flight simulators will need more computing power to apply the effects to a world that can be modified by users.

(Is ray tracing even useful, compared to rasterization? I have no prediction. Personally I am not excited by it, but fortunately I don't have to make a good guess as to whether it is the future of flight simulation. The FPS will be able to, by effective cheating, apply ray tracing way before us, and give us a sneak peak into what might be possible.)

* There never are very many windows in those first person shooters, are there?
** To be clear: there is nothing negative about the term "cheat" in computer graphics. A way to cheat on the cost of an algorithm means the developers are very good at their jobs! "Cheating" on the cost of algorithm means more efficient rendering. If the term cheating seems negative, substitute "lossy optimization".

Yes, the iPad is Magical

2010-04-03T15:35:00.003-04:00

So all kidding aside, my iPad arrived today, and it is a pretty cool device. My normal attitude toward new gadgets is "great, more video driver bugs to fix", but the iPad is exciting.

I'll blog some other time about why I think the form factor is important and there is a spot for something bigger than a smart phone and smaller than a laptop.

For now I just want to point out that it flies X-Plane; X-Plane for iPad a bunch of new features, including 2-d panels while you fly, 3-d airports with full taxiway layouts, a completely rebuilt user interface, improved sky and water effects, and even some auto-gen buildings.

Also first impressions of the device itself: it's really responsive. I have tried to surf the web with my iPod touch (which is based on first-gen iPhone technology) and it's a tough experience - between the small screen, slow CPU and limited RAM. The iPad surfs the web like a desktop. A very light weight, portable desktop.

Need...More...Stripes!

2010-04-02T21:50:00.003-04:00

Some of the coolest in-development screen-shots are the bugs. A few weeks ago while working on cloud shaders I managed to create a hybrid of an acid trip and a light-speed trip on Star Wars. Sadly the code has since been modified a thousand times and the effect is gone.

So I'm going to start posting bizarre images as they crop up. Usually they don't reveal too much about unreleased features.

This came out of some experiments with hills, mountains and UV mapping.

(Clearly what this code needs is a leopard-print texture.)

Mirrored Normal Maps

2010-04-02T20:07:00.000-04:00

Normal maps in X-Plane 940 have a funny property: if you flip the normal map horizontally or vertically, the bumps change direction. Things that "stuck out" now "stick in" and vice versa. (If you flip the normal map horizontally and vertically, the two cancel out and the normal map is not reversed.)

You can understand this by thinking of your normal map as a physical piece of metal with bumps punched in it. Flipping it horizontally really means rotating it horizontally to see the other side - now you see the back side of the bumps. Same with the vertical flip. Flip both and you have flipped it twice and it's front-side forward again.

In a move that is either just in the nick of time or dangerously reckless, I have tweaked the normal map shader for 950 RC1 (coming out "real soon") to detect and "fix" a flipped normal. In 950 rc1 the bumps in your normal map will always point in the same direction as the normal of your mesh, even if your UV map is flipped horizontally or vertically.

What does this mean to you, the modeler? It means that you can now mirror your normal map from the left to the right side of the airplane and the normal map will still have the bumps "sticking out" like you want.

I crammed this into 950 RC 1 because it looks like it's a useful change that will restore flexibility to authors making highly detailed airplanes. Mirroring a symmetric airplane (which results in a horizontally mirrored normal map) is a pretty common thing to do, and if the text is applied as decals, this can be a big win in texture space savings.

I figured best to get the tweak in here now so people could take advantage of it. Plus, what's an RC1 without an RC2?

The Real Deal

2010-04-01T22:14:00.000-04:00

It goes without saying that this post was, um, inaccurate.

This, however, is real.

X-Plane 10 Will Be For the iPad Only

2010-04-01T14:25:00.003-04:00

I wasn't planning on discussing this until April 3rd, but some sites have already picked it up, so I might as well explain the why behind it. Simply put: X-Plane 10 will be for the iPad only. I figure that by letting you know now, you can make an informed decision about whether you want to buy an iPad. (Hint: you do!)

This wasn't an easy decision to make, but here were some of the deciding factors:

I spend a lot of my time debugging video drivers, and it makes me very grumpy. You guys seem to think that you can plug anything with copper and wires into your PCIe socket and call it a "video card". By restricting version 10 to iPad only, we cut down development time by targeting only one GPU.
We love everything Steve Jobs does and kiss the ground he walks on. Steve says the pad is magical.
The biggest single feature request we get for X-Plane is "can I use X-Plane while operating a motor vehicle." X-Plane 9's requirement of 1 GB of RAM, a modern CPU, etc. means that most X-Plane 9 machines are not particularly portable. By making X-Plane 10 iPad only, we can provide X-Plane in a portable format that's more compatible with flying a flight simulator while driving.

One fringe benefit to cockpit builders: because the iPad is so light and thin, creation of a realistic home cockpit with X-Plane 10 will be easier than ever. Simply take some super-glue, wipe it on the back of your iPad, and simply "stick" the iPad to whatever part of the cockpit you want. It's so easy a four-year-old could do it!

OS X 10.6.3 Performance

2010-03-31T12:10:00.004-04:00

OS X 10.6.3 is out. Besides adding a bunch of OpenGL extensions*, it looks like vertex performance is improved on nVidia hardware. My quick tests compare 10.5.8 to 10.6.3 (since I no longer have a 10.6.2 partition) and show a 15-30% improvement. If you have 10.5 and an 8800 you may want to consider updating your OS.

I also discovered that --fps_test=3 produces unreliable results because...wait for it...the deer and birds are randomized. If they show up during the fps test, you get hit with a performance penalty. I am working to correct this and may have to recut the time demo to work around this behavior.

If you are trying to time the sim via --fps_test=3, I suggest running the test multiple times - you should see "fast" runs and "slow" runs depending on our feathered and four-legged friends.

Phoronix reported a performance penalty with the new update; I do not know the cause of this or whether the fps_test=3 bug could be causing it. But their test setup is very different than mine - a GeForce 9400 on a big screen, which really tests shading power. My setup (an 8800 on a small screen) tests vertex throughput, since that has been my main concern with NV drivers.

My suggestion is to use --fps_test=2 if you want to differential 10.6.2 vs. 10.6.3. I'll try to run some additional bench-marks soon!

EDIT: Follow-up. I set the X-Plane 945 time demo to 2560 x 1024, 16x FSAA, and all shaders on (e.g. let's use some fill rate). I put the Cirrus jet on runway 8 at LOWI, then set paused forward full screen no HUD. In this configuration, I see these results:

Objects  10.5.8   10.6.3
none     85 fps   100 fps
a lot    46 fps   61 fps
tons     37 fps   42 fps

Note that in the "no objects" case the sim is fill-rate bound - in the other two it is vertex bound. So it looks to me like 10.6.3 is faster than 10.5.8 for both CPU use/object throughput and perhaps fill rate (or at least, fill-rate heavy cases don't appear to be worse).

* These extensions represent Apple and the graphics card company creating software interface to fully unlock the graphics card's abilities.

Weird Water

2010-03-19T11:42:00.003-04:00

If you look at funky pictures of X-Plane on line, a fair number of them will show incorrect water reflections. I am working on some bug fixes for the reflection code for 950. Bug fixes might not even be the right term. To understand the incorrect reflections, you have to understand what the water code can and cannot do.

The water reflection code renders a reflection based on a flat plane. This limitation comes from the mathematics of the algorithm - a compromise to have water reflections that run at "real-time" speeds. (Real-time is graphics nerd speak for 20-30 fps and not 1-2 fps.)

As it turns out, the Earth is not flat. So we can pick up a number of reflection "bugs", due to the limits of the approximation we are using:

Over very large distances, the flat plane is a bad approximation of a water surface. The flat plane simply can't be "right" everywhere for any large scene. This isn't a bug, it's a ceiling on our maximum quality - a design constraint.
If we have two water surfaces at different elevations (e.g. a river with a dam) we can't have our reflection plane match both. So some scenes may have wrong reflections with multi-level water. This too is a design constraint.
If our reflection plane is at the wrong height or the wrong slope, it is going to produce really weird results. The reflection plane being in the wrong place despite a small scene with one level of water - that'd be a bug.
There is an art to positioning the plane - if we have a large scene (so the round earth means there is no one perfect plane) some locations of the plane will look better than others.

Now one fall-out of all of this is that things are going to look better if water is really flat, which is not always the case (both for some parts of the global scenery with production errors and some third party scenery). Where the water is sloped or contains bumps, we hit the multi-level case where we should not and we face reflection plane placement problems.

Finally, if the scenery mesh contains slanted water, we're really going to be hosed - almost by definition if X-Plane uses a sane water reflection plane, it won't be sloped, and thus this sloped water is going to be unaligned with the reflection plane and produce something that looks really funky.

So my work on 950 is aimed at having X-Plane be less easily fooled by complex and incorrect scenes less often. (Note that X-Plane can't tell the difference between Norway, where we really have water at multiple elevations, and bad input data to MeshTool.)

Even with these fixes, sloped water is still going to look pretty strange (because it is strange). And even with these fixes, multi-level water will still have its reflections approximated at best. But hopefully the visuals from the sim will be less jittery while flying over tricky DSFs.

I'm hoping we'll have a beta 2 in the next week or two.

Musings on CSLs

2010-03-15T12:51:00.002-04:00

Now that Wade has XSquawkBox 1.0.3 out, I've been thinking about CSLs - that is, the collections of simplified airplanes that XSquawkBox uses to draw the other users. The CSL system was invented back in the days of X-Plane 6, and it's getting a bit long in the tooth. You can't use OBJ8 files, and it doesn't understand a lot of the modern rendering tricks that authors use with the standard tool chain.

Plane-Maker has advanced quite a bit since then too - to make the original CSL, I had to create a special one-off hacked build of Plane-Maker to export aircraft as OBJs. This capability is now built into Plane-Maker, works a lot better, and even supports animation.

X-Plane now exports a native OBJ drawing interface to plugins. Besides giving plugins access to the fully optimized native OBJ draw code, this also means that plugins can draw objects with per-pixel lighting.

One more piece of the puzzle: in France Austin announced that we were working on a new ATC engine. One goal of this new engine is to provide ATC to the AI planes, as well as your plane, so that the other aircraft interact seamlessly in one simulated environment. (In X-Plane 9, ATC only directs you, and the AI are rogue planes that try not to buzz you when you're on the runway.)

This makes me wonder: should there be a next-gen CSL format that is shared between X-Plane and third parties, based on X-Plane doing the rendering work?

Best. Beta. Ever.

2010-03-14T21:04:00.003-04:00

Wade just cut the final build for XSquawkBox 1.0.3, and of all of the betas I have been involved in, this was the best one ever. I say this because Wade ran the entire beta and fixed pretty much all of the bugs without me! That is to say, Wade made 1.0.3 happen. So huge thanks to Wade for making a new and much needed XSquawkBox version possible.

Here are some of the features:

Automatic download and update of the server list.
Dual VoIP radios.
Proxy client support for users with multiple copies of X-Plane for multiple views.
A ton of work on the UI - a lot of little things add up to make a much more mature, usable client.

Now if only I had time to fly on VATSIM...

New Toys

2010-03-14T14:06:00.002-04:00

This isn't supposed to be a coding blog, but users do ask about DirectX vs. OpenGL, or sometimes start fights in the forums about which is better (and yes, my dad can beat up your dad!). In past posts I have tried to explain the relationship between OpenGL and DirectX and the effect of OpenGL versions on X-Plane.

At the Game Developers Conference 2010 OpenGL 4.0 was announced, and it looks to me like the released the OpenGL 3.3 specs at almost exactly the same time. So...is there anything interesting here?

A Quick Response

In understanding OpenGL 4.0, let's keep in mind how OpenGL works: OpenGL gains new capabilities by extensions. This is like a new item appearing on a menu at your favorite restaurant. Today we have two new specials: pickles in cream sauce, and fried potatoes. Fortunately, you don't have to order everything on the menu.

So what is OpenGL 4.0? It's a collection of extensions: if an implementation has all of them it can call itself 4.0. An application might not care. If we only want 2 of the 4 extensions, we're just going to look for those 2 extensions, not sweat what "version number" we have.

Now go back to OpenGL 3.0, and DirectX 10. When DX10 and the GeForce 8800 came out, nVidia published a series of OpenGL extensions that allowed OpenGL applications to use "cool DirectX 10 tricks". The problem was: the extensions were all NVidia specific tricks. After a fairly long time, OpenGL's architectural review board (ARB) picked up the specs, and eventually most of them made it into OpenGL 3.0 and 3.1. The process was very slow and very drawn out, with some of these "cool DirectX 10 tricks" only making it into "official" OpenGL now.

If there were OpenGL extensions for DirectX 10, who cares that the ARB was so slow to adopt these standards proposed by NVidia? Well, I do. If NVidia proposes an extension and then ATI proposes a different extension and the ARB doesn't come up with a unified official extension, then application like X-Plane have to have different code for different video cards. Our work-load doubles, and we can only put in half as many new cool features. Applications like X-Plane depend on unity among the vendors, via the ARB making "official" extensions.

So the most interesting thing about OpenGL 4.0 is how quickly they* made official ARB extensions for OpenGL that match DirectX 11's capabilities. (NVidia hasn't even managed to ship a DirectX 11 card yet, ATI's HD5000 series has only been out for a few months, and OpenGL already has a spec.) OpenGL 4.0 exposes pretty much everything that is interesting in DirectX 11. By having official ARB extensions, developers like Laminar Research now know how we will take advantage of these new cards as we plan new features.

Things I Like

So are any of the new OpenGL 3.3 and 4.0 capabilities interesting? Well, there are three I like:

Dual-source blending. It is way beyond this blog to explain what this is or why anyone would care, and it won't show up as a new OBJ ATTRibute or anything. But this extension does make it possible to optimize some bottlenecks in the internal rendering engine.
Instancing. Instancing is the ability to draw a mesh more than one time (with slight variants in each copy) with only one instruction to the graphics card. Since many games (like X-Plane) are limited in their ability to use the CPU to talk to the graphics card (we are "CPU bound" when rendering) the ability to ask for more work with fewer requests is a huge win.
There are a number of different ways to program "instancing" with OpenGL, but this particular extension is the one we prefer. It is not available on NVidia cards right now. So it's nice to see it make it into the core spec - this is a signal that this particular draw path is considered important and will get attention.
The biggest feature in OpenGL 4.0 (and DirectX 11) is tessellation. Tessellation is the ability for the graphics card to turn a crude mesh with a few triangles into a detailed mesh with lots of triangles. You can see ATI demoing this capability here.

There are a lot of other extensions that make up OpenGL 3.3 and 4.0 but those are the big three for us.

* who is "they " for OpenGL? Well, it's the architectural review board (ARB) and the Khronos group, but in practice these groups are made up of employees from NVidia, ATI, Apple, Intel, and other companies, so it's really a collective of people involved in OpenGL use. There's a lot of input from hardware vendors, but if you read the OpenGL extensions, you'll sometimes see game development studios get involved; Transgaming and Blizzard show up every now and then.

I Feel Manipulated

2010-03-10T12:02:00.002-05:00

Tom has a new video on youtube of his just finished Falco. The video shows what screen-shots cannot: that the mouse interactions on the plane are really well crafted.

If you're just discovering X-Plane (or just discovering that X-Plane's 3-d cockpits can be very interactive), here's X-Plane's "raw" capabilities for manipulation:

The simplest manipulations are based on mapping the mouse from the 3-d cockpit back to the 2-d panel. This can only be done when the 3-d cockpit is textured using a piece of 2-d panel. This is the oldest way to make a clickable cockpit in X-Plane, dating back to the original X-Plane 3-d cockpits. The advantage of this method is that it's very easy to set up; the disadvantage is that the mouse click gestures tend to be "flat" in their operation.
As Tom's plane demonstrates, you can manipulate just about any dataref or command via a drag along a specific axis. Axes are subject to animation, so there's a lot of potential for "grabbing" things with this interface.
X-Plane also supports direct "click" manipulation - this can be handy for buttons where you don't want to require the user to move the mouse around. There are several types of click manipulation.

Click and drag manipulations can be tied into the plugin system - your plugin sees a manipulation as a change to a plugin-created dataref. This makes it possible to create almost any imaginable mouse effect. If you don't want to write a plugin, you can still write up the manipulators to any of X-Plane's datarefs (there are thousands) or commands (we're getting up toward the 1000 mark on these too).

To create manipulators on your cockpit, you can use the latest plugin for AC3D. A manipulator is a property on a mesh within your object - each mesh can have its own manipulation with its own properties.

X-Plane does not have an IK solver. Rather, movement of "stuff" in your cockpit is indirect.

Your manipulator changes a dataref as the user drags along an axis.
The dataref change shows as an animation on your mesh.

Fortunately, ac3d has a "Guess" button for the axis manipulators. If you set a mesh to be manipulated by dragging along an axis, the guess button will examine your animations and suggest an axis that will create the most "natural" looking animation for the manipulation. For example, if you have a throttle handle that rotates, the guess button will provide a drag axis perpendicular to the throttle (to push the levers); if you have a throttle lever that pushes, the guess button will make a drag axis that runs along the lever.

Conformance Test

2010-03-08T21:47:00.002-05:00

I've been working on a conformance test for X-Plane. The idea is simple, and not at all mine: X-Plane 945 can output a series of test images that are the same on each run. The images cover a variety of rendering conditions. If a video driver is broken, the images will be corrupted.

You can learn more about how this works here: I am working on the 945 timedemo tarball now.

The main driver for this is to help NVidia, ATI, and Apple to integrate X-Plane into their dedicated testing. With X-Plane as part of their test systems, they can catch driver bugs the easy way - the day after the code is changed, rather than months later after a series of angry web posts. X-plane 945 includes a number of new features as part of its framerate test to help with this process.

My hope is that this will benefit users (who will see less bugs) and the driver writers (who can get feedback on code changes in a uniform and reproducible manner). Here are the eight images in the sample conformance test I wrote, based on the LOWI custom airport scenery.

Plugin-Drawn Objects Do Not Exist

2010-03-06T23:24:00.000-05:00

Version 2.0 of the plugin API (available in all versions of X-Plane 9) introduces three new routines that, for the first time, allow plugins to work with OBJs.

XPLMLoadObject and XPLMUnloadObject load an OBJ file (a model mesh) into memory, and then purge it when done. That part most users understand. The routine that causes confusion is XPLMDrawObjects. When you draw an OBJ with XPLMDrawObjects, you are not creating anything long-lasting or persistent in the world. Your object will be visible for one frame on screen, and then will disappear unless your draw it again. Your object is not part of any of the physics calculations.

To put this in perspective: when you make a new window using the Widgets API, the window is persistent - it exists until (1) you delete it or (2) your plugin is unloaded for some reason. You don't have to do anything per frame to "maintain" the window - you make it and it exists.

Objects are not like that. You cannot make an object "exist" in the X-Plane world - you can only draw it once per frame using the drawing callbacks. Essentially the draw-objects API is a lower level API.

Building a Layered System

Plugins operate in a layered environment, with lower level code on the bottom and your plugin at the top. The layer stack might only be 2 layers deep (XPLM on the bottom, plugin on top), or there might be several layers. Consider XSquawkBox:

The UI is drawn using the XPWidgets API. The XPWidgets API gets its drawing from the XPUIGraphics API, and the XPUIGraphics API changes OpenGL state using the XPLMGraphics API. So we've built up a layered system: basic OpenGL supports drawing, drawing supports user interface, user interface supports the plugin.
Similarly, multiplayer is done using a library that isn't part of the basic plugin system (but is open source): libXplaneMP. So here the XPLM supports drawing airplanes, libXplaneMP uses that to create a full multiplayer API, then XSquawkBox uses it.

The alternative to a layered system would be a "monolithic" one. Under a monolithic system, the only API for airplanes would be libXplaneMP, and the only way to create user interface would be widgets. Sandy and I usually prefer the layered approach because it provides a lot more flexibility. If you like widgets, great, use them. If not, no problem - roll your own on top of XPLMDisplay.

The Plugin System Is a Foundation

When Sandy and I cannot provide all of the layers, we have a strong bias toward providing the bottom layer, for an obvious reason: if the bottom layer isn't in the plugin system, it may be impossible for anyone else to create it. So typically if we have a choice between a high level vs. low level API, we'll put the low level API in first.

This is precisely what is happening with object drawing - we have the low level API ("draw an object") but not the high level one ("create an object in the scenery system"). Since we have provided the lowest level, it is possible to code persistent objects in your plugin by layering on top of our API. By comparison, had we only provided "create an object" it would be pretty close to impossible to draw an object for one frame - if you didn't want a scenery object, the API would be inflexible and useless.

On the Road a Lot

2010-03-06T11:16:00.003-05:00

I've been on the road a lot for work, so my apologies to everyone whose email I am sitting on. Most of my time these days is being spent on new next-gen tech. But there are a few things I'm hoping to get done in the short term:

Cut a new time-demo test. This might seem like a low priority item, but it's not. Apple, ATI and NVidia all run continuous automatic tests of their video drivers, with many applications and games. They have rooms full of computers that continuously run through 3 minute sections of Quake and Call of Duty, etc. If they introduce a driver bug while doing new development, these machines catch the problem immediately.
The new time demo (based on 945) will have a number of features to make X-Plane a more useful test case. If we can make X-Plane into a test case, then they can catch bugs early, and that means you don't have to see them.
Bring WED 1.1 to beta. The only thing holding it back is the DSF exporter, and I did have about two hours to poke at it last week. I'm hoping if I can find just a few more hours, I can finish off the exporter.
Examine 950 bugs. I have half a dozen bug reports against 950 beta 1. 950 will be a small beta but also a slow one, because Austin and I have a lot of other things on our plates. If you haven't heard back from me on a bug report, probably it's still on my to-do list.

We'll see how much of that I can get to in the next week.

WorldEditor Export: File a Bug!

2010-03-02T21:08:00.000-05:00

There's basically one reason why WorldEditor developer preview 2 is a "developer preview" and not a real beta: the DSF overlay export code isn't complete.

The problem is that, unlike an airport, an overlay has to be "cut" to the DSF tile boundaries. This is made slightly tricky by the fact that the overlay can have (1) bezier curved segments and (2) a UV map on those segments. My existing toolkit of polygon editing routines doesn't handle this case yet.

I have no idea when I will have time to complete this code. It is the number one piece of code that, if I had a quiet single afternoon of unexpected time to code, I'd pound it out. If I were stuck in an airport with my laptop, I'd pound it out. It should give you some idea of how busy things are that it still isn't done.

In the meantime, there is the scenery tools bugbase. By filing a bug, your issue won't get lost even if it's a while before I get to it.

A few quick rants about the bug base:

Most likely the first thing I'll do when I do get to your bug is just ask you for more info. Consider the bug to be as much a business card so I can make contact as well as a bug report.
Some bugs may get kicked out.
Do not file X-Plane bugs in the scenery tools bug base! The scenery tools bug base is not where we store sim bugs.

Do not bother to ask for direct bug base access for X-Plane itself. You cannot have it. The ratio of submitted "bugs" for X-Plane to actual bugs is at least 10:1. That is, 90% of you think that you should file a bug when you have a tech support question. Now you might be in that 10% (particularly if you've made it all the way down to this blog post), but we can't set up open infrastructure with those numbers. My hope is that the scenery tools are self-selecting to the point where people who are using developer-preview tools know what a bug report is.

Another Reason To Use a Few Big Textures

2010-03-02T13:00:00.004-05:00

The file loading code in 950 beta 1 for Windows is slower than 945. Sometimes. This will be "fixed" in beta 2. Here's what happened:

The scenery system uses a number of small files. .ter files, multiple images, .objs, etc. This didn't seem like a problem at first, and having everything in separate text files makes it easier to take apart a scenery pack and see what's going on.

The problem is that as computers get bigger and faster, rather than a scenery pack growing bigger files, they are growing more files. The maximum texture size has doubled from 1024x1024 to 2048x2048. But with paged orthophotos, multicore, and a lot of VRAM, you could easily build a scenery pack with 10,000 images per DSF.

That's exactly what people are doing, and the problem is that loading all of those tiny files is slow. Your hard drive is the ultimate example of "cheaper by the dozen" - it can load a single huge file at a high sustained data rate. But the combination of opening and closing files and jumping between them is horribly inefficient. 10,000 tiny .ter files is a hard drive's worse nightmare.

In 950 beta 1 I tried to rewrite part of the low level file code to be quicker on Windows. It appeared to run 20% faster on my test of the LOWI demo area, so I left it in beta 1, only to find out later that it was about 100% slower on huge orthophoto scenery packs. I will be removing these "optimizations" in beta 2 to get back to the same speed we had before. (None of this affects Mac/Linux - the change was only for Windows.)

The long term solution (which we may have some day) is to have some kind of "packing" format to bundle up a number of small files so that X-Plane can read them more efficiently. An uncompressed zip file (that is, a zip where the actual contents aren't compressed, just strung together) is one possible candidate - it would be easy for authors to work with and get the job done.

In the short term, for 950 beta 2, I am experimenting with code that loads only a fraction of the paged orthophoto textures ahead of time - this means that some (hopefully far away part) of the scenery will be "gray" until loaded, but the load time could be cut in half.

There is one thing you can do if you are making an orthophoto scenery pack: use the biggest textures you can. Not only is it good from a rendering perspective (fewer, larger textures means less CPU work telling the video card "it's time to change textures") but it's good for loading too - fewer larger textures means fewer, larger total files, which is good for your hard disk.

(Thanks to Cam and Eric for doing heavy performance testing on some of the 950 beta builds!)