We’re in the middle of the X-Plane developer conference here in South Carolina; I’ve had a chance to improve and revise some of the presentations since Mallorca; my voice is totally shot but once it comes back Austin and I can turn some of the talks into YouTube videos.
As always seems to happen, we’ve put a few features into the sim during the conference…why talk about a problem when we can just fix it?
So for the next patch, you can put a shortcut or alias or simlink to a scenery pack into the Custom Scenery Folder, rather than the custom scenery pack itself and that means…
…that the scenery pack can be on another hard drive. This may take the sting out of an orthophoto pack if you run X-Plane off of an SSD.
Edit: to answer a few commonly asked questions:
- This is new if you are on Mac/Win and want to use the file-browser-level alias mechanism. Yes, Linux nerds can use simlinks (I was actually surprised that this path works, but apparently it does.)
- We are only doing this for scenery packs. Scenery packs are the biggest single thing you can install, so to relieve hard disk pressure we will start with scenery packs. We might allow linking some other pack later, but for now we are not doing aircraft – our goal is to keep X-Plane maintenance simple, predictable, and supportable.
Posted in News
by
Ben Supnik |
One complaint we hear a lot from tech support is that the 747 knobs are hard to control in the 3-d cockpit. Javier and I did some investigation into this; this post describes what we found, what we are changing, and what why I don’t think the scroll wheel probably shouldn’t be used to affect the 3-d cockpit.
Hard To Drag
The fundamental problem is that it’s hard to control the autopilot knobs in the 747 by dragging with the mouse. Large drags make only a small change in the knob, so it takes forever to dial in an autopilot altitude. You’d think the solution is simple: change the scale for dragging on the knobs, right? Well, not quite.
It turns out that the “sensitivity” of the knobs to dragging is a function of the way you turn your head in the cockpit. Sit in the default 3-d position, turn your head 30 degrees to the right and drag and the knobs turn quickly. But look straight ahead, slide to your right, and drag and they are very slow.
The problem is one of perspective, and this is where it gets interesting for authors. The drag axis manipulator (which lets you make the 3-d cockpit respond to dragging the mouse) measures its drag in meters. But the distance on the screen that the drag distance takes up (in meters) depends on where the camera is placed and at what angle it is turned. This can lead to some very strange effects: in some views, a 500 pixel drag moves the altimeter only a few hundred feet, while in other views, 500 pixels moves tens of thousands of feet.
Screen Space Dragging
For real physical parts like a lever (a part that moves as you drag it), dragging in meters makes perfect sense; it lets authors match their animations to their manipulations.
But for a drag that doesn’t have a real-world correlation (e.g. you drag on the knob and the knob spins but it doesn’t move) having the camera angle affect the drag distance results in panels that can be used only from certain viewpoints.
To fix this, we are introducing a new “pixel” drag axis – unlike the current drag axis, the distance over which the user can drag is specified in pixels, so that the “sensitivity” to the mouse is the same no matter what view angle the user has. I will post details on this when we go beta.
The Mouse Wheel
While I was working on pixel drag axis, I looked at using the mouse wheel to turn knobs, something our users asked for. And while the prototype seemed ‘clever’, after some arguments with Chris I came to a bit of an inescapable conclusion: the mouse wheel for changing parts of the panel is the wrong tool for the job.
The problem with the wheel is that in the rest of the universe it is use to manipulate view information. This is true in X-Plane 10.05 as well (and it works well), but things get quite tricky once the mouse wheel is added in. Some of the problems:
- Making the mouse wheel zoom and manipulate (e.g. if you are over a knob it manipulates the knob, otherwise it zooms) risks surprising results. A user who wants to zoom might accidentally “bump” a cockpit knob, something that’s pretty frightening to a real pilot.
- We looked at requiring once of the buttons to be held down while mouse-wheeling, but that’s not a gesture you see anywhere else in the universe – effectively one of the two uses of the wheel is “buried” and we might as well only use the other. Furthermore, if we are going to require a click, the user might as well just drag on the knob itself.
- If we have to pick one or the other (zoom or manipulate), zoom is by far the most consistent thing, the thing that fits with the host OS.
- If we make the option a preference (e.g optional mouse-wheel on knobs) so few users will enable it that authors won’t be consistent in adding support to their cockpits, and the system will never get momentum. (We can’t just add “mouse wheel automatically” because the sim doesn’t know how much one click of the wheel should change a given dataref.)
We tossed the mouse wheel idea around, but in the end we concluded that the wheel should be a view/zoom/scroll function, not a data change function – we couldn’t find any example apps that used the wheel to change the contents of the screen. In the end, authors need to make clicking work well, and we need to provide manipulators (like the screen-space drag manipulator) to make that possible.
One of our servers is down for maintenance. This means that the following are temporarily offline:
- Scenery tools downloads.
- GIT repos (and the cgit web interface).
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.
Cloud Performance
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.
Performance Minus Clouds
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 Cars
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.
Fill Rate
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.
CPU Still Matters
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:
- We are specifically optimizing the cloud path for ATI/Windows, which should close the biggest performance gap.
- We still have a bunch of performance optimizations to put in that affect all platforms.
- Over time, I expect this to make ATI very competitive, and to allow everyone to run with “more stuff”.
- Even with tuning, you can max out your CPU so careful tuning of rendering settings really matters, especially with older hardware.
* 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.
Posted in News
by
Ben Supnik |
Here are three obscure Plane-Maker/X-Plane features that can save you time if you developer complex aircraft.
Plane-Maker Will Copy Your Instruments
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.
X-Plane Can Make a Panel Image for UV-Mapping
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.
Plane-Maker Will Tell You What’s Wrong
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:
- Exclusion of scenery elements from shadowing for pretty much all scenery elements.
- Use of “conditionals” (see the OBJ8 spec or previous post) to use different textures when HDR is on or off for facades, ter and pol files. (This is available for OBJs since 10.0 – this is an extension to other scenery formats.)
- Texture size limit bumped up to 4096 x 4096 max. (The max panel size will remain 2048 x 2048.)
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.)
