Procedural Modeling of Urban Environments

This was a half-day course, but the only lecture I saw (which I heard was by far the best) was from Pascal Müller from the Federal Institute of Technology in Zurich. Muller also had a paper in SIGGRAPH this year; his paper is available here, so follow along in that if you want a deeper explanation. This was pretty much the first time I‘ve seen a presentation on procedural generation of cities that I thought did a better job than SimCity. If Maxis is going to start working on SimCity again, the first step is to hire this guy. His wiki is here.

Here are my notes from his course talk on CityEngine, his city-modeling tool. I didn‘t necessarily takes notes on every element, because his paper on CityEngine is already available here.

CityEngine isn‘t an automatic generator, but an interactive tool for very quickly generating buildings. "It never happens that you just hit the button and everything looks great."

The general workflow is as follows: If you‘re modeling from scratch (he can also start with a user-specified street or lot grid), start with an extended L-system for streets. There‘s an L-system that generates major, then through, then minor streets; however, instead of being a pure L-system, it incorporates two other elements: there‘s a global goal system (for instance, connecting to neighboring areas) that influences where the L-system is applied; and secondly, there‘s a local reaction/diffusion system to try and maintain sensible street spacing on the small scale.

Defining Roads and Lots: Once the streets are established, it generates 3D road data out of the vector paths from the L-system (this should sound familiar to SimCity engineers). Then, the "blocks" defined from this need to get divided up into lots, each of which will be filled with an individual building.

At this point, you save the city because the rest of the work is essentially parallel within each lot. He talked about all the competing Geographic Information System file formats out there:

KML	Keyhole Markup Language. Generally the best format, associated with Google Earth.
GML	Geographic Markup Langauge. Basically an open-source version of KML.
SHP	This is the format associated with the commercial GIS system ArcView.
DXF	The lowest-common-denominator format, still used by many GIS systems.

Obviously, if you‘re using a user-defined street or lot grid, you read that in to continue from this point.

Modeling Massing of Buildings: Now, for each lot, we need to decide what the building that fits on it is. He starts by creating a bounding volume from the lot and statistics about population density and usage. Then, he uses a rule-based system (which includes some randomness) to replace each element of the building mass with a subdivision into other shapes. The library of shapes (cube, cylinder, etc.) and the relative sizes are governed by rules intended to capture the architecture of the time (e.g., "Art Deco" or "Roman Villa"). Here‘s an example from his "International Modern" ruleset:

Building Facades: Now that the masses of the building are established, he used a similar rule-based system that divides the facade up into multiple areas, adds details like column capitals, dormer windows, and so forth. An example rule he showed was:

1: facade(h): h > 9 -> floor(h/3) floor(h/3) floor(h/3)

The meaning is this rule is: For a facade of a given height, if the height is greater than 9, replace it with three "floor" elements, each of 1/3 the height of the original. Another, more complicated rule that gave rise to "Old Chicago" style buildings was

2: facade -> Subdiv("y",3.5,0.3,3,3,3) { ff1 | ledge | ff2 | ff2 | ff2 }

The meaning of this rule is: replace the facade by a sequence of elements "ff1", "ledge", and then three "ff2"s, where the space in Y is subdivided proportionately in the proportions given. In addition to these production rules and Subdiv rules, there‘s a "Repeat" rule which allows for repeating approximately as many sub-elements as there are space for -- the "repeat" rules are the ones which particularly allow for creating windows.

One of his coolest examples was a reconstruction of Pompeii, the roman city buried under a pyroplastic ash flow from Mt. Vesuvius. Because of many archaelogical expeditions over the years, we know the street elevations plan, building materials, and a fair estimate of the population density of Pompeii, but we don‘t know the details of many of the buildings. They started from the street and population density maps, and interviewed researchers in order to derive the rulesets for generating Pompeii‘s buildings. The coloration and decorations were well-established from Roman-era archaelogy.

One of the great things about this example was that it was fast -- Pascal said it took about 1 day to create the GIS data, 1 day to create the rulesets, and 1 days to create the individual elements (windows, roofs). They used Greenworks‘ XFrog to create detailed, biologically correct plants that the rulesets scatter throughout the cities.

In all his cities, he bakes ambient occlusion into the buildings as part of the outdoor lighting pass. If you check out his examples, you‘ll find that this multi-layered approach gives rise to very interesting, varied, and yet thematically unified cities.