Blog

The Future of Facades

Sergio and I were discussing the future of facades today. Facades are DSF polygons that are extruded into buildings by pushing up the polygon into a roof and texturing the roof and walls from a single texture using some simple formulas. The rules for facades are very simple – we originally thought them up for the purpose of creating buildings that precisely fit a city grid no matter what the block spacing.

The problem with facades is that the rules make very simple buildings – especially the roofs. So we want more powerful facades and the question becomes: how best to do this? There are two possibilities and I mention them here because they underscore what I think is the largest overarching design decision when creating a flight simulator scenery system.

1. We could make the facade builder in X-Plane smarter (write new rules).
2. We could write a stand-alone tool that converts the DSF polygons (plus a rule file) into OBJs that are then placed directly into the overlay.

This second strategy would turn the facade from a type of scenery element into a tool for making OBJs. We would be “pre-compiling” our facades.

Here are some of the considerations:

SPACE VS SPEED

Precompiling primitives is a space-vs-speed trade-off. For any given algorithm, it’s usually faster to pre-build the entities and load them from disk than to build them in the sim. But pre-building means more files on disk, meaning bigger downloads, more DVDs, etc. Building up buildings from facades inside X-Plane is actually a form of compression.

EASE OF DEVELOPMENT

This is one criteria where I think pre-compiling scenery is a clear win: it’s easier to build a stand-alone facade-to-OBJ converter than to implement it inside X-Plane. X-Plane is a relatively unfriendly place to build scenery algorithms because it’s busy being a flight sim.

STABILITY VS UPGRADABILITY

If we make OBJs out of facades using a tool, the objects will look the same even if we create a new version of the tool. This is good in that it means that custom scenery won’t change how it looks, but it is also a limitation because improvements to facade technology require rebuilding a lot of objects to take effect.

(Another aspect of this: if the objects made from the tool use a texture, that texture can’t have its shape changed even if we make new rules, because some objects will be on users machines that were built with the old rules.)

X-Plane mostly errs on the side of pre-building scenery, and this is the one area where we really take it on the chin for that decision: the inability to easily create a new composite look from changes to some parts of the scenery. (Airports that don’t cause grass to appear under them is an example of this.)

Perhaps some good questions for weighing these options are:

1. Would an author care whether the facade looks exactly the same in the future?
2. Are there enhancements coming along in this technological area that we would not want to miss out on for older scenery?

OTHER CONSIDERATIONS

Information loss: when we turn a facade into an object, the original polygon information is lost. Is it important that we ship the actual base polygons that make up buildings, or are the OBJs that represent them good enough?

Contextual Information: often we know more about a given situation when making scenery than when displaying it. Could we do better at building up a facade inside the sim (where we have context from other scenery packages), or when creating the sim (where we have a much larger dataset)?

Posted in Development, File Formats, Scenery, Tools by | 1 Comment

Where To Get Help

Just a gentle reminder: if you are having problems with X-Plane (especially the installer), please do not post a comment to this blog. Instead email Randy and Jack, or tech support guys, at info at x-plane dot com. This is the official way to get tech support, and they will work hard to make sure you can use X-Plane.

Comments Off on Where To Get Help

Polygons Part 2 – Real World vs Custom

In a previous post I discussed polygons, how they can be used, and a little bit about how they relate to X-Plane 850 and the new apt.dat system. I have been working on some demo scenery that will make this all clear, but the great is the enemy of the good, so rather than wait I’ll post more on this now and get the demos done as soon as I can.

There are essentially two ways to get at the new polygon code: via the apt.dat system or via an overlay DSF. When should you use apt.dat and when should you use an overlay DSF?

  • If you are trying to model something that is directly in the apt.dat spec, use an apt.dat file. For example, use apt.dat if you are making blue taxiway lights.
  • Use a custom overlay DSF if you are modeling outside an airport. (Do not make “fake” airports to use apt.dat features.)
  • If you need a custom look not supported by apt.dat, use an overlay DSF – it’s the only way.
  • Use a custom overlay DSF if you are modeling something that isn’t found in an airport, even if it looks similar. (For example, if you want blue lights to model some unique architecture in an airport, do not use apt.dat taxiway lights – your lights may look the same, but they are not the same!)

This last point is important: do not “abuse” the definitions of apt.dat files just because they look similar.

There are essentially two kinds of features in the scenery system:

  1. Features that do not change how they look, ever. For example, we do not change the way a textured triangle looks in an OBJ file.
  2. Features that are designed to model the real world. Over time, we change them to look more like the real world. For example, approach lights have changed a lot in 850 to look more like the real world ones.

This second type of feature is the one where I issue caution: if a feature in apt.dat or the sim is meant to emulate how the real world looks, we will change how it looks to improve rendering! This is why it is important not to use apt.dat feature for purposes other than they were intended for. It might be that in X-Plane 8.50 the blue taxi lights look just like some other feature you want to code. But in a future version, we might make them more realistic for an airport and they will look worse for your other application. By using apt.dat features only for their true purpose, you help us ensure that our changes to the base artwork make scenery better, not worse.

