Category: Tools

When Are We Going To Get High? The Plan For Cities

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.