I wish WED looked like this

I get a fair number of emails where users send me a link and say "can you make X-Plane/WED look like this?" I'll beat you to the punch this week...I wish WED looked like this.

Unfortunately it probably never will for three reasons:

1. X-Plane's time to create the structures you see is slow enough that editing the real world in real-time would be difficult. We try to load things on another thread while you fly to help smooth this.
2. Our scenery creators do a lot of work to build the DSFs before you fly - minutes per DSF...again, from the time the raw data changes, a lot of computation happens.
3. We're trying to keep our tool set open source, but the X-Plane rendering code is closed source, so it would have to be rewritten (a huge task), e.g. WED would need an alternate editing engine.

(Of course if it was rewritten, it could be done so to fix points 1 & 2.)

Still, we must all dream. :-) :-)

Flat Shading is Evil (and other OBJ sins)

Almost two years ago, I posted this blog entry, pointing out that some legacy OBJ commands are, well, evil.

My inclusion of ATTR_poly_os in that blog post was a little strange - when used correctly, ATTR_poly_os is the right way to overlay decals on the ground, and it is fully supported. (The message is just, I suppose, that if you need a huge number for your poly_os, something is really wrong.)

Now ignoring ATTR_poly_os, you might notice that the AC3D plugin exports almost none of those dubious attributes. But what about flat shading? Flat shading isn't necessary, but you were allowed to use it.

So I came to my senses and modified the AC3D exporter - the exporter will now never use ATTR_shade_flat - instead it uses smooth shading and per-vertex normals, avoiding an unnecessary attribute no matter what you do in AC3D. 99.99% of the time this will yield fastest framerate?

Why wasn't the plugin always like this? I thought it was, and only discovered today that I hadn't finished this optimization.

RFC: Airport Vehicle System

I am interested in proposals for an airport-vehicle system in X-Plane. I will explain exactly what I am looking for, but first I must note the oddity of this request:

99.99% of the time, users give us too many implementation details on a feature request. Usually we want to know what you want, and not how you want it done. Example:

Bad: please implement VBOs for the 3-d clouds.
Good: please improve frame-rates when 3-d puff clouds are used.

If you ask for something too specific, we can't tell what you really want - there might be a better implementation.

So normally the feature request is what's useful, not the implementation.

In this case, however, I am interested in a proposed system for third party control of airport vehicles. If you have an interest in this, please write up a proposal and email me. Forgive me bashing you over the head with this, but often I get flooded with email on this.

• Please do not email me on this unless you have a full proposal for a system by which authors can control ground vehicles. Please do not email me asking for other features, telling me which type of truck is your favorite, or asking for user-level features. My goal here is to get feedback on how third parties would like to be able to customize a ground vehicle system. If you don't understand the difference, please don't email on this subject.
• I cannot promise that I will do anything you say, in particular, only that I will read and carefully consider anything that's sent to me that makes sense.
  
• and I cannot say when this will be used (not that soon though -- if we're only in the RFC stage we're only beginning to look at this). This is not a feature announcement.

I will try to respond to proposals quickly, but I've been pretty badly swamped by email, so it could take a few weeks!

X-Plane Dark Arts: Airplane Object Translucency II

In my previous post I described the underlying problems that make translucency in airplane cockit objects tricky. That gives us the background to understand how X-Plane draws cockpit objects and why.

The actual draw order for airplane-related objects is this:

