This is a view of the underlying vector data for the current KBOS taxiway layout. It is floating above the ground because the data hasn’t been “draped” onto the layout yet. There are two copies because the data has been debugged once for each DSF tile that the airport spans; when the actual paint is put down, only one copy of the lines will end up on either DSF, so we don’t have double triangles.
These four buildings are facade-scrapers, a new feature in X-Plane 10.
X-Plane 8 and 9 support facades. A facade is a building definition that is extruded to an arbitrary shape and height specified in a DSF. Facades allow us to build custom-shaped buildings that fit a precise footprint. The walls are created by cutting and repeating a grid texture of windows.
With a facade-scraper, two objects are placed in the center of the facade to form a tower. The facade base itself can exactly fit a city block, while the OBJ pair gives us a tower with architectural detail.
This is a wire-frame view; the facade itself is wire frame, and the ground is wire-frame, revealing the two objects. The base of the facade sits on the ground, but the tower can move up and down, with excess underground. This allows us to customize the height of the building to precisely meet the DSF height.
(This facade is a test case that I built out of Alex’s Chrysler building; the UV mapping on the base is pretty rough since I was just creating test files.)
One or two more facade follow-up pictures. Here we have a curved facade airport terminal. There are still some bugs with how the roof and walls go together. A facade definition has two sets of wall definitions: one meant to be curved (with more vertices for smoother curving) and one with fewer vertices for frame-rates when a wall is not curved.
Here is the same picture in wire-frame mode. You can see the second layer of cars. The new facades can have multiple roofs – this feature was specifically put in to allow us to build parking garages.
By request: a series of shadow pictures.
From left to right: no shadows, 1 texture along 500 meters, 2 texture along 500 meters, 2 textures along 5 km, 4 textures along 5 km. The distance is how far into the distance X-Plane tries to apply shadows (longer distances mean more CPU work to shadow more of the world, with less resolution on the shadows) and the number of textures is the number of separate texture shadow maps we apply. The more separate shadow maps we apply, the more resolution we have to work with.
If there’s a take-away point for shadows, it’s this: they’re really freaking tweaky. They can look really good or really bad. The shadows you see here are not at all done; we still have a lot of tuning and optimization to do. But these pictures will give you an idea of why we didn’t ship shadows in version 9 (the way I had hoped to): when they look bad, they look really bad.
I suspect we’ll have rendering settings to let you use more shadow maps to get nicer shadows at lower fps, or tune them down for more speed; we already have this with the reflection detail rendering setting.
One difference between X-Plane 10 development and previous development efforts is that, because we have a fairly large art team (by LR standards), we’ve been developing a lot of the tools for version 10 scenery/airplane development during the main development cycle. In the past, we’ve gotten the sim out, then added the tools later; I think the delay will be a lot shorter this time around, since many of the tools more or less work.
For WED, we have some of the new 10.0-related features controlled by #define; they’ll remain off for WED 1.1 (which basically makes WED a DSF overlay editor for X-Plane 9.0) and then go into a WED 1.2 release. I think the timing will be tight – that is, we’ll get 1.1 finished during or right after X-Plane 10 beta, and then have a development preview of WED 1.2 almost immediately, by exposing the new features we are using internally.
What will be in the next crop of WED features for X-Plane 10:
- ATC taxiway layout editing for the new X-Plane 10 ATC system.
- A few more DSF tricks, like forests that render trees on the polygonal outline instead of the interior.
There are also some 1.2 features that we’ll get eventually that are in rough or partial shape right now:
- Autogen placement (works pretty badly right now).
- Road grid editing (still highly experimental).
WED File Formats
This brings us to WED’s file format. If you’re not a coder, suffice it to say nothing’s going to break…the rest is technical.
WED 1.0 uses a sqlite3 database to persist earth.wed files. This seemed like a good idea at the time – I thought it might be useful to do database-like queries against WED files. Unfortunately, it’s not a good idea.
- WED can’t run against the database, it loads it all into RAM, so the database is wasted.
- Using sqlite3 slows down development time and makes versioning files more complicated.
- The performance of the code that uses sqlite3 is poor.
I really do like sqlite3 as an embedded database, but my use of it is just not well thought out.
So I am planning to replace the sqlite3 database with some other file format. I am planning on doing this before finalizing WED 1.1, to get the change over with before I go any further with the database format.
WED 1.1 will continue to read sqlite3 databases for the purpose of opening legacy projects (both 1.0 and older 1.1 beta projects) but will only save in the new file format.
The new format isn’t yet decided, but the strong contender is a simple XML format that persists each object in the WED hierarchy. This would give us something structured, readable enough to debug, and there are lots of third party tools to work with XML.
If you area third party developer and have any strong opinions on WED’s internal file format, shout at me by email.
If there are two take-away points from this post, they might be this: there are a lot of new scenery system features in X-Plane 10, and I spend most of my day looking at surreal stuff.
Exhibit one: this is a next generation facade. Facades have been in X-Plane since 8.0 – they provide a way to construct a building from a polygonal outline.
In X-Plane 10, the facade engine is greatly enhanced, for the purpose of creating airport terminals. The facade on the left is a partly completed major airport terminal, with some random stuff put in by me for testing. Some of the new facade features:
- Facade walls are 3-d, containing real architectural features.
- Facade walls can support some level of translucency. You can see inside those windows.
- Facade walls can have objects attached – that’s where the jetways come from.
- Facade roof texturing is enhanced, for repeating, tiled roofs.
- Facade roofs can have objects placed at periodic intervals – that’s what all of those cars are. (I just grabbed the first object I found in the library.)
- In version 10 facades can go around bezier curves.
This is the same shot at night. The headlights from the cars illuminate the roof. No special trickery is needed for this – the cars have named lights, the cars sit on the roof, the light hits the roof. That’s the nice thing about global illumination: you attach lights and it just works; you don’t have to worry about what spill has to be baked into what texture.
This is a wider shot of the airport terminal with cars on the roof – as you can see, there’s a lot of cars. Since X-Plane 8, the sim has been able to cope wieth large numbers of objects visible for small distances. This is why we can build 10,000 3-d light fixtures at KORD and it doesn’t affect framerate. X-Plane 10 has some enhancements to the OBJ engine, including instancing, that should let us see more objects from farther away.
This is the matched night picture for the one above; you can see that having a large number of small lights casting global illumination doesn’t fps. With global illumination, the area of the screen the light covers affects fps but the total number isn’t so important.
Here are the cars with shadows turned on; like global illumination, shadowing affects everything, so you don’t have to worry about what scenery element is shadowing what other elements. The cars are on the roofs, ergo the cars shadow the roofs.
(You can see the shadow running out of resolution in the far ground – I still need to do a lot of shadow tuning; they’re really picky.)
Finally, one not totally ridiculous picture. (Poor Tom – I just post his art assets to the web regardless of what state they’re in; this’ll be the last time he sends me an updated library!) The building casts a shadow on the jetway, which shadows itself and the tarmac. It’s not until you take the shadowing away that you realize how much they sell the image.
I spend most of my day looking at X-Plane looking bad. If X-Plane looked good, there’d be no reason for me to look at what it was doing. (Poor Tom – I seem to alway
s have one of his planes loaded when I take a goofy screenshot. The Baron looks a lot better when it hasn’t been melted.
Besides pictures looking goofy due to bugs (that intersection was not supposed to have the sidewalks rotated) I often do my testing on old or random art assets I find lying around my hard drive. Those cross-walks aren’t even what we’re supposed to be using; they’re just something Alex sent me months ago to tinker with. Typically most of the scenery isn’t even in the picture to save time loading the sim.
A lot of the time the art assets that I use have been painted over to make debugging easier. The red, cyan, green and yellow intersections have been painted bright primary colors so I can see exactly where the 13 pieces of an intersection end up positioned. The real art assets are carefully drawn to blend together perfectly to create the illusion of a continuous world. Such a world is nearly impossible to debug!
A lot of what I see includes debug markings that don’t even show up in the final sim. The yellow and pink dots show various road grid mesh vertices; the color coding shows the level of mesh vertex duplication. (In this shot, there’s a lot of duplication – yellow – this was taken while I was measuring an inefficiency in the rendering engine.)
So I heed your calls for more screen-shots, but most of the screenshots on my hard drive are like the ones above, not the ones I am about to post; rather the ones that look like you might want to fly the sim are few and far between.
There are still a bunch of bugs in these pictures, but after staring at yellow dots, Dada-esque airplanes, and rainbow intersections all day, I was surprise to see something that looked vaguely like my home planet.
My Mac Pro (2.4 ghz Core 2, 8 cores, Radeon 4870) gets just about 20 fps exactly with those shots; that’s with global illumination and a shadow setting that will be medium; forests and autogen are maxed out. I’m hoping to get a bit more performance out of the sim when I have time to tune shaders, but that’s also an aggressive set of rendering settings on a no-longer-new computer.
We have not been adding features into X-Plane specifically to aid conversion of scenery from MSFS (and I don’t think we will), but sometimes features we want outright help solve conversion issues too. Here are two new features I expect us to ship in version 10 that should help the conversion of overlay scenery packs.
Draped Geometry: I’ve mentioned this feature before; basically in X-Plane 10, the horizontal geometry that sits “on the ground” can be marked for real 3-d draping, rather than just polygon offset. Draping is the process of actually cutting and shaping that geometry to perfectly ‘hug’ the ground – it’s how we can put a runway or taxiway on top of non-flat ground without Z thrash.
In X-Plane 9 you can create draped geometry, but you have to use .pol files; this can be awkward if you want to put an element in many times, share an element with other authors, or have an element on the ground match a 3-d object.
In most of the cases where I have seen serious Z thrash in scenery conversions, simply changing ATTR_poly_os to the new proposed ATTR_draped will fix the problem.
OBJ Elevation Control: X-Plane 10 will allow you to position an object vertically as well as horizontally, probably with something like this RFC.
For scenery conversions, this means that a scenery pack authored to a specific height elevation can be duplicated precisely.
For authors creating new work, this makes certain kinds of scenery possible that would have been very difficult before. For example, we get asked fairly often about LPMA. which features a runway on pillars. You can model as this as an OBJ with a hard surface, but in X-Plane 9 it’s very hard to predict what height that OBJ will be placed at. (Hack/work-around: place the OBJ in the water and model the geometry offset from the runway location. Most scenery packs should have the water at MSL 0.) With elevation control, the runway can be built at the real runway surface height and will be placed their explicitly.
Robin sent this out to the news list:
A quick note for X-Plane airport designers (if you are not an X-Plane airport designer then please disregard this message).
Good News – it is still possible to submit new or revised airport designs for inclusion in the X-Plane version 10 scenery generation process. Please send me any submissions before February 7, 2011 so that I can consolidate them and generate the special data files that will be used to generate the new global scenery. I need just the apt.dat file for each airport – if you have multiple airports, please consolidate the data into a single file.
Why is this important? When new global scenery is generated for X-Plane 10, the latest airport data will be used to:
- Define the “land use” in the vicinity of the airport. This will ensure that an appropriate terrain texture is used under the airport, and will also suppress the trees and auto-gen buildings.
- Smooth any terrain undulations in the vicinity of the airport.
- Ensure that runways have “land” underneath them – especially important for airports alongside rivers, lakes or oceans.
The best way to help this process is to define an accurate airport boundary in World Editor (WED). If no boundary is defined, we will try to approximate a boundary based upon all other available data for an airport. If you only have time to create an accurate boundary (but not the rest of the airport details) then that is fine also – I can still use such data for this process.
Let me know if you have any questions
– Robin
My apologies for the earlier false deadline – we thought we were going to cut the global scenery a lot sooner.
One of the comments on the suburban preview screenshots I’ve heard in a bunch of places is “I hope it’s not going to be that dark” or “could you guys add more light”?
At this point, light levels in our previews are not reflective (no pun intended) of how the sim will really look. The reason is simple: the light model is not fully debugged (who am I kidding — it’s not even remotely debugged) and it only takes one light model bug to completely throw off the light levels. So I think light levels are going to be a case where the sim’s lighting looks a bit funny right up until the last bug is swatted – it’s just the nature of those kinds of bugs.
To give you an idea of how much change there is in lighting from version 9 to 10, here’s a short laundry list of sim changes that affect lighting:
-
Dynamic Exposure. X-Plane 10 reduces the effect of emissive (_LIT) textures base on the brightness of the sun. In X-Plane 9, emissive textures have the same impact regardless of time of day; thus a lighting effect that looks good at night will look too strong during the day. (In real life, you eyes would adjust for the sun and the artificial light would seem less bright.)
-
Linear Light Mode. This gets confusing fast, but basically, our eyes perceive light in a non-linear way; we are more sensitive to low light levels than bright light levels. Computer graphics mimick this behavior; the result is that most computer lighting models are physically incorrect in some circumstances. Using the non-linear eye-based behavior has been the norm for while because it was cheaper hardware-wise, but these days it is possible to do physically correct linear lighting. We are adding this wherever we can; the correctness varies with rendering settings since physically correct lighting is more expensive GPU-wise and we don’t want to hurt fps for low-end users.
-
Deferred Rendering. X-Plane 10 has two rendering modes: a forward renderer (which is a lot like X-Plane 9) and a deferred renderer that supports global illumination and an HDR rendering space.* This creates a certain amount of chaos because the code for forward and deferred rendering are separate, and they seem to develop separate, unrelated lighting bugs.
-
Global Illumination. X-Plane 10 supports global illumination in deferred rendering mode, which means that thousands of lights can light up any part of the scenery system. Thsi means that (for the first time) an object may be lit by dozens of light sources at once. It turns out that the linear light model is a lot more important when we have more than one light source. (In fact, Alex and I realized that we needed a linear light model when looking at highways lit by streetlamps.)
-
New Light Billboards. X-Plane, like most flight simulators, uses billboards (textured squares that face the camera) to draw the light effects near a light source, like glare and bloom. The shape, textures, and equations for the light billboards are heavily revised in version 10.
-
Clouds. The weather system is being rebuilt, including new shaders for cloud puffs. Since cloud puffs aren’t like solid buildings or airplanes, they have their own shaders with their own light characteristics. We are also experimenting with increased ground visibility, which affects fog.
If there’s a take-away point, it’s this: lighting isn’t just one piece of code in X-Plane – it’s the sum and interaction of a large number of features, all of which are being heavily worked over. Only when all of the features work correctly and work together in harmony will we have what appears to be sane lighting.
* Some users may confuse HDR, which just means an image with increased dynamic range for light levels, with the more common effects that games ship once they have an HDR render: bloom and tone mapping. Bloom is when bright light sources “blow out” and splat light around nearby areas; tone mapping is a technique to visualize that high dynamic range on a normal monitor – often it is used to simulate your eyes adjusting to variable light levels.
I do not think we will ship bloom in version 10.0; I experimented with it and found it had almost no value. First, there are very few scenes in a flight simulator where bloom is that useful; it seems to be a lot more useful for interior rendering, like you’d see in a first person shooter. Second, X-Plane already has a number of bloom-like effects, including halos around lights via billboards, sun glare, etc. With most of the important cases already covered by ad-hoc effects, my early experiments with bloom weren’t very promising. We may revisit bloom later, but I don’t think it’s as important as other effects for now.
Similarly, I don’t think we will have dynamic tone mapping because we will have an overall dynamic exposure control running all of the time. Again, the value of tone mapping is more obvious with first person shooters, where you can go from interior to exterior and you want the world to be ‘overpoweringly bright’ for a while. By comparison, pilots do their best to preserve their night vision, and the interior of an airplane is designed to match that; instruments auto-calibrate their brightness to the overall light levels, making tone mapping less important.
A few days ago Tyler posted some pictures of the “auto-gen”* for X-Plane 10’s global scenery.
First, a few notes on hardware and performance: Propsman took these pictures on a new iMac, so that’s a core i5 and a Radeon HD 5000 series GPU – that is, a pretty decent system. Hardware technology continues to advance rapidly (especially on the GPU front), so there’s a big difference between a ‘decent’ system bought today and even a hard core system from two years ago.
I don’t know what your performance will be like. I do know that the system is performing well enough so far in its not-really-all-that-optimized form that we think we can ship it, and more importantly I know that we can turn the level of detail down in a number of ways to lighten the load as needed.
The most expensive feature you see here is the real-time 3-d global shadows. Heavy shadowing combined with heavy 3-d does add up and hit the system hard, but I think we’ll be able to have intermediate shadow settings that should be more affordable.
X-Plane 10 will use hardware instancing if your GPU is capable of it, and it makes a big difference in the amount of 3-d you can show.
X-Plane 10 is also quite a bit more fill-rate intensive than X-Plane 9; if your GPU is having fill-rate problems with version 9, some version 10 features will be out of reach. In the past, X-Plane has been light on fill-rate, so we’ve had users running with cut down cards (like a GeForce 8400) without realizing that their card isn’t that fast.
Some users have asked about architecture and localization. I expect we will not ship out of the box with multiple local regions; however, the library system allows us (or any third party) to provide new artwork sets for local, architecturally reasonable buildings.
Finally, it might be a bit difficult to see in these pictures (because they are focused in on the detail), but the 3-d buildings you see here work with the real-world roads. In the past, we’ve had a clash between the buildings and roads vs. the terrain texture. This is a problem we are solving for X-Plane 10.
* Auto-gen, meaning bulk buildings that populate the world in urban areas…whether it’s really auto or gen or anything like autogen in the past is a complex discussion that will have to wait.
This is a view of the underlying vector data for the current KBOS taxiway layout. It is floating above the ground because the data hasn’t been “draped” onto the layout yet. There are two copies because the data has been debugged once for each DSF tile that the airport spans; when the actual paint is put down, only one copy of the lines will end up on either DSF, so we don’t have double triangles.
