On my todo list for X-Plane 10.0: do something to get rid of the goofy reflections in the planet-wide water. The problem is that the reflection tricks that we pull to draw water look wrong when we zoom out so much that water surfaces are curved.
So what if we just got rid of planetary water entirely?
Apparently the ocean is “full of stars”…
Here’s another picture, lest you think I spend 100% of my time destroying X-Plane’s shaders.
That’s still in the shader development stage – I’ll toss it to Javier to work out the tuning once it’s a little bit further along.
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?
ff
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.
If you want to submit an airport layout to Robin in time for the X-Plane 10.0 scenery render, please submit it to him by October 1st, 2011. See http://data.x-plane.com/ for more info on the apt.dat file.
(And yes…my previous estimate for when we’d be cutting the scenery was off by a lot. I apologize to everyone who crunched for that deadline. For what it’s worth, I told Austin that if we didn’t get X-Plane 10 out this year I’d cut off one of my fingers.)
We will not be accepting ground traffic flow layouts for the new ATC system or user-submitted building placements before the sim is released. Once the sim is out there we’ll start working on that process. Our intention is to collect and redistribute airport building layouts and ATC data (using X-plane 10’s new airport element art assets) the same way we do for apt.dat files.
This post is going to be geeky, and probably only of interest to X-Plane authors who have worked with OpenStreetMap data.
OpenStreetMap represents roads as a series of points…a lot of points. One of the problems with importing OSM into X-Plane is that the data density goes well beyond what X-Plane was designed to handle. I have seen OSM roads with a point every 8 meters!
Even if X-Plane could handle that data density, how do we fit all of OSM onto a few DVDs? The answer: convert the list of points to bezier curves.
This is the raw OSM line data for the interchange of I-8 and I-5 in San Diego. Actually, that’s a bit of a lie; the data has been reduced significantly in density. We reduce the data up front to avoid killing our DSF generation software, but also because the curve-generating process doesn’t need all of that data to do a good job.
This is the result of curve generation. The DSF generator tries to fit the minimum number of curves possible to the points by first converting line segments to approximate curves, then replacing pairs of curves with larger single curves up to a certain error point.
The error tolerance varies by road type: exit ramps are given a lot of leeway because they look good as long as they are loops; city streets are kept precise so that the curves don’t crash into buildings. Most precise: railroad tracks, where pairs of tracks are often very close together.
In this diagram, the blue and purple lines are the original curves and the white ones are the simplified replacement, showing error; the points are the actual data written to the DSF. Look at how few points we need for those on-ramps! At current settings, the algorithm reduces the size of road data in San Diego by about 25%.
Here ya go!
WED 1.1 beta 4 is now posted – see the Scenery Tools wiki for download links. Thanks to Matthias for the patches to remember the hierarchy’s open/close state – I suspect a lot of users will appreciate this detailed touch. Thanks also to the handful of users who tested some early versions of this beta – there are a bunch of big changes in beta 4 that needed a few tries to get right. (If you find bugs in WED or any of the scenery tools, please report them here.)
This will hopefully be the last beta for WED 1.1, setting us up to move on to WED 1.2 with X-Plane 10 editing features; beta 4 contains three areas of improvement that had needed attention.
Correct Preview Order
WED used to preview scenery based on the order of your work in the hierarchy. This isn’t so good because X-Plane has its own draw order based on layer groups. The next beta will do a much better job of showing the final draw order that X-Plane will use, so you aren’t surprised when you view your exported scenery.
Saving Work When the Undo System Blows Up
There has been one data loss bug in WED that has persisted since version 1.0: if the undo system blows up, you get a nasty error (“WorldEditor has hit an error due to a bug. Please report the following to Ben…”) and no chance to save.
The next beta will automatically save your work in a special file (earth.crash.xml) that you can use to get your work back in the event that the undo system blows up.
Why does WED crash like this at all? The problem is that the undo system saves incremental deltas as you edit your project, to save memory (so we can have a gajillion levels of undo). If the book keeping gets screwed up, we are hopelessly borked because with missing deltas we can’t ever get the project back to a state that makes sense. Once we lose deltas, we’re lost. The error dialog box pops up when it does so that we can know that the problem is with the undo system – otherwise we’d just have an inexplicable crash with no idea what went wrong.
When last I checked, there were only one or two users still seeing undo problems – I’ve added additional logging, so if you do see problems please file bugs!
Changing the File Format
WED 1.0 uses a database as its file format. While this seemed like a good idea at the time, it has since proven to be a performance and maintenance problem. The next beta of WED will use an XML file format.
WED 1.1 will still read the old database format (including the format used in previous betas), so you can open your old projects. Projects saved in the new beta will not open in the older betas, but this is no surprise.
For the nerds: when I first started working on WED, I thought that it might be useful for WED files to be databases so that bulk operations could be performed on large quantities of data. Since then I’ve realized that WED isn’t a GIS or spatial database app – rather it’s a modeling tool. The new XML file format is basically a direct output of its internal editing-centric format.
A few random items in no particular order…
- Comments to the dev blog should be working again – sorry about that. WordPress hoses the file system permissions every time we update the anti-spam plugin (which is very important btw – WP is a spam magnet) and as usual I forgot to fix it.
- The dev blog (and news feed on the main site) are slow because of the social networking plugins. I’ll be poking at this a bit next week when Chris gets back. We do have a cache on the blog, but local browser cookies can interfere with it.
- If you’re running OS X 10.5.8, have a decent machine (e.g. at least a few cores or a DX10 or better graphics card), etc. and you are going to run X-Plane 10, then you should update to at least OS X 10.6. 10.5.8 is missing some key OpenGL driver extensions, and the system memory allocator is really bad in the multicore case.* (I spent part of today making 10.6 my main OS and 10.5.8 just for testing because I can’t work with the poor allocator anymore.)
* For X-Plane 9, we put a third party high-speed allocator, “NEDMalloc” into X-Plane. We will not be doing this for X-Plane 10. All of the modern OSes (modern Linux, OS X 10.6/10.7, and Windows 7) contain high quality system allocators, and having a second allocator “layered on top” lowers our total memory capacity, which we don’t want to do.
My previous post announced that a previously pre-computed operation (setting up the elevation of a DSF) will move into X-Plane in version 10. We have multicore and we can save some space and improve quality.
This led one commenter to speculate as to whether the entire meshing process can move into X-Plane. Unfortunately it cannot; a lot of other scenery creation processes are tied to pre-building the mesh, and some of those are still very, very slow. But it does beg the question of how more we might move into X-Plane.
The Original Precomputation Decision
The original DSF strategy (designed for X-Plane 8.0 a long time ago) was to pre-compute all of the difficult problems for scenery tiles so that X-Plane could simply load the data and draw it. This got us four things:
- We could use expensive algorithms to build scenery without hurting sim performance.
- We could pre-optimize the scenery for fast frame-rate, even if those optimizations were slow to compute. (No one cares if building the scenery takes longer, that’s done before your DVD is burned.)
- In some cases, we could reduce data size if the finished computed output was smaller than the input files.
- Scenery is deterministic – because the work is done ahead of time, changes in the sim don’t affect how scenery looks. New scenery technology mostly goes into the off-line scenery generator, which means less backward compatibility work.
The down-side of this decision was that we didn’t have a good way to integrate or modify scenery data on the fly. Changes in apt.dat files, for example, are not reflected in the scenery, since the scenery is already “fully baked” when the sim boots.
From Precomputation to Multicore and GPU
With X-Plane 10 we’re doing a few things to move rendering work from “ahead of time” to “while you fly”, using multiple cores and the graphics card for the work, since those are areas where computers have gotten a lot more powerful.
- In X-Plane 9, terrain is selected by slope (among other things) – this is why you see steep cliffs and moderate scree above grass and forests on a mountain side. In X-Plane 10, some of this happens on the GPU – we build a single shader with three terrains, and the GPU picks amongst the terrain on the fly.
- In X-Plane 9, we pass the raster elevation mesh to the DSF loader, rather than bake it into the mesh. Eventually we may be able to pass this data directly to the GPU.
These two techniques are meant to someday play together: if the GPU has the elevation and knows how terrain changes with slope, then we can have detailed terrain on the GPU without bogging down the rest of X-Plane.
Going Further
How might we further push this technology? I can imagine that at some point, if the sim can arbitrarily increase the triangle density of a mesh using the GPU and the raw elevation data, then we could reduce the triangle density in the DSF to only the triangles needed to represent land class changes, saving DSF space.
Using a triangulation to represent polygonal vector data isn’t as crazy as it might sound; there are a number of computer algorithms that subdivide polygons into triangles to lower the computational cost of processing them. (We even use one such algorithm to simplify complex polygonal shapes – see MapHelpers.h in the scenery tools code for the scary details.)
So in the long term the triangle mesh that drives X-Plane scenery can change from an approximation of elevation (with terrain along for the ride) to an optimized way to store terrain polygons (with elevation to be applied later).
Here’s a clearing house of past links on the topic of precomputation and global scenery:
For something like six or seven years, DSF has fundamentally been a vector scenery format, meaning it contains points, lines, and connections between lines that define how scenery looks. With X-Plane 10 we’ll be adding raster data to DSF.
One way we’ll use raster data inside DSFs is to store the raw elevation data for a DSF tile. Originally we saved only the final triangulation of the mesh in 3-d; we will now save the triangulation in 2-d* and the raw elevation, which X-Plane will put back together again.
We get a few wins from storing elevation separately:
- After compression the files are actually smaller. This is because the data is more “regular” when stored in raster format than as part of the triangulation, and also because we don’t need to store normal vectors.
- Since we’ll have the elevation data in its original form, we can use it to someday enhance the mesh for graphics cards that support hardware tessellation.
If raster data is a win in both quality and file-size, why didn’t we do this originally? Two reasons:
- Originally DSFs shipped in zip files; the big win in compression with regular data comes from the more advanced 7-zip compression we started using to ship X-Plane 9.
- Raster encoding means increased load time in the sim as it “puts the mesh back together”. Today in a multi-core world this is totally moot – DSF loading happens on another core, but originally DSFs had to be loaded on single-core machines, so load time was a key performance point.**
We will also be able to put other data into the DSFs, although I’m not sure what the final file set will be. Good candidates include bathymetry data and urban-density data to affect autogen.
Finally, we get a lot of requests from plugins to access X-Plane’s elevation data; with an irregular triangulation, access via plugin isn’t practical. But with raster data, the code to locate and view the raster block inside a DSF is actually pretty easy and the data comes in a simple, easy-to-use format. This might be useful for moving maps and other such technologies.
* Technically we store the triangulation as a flat 3-d mesh; DSFs RLE encoding means that the all-zero elevation and normal-offset fields crunch down to nothing.
** The decision to make roads 2-d and set up their height at runtime is a similar decision; the original 3-d roads took up more DSF disk space to save load time.
My previous post went on a massive ramble about “wicked problems” and “knapsack” problems – the short version is that I’m working on DSF generation. Here are a few more pics from DSFs in drydock.
Not everything is unsovled problems; these pics show an algorithm that “removes noise” from digital land class data – the idea is a riff on this paper. I’m still not sure where it’s going to fit into the flow of data in scenery generation, but we’re looking for it to consolidate forest types.
What does autogen look like while it’s being born? It looks like this. For X-Plane 8 and 9, the autogen is built using bitmap technology – the DSF generator literally builds a bitmap image of a city block and tries to “fit” buildings by drawing them and checking for per-pixel overlaps. Version 10 changes this completely – autogen is built polygonally. In this pixture, the blue polygons are strings of houess built around roads; where the terrain is too steep, the polygons are clipped.
Getting polygonal autogen setup to be fast enough for production use has been a battle, but we’re getting there.
