Order Independent Transparency - What It Fixes

Yesterday I blogged about Order Independent Transparency (OIT). That robot is very shiny, but what does this fix in X-Plane itself? Here are two pictures that show the problem in an X-Plane context.

This is the Cirrus jet in X-Plane 9.22.

Pretty, eh? But...look through the right two windows - look at the passenger door on the other side. Note that through the middle window the passenger door is visible. Through the right window, the entire passenger door is gone!

This is the same shot from X-Plane 940, where the problem has been corrected.

The bug you see here is incorrect draw order. In X-Plane 922, the right door (which contains the right-most near window) is drawn before the left door - hence its translucent part destroys the door.

Max fixed this by changing the draw order of the model - the new cirrus draws the inside view of both doors before the outside view of either doors; because the geometry is one-sided he can draw the 'inside' first and outside 'second'.

These two blog posts explain translucency in a lot more detail.

What X-Plane has now is "order dependent" transparency - if translucent surfaces are not drawn from far to near, you get artifacts like the missing door.

What OIT promises (and that robot demonstrates) is the ability to have translucent geometry and not have the objects behind the translucent parts disappear.

I'm Looking Through You

Order independent transparency (OIT): first, the shiny robot.

So first, what's so special about this? Well, if you've ever worked with a lot of translucency in X-Plane, you know that it doesn't work very well - you invariably get some surfaces that disappear at some camera angles.

The problem is that current GL rendering requires translucent surfaces to be drawn from farthest to nearest, and who is far and who is near changes as the camera changes. There are lots of tricks for trying to get the draw order mostly right, but in the end it's somewhere between a huge pain in the ass and impossible.

What's cool about the robot data is that the graphics card is drawing the transparency even if it is not drawn from back to front, which means the app can just shovel piles of translucent triangles into the card and let the hardware sort it out (literally).

X-Plane is currently riddled with transparency-order bugs, and the only thing we can do is burn a pile of CPU and add a ton of complexity to solve some of them partly. That proposition doesn't make me happy.

So I am keeping an eye on hardware-accelerated OIT - it's a case where a GPU feature would make it easier for modelers to create great looking content.

WED - Click to Split

This feature is not in the WED developer preview (because I just coded it) but: WED 1.1 will feature "click-to-split" for edges. With WED 1.1 you can option-click the edge of a polygon or line feature (but not a must-be-straight entity like a runway) to insert and drag a split point.

This will hopefully be a lot easier than the current, convoluted, WED 1.0 technique of selecting the two surrounding vertices and picking "split", then repositioning the vertex.

Hackers: this features is not yet checked into the tree, so ... building from source won't help you. It'll be available some time in the next week.

A Developer Preview

I realize as I write this that I am going to get some comments mocking the fact that X-Plane 940 is on RC, um...13. I don't decide the milestones for X-Plane, nor do I decide the version numbers. If you want to discuss why X-Plane is 940 (and not 930 or 950) and why it goes beta and RC when it does, email Austin. What follows is all about the scenery tools, not X-Plane.

With that out of the way: I have released a WorldEditor 1.1 developer preview. So I wanted to explain in a little bit more detail what the difference is between a developer preview and a beta. Here is an approximation of the standard definitions of "milestones" - they are what I use for WED.

1. Development: not all features are coded, no guarantees about bugs.
   
2. Alpha: all features are coded, no bug is so severe that you can't at least try a feature. (For example, if WED crashed on startup, it would not be alpha, because you could not test saving files.)
3. Beta: all requirements of alpha, also no bugs that cause program crash or data loss.
4. Release: no open bugs.

This all applies to known bugs. Beta software may crash and cause data loss - it's just that we wouldn't have put it out as beta knowing that this happened.

WED 1.1 is still in phase (1) - development, and the build I posted is a developer preview - a cut of whatever code I had laying around. So: I can't promise it isn't going to trash your data or crash! Be even more cautious with the developer preview than you would with a normal beta. You don't want to run a five hour session without saving your work, and you want to be backing up your work often - the "save" command might trash your entire project.

Why do a developer preview if it's still so buggy? Some users who know how to compile WED from its source code are already using WED 1.1 and they seem to be enjoying it. So far it appears not to be lethally broken. Given that and the fact that most of the uncoded WED 1.1 features are usability and edge-cases, it seemed like the developer preview could be useful for getting earlier feedback.

One last note: the manual is not updated at all, nor is there any documentation on the new features. Let me be clear: no tech support or help is provided what-so-ever. Do not email me, or X-Plane tech support with "how do I use WED 1.1" questions. If you cannot figure out how to use WED 1.1 on your own, don't use the developer preview.

XSquawkBox Transition

We've made some progress in transitioning XSquawkBox to be under Wade's primary management - read more here.

Never Ignore A Bug You Don't Understand

First, I want to thank the X-Plane users who have gone through piles and piles of regression tests to isolate some of the peskier bugs. Often a bug only occurs on hardware that we don't have in-house, so this detailed reporting is a huge help in shipping a program that has to run on a huge number of configurations.

Sometimes a user will offer to work around a bug by changing an add-on, or just dropping the add-on. But...I have learned the hard way: never ignore a bug you don't understand.

First, the bug might run much deeper than the reported use. Perhaps the bug is actually affecting dozens of other add-ons.

If we don't understand the bug, how can we say "this is so unimportant that it can be ignored"?

Now some bugs, once diagnosed, may prove to be not worth fixing. But...until the bug is fully understood, we have to take the time to dig in. We can't just give up because the bug seems unimportant.