Tools - it'll get worse before it gets better

Here are some musings on the scenery tool situation...first the bad news:

I think 850 will ship with no WorldMaker at all. WorldMaker 8 cannot edit terrain, airport editing is being moved to a separate program, and navaids and fixes are now edited inside X-Plane.

The new scenery tool will probably not be ready by 850 beta 1. I hope to have the first beta of the scenery tool available during the X-Plane 850 beta process - but the scenery tool beta may go on longer.

I am considering 850 airport editing to be higher priority than overlay editing - Jonathan Harris already has a cross-platform overlay editor, but there are no 850 apt.dat editors, so I may release the scenery tool with airports first, then put overlays in later, to get people started with the new airport technology.

Finally the new editor will not be able to save older airport layouts. It will be able to read them, but they will be converted and saved in the new format. If you need to edit old layouts I suggest you use TaxiDraw.

So is there any good news? Well, the main work on the apt.dat format is done, so we'll have a ton of new features for modeling detailed airports. Bezier curved pavement, taxilines, signs
specified by their text, and a whole new lighting system.

Also once 850 ships, scenery tools will be my number one top priority, so I think that while the first few betas of the new scenery tool will be painful and awkward (as we get the basic UI and usability features in place while simultaneously trying to fix X-Plane bugs) I think that we'll pick up a lot of momentum once 850 ships.

Also one note on platforms: the new scenery tool will ship for Mac first, then Windows. I don't have specific plans for Linux, but how soon it happens dependes partly on who I can enlist to help with a port (I don't have a Linux box) and partly on whether it works under WINE (I suspect it may). The whole project will be open-source too so anyone who wants to try to get it working on system X will be able to. With the first beta I should have a "real" source distro, as much as is possible given the development tools I'm using.

It's supposed to just work!

X-Plane 8.50 will introduce a new version of the apt.dat file, but it is also designed to support old apt.dat files without any changes. So if you download the 850 beta (not out yet, but soon!) and an apt.dat file that used to work stops working, that's a bug!

If you hit this case, please do not change your apt.dat file to work around the problem - instead please file a bug. A link to our bug reporter can be found on the bottom of this page.

Also OS X 10.4.7 is out and we've received some reports of crashes. So far these appear to be related to custom scenery packages using ENV. If you remove custom scenery and the crash goes away, then please try to identify which scenery package in particular crashes (ideally which ENV file), and then file a bug with that specific package. If we can get a specific package that causes the problem, we'll be able to fix this a lot quicker.

Taxi Signs

Starting with X-Plane 850 (not quite beta yet), the apt.dat file will allow you to build taxiway signs into airport layouts. We're using a simplified version of the sign-specification language from FlightGear (which shares apt.dat data) - you can read the on-going spec/discussion here.

The syntax isn't final, but here's a rough idea of what it will look like:

20 42.363178 -71.012238 110.0 {@R}22R-4L{@@}4L-22R
and here's an example sign (not the same as the apt.dat example listed above):

The basic idea is: a sign has a latitude and logitude location and a heading (in this case 110, so the front of the sign is visible when parked to the east). The text of the sign is plain text - special characters are put in braces {} and special formatting starts with a @ character. @R turns the sign red, @Y yellow, etc. and @@ changes to the back side of the sign. Arrows are specified with a ^ followed by the direction, so a left-downward arrow is ^ld.

SPAM - the cure is worse than the disease

Well, the disease is pretty bad too. I spend more time than I'd like to admit to Austin deleting ads for blue pills, credit cards, and dirty websites on the XSquawkBox forums, this bog, my in-box, etc.

Unfortunately one of the side effects of all the spam floating around out there is that anti-spam software is starting to defeat normal communications.

Email is the primary means of communications within Laminar Research and we periodically lose valuable development time when one of us ends up black-listed on an anti-spam list.

