So…just how awesome is my main development machine? Not that awesome.
Periodically users ask me what my setup is. Usually the user wants to set up a really nice machine to run X-Plane at its best and figures “let’s find out what the guys who write X-Plane have.”
But … my main development machine is definitely not selected to be the best possible X-Plane machine. I put together a system to:
- Debug X-Plane productively.
- Test all aspects of X-Plane.
- Create the global scenery as fast as possible.
In practice this means a Mac Pro with 8 cores, 12 GB of RAM, a lot of hard drive, and not particularly fast CPUs. It’s a machine that can churn out 8 DSFs at once. There’s no need for me to keep upgrading the CPU type itself – it’s the 8 way parallelism that makes DSF creation fast. (To Apple’s credit, the IO in the machine is fast enough to keep all 8 cores busy!)
Being an Intel Mac, the machine is triple-bootable into Vista (someone in the company has to have it) and Ubuntu Linux.
Right now I have a Radeon 4870 in the machine and an 8800 on my shelf. I do recommend the 4870 to Mac users – it’s a very nice card. But for my purposes it has one annoying problem: it takes up the space for the second graphics card slot and both power connectors…I may go back to a lower powered card so I can have one NV and one ATI card in the machine at the same time – a great configuration for debugging. (I do not recommend that any user ever mix graphics card brands…”don’t try this at home”, etc.)
Maxing out X-Plane isn’t on the priority list. In particular, past these goals, the faster the machine, the less likely I am to notice a problem.
An example: during 930 development, for some period of time, we had accidentally set the code to allocate an extra 1 GB of RAM at startup. Oops! The embarrassing part: neither Austin and I noticed for weeks. Both of our machines have plenty of RAM, and OS X has a decent VM system, so we just ran, using a lot of memory.
Then one day I try to start X-Plane on my laptop and the whole machine nearly catches on fire. Sure enough…an extra 1 GB of RAM is being grabbed.
The moral of the story: I’d rather not have a machine that hides things from me, if it doesn’t affect productivity.
Palm announced 3-d gaming for the Palm Pre! Some big names there…Need for Speed, Monopoly, the Sims 3, X-Plane — hey!! Laminar Research?!?! Who let those hacks in!??
I have the original Palm Pre (not the newly announced Palm Pre Plus) and flight is quite smooth! Thanks to the Palm team for letting us in on the roll-out.
With a new year and CES upon us, it’s go time for pundits to predict the future of the technology industry. Lori considered the question of how technology might affect X-Plane and pronounced:
Pixel shaders will get shadier.
I think she is right. It is only a question of how long until they are so shady that they are basically pitch black. (At that point, I expect a significant boost in framerates!)
There is no need to use the 3-d panel if you only want 3-d cockpit.
That might be the most counter-intuitive statement in the entire universe. Let’s break it down and see what’s going on. Originally we had the 2-D panel. The 2-D panel was where you put your instruments for interior views. When 3-d cockpit support was added, the 2-D panel was used to create the panel texture – that is, the instruments texture for the 3-D cockpit.
Thiat worked for a while, but as handles became more complex, screens became larger, and as 3-D cockpits became a more complex, authors started to run into the system’s limitations. If the author wanted to create a huge panel, then the panel texture for the 3-D cockpit was huge. Furthermore, texture space for the instruments in the 3-D cockpit was wasted because the 2-D panel had to have windows on it.
With X-Plane and 9 we added the 3-D panel to fix these problems. The 3-D panel is a second panel whose sole purpose is to provide instruments as a texture for the 3-D cockpit. When you have a 2-D panel and a 3-D panel, the 2-D panel is used to draw the panel in 2-D viewing modes and 3-D panel is used only to create the panel texture for the 3-D cockpit. With this setup the 2-D panel can be huge, and the 3-D panel can be small and compact with no windows.
The 3-D panel solves a second problem as well. Often the overhead panel is drawn in perspective on the 2-D panel this perspective view is useless for texturing a true 3-D cockpit. With a 2-D panel and a 3-D panel, the author can draw the overhead in perspective for the 2-D panel, and orthographically for the 3-D panel.
Now here’s where things get complicated: if an airplane has no 3-D panel the 2-D panel is used for both the 2-D view and the 3-D cockpit. But some airplanes have only a 3-D cockpit. In this case, there is no reason to use the 3-D panel at all. You can simply use the 2-D panel for texturing the 3-D cockpit and not worry about the user seeing it; in a 3-D only plane the user will only see the panel as a texture for the 3-D cockpit.
This setup is confusing in name: how can you have a 2-D panel used for a 3-D cockpits? But it is an allowed configuration. In fact, it was the only configuration allowed in X-Plane 8.
In summary: a 3-D cockpit can use the 2-D panel or 3-D panel as its panel texture. If an airplane has no 2-D panel, then the 2-D panel can be used for the 3-D cockpits without problems. In this situation and there is no need for a 3-D panel.
(It might be better to think of the 2-D panel and three panels simply add his two panels so that you can have two different versions of the panel. The names to the panel and 3-D panel are really just labels.)
Happy New Year! This entire post is going to be off topic, but hopefully worth it; I will resume the usual ranting about how video cards are slowly turning our brain into string cheese later.
I think my favorite part of working for Laminar Research and being part of the X-Plane community is the friends I have made in the X-Plane community – X-Plane really does bring a great group of people together. While I lived in California, I met Jay Oliver, and actually lived not too far from him while I was in ATC school.
Here’s the thing about Jay: he is a fabulous musician. In an age where music is “produced” and so much of what we hear is digitally manipulated, there’s a lot to be said for listening to a human being who is simply astoundingly good with his or her instrument. It’s an experience that can’t be synthesized. It was always enjoyable to get a few drinks into Jay and put him down in front of the Piano and then just listen.
I’ve been listening to Jay’s new album for a few days now, but Austin beat me to the punch, putting it on the X-Plane announce list. Jay set up his new website here, and his album is available for sale in CD or DRM-free mp3 format. You can also listen online right on the site.
Austin’s usual diet is highly electronic, usually runs at about 180 beats per minute, and is the musical equivalent of shooting Jolt cola directly into your brain. What Jay does is completely different, and it’s really something special.
It’s been a tough year for X-Plane authors. Key framing, manipulators, global lighting, baked lighting control, generic instruments, normal maps…version 9 has extended the possibilities for airplanes in a huge way. This is great for X-Plane users, and great for any author who wants to push the envelope, but there is a flip side: the time investment to make a “cutting edge” X-Plane aircraft has gone way, way up.
Here’s the problem: as hardware has been getting faster, the amount of data (in the form of detailed airplane models) needed to keep the hardware running at max has gone up. But the process of modeling an airplane hasn’t gotten any more efficient; all of that 3-d detail simply needs to be drawn, UV mapped and textured. Simply put, NVidia and ATI are making faster GPUs but not faster humans.
That’s why I was so excited about order independent transparency. This is a case where new graphics hardware and nicer looking hardware means less authoring work, not more. (The misery of trying to carefully manage ordered one sided geometry will simply be replaced by enabling the effect.)
My Daddy Can Beat Up Your Daddy
Cameron was on FSBreak last week last week discussing the new CRJ…the discussion touched on a question that gets kicked around the forums a lot these days: which allows authors to more realistically simulate a particular airplane…X-Plane 9 or FSX.
This debate is, to be blunt, completely moot. Both FS X and X-Plane contain powerful enough add-on systems that an author can do pretty much anything desired, including replacing the entire host simulation engine. At that point, the question is not “which can do more” because both can do more than any group of humans will ever produce. As Cameron observed, we’ve reached a point where the simulator doesn’t hold the author back, at least when it comes to systems modeling.
(It might be reasonable to ask: which simulator makes it easier to simulate a given aircraft, but given the tendency to replace the simulator’s built-in systems on both platforms, it appears the state of the art has gone significantly past built-in sim capabilities.)
Graphic Leverage
When it comes to systems modeling, the ability to put custom code into X-Plane or FS X allows authors to go significantly beyond the scope of the original sim. When it comes to graphics, however, authors on both platforms are constrained to what the sim’s native rendering engine can actually draw.
So if there’s a challenge to flight simulation next year, I think it is this: for next-generation flight simulators to act as amplifiers for the art content that humans build, rather than as engines that consume it as fuel. The simulator features that get our attention next year can’t just be the ability for an author to create something very nice (we’re already there), rather it needs to be the ability to make what authors make look even better.
(This doesn’t mean that I think that the platforms for building third party “stuff” are complete. Rather, I think it means that we have to carefully consider the amount of input labor it takes to get an output effect.)
I find it very difficult to write good documentation for the X-Plane scenery system and tools. Not only am I not a technical writer by training and not particularly good at explaining what I am thinking in non-technical terms, but since I have been working on the scenery system for over five years, I don’t really have good perspective as to what is complex and what is straightforward.
For this reason, I try to keep my ears open any time an author cannot understand the documentation, cannot find the documentation, or in another way has a problem with the scenery website. These “first experiences” give an idea of the real utility of the docs. Writing a reference for people who know things is not very hard – writing an explanation for new authors is much harder.
One author who was converting from MSFS to X-Plane pointed out a problem with the documentation that I hadn’t realized before – but I think he’s on to something. He pointed out that the information you need to complete a single project is often spread out all over the place. You probably need to look at an overview document, a file format, and a tool manual, each of which describes about 1/3 of the problem. To make it worse, each document assumes you know what the other ones say!
Who would write such poor documentation? A programmer, that’s who. (In other words, em.) In computer programming, the following techniques are all considered good design and essential:
- Breaking a problem into smaller, sections.
- Limited cross-references between these sections as much as possible.
- Keeping the sections independent.
- Not duplicating information (code).
In other words, the docs I have written for the scenery tools are a mess because they are “well factored”, a good thing for a C++ and a really useless thing for humans.
This is definitely not the only problem with the documentation, which also suffers from a lack of clarity, is often incomplete, and could use a lot more pictures. I am a programmer, and I am paid to make X-Plane faster, better, etc. It can be very hard to find the time to work on documentation when the next feature needs to be done. And yet…without documentation, who can use these features?
Now that I’ve at least figured out that factorization is bad, for the short term I am going to try to write “non-factored” documentation. The first test of this will be MeshTool. I am doing a complete rewrite of the MeshTool readme. Like the ac3d readme, MeshTool needs a full large-scale manual of perhaps 10-20 pages, and the task needs to be approached recognizing that the manual is going to contain a huge amount of information.
When I work on the MeshTool manual I will try to approach it from a task perspective, with explanations of the underlying scenery system, rather than a reference perspective that assumes authors might know why the given techniques work. We’ll see if this creates a more usable manual.
First, Merry Christmas and seasons greetings to, well, pretty much everyone – it’s been great to hear from everyone over the last week. I had a chance to poke at the scenery tools and have posted two new beta builds:
- MeshTool 2 beta 4.
- WED 1.1 developer preview 2.
You can download them both here.
MeshTool 2 beta 4 should be the last MeshTool beta short of bug fixes – that is, I’ve taken feature requests during the MeshTool beta, but I think we have what we need. Future feature enhancement will go in a later version.
Besides some useful bug fixes, there are two new features in this beta:
- You can specify a specific land class terrain with a shapefile.
- You can control the physical properties of orthophotos (are they wet or dry) with a shapefile without cropping out the water. This is useful for authors who want to use translucent orthophotos to create tinted water effects like coral or shallow sandy bottoms.
The WED developer preview simply puts up more bug fixes. WED isn’t quite beta because of one nasty limitation: the code that exports UV-mapped bezier curves doesn’t handle polygons that cross DSF boundaries. This code is going to be very difficult to get right – the combination of bezier curves, polygon cutting, and UV maps is a bit of a witches brew. Since WED isn’t really complete without this, I’m not calling the build a beta.
Also a docs update: I have posted the WED and Ac3d manuals in PDF form directly on the website. The AC3D manual (and motivation to do this) are thanks to Peter, who converted the manual from readme-text to PDF. I was shocked to realize the ac3d README is almost 20 pages. Hopefully having the manual in PDF form will help people realize just how much documentation is crammed in there.
X-Plane doesn’t natively and directly support popup panels, but that doesn’t mean you can’t pop them up. Generic instruments have a dataref-driven set of show-hide fields. (The “filters”.)
Now what you might not have realized is: groups have filters too! So you can hide an entire group with one filter, and you can put premade instruments in the group.
So…even though the FMS is a premade instrument with no filter fields, by grouping it you can show and hide it.
Important: the backgrounds of instruments are not shown or hidden. So if you want to do this, customize the FMS to have a transparent background, and use a generic rotary to put a real background behind it. The rotary goes in the group, and thus it can show and hide.
One more tip: clicking in 2-d goes through one instrument to another, for historical reasons. So if you pop up an instrument, you might want to hide the instruments it popped up over so clicks don’t affect them.
A quick tip to anyone using OpenGL and a plugin to make custom instruments. (The most common case of this I can imagine is customized glass displays, where it may not be practical to use 10,000 generic instruments, and the display being emulated is basically a computer display.)
OpenGL is not pixel exact, its per-primitive anti-aliasing (e.g. draw me a smooth line) is inconsistent and weird, and you probably won’t have full-screen anti-aliasing on your panel. (FSAA is out of your control, as X-Plane sets up the panel render.
For this reason, I recommend “texture anti-aliasing”. Basically in this technique you draw everything as rectangles, – for your lines, you use textures that have alpha at the edge. The linear intepollation of the texture forms the anti-aliased edge.*
For a detailed examination of the problem, I recommend this page. (arekkusu is a freaking genius and his treatment of the problem is very thorough!) I have also tried to explain how the hell OpenGL decides what it’s going to draw here. There are a few important cases where you can be pretty sure about what OpenGL will draw, and a lot of cases where you’re playing pixel roulette.
The “texture” technique also has the advantage that it leads nicely into the use of texture artwork. For example, if you need a line with an arrow-head, well, you’re already drawing a line as a textured rectangle with pixels in the center and alpha on the sides. Just ask your artist to draw an arrow-head in photoshop!
* Texture FSAA actually produces better results than FSAA (with non-AA pixels). The reason is that FSAA produces a finite number of intermediate alpha levels. The number of finite levels depends on the FSAA scheme, but it is always discrete levels, hence 16x FSAA looking better than 2x. By comparison, when we use textures, we get a smooth linear blend between our transparent and opaque pixels, giving us the smoothest possible anti-aliasing.
