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.
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.
Global Attributes and Instancing
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:
- Modeling program exporters should allow an author to identify an object as “for instancing” or not.
- Authors should check “for instancing” for any object that is heavily repeated. (A car or a single tree or a static airplane, for example.)
- The modeling program can then try to prefer global attributes for instancing objects but not for regular ones, which should come very close to optimal behavior.
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:
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:
- Providing alternative LIT textures when HDR is on or off. Note that only one texture is ever loaded (when the HDR rendering setting is changed, X-Plane unloads one and reloads the other) so this does not increase VRAM.
- Removing drop shadows that are baked into a model when shadows are on.
That second case would look like:
IF NOT GLOBAL_SHADOWS
# This is the shadow geometry
TRIS 300 6
When global shadowing is turned on, the entire set of draped geometry disappears, removing baked vs. real shaodw conflicts.
I realized the other day that while Chris and I have discussed cities with a bunch of people, I left out the city plan from my series of “road map” blog posts a while back.
The picture on the right is downtown Seattle from the upcoming X-Plane 10.04 beta 7, which includes an update to the urban art assets: new facades, a bunch of lit textures, and careful library tuning by Propsman. (There’s also some clever use of spill lights next to the tall buildings.) This update is part of ongoing work to build out our new city autogen; this post will explain the road map for that work.
A Radical Approach to Cities
Before I describe some of what’s failing in the current city scheme, how it’s supposed to work, and what we’re doing to fix things, let me take a few paragraphs to describe the “big idea”. Cities in X-Plane 10 are completely different from X-Plane 9, and they’re completely different from any other flight simulator that I’m aware of.
Before X-Plane 10 there were three approaches to cities that I am aware of:
- Land class tiles. You create repeatable square orthophoto textures of cities and put matching 3-d on top of them. What’s good about this technique is that it runs on really minimal hardware, it looks good without using a lot of resources, and it’s fairly easy to code. The down side is that you will not get accurate cities. There is no way to use additional data to put roads or buildings in their actual correct places. You will always get a plausible but non-accurate city, a “city in theory”. This is the technique X-Plane 6 and 7 used, and the technique FSX uses.
- Vectors over land class tiles. You create repeatable square textures of city (just like above), but instead of attaching the 3-d to them, you build your 3-d off of real vector data. This is what X-Plane 8 and 9 did. What’s good about this technique is that it runs on modest hardware, and it puts your roads and buildings exactly where they should be. The down side is that the 3-d is completely misaligned with the textures underneath, creating a “stew” effect when viewed up close. (Some users consider this mismatch absolutely unacceptable; others seem to not care.) There’s no question that the texture mismatch is not plausible, but the shape of the city is accurate. This is the technique X-Plane 8 and 9 use.
- Fully custom cities. If you can afford custom non-repeating orthophotos of the real city and you have the matching 3-d data, you simply build the city and everything matches up. This is the ideal way to build a city, but it assumes custom data for every city; this is great for custom scenery but not scalable to a global product. It is plausible and accurate but not global.
For X-Plane 10 we wanted a way to have it all: a city that was plausible (e.g. looks good and doesn’t have weird artifacts) but also accurate (e.g. shaped like the real city, using data that’s now available – we can know where every road is, and even some of the buildings) and for the default sim, our approach has to be global; we can’t simply build a custom city for every city on the planet. And when we looked at the technology out there, it looked like it was for the first time possible.
Here’s what we came up with: in X-Plane 10, the unit of autogen is not the landclass orthophoto tile (a 1 km x 1 km square of terrain whose entire interior is defined by the texture and 3-d). The landclass tile has wonderful properties, but it’s just too big to be accurate for a real city.
Instead X-Plane 10’s unit of autogen is the city block. Each city block is an individual autogen unit, and the autogen is capable of flexing and shaping itself to fit the demands of a real road grid based on real data. This means we can have plausible autogen with tons of detail while sitting inside the real road grid of a real city.
This approach is significantly harder than using landclass tiles. Each autogen primitive needs to be able to resize and contort itself to meet the demands of real world data while still looking like it was meant to be there. The road grid has to look really good even as it is built from vector data, because we can’t just bake the pictures of the roads into the terrain. The terrain has to contain no city details in the near view (because the autogen defines where there is city), and the autogen buildings have to have “skirts” of orthophoto that they drop down to put their driveways and other ground details in place.
Then the rendering engine has to somehow take all of these disparate parts and render them at high speed!
So Does It Work?
When the new system works, it really does work and we get plausible and accurate cities with good performance on a global scale. But this system is entirely new – because it is such a radical change ,we couldn’t recycle any art assets or code from previous versions of X-Plane and thus it is very new, and frankly a bit raw. So when it fails, the artifacts are sometimes quite spectacular.
As the system ships now, a few things tend to go wrong; I will describe what’s going on under the hood and what we expect to do to fix it.
Crazy, Deformed Roads. This is the most common reported bug. (Hint: please stop reporting this. I know about it already.) We feed extremely detailed road data from OpenStreetMap into X-Plane; unfortunately due to bugs in the code, sometimes when X-Plane analyzes an overpass, it can’t figure out how the roads should stack up, and it instead creates some kind of ridiculous bridge, e.g. a road that shoots straight up into the sky or a giant 1000-foot tall arch.
The good news is: this is just a bug in the rendering engine; when I fix the bug (which I hope to do for the 10.05 patch), the artifact should go away without the need to redo any DSFs.
I brought this bug on myself by insisting that the roads be draped on the terrain. X-Plane 9 placed roads at absolute altitudes in 3-d space, which was easy for X-Plane, but meant that roads weren’t easily used in an overlay. For X-Plane 10 I wanted to make it easier to work with roads directly; once the road bridging bugs are fixed, this should be doable.
The road system is already doing a number of things we are pretty happy about though:
- Roads are made of bezier curves. Once we go 64 bit we’ll be able to crank up the smoothness factor for users who have a lot of RAM.
- The road junctions are flexible – that’s how we get clean, real, custom-looking junctions out of raw vector data. Over time we can add more junction definitions to make nicer looking overpasses.
- City roads drape on the ground, avoiding Z thrashing and some of the other ugly version 9 artifacts.
Where Are the Buildings? The second bug report we get is that cities don’t contain enough big buildings, or enough sky scrapers. Most commonly the problem is residential houses appearing downtown.
The problem here is that the new autogen requires new art assets; we couldn’t just reuse our substantial pile of buildings from X-Plane 9. So we’re building more buildings; what you see in the meantime is the existing art assets shoved into the wrong kind of library slots. Once we have more appropriate buildings for a given library slot, things should look better.
We have also discovered some cases where the placement of autogen in the DSF isn’t very good. This was the first global render where we built the new autogen and there are some clear cases where we can do better.
So when it comes to building placement, things should get better by putting more art assets in a net update; we’ll probably recut some major city DSFs to get even better use of that autogen. (One nice thing about cities: there aren’t that many of them. There are over 18,000 DSFs in the global scenery, but the top 100 cities world-wide..well, that’s probably about 100 DSFs.)
There are two aspects of the buildings that are already working right now:
- There is a ton of detail. If you get in close to the autogen, you’ll see a scene similar to what you might get in a custom scenery pack.
- It’s fast. You can max out the road and building density on today’s hardware and get 25-30 fps. Compare this to X-Plane 9 where even four years after the product shipped, “insane” objects is often not reachable.
I put Seattle from v9 on an i5 machine for testing and compared it to v10 with insane roads, insane autogen, moderate forests, and shaders. I got > 25 fps in v10 vs. approximately 5 fps in v9. We’re going to try to keep that kind of capacity for huge amounts of autogen with high performance as we add more building types.
One last note about autogen and buildings: in X-Plane 10 the autogen can optionally be “height sensitive” – in this case the buildings in the autogen block take on an AGL height based on the DFS. We only use this for appropriate autogen types. For example, a dense urban city block might be height sensitive (since the DFSs contain heights for skyscrapers) but a block of residential houses is not height sensitive – they’re always just little houses.
In most cases the height data is already in the DSF; once we get the right autogen art assets in place, they should start repsonding to the height data.
Green Terrain. The third bug report I hear about is green terrain – that is, a city is filled with nothing but a big green expanse. To understand this bug you have to understand how our autogen creates the look of the terrain.
Austin posted in one of his early
rantsmanifestos that we would build the terrain from the ground up, with green grass for the ground and no cities if 3-d is not enabled. This is a massive simplification of what actually actually happens.
The terrain is a composite: the actual base terrain is indeed devoid of any recognizable city details – because they will come from overlays. The ground instead contains “natural turf” patterns that try to impart some detail while accepting overlays.
The road grid then puts down a layer on top of the ground, with sidewalks and the actual pavement.
On top of that, the autogen system puts down a ground tile for each building. (One autogen block consists of multiple tiles, and the tiles are moved around to fit the block shape.) The tiles are mostly transparent, but contain details that mask parts of the ground, such as sidewalks and driveways.
Thus the combination of three layers (ground, road and autogen ground tiles) composite together to form the kind of detail that you would normally get in an orthophoto.
So when we have green terrain, there are actually several problems conspiring to ruin this “composite orthophoto” effect:
- If we don’t have the right autogen buildings (see above) we won’t have the right ground tiles. More buildings will help fix this.
- It’s actually a bit tricky to build the ground terrain that can sit under the autogen; the only really complete climate we have supported right now is a northern climate (which works well in Seattle). So as we add more urban base terrains the bottom layer will start to work better.
- When you turn down autogen density, some autogen city blocks disappear. This is a hold-over from version 9. What we want to do is keep the base tiles but remove the 3-d when you turn the rendering settings down. This will lighten the rendering road, but the 3-layer orthophotos will still look good. (Similarly, we’d like to reduce detail but keep all roads for lower road settings.)
In other words, once we have more buildings, more ground terrain, and a better way to turn down detail, the terrain should look more like a real city under a wide range of rendering settings.
(If you’ve really watched the sim carefully, you may have noticed that the ground textures actually crossfade from “just grass” to orthophoto-like as you get farther away from them.
Everything listed above represents incremental improvement of our cities – more art assets, bug fixes, smarter LOD and rendering settings. But that’s just the beginning. I believe that what we have on our hands is a fairly big fundamental improvement in how cities are handled: we have a way to build cities that provides a huge amount of up-close detail while working from detailed data (and representing that data), and it can run at good fps on today’s hardware.
Down the road I think we’ll be able to integrate and utilize OSM data to get even more detail into our cities and further push the envelope for how much detail, realism and accuracy we can get into cities at a global scale.
I spent a few hours last night working on X-Plane’s facade engine – that is, the part of X-Plane that builds buildings, fences and structures from their shape traced on the ground. Besides fixing some v9 compatibility bugs, I had a chance to add in a few last features that didn’t quite make the 10.00 cut.
I used Tom’s “classic”-style parking garage (you’ve seen it – it’s the one used at KSEA in the demo area!) to test some of my work; some of the work on the facade engine illustrates three different ways to optimize a program.
Be More Efficient
The first way to optimize is to find ways to accomplish the same work in less time – that is, to write more efficient code. This is certainly the least risky form of optimization: there’s no trade-offs, you just get more for your hardware dollar.
In the case of Tom’s parking garage, after putting geometry in place for the roof of each floor (to fix a rendering bug) I noticed that we were building the mesh for each floor twice – once for the roof of the level and again (but facing in the opposite direction) for the floor of the next level. I added some code to the engine to recycle the mesh, but create duplicate indices; now two-sided roofs in facades use about half the vertex count.
There are still a number of places in X-Plane 10 where we can be more efficient. But rewriting code to be better takes time; these performance changes will come out incrementally, and any one change may not be that noticeable. What is important though is the net effect of improving efficiency over and over again.
This sounds negative, but when it comes to computer graphics, cheating is preferable. Clouds behind the panel? Just cheat – don’t draw them! Trees too far away? Use a billboard! No airplanes in the game? Use a painting for the sky and don’t bother with 3-d clouds. What I am referring to here is finding ways to deliver the appearance of eye popping graphics for significantly less work. This kind of optimization is critical to making a competitive rendering engine.
In the case of Tom’s garage, the facade engine puts the same number of cars on every level of the garage. This is hugely wasteful; while you might want cars on the roof, you don’t need very many on the lower levels. The lower levels are only visible from the side, and from the side even a few cars are enough to create the appearance of a non-empty garage.
So I am adding to the facade engine the ability to specify mid-level objects and roof objects separately; Tom can use that to “thin out” the objects in the garage. The result will be a big reduction in OBJ count for almost no visual quality loss.
I think there’s a lot of fine tuning we can do like this to make sure that we spend our hardware budget only on things that really matter most.
This isn’t really a type of optimization, but it’s important to make sure that the rendering engine can throw visual detail out to meet the requirements of older computers. One of the problems with X-Plane 10 is that some parts of the rendering engine only have one mode: “maxed out”.
10.04 beta 2 will allow facades to specify attached objects (like the cars on the parking garage roof) that decrease in density with the rendering settings. The result will be a full garage when objects are on “insane” but a mostly empty one with just a few cars when objects are on “default”.
Tom and I are working to put this kind of object density control in all of Seattle (as well as the airport library it uses and the rendering engine components that the library uses); the result should be a Seattle demo area that becomes significantly cheaper when the rendering settings are dialed back just a bit.
I had a chance to catch up with Robin the other day and discuss airports with him. Here’s the basic road map for airports in X-Plane 10.
In version 9, an airport consisted only of taxiway layout data. Robin collected and managed a big database of contributed airport taxiway layouts, which are available under GPL and ship with the sim. WED 1.0 lets you edit these layouts.
In X-plane 10 we now have three categories of airport data:
- The taxiway layout – this lives in the apt.dat file.
- The ATC taxi layout and flow information. This also lives in the apt.dat.*
- Lego brick building placements. This lives in an overlay DSF.
Our plan for the version 10 run is to collect all of this data together and redistribute it all, just like we do the current apt.dat file.
We also plan to build a few airport building layouts ourselves, using the existing lego bricks, without custom elements. This will help us further debug the bricks, get users some more airports quickly, and help us understand the authoring process. We have some of Tom’s time earmarked for this.
WED 1.2 will support taxi layouts and airport building placement. Based on my talk with Robin, I believe I will also need to build a more specialized “Send to Robin” export function that pre-checks and packs the submission to streamline the process; since an exported airport will include DSFs and apt.dat files (and should not contain custom OBJs) having the packing be automatic will save everyone a lot of time.
What about autogen buildings? I don’t know. We wanted to try this before we shipped and ran out of time. I think we could autogen buildings for small airports that just have buildings next to the autogen taxiways, but for custom layouts I don’t know that autogen will ever be good enough to make humans happy.
Over the next few weeks I’m hoping to have more time to roll out tools and documentation to move this process forward. The library is already complete, so the quicker we can get everyone using it, the better.
* If you have an airport layout wihtout taxi layout and flow information, X-Plane automatically generates default flows and layouts.
My last few posts have tried to paint a picture as to where the various art assets and files will live for the new ATC and airport lego bricks in X-Plane 10. I want to specifically point out how the library interacts with these features because the library lets you do some very powerful things, and I suspect that it is often misunderstood.
First: if you want to use our art assets, you get them via the library. Almost every scenery art asset we provide in X-Plane sits in the library somewhere. This includes most of the art assets we use to build airport apt.dat layouts. So whether you want our lego brick terminals, ATC voices, taxiway centerline light strings, or autogen buildings, they’re all in the library and you can “just use them” in your custom scenery by referencing the library.
But second: since the default scenery goes to the library to get art assets, you can replace our art assets with your own using a scenery pack. Don’t like our runway lights? Make your own and put them in the library via a custom scenery pack. Want more variety of cars? Make a few more and put them in the library via a scenery pack.
Since the library can be customized in location specific ways, you can also make new themes. Replace our autogen with something appropriate for your own country, and put the pack in the library with the locations you want your art used for.
There are only a few files we intend to collect and redistribute – and they’re all files of data. But modifying the sim’s art assets is still really easy – if you want to add art assets to the default parts of the scenery system, just make a custom pack that puts your assets in the library – it’s as good as if it was built into X-Plane.
This post is going to be a bit of a brain dump: I will explain where the various new types of data go for the new airports and ATC system.
First: everything lives in scenery packs. Since X-Plane 9, every bit of scenery X-Plane has (including the default airports, global scenery, and art assets for taxiways) all live in scenery packs. Those scenery packs live in Custom Scenery (if installed by user) or Resources/default scenery (if installed with the sim). The global scenery packs have their own folder in the main X-Plane folder so you can find them easily – at 78 GB it’s likely you might need to delete some, then reinstall later.
A scenery pack in version 9 can contain the following “stuff”:
- DSFs – that is, scenery tiles for 1×1 degree areas of the world. Those DSFs can contain a base mesh or just overlay 3-d on top of another base mesh.
- Art assets (.obj, .fac, .png, etc.) in any sub folders desired.
- apt.dat – an apt.dat file can provide replacement airport layouts on a per-airport basis. You can replace one or all of the airports.
- library.txt – a scenery pack can publish its art assets to the library for use by other scenery packs.
In X-Plane 9 we ship a scenery pack with most of our airport art assets (published to the library) and we ship another scenery pack containing Robin’s latest data – we try to update this scenery pack in each patch to match Robin’s latest.
In X-Plane 10, scenery packs are still the way you get your data into the sim. In fact, all ATC data sits inside a scenery pack too. We figure that you might want to make a custom airport with custom ATC, custom airport layout, and custom buildings. So rather than reinvent the wheel, ATC data is part of scenery data. The ATC data shows up in a few places:
- Airport ground operations data actually live in the apt.dat file. This includes “flow” information (e.g. which runways are in use, what’s the pattern runway) for various operations as well as the ground taxiway layout. The ground taxiway layout specifies a connected line graph of where airplanes can taxi. (Note that there is only one taxi layout even if there are multiple flows. This is because even if the runway in use changes, the concrete doesn’t move.)
- Airport controller and airspace specifications (including tower controllers) live in a new atc.dat file – you can put one in each scenery pack, not unlike the apt.dat file.
- Voice packs are created using a .voc file and a pile of sound files. Like OBJs, they can be put into the library – voice packs are the “art assets” of ATC.
Why is it that the ground layout is in the apt.dat file but the controllers are not? Robin collects the apt.dat file, and we wanted to make sure that if someone moves the pavement, that person moves the taxi layout too. Having them in separate files would be a recipe for a loss of synchronization.
Note that there is no mention of airport buildings in any of this. Airport building locations will ship as DSF overlays – they’re a scenery pack just like we have in version 9. The default art assets made by Tom will also live in a scenery pack and be exported to the library for anyone to use.
Since everything is implemented via scenery packs, you can create anything we can create, and you can publish your work directly via a custom scenery pack. You don’t have to share your data with any of the central collection-and-databasing efforts to use this new technology.
There will be two types of scenery packs that ship with X-Plane (and are updated via free patches during the lifetime of the sim).
First, we have default art assets that we provide to make the sim work and to help you create scenery.
- Default airport elements, including the airport building lego brick library.
- Default ATC voice packs.
Then we have scenery packs that come from collected data. We ship the latest updates.
- Default airport file from Robin, containing airport pavement layouts, gate positions, and (in v10) taxiway diagrams and runway flow information.
- Default airport building placements (in DSF form). We will start this file off but then it will become something that everyone can contribute to and use.
- Default ATC controller file, containing airspace information and controllers/frequencies. We will seed this file with center controllers to cover a big chunk of the world, but I am hoping that we can accept user-submitted corrections and contributions.
(If you squint at this list, you’ll see the divide: we are trying to involve the entire community in data-gathering activities, but we are having our internal art team make the default art assets.)
Finally, there is one more piece to the puzzle: autogen. Autogen is a horribly ambiguous world in flight simulation because it means 85 different things. So let’s be more specific: automatic in-sim generation of data. When the sim is missing data, what data will X-Plane “make up” on the fly? There are two cases of automatic data generation in the sim while you fly in version 10:
- If there is no controller specified in any scenery pack for a given airport, but there is a tower/ground/delivery frequency for the airport, Chris’s ATC engine will automatically create a controller based on the frequency. This means you get tower/ground/delivery ATC on the right frequencies for all of the towered airports, even if we don’t put those controllers in the default controller file.
- If there is no airport layout for a towered airport, we will generate a taxi layout and default flows by picking runways and analyzing the taxiway structure. This allows you to have AI ATC at any towered airport. (The layouts that X-Plane generates are not going to be as good as what you can build in WED.)
We almost always prefer pre-generation of data to in-sim generation – it lets us use a higher quality algorithm without hurting fps. (One of the limits of the ATC layout generation algoirthm is that it can’t use too much memory since it is running inside X-Plane.) But in the case of airport controllers and layouts, a custom scenery pack can contain an airport that we’ve never seen before – so we have to be able to generate the matched ATC data on the fly.
My previous post describes some of the new tech behind the airport system. It’s important to remember that we can provide a single “lego brick” in the airport system that places multiple OBJs (e.g. an .agp scene or a .fac facade with attached objects), and it’s also important to remember that simple OBJs are reasonably fast in X-Plane 10, so using a bunch of small, simple objects can be a win.
With that in mind, our current plan for gates and jetways is:
- Provide a lego brick to create a parking spot. This lego brick would be located at the same place and heading as the apt.dat start location – it would be an .agp mini-scene that would bring in the ground markings (via an OBJ with draped geometry) as well as any other nearby equipment that we want to populate and align relative to the airplane.
- Provide a lego brick jetway that has an anchor point on the terminal facade wall. The jetway will be static in 10.0 – we’ll address animation in a patch.
- Provide wall type rules that control where there are (and are not) windows, so that you can ensure that there aren’t windows underneath the jetway.
Thus, placing each gate in WED should be three clicks: jetway, ramp start, parking scene. The ramp start and parking scene will be colocated. (We could probably create a function in WED to make ramp starts for every parking scene to make this even easier.)
The jetways will align with the facades by locating the point location of the OBJ (that is, the single point where you tell X-Plane to put the OBJ) with a point on the facade wall. First, you’ll split the facade wall at the point where the jetway belongs, then you’ll place the OBJ.
Why split the wall? Splitting the wall guarantees there won’t be windows underneath the jetway. The facade wall definitions are set up to have non-glass at the end of each side. so by dividing a side in half (for example), you ensure that there will be a few meters of non-glass right where you need them. The art definitions will be set up to ensure at least enough “jetway-friendly” wall for half a jetway on either side of a segment.
We considered attaching the jetways and parking scenes directly to the facade wall, so placing a facade terminal would “auto-gen” the parking spots, but ultimately we rejected this for a few reasons:
- The facades can’t spawn ramp starts – you’d have to place those by hand anyway.
- The ramp starts might not align very well with the facade, which would look bad.
- Users who fly online or care about realism care about having real-world gate locations. Autogen gates and jetways wouldn’t provide enough precision.
- We looked at a number of proposals to autogen gates with exact precision but they were all insanely complicated.
Before I can describe the way we are planning on handling Jetways in X-Plane 10, I’ll have to describe some of the rendering technology that goes into the lego bricks; the airports are built on a bunch of new version 10 features.
- Global lighting. The airport objects come with lights that cast halos in all of the expected places. Sometimes the light is attached to a building, but there are also tand-alone “light pole” lights. This simplifies placement and arrangement because you don’t need to worry about matching LIT textures on the ground to your objects. You simply place lights and the resulting lights do what they should. If things are too dark, just place more lights.
- Draped geometry in OBJs. In version 10, an OBJ can have draped geometry that sits on sloped ground perfectly. Tom uses this for parking spot markings, etc. To place a parking spot, it’s one click in WED to place the object and you’re done.
- Improved OBJ performance. On machines with new video cards, we use instancing to draw OBJs if they are simple enough (e.g. no animation, no material attributes). This means that the cost of very small, simple objects is much lower than in version 9. Thus you can place a lot of clutter on the apron and it shouldn’t hurt performance too much.
- Attached objects on facades. A .fac facade definition in version 10 can have attached objects, the same way the roads do in version 9. In version 9 we used attached objects to add pillars to road bridges; in version 10 Tom can attach a light pole object to a facade and it will automatically be placed in alignment with the facade section that it matches.
- Custom facade wall selection. in X-Plane 10, you can pick which art asset wall definitions are associated with a given facade. For example, when you place the fence facade in WED, you can pick which section has the gate. When you place a terminal, you can pick which sections have windows and which do not. (The wall selection is made via a popup in WED – WED reads the wall names out of the .fac file.)
- Autogen Point scenes (.agp files). An autogen point scene is a draped footprint texture which is annotated with a mix of vegetation (defined by a .for file), objects, and even facades. Tom builds the .agp in Blender, forming a “mini-scene”. You place an .agp just like an OBJ in WED – you specify its location and heading – point and click. (The file is called autogen point because it is located at a single point in the DSF.)
- The ground tile from an AGP can use a special shader that adds various amounts of grit and other high-res textures; a control texture with primary colors painted into it specifies where the various high-res texture effects take effect.
Autogen point scenes allow Tom to build a building that comes with extra objects (parked cars in the parking lot, a mailbox), facades (a fence around the object) and a draped polygon all in one click. Putting it all together, you can place an autogen scene in one click and get a facade with exact wall types, lots of objects (that run quickly) with instancing, and global lighting shining on the entire situation.
All of this rendering tech is also completely available to third parties – you can make your own .agp art assets or your own facade types with custom walls, etc. Everything that the airport lego brick library uses will be available via text files in your custom scenery pack.
There were a bunch of questions in the comments about the airport lego brick system. We’ve talked about it a bit, but we’ve never really described the project in one place. Tom sent out some pictures of the system as he was testing it, so I’ll repost them and explain what’s going on.
First, the basic idea: for the last few versions, X-Plane 9 has shipped with default airport layouts (built off of the apt.dat file) but no buildings. The apt.dat file is an open source data file managed by Robin Peel; Robin integrates multiple public data sources and users submit their own improvements and changes. The result is high quality airport layouts despite the lack of a good free global data source.
When we were first looking at new features we wanted to put into X-Plane 10, airport buildings were a high priority; we didn’t want the airports to be empty. Thus airport lego bricks were born. The idea is:
- Our art team builds a series of useful art components for airports (“lego bricks”), e.g. terminal buildings, hangers, light fixtures, trucks, etc.
- LR seeds part of the world with some initial buildings. I don’t yet know how many buildings we will put down. When an airport layout is automatically generated by Robin (just a runway and taxiway) we can easily put down buildings, but for a more complex layout a human may have to look at the layout and say “that’s where the hangers go.”
- WorldEditor 1.2 will have features to edit these layouts. (Tom is using WED 1.2 now – in fact, the source is posted. It’s my hope that we can get WED 1.1 out ASAP once X-Plane 10 is available.)
- LR or Robin or someone collects the placement data for these structures and integrates user submissions, as well as layouts that LR builds internally.
- The new data from all sources goes into X-Plane updates so that users get new layouts quickly.
The lego bricks come in forms you already know of: OBJs and facades, as well as a new “autogen point” file which I will explain in another post. Here is a picture of WED 1.1 with a simple airport layout that Tom built.
The green polygons are forests; the gray polygons are facades. In X-Plane 10 and WED 1.2 you can pick the wall types for each wall of a facade, so the walls are now color coded. (When you select the facade, a popup menu has names like “wall with jetway” or “glass wall”.) Placements of OBJs and autogen have real previews from the top down.
It is my hope that building these kinds of scenes will be easier than building the underlying pavement, because most of the airport elements are drag & drop objects, e.g. you just point and click; the facades are simply traced as outlines. To build a layout using these parts you won’t need to know how to use a 3-d editor, hack an OBJ file, texture-map a 3-d mesh, and you don’t have to do your own texturing work.
But what do the results look like?
Not bad for point and click. The airport lego bricks leverage the rendering engine enhancements in version 10 to provide a lot of detail without having to build a custom scenery pack:
- Since X-Plane 10 has global illumination, light fixtures (either attached to a premade object or in one of the dedicated light posts) simply shine down on whatever is nearby. Put an airplane under a light post and the results look correct – no render-baking required.
- The version 10 facade engine is greatly enhanced; that terminal with jetways sticking out is a v10 facade, and it is in full 3-d.
- X-Plane 10 features new shaders that add extra detail to surfaces – that’s where the grit is coming from in the driveway in the third picture.*
- If the user enables shadows, 3-d casts shadows on everything else. Put a car next to a building, and it will be in shadow, but only at certain times of day.
We have not yet built the submission editing and review process, but at this point the plan is to collect and redistribute overlay DSFs – they are the logical container choice for a bunch of OBJ placements. We are not planning a special .dat format for these buildings.
A few other questions that have come up:
How will ATC data be handled?
Traffic flow information (e.g. where the planes taxi) sits inside the apt.dat file and will be collected as part of the regular apt.dat process. Non-airport ATC data will be collected separately; more on that some other time.
Can this be used for custom cities?
No. The scope is strictly airports. We can collect placements for airports because:
- Airports start out truly empty – the DSF generator clears them out. So there are no conflicts with autogen. For cities, we’d have to “coordinate” with the default buildings and roads, which gets complicated fast.
- The number of “things” in an airport is small – maybe hundreds if you really get into detail, compared to hundreds of thousands for a city. So it is practical to completely build an airport.
- Because one person can build an airport, we only have to worry about conflicts between submissions – we don’t have to worry about merging several parts of a city.
- The set of art assets we need for an airport is limited, so we can provide a reasonably complete library.
- Airports are really important to a flight simulator, so it’s worth all of the effort on everyone’s part to do this.
Generally speaking, I would like to increase user involvement in all parts of the scenery process. I get a lot of emails where people ask “how can I change X” or “can I fix this and send it to you”. The scenery system needs to address both highly skilled authors making complex custom payware packages and casual authors who want to do a freeware pack or just contribute to the overall quality of scenery. So we’ll be looking more at how we handle cities and OSM data in the future. For now we have our hands full just getting OSM water and roads into the sim.
Can we use other objects, custom or from OpenSceneryX?
No. The default layouts need to be built entirely from art assets that ship with the sim. We think OpenSceneryX is great, but the goal of the airport lego bricks is to solve a small, specific problem in a self-contained way, so that people can download the sim and immediately see buildings.
How does this relate to custom scenery?
The lego bricks definitely do not make custom scenery unnecessary – they provide a general set of elements for airports, but I think users will continue to want partially or fully customized airports.
A good analogy is the default instruments: because X-Plane ships with over 900 premade instruments, a user can rapidly build a decent looking 2-d panel with no photoshop or dataref work. But to make a panel that truly looks like the real plane (or to work in 3-d) custom work is needed – it’s more effort but the results are better. Airports will be similar: generic layouts will look good, but custom work will look better.
(Could a payware custom scenery pack include generic elements? I don’t know. In the airplane world, if a payware airplane contains default instruments it tends to get poor reviews. But I don’t see why a custom airport couldn’t use our lego bricks for some of the smaller elements like light poles and baggage trucks, if the main buildings were fully customized.)
* It is possible to make grit effects in X-Plane 9 in the same manner that it is done in MSFS: place a translucent overlay polygon with a high-frequency repeating texture on top of the surface you want to make “dirty. Having this capability in a shader in X-Plane 10 improves performance – we can draw one layer of “stuff” and have all of the effects go down at once.