Recently I've also been hitting cases where I either can't return an email from a user at all (they can email me but I get spam-filtered when I reply) or the reply requires me to authenticate myself in some way (which takes away from the total volume of email I can answer and makes everyone's responses slower).

So if you have emailed me about scenery and heard nothing it could be my horribly clogged in-box, which is months behind, but it could also be that I emailed you but was a casualty of the war on spam.

The little things...

It's the little things that often take the longest to program, or at least make developing a feature take longer than expected. But I think flight simulation has reached the point where the details are what matters.

Trivial example: if we have a runway that's shorter than 9000 feet and about an even multiple of 1000 feet then the distance-remaining signs (every 1000 feet) from the two directions may be too close to each other or even overlap. X-Plane 850 will detect this case and generate a single two-sided distance-remaining sign (like real life), so that the signs don't obscure each other.

If the runway length is such that merging the signs would create too much error in their measurement, or we only have a sign in one direction, there is no merge.

The 850 airport code is full of tiny details like this.

Cleaning up the house

In Austin's recent post to the news list he mentioned that we'd cleaned up a lot of code internally, making X-Plane tighter, leaner and meaner. But is this really a feature, something that you would care about as a user? I can think of at least 3 ways it directly affects the sim.

One difference between X-Plane and most other software is that you can email the authors and ask for a new feature and possibly see it within a few months. But when we evaluate feature requests, time to develop the feature is a big consideration. Having a cleaner code base means we can put new features in faster, which means everyone is a little more likely to get something new. (Of course, we can't do every feature that is requested...this only improves the odds a little.)

Similarly, X-Plane is a subscription - so the amount of improvement you see across a version of X-Plane is directly affected by our ability to put new stuff in quickly. I've worked at companies with a range of policies toward code clean-up, and I've found that Austin's policy of "constantly keep your house in order" (with major code cleanup on a monthly, not yearly basis) results in us being able to get a lot of cool things done without being held back.

Finally one direct result of code cleanup is often performance. For example, under the old code we really had two rendering engines. One handled DSF and ENV scenery, and the other handled airports, superimposed on top of them. Each one knew how to draw a bunch of triangles. Each one knew how to decide whether triangles needed to be drawn. Each one knew how to check whether the plane was on top of some part of the scenery (e.g. a runway or the ground).

This was bad for two reasons: first, it meant we spent twice as long working on anything - once for airports, once for scenery, and second, the two engines were not equal. It turns out the DSF/ENV engine, which is newer and has had a lot more time spent on it can out-perform the old airport rendering engine. This was an issue for 840 but is an even bigger issue for 850, where we want to make airports much more realistic.

By merging thet two and using only our better engine for both, we not only clean up our code, but airports render faster immediately. I do not have final stats on this, but the speed improvement is variable - anywhere from as little as 10% faster to as much as 50% faster depending on the view angle, airport chosen, visibility, etc. So even if you end up turning off all of the new 850 visual features and go for speed, 850 should still be an improvement.

New Toys For 850

A DSF can place polygons (beaches, facade buildings, forests), points (objects), mesh patches (terrain) and vector networks (roads). Note that while there are only four geometric types in DSF, there are now six "graphics" types. The versatile DSF polygon can be a beach, buiding or forest depending on what type of text file the DSF links to. This gives us a way to expand X-Plane scenery and invent new tricks without changing the fundamental DSF file format.

A few new graphic types will be coming to X-Plane 850, all based on polygons:

• Draped polygons overlay the terrain with a texture - useful for making custom airport pavement or fixing some terrain in a city.
  
• A "string of objects" follows a linear path placing objects periodically - useful for putting down airport lights or putting a row of bushes between two farm fields.
• A "ground marking" type places a painted line on the ground - useful for airport markings, for example.

In all three cases, these tricks are available in the new apt.dat version 850 based on some predefinde types (a yellow taxiway line, green taxiway centerline lights, concrete apron pavement), but are also available in the DSF in a customizable manner. This will allow you to use these powerful techniques outside the airport environment or with custom artwork.

How Many Cessnas can fit on the head of a pin?

When is up really up? X-Plane has two choices when you try to build something that goes "up" in the scenery system:

• Up can mean straight up against gravity. For scenery far away, up is no longer parallel to up nearby because the Earth is round.
• Up can also mean up in the XYZ coordinate system. This is the same as up against gravity at the center of loaded scenery, but wrong for everywhere else.

So what does X-plane use? Well, it depends on what we're doing. Usually up against gravity is the "right thing to do", but often XYZ up is close enough and a lot faster, so we sometimes take that shortcut for frame-rate. Here's a rough breakdown:

• For DSF terrain meshes and objects, up means against gravity.
• For roads, forests and facades, up means XYZ up.

Now in X-Plane 850, we try to move scenery around the world rather than rebuild it. But 3-d stuff like roads and facades are only built very near the plane (which is very near the center of XYZ space), so generally speaking when a road, forest or facade is built, XYZ up is really going "XYZ" up. (If that didn't make sense, don't worry about it - my point is only that scenery shifts don't affect this discussion.)

X-Plane 850 will allow a number of 3-d definition-types to interact physically with the plane: objects can specify the surface type for their hard surfaces on a per-triangle basis (e.g. grass, concrete, asphalt). Facades can have hard walls or hard roofs, and segments of roads can be hard. (This will make it possible to land on the roads again IF we can apply these attributes to our definition files.)

So how many Cessnas can sit on the edge of a fence? Well, if that fence is straight up (and I mean "XYZ" up) then none. X-Plane checks for collisions and ground contact by looking straight down (XYZ down, not against gravity) to find what is below the plane. A truly vertical triangle has no width when seen from straight above, so the plane can never sit on it.

(Lest you worry about the imprecision of this, please note that when you are on top of something, the distance from your wheels to the geometry is 0 meters, so the error between the two "ups" is 0.)

When you are making an object, remember that the object is not facing XYZ up, but rather it is slanted based on the curvature of the earth. So a perfectly vertical wall might actually not be vertical and might thus work as a hard surface . Similarly an almost vertical wall might become vertical and not work. The safe thing to do: make sure that all hard surfaces are not even close to vertical. 45-degree slopes, etc. are okay though!

For a facade, the walls cannot be hard because they will always be perfectly vertical. This presents a problem if you want to make a fence that the plane can't pass through. One solution: use the angled roof feature of facades to curl the top of the fence in at a 45 degree angle. That segment of the fence won't be vertical and will cause the hard walls to work properly. (In fact, hard walls in facades will be provided in 850 specifically for this purpose. For a building, the walls are vertical and the roof can be hard.)

Why not make everything lit?

There are costs to every feature we put in X-Plane...the obvious ones include:

• The time to code the feature.
• The time to test the feature.
• The time to recode the feature if we ever rewrite the rendering engine (which we do fairly often to try to take advantage of the latest graphics technology).

There are also some less obvious costs:

• If a feature isn't used often, it's more likely to end up broken without anyone noticing, reducing the overall quality of X-Plane.
• We have to keep track of our use of graphics card resources. If we add a feature (like lighting) now, perhaps this will prevent us from reliably putting a new more improtant feature in later because some scenery may be using all of the card's resources.

For example, what if we discover that we can make crashing waves, but only on unlit beaches? If we never added lit beaches, we know this is safe. But if we do support it beaches, then perhaps there is some scenery out there for which the crashing waves won't work because we can't have both.

The moral of the story: laziness is good! Since every feature costs, there is sometimes an advantage to waiting until someone asks for a feature before coding it.

Should everything do everything?

You may have noticed: all of the "artwork types" (objects, terrain, roads, beaches, etc.) now do textures in almost the same way - with a TEXTURE command and a TEXTURE_LIT command. (Two notable exceptions: beaches and forests can't be lit yet. We haven't found a case where this is a goood idea but it may happen...nuclear accident anyone?)

The idea here is to unify aspects of all art files so that when future extensions come along, they can be used everywhere. For example, some day we will have textures whose choice is controlled by datarefs. When this happens, because every art file uses a similar mechanism to find textures, we can introduce commands not only in the terrain, but also in objects, facades, roads, etc. so that any type of art can be made seasonal.

This got me thinking about whether all aspects of every artwork type should be available in every file. I think the answer is...sometimes. For example, being able to use lit textures
everywhere is a good thing. But should it be legal to make hard polygons out of every art type? Definitely not every type. Terrain's "hardness" for example is decided inside the DSF, so the only question is "how bumpy should the ground be when it is hard". Objects let you control these things per polygon. But if we have hardness for a facade, how would we specify hardness? Perhaps just whether the roof is hard or not...

I think that X-Plane 8.50 will have more overlap in capabilities between the various types of 3-d "stuff" (beaches, objects, roads, etc.) but we still won't have 100% of all features in every file type. Some combinations just don't make sense.

A subtle change in blastpads

Two, actually...we'll see if these behaviors show up in beta...

This is runway 4L at KBOS, from Google Maps. Note that a taxiway travels behind runway 4L on top of the blastpad.

Now compare how these look in X-plane 840 and X-Plane 850..

In X-Plane 840, the blast pad goes over the taxiways. This is fixed for 850. However you can see that the author may have been expecting this effect - there's a lot of taxiway pavement put down around this junction. The new apt.dat format will alleviate this to some extent by allowing pavement to be shaped in arbitrary polygons, making overlapping no longer necessary.

A more subtle shift: note that the threshhold is not in the same place in 840 and 850. This is because in 840 the blastpad (like most of the runway) is built in square tiles. Since the runway is 150 feet wide, the blastpad is rounded to a mulitple of 150 feet long. In 850, the blast pad is chopped at the exact point, so the threshhold can be where it is supposed to be.