I have blogged before about the importance of not shipping products that target beta builds of X-Plane, and the importance of waiting to the end of beta for file formats to settle down.
This also applies to the library! While we are in beta, objects in the library may be renamed or disappear in ways that could break your scenery.
So if you are making custom scenery that uses our library, you have two options:
- Ignore the beta; develop against the last stable release (10.11) and use that library, which we will continue to support.
- Use the beta, but don’t release yet, and be prepared for objects to come and go.
In other words, if your custom scenery works in 10.11 but fails in 10.20, please file a bug – we screwed up.
But if your custom scenery works in one 10.20 beta but not another 10.20 beta, don’t use 10.20 beta objects yet – they’re not fully cooked!
I have updated the OBJ8 specification with the new X-Plane 10.10 commands. This blog post explains why we added some of these commands.
Pixel-Space Drag Manipulator
The pixel-space drag manipulator is a new axis manipulator whose drag length is measured in screen pixels instead of meters; its drag axes are always screen aligned, but it works both horizontally and vertically.
The goal of this manipulator is to make draggable knobs that:
- Have a good response speed for both slow and fast drags via a non-linear curve and
- Have the same drag sensitivity no matter what camera angle.
The axis manipulator has the problem that it works in 3-d; depending on how you look at the manipulation target (both position and rotation) the sensitivity of the drag can change radically.
Recommendation: use the regular drag-axis manipulator for levers and other physically moving items. Use the pixel-space drag manipulator for drags where the underlying target does not move, like knobs. Use button-type clicks for anything that just toggles – it’s easier on the user.
No Shadows
Three new attributes (GLOBAL_no_shadow, ATTR_no_shadow, and ATTR_shadow) allow you to exclude part or all of your object from shadow casting. Shadows can make certain types of geometry, like grass billboards, look silly; excluding them from shadows fixes artifacts.
Note that ATTR_no_shadow is different from ATTR_shadow_blend..
- ATTR_no_shadow: the geometry simply does not cast a shadow! This is meant to exclude objects like vegetation.
- ATTR_shadow_blend: the geometry does cast a shadow, but only if the alpha is greater than a certain ratio. This is meant to make windows with tint cast shadows correctly.
Recommendation: fix shadowing bugs using ATTR_no_shadow for non-instanced objects, and GLOBAL_no_shadow for instanced objects. Use the Plane-Maker check-box for parts on aircraft.
GLOBAL_cockpit_lit
This attribute lets you have your cake and eat it. In X-Plane 9, ATTR_cockpit gives you alpha blending, but ATTR_cockpit_region gives you correct 3-d lighting. You have to pick one or the other.
In X-Plane 10.10, GLOBAL_cockpit_lit gives you both. It makes ATTR_cockpit use 3-d lighting (while maintaining translucency) and it makes ATTR_cockpit_region respect alpha translucency (while maintaining cockpit lighting).
You can add this attribute to any airplane. This attribute should make it easier for authors to adopt correct 3-d lighting in their airplanes.
Recommendation: use GLOBAL_cockpit_lit on any airplane that uses ATTR_cockpit to change to 3-d lighting for your panel texture. Also see here for more guidance.
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.
Global Lighting
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.
Draping
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
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:
- 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
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.
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.
What Next?
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.
Cheat!
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.
Scale Down
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.
