One of our servers is down for maintenance. This means that the following are temporarily offline:
The installer-updater is still running – it runs off of a different server. I just fixed a number of broken links to the installer on the main website.
I don’t have an ETA on when the server will be back up, but if it’s not today I will stab myself repeatedly with something sharp.
I have spent almost the entire last week looking at ATI performance on Windows in depth; this post summarizes some of my findings and what we are now working on. Everything on this post applies to ATI hardware on Windows; the ATI Mac driver is a completely separate chunk of code.
Forgive me for quoting an old post, but:
As with all driver-related problems, I must point out: I do not know if it’s our fault or ATI’s, and the party at fault may not be the party to fix it. Apps work around driver bugs and drivers work around illegal app behavior all the time…that’s just how it goes. Philosophically, the OpenGL spec doesn’t require any particular API calls to be fast, so you can’t really call a performance bug a bug at all. It’s ATI’s job to make the card really fast and my job to speculate which subset of OpenGL will cause the card to be its fastest.
This proved to be true – most of the ATI performance problems on Windows involve us leaning heavily on an API that isn’t as fast as we thought it was, but that’s not really a bug, it’s just the particular performance of one driver we run on. The solution is to use another driver path.
I’m going to try to keep this post non-technical; if you are an OpenGL nerd you can read more than you ever wanted to know here.
With 100,000 cloud puffs (this is a typical number for one broken layer, looking at an area of thicker clouds) we were seeing a total cost of about 9 ms to draw the clouds if we weren’t GPU bound, compared to about 2 ms on NVidia hardware and the same machine.
Is 7 ms a big delta? Well, that depends on context. For a game developer, 7 ms is a huge number. At 15 fps, saving 7 ms gets you to 16.7 fps, but at 30 fps it takes you up to 37 ms. That’s one of the crazy things about framerate – because it is the inverse of how long things take, you get bigger changes when the sim is running faster. For this reason I prefer to think in milliseconds. If we can get a frame out in 20 ms we’re doing really good; if it starts to take more than 50 ms, we’re in real trouble. You can think of 50 ms as a budget, and 7 ms is 15% of the budget – a number you can’t ignore.
The ATI guys pointed us to a better way to push the cloud data through to the card, and the results are better – about 3 ms for the same test case. That should make things a bit better for real use of the sim, and should get clouds out of the “oh sh-t” category.
Now there is one bit of fine print. Above I said “if we weren’t GPU bound”. I put the sim through some contortions to measure just the cost of the geometry of clouds, because that’s where ATI and NV cards were acting very differently. But for almost anyone, clouds eat a lot of fill rate. That fill rate cost is worse if you crank the rendering setting, run HDR, run HDR + 4xSSAA, have a huge monitor, or have a cheaper, lower compute-power card. So if you were CPU bound, this change will help, but if you don’t have enough GPU power, you’re just going to be blocked on something else.
(A good way to tell if you are fill rate bound: make the window bigger and smaller. If a smaller window is faster, it’s GPU fill rate; if they’re the same speed it’s your CPU or possibly the bus.)
At this point I expect to integrate the new cloud code for ATI Windows into the next major patch.
I took some comprehensive measurements of framerate in CPU-bound conditions and found that with the “penalty” for the existing clouds subtracted out of the numbers, my machine was about 5% faster with NV hardware than ATI hardware. That may represent some overall difference in driver efficiency, or some other less important hardware path that needs tuning. But the main thing I would say is: 5% isn’t that much – we get bigger changes of performance in routine whole-sim optimization and they don’t affect all hardware in the same way. I have a number of todo items still on my performance list, so overall performance will need to be revisited in the future.
The other code path in the sim that’s specifically slower on ATI cards is the cars, and when I looked there, what I found was sloppy code on my part; that sloppy code affects the ATI/Windows case disproportionately, but the code is just slow on pretty much any hardware/OS combination. Propsman also pointed me at a number of boneheaded things going on with the cars, and I am working to fix them all for the next major patch.
So my advice for now is to keep the car settings low; it’s clear that they are very CPU expensive and it’s something I am working on.
One of the problems with poor CPU performance in a driver is that you never get to see what the actual hardware can do if the driver can’t “get out of the way” CPU-wise, and with clouds having a CPU penalty, it was impossible to see what the Radeon 7970 could really do compared to a GTX 580. Nothing else creates that much fill rate use on my single 1920 x 1200 monitor.*
I was able to synthesize a super-high fill-rate condition by enabling HDR, 4x SSAA, full screen, in the 747 internal view. This setup pushes an astonishing number of pixels (something that I am looking to optimize inside X-Plane). I set the 747 up at KSEA at night so that I was filling a huge amount of screen with a large number of flood lights. This causes the deferred renderer to fill in a ton of pixels.
In this “no cloud killer fill” configuration, I was able to see the 7970 finally pull away from the 580 (a card from a previous generation). The 7970 was able to pull 13.4 fps compared to 10.6 fps, a 26% improvement. Surprisingly, my 6950, which is not a top-end card (it was cheaper than the 6970 that was meant to compete with the 580) was able to pull 10.2 fps – only 4% slower for a significantly lower price.
In all cases, this test generated a lot of heat. The exhaust vent on the 7970 felt like a hair dryer and the 580 reached an internal temperature of 89C.
One last thing to note: despite our efforts to push more work to the GPU, it’s still really easily to have X-Plane be CPU limited; the heavy GPU features (large format, more anti-aliasing, HDR) aren’t necessarily that exciting until after you’ve used up a bunch of CPU (cranking autogen, etc). For older CPUs, CPU is still a big factor in X-Plane. One user has an older Phenom CPU; it benches 25-40% slower than the i5 in published tests, and the user’s framerate tests with the 7950 were 30% slower than mine. This wasn’t due to the slightly lower GPU kit, it’s all in the CPU.
The executive summary is something like this:
* As X-Plane becomes more fill-rate efficient it has become harder for me to really max out high-end cards. It looks like I may have to simply purchase a bigger monitor to generate the kind of loads that many users routinely fly with.
I meant to post this before, but: the new Catalyst 12-3 drivers fix a number of Radeon HD 7xxx-specific artifacts with X-Plane: incorrectly cut-out tree billboards and flashing triangles. So while I suggest latest drivers anyway, this update is particularly useful if you have a 79xx.
Just a quick tip on tuning X-Plane’s rendering performance: if you see your fps start off strong and then drop over time to a crawl, with low GPU, turn down the cars.
Here’s the problem: cars are spawned over time. The way the car engine works is that X-Plane comes up with a budget for cars based on rendering settings, and adds a few more every frame as long as it’s under budget; if it is over budget it simply doesn’t replace cars that are killed by being too far from your plane or reaching a dead end.
It can easily take several minutes for car traffic to build up.
And the thing about the car traffic is: it’s incredibly CPU intensive. This is something that I am working on and it may get better for future patches, but for now just consider this: a reasonable setting for cars (for your computer) should be based on the framerate after several minutes, not the one you instantly get when there are virtually no cars!
FOR IMMEDIATE RELEASE: Columbia, SC. Laminar Research announced today that in a surprising board room coup, the company is terminating owner, CEO, president-for-life and benevolent dictator Austin Meyer’s employment, effective immediately.
Randy Witt, VP of marketing, stated: “We couldn’t actually fire him because he owns the company, so instead we locked him in the first floor bathroom of his house. As far as we know the bathroom doesn’t have net connectivity, so he should be out of our hair. We left him some magazines.”
While many long-time X-Plane users were surprised that Mr. Meyer, who has worked on every version of X-Plane since version 1 and was the only X-Plane developer for the first 7 versions of the product, would be terminated so swiftly, others saw it coming. “We knew we had a problem a year or two ago when Austin started talking about plausibility all the time,” recalls Alex Gifford, Laminar’s resident mad scientist and autogen developer. “I had a really wonderful pig with a camera mounted on its head, but we couldn’t use it because it isn’t ‘plausible’ that such a pig would walk down the streets of New York. I thought to myself: the X-Plane I knew and loved would never have shied at putting random animals, some perhaps heavily armed, all over the sim. Just look at X-Plane 9!”
Senior grumpy software engineer Chris Serio concurs. “He wanted to remove the deer that randomly run across the runway at major class B airports. We begged him not to. We just looked at each other and said ‘who is this guy and what happened to the Austin we once knew?'”
But the final straw was Mr. Meyer’s early April 1st prank, stating that X-Plane would become a casual flying game similar to Microsoft’s recently released “Flight” product.
Barista-in-chief Ben Supnik describes the scene: “We were just appalled. I mean, publicly mocking our competition, preferably without using their actual products, while our own product has serious known bugs is standard operating procedure for Laminar Research. But the early release of the announcement was just unacceptable. Laminar has always been about missing deadlines, sometimes by several years. The notion that such a statement would come out over a full week early was just too much for us to bear.”
When asked how X-Plane might change in Mr. Meyer’s absence, Mr. Supnik hinted that the company would move to a table-based flight model with “at least four or five data points”, and that, with plausibility no longer a necessary design goal, the company was looking to license Skyrim as its rendering engine.
Here are three obscure Plane-Maker/X-Plane features that can save you time if you developer complex aircraft.
You may know that in Plane-Maker, you make your own copies of X-Plane’s PNG files to customize the look of the instruments. But did you know that Plane-Maker will copy the images for you?
Select an instrument and type Control-P (which is the default for the command binding “pln/panel/copy_instrument_png”). Plane-Maker will copy all PNGs for that instrument into your aircraft’s cockpit or cockpit_3d folder. This can save you the time spent wading through X-Plane’s cockpit folder to find the right PNG files.
When you are making a 3-d cockpit, you use the 3-d panel as a texture. But how do you know how to UV-map this texture in your cockpit? Often the panel background (panel.png) is blank.
X-Plane can make a snapshot of your panel for you, in the exact size you need to UV map. Use Control-Alt-Shift-Space (Command-Option-Shift-Space for Mac nerds) to run the “sim/operation/make_panel_previews” command in X-Plane. It will make a PNG file in your aircraft called Panel_preview.png – it’s just like Panel.png but with the instruments drawn in – perfect for UV mapping.
That sad face icon in top bar of the Plane-Maker panel editor enables “warning” mode. In warning mode, every instrument that has a potential problem gets a red outline. Select one instrument with a red outline and in the upper left corner of the panel you’ll see a description of what’s wrong.
This picture on the left is from Plane-Maker editing a 3-d panel. (That’s why it is just a “packed” set of instruments with no background; this panel is used as a texture for a 3-d cockpit – each instrument is UV-mapped into the right location.)
The air-speed indicator has been flagged as having a problem, and the text shows it. In this case, the lit texture has an alpha channel, which causes the lit texture to draw incorrectly. Fix the texture and the warning will go away.
I strongly recommend checking all Plane-Maker “red boxes” on your plane – most of the warnings will tell you about problems that would otherwise be very hard to detect.
X-Plane 10.05r1 is now available – click “get betas” and run the installer’s update function to get it. This is a really tiny patch; we needed to fix language on the 32-bit Windows warning, and we took the opportunity to fix hard cockpit walls and the carrier landing while we were at it.
Everything we’ve discussed on this blog for the upcoming beta is coming – but for a future patch in a few weeks. That will be a major patch with a multi-week beta period and real enhancements to the sim. We’re already deep into development on this work; the 10.05 micro-patch is just a quick build to fix a few tiny bugs.
I expect us to go final with 10.05 in a day or two – there are only two code changes, so it should be quick to find any possible problems.
It looks like, for the next major patch, we’ll be able to get a few features in that authors have asked for:
The one other authoring request that we heard loud and clear in Mallorca but will probably not get to in the next major patch is an option for seasonal textures in third party add-ons. It’s a slightly more complex change and will have to come in a later patch. (But we have moved the priority of this feature way up in response to developer feedback.)
I finally finished up an update to the OBJ8 specification, as well as the forest specification – see here for the documents. These specifications are mostly of interest only to developers who are working on scenery exporters.
The OBJ specification is very thick – here are some of the hilights of what’s new.
In X-Plane 10, you create global spill lights by attaching a light to an object. (Thus, spill can come from any object-bearing part of the sim – an airplane, custom scenery, etc.)
One way to do this is with the existing named and parameterized lights – these features existed in version 9, but in version 10 there are some spill lights added to the light list.
What may be of more interest to custom authors is the new LIGHT_SPILL_CUSTOM command. This lets you build a completely customized spill light. You control its size, color, shape and direction. You can even optionally run the light through a dataref, giving a plugin custom control of the light.
In X-Plane 10, an object can contain geometry that is “draped” on the ground – that is, X-plane will subdivide, bend and modify part of your object mesh so it sits perfectly on the ground even if the ground is sloped. ATTR_draped makes this happen.
This feature is a much better alternative to using ATTR_poly_os to make marks on the ground. Draping produces objects with better performance, and the geometry always sits on the ground with no artifacts.
As an added bonus, you can optionally use a second, different texture for the draped part of your object from your regular object. (Internally the draped geometry actually becomes something like a .pol file – this is why it can have its own texture.)
Draped geometry makes it much easier to make airport markings. If you want a parking spot, simply draw it on a quad, make it draped, and drop it into place with WED. Tom uses this heavily in our airport library.
Draped geometry also makes it easier to have ground markings that match the object they come with. For example, if you want a house and the house comes with a driveway texture, you can make the driveway texture a draped quad and when you place the object, the draped driveway is always in the right place.
In X-Plane 10, it is possible to set a few key attributes (blending and shininess, among others) globally for the entire OBJ, rather than using an ATTR_ to change part of the object.
These global attributes make hardware instancing possible. In hardware instancing, X-Plane draws many objects with a single instruction to the CPU. In order for this to happen, X-Plane must be able to draw the entire object without needing CPU intervention mid-object. This means an instanced object has to be free of animation, attributes, and a few other features.
The global attributes let you set things like shininess and still have a single-call draw object, ready for instancing. Alex uses these heavily in the urban autogen, and it really helps performance.
My fear is that global attributes are going to be a source of confusion for authors. When should you use them? How do you add them? This is my thinking:
Conditionals are simple logic statements that include or ignore parts of an art file based on the rendering settings. In particular, they let you change an OBJ based on whether HDR is on or shadows are on. For example:
IF GLOBAL_LIGHTING TEXTURE_LIT my_airplane_hdr_LIT.png ELSE TEXTURE_LIT my_airplane_LIT.png ENDIF
In this example, which LIT texture the OBJ uses will depend on HDR.
Because the conditionals can be used anywhere in the OBJ, you can change any aspect of the OBJ to customize for HDR. You can replace a texture, remove lights, add more geometry, etc.
I don’t know how heavily people will use conditionals, but they give authors the option to make one file tuned for both HDR and non-HDR, shadows and non-shadows.
I think the two most common uses of conditionals will be:
That second case would look like:
IF NOT GLOBAL_SHADOWS ATTR_draped # This is the shadow geometry TRIS 300 6 ATTR_no_draped ENDIF
When global shadowing is turned on, the entire set of draped geometry disappears, removing baked vs. real shaodw conflicts.
X-Plane 10.04 went final yesterday – as always there’s one bug that gets by you. In our case, “solid” cockpits (cockpits that constrain the camera so you can’t move through walls) are inoperative.
At this point it looks like we will do a tiny micro-patch to make 10.05 that fixes this and puts some new strings into the app. Honestly if we didn’t have string changes, I’d probably wait for the next real patch for the cockpit fix, but I believe that it is a low risk change if we must cut the app anyway. The main goal of 10.05 is to get the language just right in some of the dialog boxes for the next set of DVD masters.
The amount of change from 10.04 to 10.05 will be very tiny – comparable to 10.04 rc2 to 10.04 rc3 – literally one or two lines of code changed total.
In the meantime we are working in parallel on the next big patch.
Work on 64 bits is underway – I do not believe it will be available in the next big patch, and we have not specified any date (soon or far away). Simply put, I am staying out of the business of release dates for work like this. Our internal estimates have huge margins of error, due to the many unknowns of the process, and I don’t think we make anyone happy by saying when the feature will be available and then being wrong.
When X-Plane or the installer checks for updates, it sends an identifier (called a “user agent”) to the server. This is a standard part of HTTP and all web browsers and web-communicating programs do this; our servers (we use Apache, like most of the universe) keep a log of the “user agents” calling in, which can tell you what web browsers and other programs are requesting web pages.
Here is an example of two user agent strings from a real access to our web page:
Mozilla/5.0 (iPad; CPU OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A334 Safari/7534.48.3
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
As you can see, Safari and Firefox are both identifying what version they are and what operating system they are running on. This means the website owner can tell how many people are viewing with older browsers or tablets/mobile phones, and optimize the layout of the site accordingly.
Here’s what X-Plane looks like when it calls up our web server:
X-Plane 10.04r3-3-IBM6.1_64
For as long as we have had auto-check-for-update, X-Plane has include the operating system in its user agent string, just like web browsers do. This means that we can tell the approximate operating system split by looking at the user agent strings on the server.
With X-Plane 10.04 we have moved to the more complete string you see above – in particular, it includes whether the version of Windows is a 32 or 64 bit edition. (The above string comes from Windows 7 64-bit. Why Windows 7 is versioned 6.1 is beyond me. The extra “3” is an indication that the user has a full global edition of the sim – this is a paying user running on Windows 7 64-bit.
So I can tell you that at least for users who have updated to 10.04r3:
Not much. We didn’t actually set out to do a hardware survey – rather we put a user agent string into the installer when we first wrote it, because it’s required by the protocol. Apache logs user agents by default, so it was only after running the installer a while that we realized that we could “mine” the log for platform information.
We do not: