A quick note on an issue that apparently came up during the X-Plane Town Hall (I have not had a chance to listen to any recording or read a transcript; Austin just pinged meo n this):
What if two people submit library buildings for the same airport?
We actually already have to cope with this since we already crowd-source taxiway layouts.
My view is: we’ll put infrastructure in place when the problem occurs; there are a lot of of ways to cope with collisions of contribution, and the problem has been solved in many cases already. So I want to wait and see what kind of collisions occur and then pick the best method (whether technological or organizational) to deal with them.
Robin already tracks who submitted data, so we have the basis to identify when there has been a change or a possible collision.
WED 1.2 is in beta now — thanks to the users who have taken the time to submit WED bugs (which go here, btw). Tyler is working on an update to the manual, and I’ll try to find some time to squash bugs.
But how do you share an airport with terminals with the rest of the X-Plane community? At the X-Plane developer’s conference, we reiterated that we want to extend our crowd-sourced airport data collection to include terminal buildings and ATC routes, as well as the pavement layouts that Robin already curates for us.
To be clear: you do not have to share your WED creation to use WED! WED can be used for custom scenery and your own private creations; submitting your work for sharing with the community is optional!
Here is our thinking on submitting airports:
- Submitted airports will in the future contain three types of data: taxiway layouts (in an apt.dat), ATC taxi route data (also in the apt.dat) and library airport building placements.
- We will not accept custom art assets! The public database of airports is meant to be location data only! Custom scenery is great, but the purpose of the public database is to populate the world, not to crowd-source the art-creation process.
- WED will have a “package for submission” export option that properly bundles everything into a single file in a format useful for Robin.
- The package for submission option will do some basic validation, to catch problems like custom objects in the library, or possibly erroneous data.
You will also still be able to say “Build Scenery Pack” to create a custom scenery pack for your own use – WED 1.2 is meant to support both the crowd-sourcing and custom scenery work-flows.
The “package for submission” work is still in progress; Robin and I will test this out privately while WED is in beta so that test submissions don’t flood the data collection process.
Posted in Tools
by
Ben Supnik |
This is why.
Let me anticipate the inevitable “why don’t you just use Google Maps” question: to the best of my understanding, tracing your airport vectors off of Google Maps imagery is an unlicensed use of their service and would result in a derived product owned by Google. That’s pretty much a deal breaker.
OSM’s use of background imagery to trace (in Potlatch) comes from specific license agreements between OSM and the image provider – in other words, the image providers are “donating” to OSM by giving them a specific license to trace without ownership issues.
Anyway, I am open to other ideas. (Except for “no, you didn’t read the license right, Google really doesn’t mind if you use their imagery for free to create your own data set”. I am not open to that! 🙂
Posted in Tools
by
Ben Supnik |
I have updated the WorldEditor page to link to the new builds of WED 1.2 beta 1. This is the first beta of WED 1.2, which we showed at the X-Plane developer’s conference in SC a week ago. A few hilites:
- Finally, a real airport import dialog box – when you import a dialog box, WED will let you pick a subset of airports to grab. So now you can open the entire apt.dat file from Robin and just pick the airport you want.
- There is now a library preview pane for objects, autogen scenes (.AGP files) and draped polygons.
- WED 1.2 supports all of the new v10 overlay editing extensions, e.g. forests as tree lines, facade wall-type control, etc.
Tyler and I are working on a 1.2 manual but it’s still chaotic enough that I think it isn’t even ready as a beta document.
Last weekend I was in Columbia, South Carolina for the second X-Plane developer’s conference – that is, the US meeting. I’ll try to write that up later, but first a quick note on WED 1.2. We had Tom Kyler on site, and his demonstration of WED 1.2 with the new lego brick objects turned out to be the surprise hit of the weekend. It’s one thing to say “we’re going to crowd-source airports” – it’s another to show the pieces in action.
WorldEditor 1.1 is released, and WED 1.2 is available as a “developer preview” – it’s that developer preview we showed at the conference. A real “beta 1” will be out shortly.
What’s a developer preview? It’s an incomplete beta. In this case we didn’t have all of the features of 1.2 in place, but I wanted to get it out there for people to poke at. Tom set up Seattle using the developer preview, so clearly it’s “usable” – albeit with a heavy dose of caution.
My plan is to get WED 1.2 beta 1 released some time this week, with every planned feature except for “submit-to-Robin”, which he and I should probably test internally a bit while we make sure that WED’s output is solid.
Note that if you are making custom scenery, there’s no reason why you can’t use WED 1.1 for now – it’s finished and stable. WED 1.2 has usability and v10 updates, but overlay editing has been available in WED 1.1 for a while.
After WED
After WED, the next scenery tools priorities will be:
- Getting ac3d and Blender 2.49 caught up for version 10 technology. For Blender 2.49, I am trying to merge my
hackingchanges with Jonathan’s, so that users of the public scripts can use my v10 mods without having to rework content. I will send these to Jonathan, and also post some of our newer scripts (e.g. autogen-editing).
- MeshTool 2.x will write v9 meshes, but a new 3.0 version will be needed to make “v10”-style DSFs; this is on my todo list.
What About That Program That Simulates Airplanes?
It’ll take a bit to get through the scenery tools because we are also mid-patch for X-Plane. 10.10 will be the next “patch” with new features. It looks like we will post a 10.06 first with some new translation files that have come back to us from a number of sources.
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.