(This division of all scenery features between ones that are “stable” and ones that are “based on the real world” can also be seen in most parts of the sim. In particular, the flight model is designed with a “based on the real world” philosophy, a very controversial decision I’ll have to blog about some other time.)

Next: fixing airport terrain with polygons.

Posted in File Formats, Scenery by | Comments Off on Polygons Part 2 – Real World vs Custom

I’m not dead! (Just coding tools)

I realized when I saw the “view stats” of 0 that I haven’t posted in maybe two weeks! Nothing’s wrong, I’ve just been busy coding scenery tools since 860 went into RC. I’ll post something useful here soon!

Just a quick random note: the maximum number of vertices in a DSF polygon is 65,535 vertices. If you have a polygon with more sides, you’ll need to simplify or subdivide it.

I would also add that the speed with which forests are built up is related ot the polygon complexity (as well as the total trees made). The algorithm is pretty fast, but you may want to consider a simplification algorithm that removes sides, making the polygon smaller, if the total error is less than a few meters (or whatever your tree spacing is), nuke the side!

Posted in File Formats by | Comments Off on I’m not dead! (Just coding tools)

Popup Blockers and the Installer

For a while we’ve been getting the rare report from a user that our installer won’t download – usually it dies mid-download on a given file.

(Our servers transfer a complete 600 MB demo copy of X-Plane once every 8 minutes, all the time. So if we get a report of a problem from one isolated user, it’s almost always specific to the user. Systemic problems like a bad server generate a ton of email.)

One user stuck with us through some via-email debugging and we finally figured out one of the causes of failed downloads: popup blockers!

The X-Plane installer is built around simple off-the-shelf technology where possible. In particular, files are zipped and sent via http. This means we’re using openly available existing standards, and we get to leverage free code. (The biggest win is being able to use “plain old apache” for serving the installer.)

To the operating system and any firewalls involved, the X-Plane installer doesn’t look that different from a web browser. It goes to a web server and requests a big pile of files, a few at a time.

It turns out some popup blockers will detect patterns in URLs and automatically substitute the web content! So we go out asking for an object called com_120_60_1.obj.zip and the popup blocker decides that (perhaps because it’s a zip file and has 120_60 in it) the file shouldn’t be made available. It substitutes a 1-pixel black GIF file that the browser can show inconspicuously..

Of course, that one-pixel black file doesn’t look anything like a zip file – when our installer gets it, the installer has a fit.

This bug was a mystery before – what would cause our servers to send just one user a tiny GIF file, and only in one case. Now that we know that the software is designed to zap web advertising, it makes perfect sense.

Posted in Development by | 4 Comments

Now We Are 3

With X-Plane 860, we now mark the X-Plane executable as being capable of using 3 GB of virtual memory on Windows. This means that if your copy of Windows can support large address spaces and you have a powerful enough PC, you can now use more add-ons. (Mac and Linux have always gone to 3 GB by default.)

You can read more about setting Windows up to handle large address spaces here. Please don’t try this if you don’t know what you’re doing, and please don’t contact our tech support if you destroy your copy of Windows — we can’t support the whole OS.

Please note that this change does not improve the hardware capabilities of your computer – it only enables X-Plane and Windows to take full advantage of what you have. You will not see a performance boost because of this.

1 Comment

Airport Flattening, the Untold Story

I’ve been meaning to write this blog entry for about a year now. X-Plane 8 allows the airport surface area to be sloped. Here’s some of the back story and details.

Back when Austin and I were doing the design work for teh X-Plane 8 scenery system, we made a decision to allow sloped runways. The issue is that flattening the airport area requires the sim to edit the mesh on the fly, something we wanted to avoid.

(X-Plane’s scenery system is based on removing the editing of scenery from the sim itself…”X-Plane is not a GIS”. I did some slides on this once, I’ll try to post them soon.)

Instead we decided to simply drape the airports over the terrain, no matter how it was built. We figured that the sim’s engine could handle this (as it turned out, there were bugs that were fixed in the 8.20 patch) and in real life runways are often quite sloped!

Unfortunately when theory meets practice, things can get ugly…the biggest problem we saw was that in the original set of DSFs, the underlying terrain was very bumpy, and the smoothness requirements for a plane to take off are very high. (Flattening is also necessary to match the ground height with other sims for online flight.)

So we retrofitted the X-Plane engine with terrain flattening for airports. The flattening engine is meant as a last resort, to get absolute flatness and repair an already-flattened DSF. Its goal is not visual quality, but rather speed — that is, we can’t take 10 minutes analyzing the DSF each time we load one, or the sim will freeze pretty badly. (If this requirement that the flattener be fast ever goes away, we could do a much nicer job of flattening.)