1. Far away weapons.
2. All of the airplanes that we are not inside (this means the user's plane in an external view, and AI planes all the time). For each of these planes, the external cockpit object is drawn first, then the parts, then the attached objects in order.
3. Clouds and puffs and other such environmental phenomena.
4. The geometry of our plane, if it is to be drawn and we are in an inside view.
5. The attached objects in order for our plane, if internal geometry is drawn and we are in an inside view.
   
6. Weapons that are very close to the plane.
7. The inside cockpit object, if we are inside the plane.

A few things to note about this draw order:

• Note that weapons appear twice in the category of "near" and "far". This is all about the clipping plane - if a weapon is close to us, it must be drawn with the cockpit object, late in the draw cycle, when we are doing "close" things. Weapons are treated dynamically - they change where they are in the draw cycle depending on their position in space. This is necessary because a weapon starts out real close (just off your wing) and then goes real far away.
• The user's airplane is special-cased when we are in an internal view ... at that point if external things are being drawn, they are done in the later "close" view with the cockpit.
• The external cockpit object is (strangely) quite early in the draw order. There's really no good reason for that. What's particularly annoying is that it's inconsistent with the internal draw order. The main point of internal/external cockpit objects is to let you simplify your cockpit object in external view for performance.

Is there a sane way to set up an X-Plane 860 aircraft with translucent geometry? I'm not 100% sure about this, but it looks to me from the code like the correct thing to do might be:

1. Put any translucent windshield/canopy/etc. in the last attached object.
2. Put only the interior panel (and not the canopy) in the cockpit object.

This works because in the external view the canopy is drawn last, and in the internal view, the panel is more or less guaranteed to be closer than the canopy, which is good enough.

Happy Birthday, World

Today is Rosh Hashanah, the Jewish New Year. In Jewish tradition it is also thought of as the birthday of the world. If you're reading this blog, you probably have some interest in how X-Plane attempts to simulate the world on your computer. The attempt over the years to create a higher fidelity simulation has led me to a deeper appreciation of the subtlety, complexity, and beauty of the real thing.

(Nothing makes you realize how rich and intricate the world is than trying to model it with a few million triangles and ending up with something that looks completely crude.)

X-Plane's digital world isn't the only way that we interact with a proxy instead of the real thing. When we drive instead of walk, eat packaged food from a supermarket, talk on the telephone instead of talk in person, our technology becomes a proxy for our relationship with our direct natural environment - the planet, plants, animals, and other human beings.

Now I'm not saying that any of these things is bad. I'm not about to become a dairy farmer, and without the internet we couldn't create X-Plane at all. But I think it's important on this day, and hopefully every day to take time for activities that put us in direct contact with the world. Consider a few questions:

• How does what I eat affect the world?
• How does my travel affect the world?
• What impact does my home have on the world?
• Am I leaving the world in better condition for the next generation or worse?

Please ... take a few moments to consider the world, the only home we've ever had.

When I was in the Dolomites a few years ago with Sergio we were looking at the dolomites from his friend's balcony - mile after mile of beautiful mountains and rolling hills. I looked at him and said "God has more polygons than we do." It was a joke at the time, but I think that the act of really observing the real world and realizing that the digital reality and technology we create can be a proxy and an addition but never a replacement is critical to understanding the responsibility for stewardship we have over the planet. Are we taking good care of our most precious gift?

X-Plane Dark Arts: Airplane Object Translucency I

Side note: please do not post tech support questions as blog comments - please use the x-plane-scenery yahoo list or the x-plane.org scenery forum. I would like to keep tech support discussions in easily search-able public places so future users can get answers quickly.

I saw a post on x-plane.org referring to the process of creating translucency in objects attached to airplanes as a dark art. There is definitely a lot of weirdness in how X-Plane draws airplane objects. I will try to shed some light on what's really going on and how to deal with it. For this first post, I'll explain the requirements of the hardware, which shape the ensuing chaos.

First, and most important, in order for X-Plane to render translucent geometry (objects or otherwise), the geometry must be drawn from farthest from the viewer to closest. This is in stark contrast to normal operation -- for transparent or opaque geometry, we can draw the closest objects first, and the graphics card makes sure the far away objects don't "paint over them". But the technology that does this (z-buffering) doesn't work when the closer geometry is translucent. (If the translucent geometry is drawn first, it acts opaque to what is behind it.) For more info on this phenomenon and what to do about it, look here.

So in order for our translucent cockpit objects to draw correctly they need to be drawn from "back to front". But note that this term is relative to the camera -- which object is closest will depend on where the camera is located!

The other cause of cockpit object weirdness is the near clipping plane. At any time when X-Plane is drawing, there are two limits on where we can draw:

• The near clipping plane defines an invisible wall - anything closer to the viewer than this distance will not be drawn.
• The far clipping plane defines the other invisible wall - anything farther from the viewer than this distance will not be drawn.

The far clipping plane is usually set far enough away that objects disappear into the fog before hitting it. The near clipping plane is usually set close enough that by the time an object hits it, your plane has crashed.

Now here's the rub: the quality with which the graphics card can discriminate which polygon is closer (via z-buffering) goes down as the ratio of the far to near clipping plane gets larger!

Take a second to think about that. Basically if we want to increase the visibility in X-Plane without losing z-buffering fidelity ,we need to move the near clipping plane farther away from the user.

The real problem is this: X-Plane, with its sometimes long visibilities (when you get up into orbit, you can see a long way!!) really stretches the z-buffering fidelity of even modern cards. So we have to keep the near clip plane fairly far from the viewer in order to have the world look reasonable. But that distance might be a lot larger than the distance from the viewer to the interior of the cockpit!

We work around this by having two separate drawing passes. We first draw the "outside" world, with a near clipping plane that is fairly far away. (Every now and then a user tells me that this clip plane is causing scenery not to be drawn.) We then draw the cockpit interior and the user's plane, with the near and far clip plane both reset to be a lot closer. This way we can use our "z-buffer precision" in different ways for different geometry.

(It should be noted that z-buffering does not correctly handle the relationship between near and far objects when we reset the near and far clip plane. This technique works because we assume that everything drawn in the "cockpit" view will draw over everything drawn in the "outside" view.)

In my next post I will explain what X-Plane actually draws. For now suffice it to say that X-Plane has the task of drawing from farthest to nearest, but also the task of drawing in two phases: a far-away outside view and a close inside view.

New Texture Commands

If you look at a lot of the text file formats we often have something like this:

TEXTURE
TEXTURE_LIT
TEXTURE_NOWRAP
TEXTURE_NOWRAP_LIT

etc. It's a bit of a disasteer. The problem is that the command is encoding two separate ideas:

1. What the texture is used for (primary texture vs. lit vs. composite vs. mask)
2. How the texture is loaded (with wrapped vs clamped edges)

What got me looking at this was a test Sergio did with some ground lighting. He had texture compression on and his nice lighting and halo textures were absolutely trashed, because texture compression isn't very nice to alpha masks.

Internally we deal with this by marking textures as "not to be compressed" -- this is why the clouds don't look ugly. I thought, "why don't I make this available in OBJ and pol files...that's not very hard". But do we really want this?

TEXTURE_LIT_NOCOMP
TEXTURE_LIT_NOCOMP_NOWRAP

So I'm thinking we may need a syntax that separates the "what" (what slot in the scenery the texture is used for) from its settings. Something like this:

TEXTURE2 -nocomp -wrap my_truck.png
TEXTURE2_LIT -comp -nowrap my_truck_LIT.png

The "flags" would affect how the texture is loaded (the two obvious ones are wrapping/clamp controls, and compression-inhibition) and the command name would say what the texture is used for.

I am also looking at adding normal maps to objects - this would be a third texture attached to the object (so you could have a base texture, normal map, and lit texture). The advantage of this scheme is we'd need only three commands with a pile of flags.

Anyway, just something I'm thinking about.

(One thing I haven't worked out is how this would interface with dataref-driven textures, which would require yet more file format gunk.)

How to Make X-Plane "wicked fast"

Here's a hack that you can do to make X-Plane a lot faster: switch back to ENV scenery.

Okay, this is a completely ludicrous statement, but ... if I take X-Plane 860 (default settings) and turn off birds, cars and high detailed world, then view runway 6 with no panel, I get 45 fps with DSF vs. 83 fps with ENV. Load times are also faster too - the KSBD tile takes about 3 seconds to load vs 0.22 for the ENV.

Now of course you wouldn't want to use the ENVs if you've used the global DSF scenery -- even on the most simple axis the DSF scenery is superior, with typically around 150,000 to 300,000 triangles per tile rather than 60,000 in an ENV. (There's a lot more going on in a DSF than just that.) So ENVs are a lot faster because they do a lot less. You get what you pay for.

Just for fun I tried running X-Plane "7.0 beta 0", which was sort of a 7.0 preview, really more like X-Plane 6.70. It runs at about 85-90 fps. But it turns out that you'll get the same thing out of X-Plane 860 by replacing the new bezier-curve-based runway layout with the old simple square one. I also noticed that there are no runway shoulders in 7.00b0. It does beg the question: while I tried to set them up as similarly as possible, how man other things is X-Plane 860 doing that we just don't notice, but that cost fps?

I mention this in the context of the hardware requirements for future versions of X-Plane. We do sometimes raise the hardware needed to use X-Plane by putting in more graphic detail (that consumes more hardware) and not providing a fallback to the old way X-Plane looked. But I think what creates the sense of "I need a new computer" even more is how tempting and desirable the new technology is compared to the old.

When you look at computer performance in a given market, additional computer performance translates into additional usefulness up to a certain point. Past that point, the additional performance is worthless. This drives the price/performance ratio of the entire market -- you can see it with desktop computers.

It used to be that desktop computers cost $1000. Then we hit a day when all new computers could word process, send email, and surf the web with no trouble. At that point, buying a faster computer is pointless, and thus computers started to drop in price. This makes companies like Intel fairly unhappy.

But the flight sim world doesn't have this problem yet - every bit of new computer performance can be invested in more realistic graphics, something that there is clearly an appetite for.

In this context, my concerns will always be:

• Efficiency. For the same hardware and graphics detail, is the framerate getting better, or at least not worse? (Previous comparisons of 8.60 with 7.63 show 8.60 to be faster with ENVs...I think that 7.00b0's apparent speed is because it's missing a ton of features that the version 7 run introduced.)
  
• Lowest config. How far down can we strip the graphics to let users with older hardware keep playing with the most recent airplanes and features?
• Highest config. How much hardware can we soak up and convert to graphics detail? Are users with the newest systems getting their visual "money's worth"?

Growing Pains for Mac Users

We are now seeing two sets of Mac OpenGL driver-related bug reports: problems with the new Mac Book Pros (with an nVideo GeForce 8600) and with the new iMacs (with an ATI Radeon HD2400 or HD2600).

This doesn't surprise me for two reasons (both of which are speculation, btw...I am not privy to what goes on inside Apple):

1. Both of these cards are "next-gen" in a major way: DX-10 compatible hardware. That means they have a lot of cool new features. My speculation is that this larger jump in functionality of the hardware means more changes (and more bugs) in the drivers.
2. We're getting closer and closer to the next major OS upgrade (10.5), but this new hardware has to run 10.4. So I wouldn't be surprised if everyone at Apple is fighting two fires at once, limiting resources.

So while this is frustrating to Mac users who have these machines, I would encourage patience. I don't think we've seen to date a Mac that has been "left broken" -- several machines have had problems with the drivers in their initial intro, and Apple usually fixes them as soon as possible. In the long term I believe that these will both be really nice X-Plane machines.