The current flattening engine has two unfortunate properties designed to keep it fast:
– It flattens an area that is larger than the airport surface area (it rounds up) and
– It flattens vertices that are in the flattening area, not whole triangles.

The first limitation means that it may crush mountains around the airport, and is not appropriate for airports that are embedded in complex, hilly terrain.

The second limitation needs more examination. If a mesh triangle is partly inside the flattening area and partly outside, then the triangle is not flattened – one vertex is moved, and the others aren’t, which cause it to be sloped.


In these pictures, the blue lights represent the airport area perimeter, but the red lights show the full area that is flattened. I have artificially set the airport elevation much higher than surrounding terrain, to make the flattening obvious. Notice how some triangles become highly sloped!

When we make the global base scenery, we use the default airports from Robin’s database. So even if you do not want to submit your custom airport layout to Robin’s database, consider submitting some kind of layout to Robin. If an airport is present in the default scenery, then the area will be pre-flattened, which makes the sim’s flattening both work better and maybe even unnecessary.

Also, you can use the 130 code in a custom airport area to increase the airport boundaries, increasing the amount of flattening. But this is a mixed blessing – as you can see the mechanism is very imprecise. If you do use a 130 code in a layout and you submit the layout to Robin, please remove any 130 boundaries that have been set to a large area to flatten an airport.

Posted in Development, Scenery by | Comments Off on Airport Flattening, the Untold Story

So Why is WorldMaker Still Around?

I realize this blog post will probably just inflame a bunch of email about how the scenery tools aren’t available yet, but I’ll answer the question and take the flames, because it’s a fair criticism and scenery tools are a fair feature request.

The long term direction of scenery tools is this:

  • Scenery tools will be separate from the X-Plane distribution, free, and open source. (This separation allows us to post scenery tool source without posting X-Plane source, and to use GPL code in the scenery tools.)
  • A few very basic editing functions (like adding nav-aids) are integrated into the sim to allow instructors to correct nav data during a training session.
  • WorldMaker therefore is no longer a scenery editor at all.

So why haven’t we killed it? We’ve been tempted to. But it will serve a long term purpose in the scenery tools ecosystem: it will be a small-footprint 3-d scenery previewer.

Because the scenery tools don’t use X-Plane code, the scenery tools will have two limits to their previewing capabilities:

  1. There is always the risk that with different code, the tools will preview scenery differently from X-Plane’s final render.
  2. Because the scenery tools don’t use X-Plane’s renderer, we basically have to rewrite viewing code in the scenery tools from scratch. That’s a lot of code, so for a while the preview in the tools will be limited.

Running X-Plane and the scenery tools at the same time isn’t a great option – since X-Plane loads a lot of scenery, and a weather model, and a plane, and then tries to run at max fps, it tends to be a bit of a pig in terms of system resources. WorldMaker will be a viewer that can reload your scenery quickly so you can have a 3-d view of what your end result will look like that will match X-Plane.

Posted in Tools by | 3 Comments

It Ain’t Over ‘Til It’s Over

Just a gentle reminder: please do not consider anything in a beta to be final!

By this I mean: there is a risk that file formats that are new to the current sim (860) could further change during the current (860) beta run.

So…if you are working on scenery that depends on new 860 features, please do not ship your final scenery until 860 is finished! This way you can be sure you’re compatible with the final formats.

If your scenery uses 850 features and 860 breaks them, please report a bug, as 860 should handle any legal scenery that 850 handles.

(This goes for plugin datarefs too!)

Posted in Scenery by | Comments Off on It Ain’t Over ‘Til It’s Over

Logitech Joystick – Framerate Fix

I found the reason for frame-rate loss for Logitech sticks…everything in this entry is Mac specific.

X-Plane has (for a long time) done a rather poor job of parsing the HID descriptors that
the driver provides for USB joysticks on OS X. However it turns out that in the case of Logitech, after we found the 4 axes the joystick usually has (pitch, roll, yaw and throttle) we then went on to misparse a bunch of strange stuff at the end of the stick as more axes. It turns out that reading those axes causing some kind of huge framerate loss. I don’t fully understand this, but given the HID spec I’ve seen I’m not hugely surprised.

Why is this x86-Mac specific? I don’t know! Why is this so much worse in 860? Well, in 860 we raised the number of axes from 6 to 8. With more axis slots, we tried to read more incorrect parts of the logitech stick, for more fps loss.

The solution is one that’s been a long time coming: I’ve rewritten a bit of our Mac HID-parsing code to do a better job of figuring out what’s a joystick element and what’s not.

The bad news is: for the next few betas there may be some broken joysticks. If you have a joystick and it stops working in the next beta, please file a bug and include as much specific info about your joystick as you can.

The good news is: I think we will get almost all of the fps back on x86 Macs – Logitech users will not need to get new sticks.

A side effect is that we should no longer have “dead” slots – that is, buttons and axes that didn’t do anything. This should allow you to use more of your X-52 if you have one.

5 Comments