Procedural Modeling of Cities

Procedural Modeling of Cities

Yoav I H Parish Pascal Müller parish@imes.mavt.ethz.ch pascal@centralpictures.com ETH Zürich, Switzerland Central Pictures, Switzerland

ABSTRACT

Modeling a city poses a number of problems to computer graphics. Every urban area has a transportation network that follows population and environmental influences, and often a superimposed pattern plan. The buildings appearances follow historical, aesthetic and statutory rules. To create a virtual city, a roadmap has to be designed and a large number of buildings need to be generated. We propose a system using a procedural approach based on L-systems to model cities. From various image maps given as input, such as land-water boundaries and population density, our system generates a system of highways and streets, divides the land into lots, and creates the appropriate geometry for the buildings on the respective allotments. For the creation of a city street map, L-systems have been extended with methods that allow the consideration of global goals and local constraints and reduce the complexity of the production rules. An L-system that generates geometry and a texturing system based on texture elements and procedural methods compose the buildings. CR categories: F.4.2 [Mathematical Logic and Formal Languages]: Grammars and Other Rewriting Systems: Parallel Rewriting Systems, I.3.7 [Computer Graphics]: Three-Dimensional Graphics and Realism, I.6.3 [Simulation and Modeling]: Applications Keywords: L-system, software design, developmental models, modeling, urban development, architecture

1 INTRODUCTION

Modeling and visualization of man-made systems such as large cities is a great challenge for computer graphics. Cities are systems of high functional and visual complexity. They reflect the historical, cultural, economic and social changes over time in every aspect in which they are seen. Examining pictures of a large-scale city such as New York reveals a fantastic diversity of street patterns, buildings, forms and textures. The modeling and visualization of large-area cities using computers has become feasible with the large memory, processing and graphics power of todays hardware. The potential applications for a procedural creation range from research and educational purposes such as urban planning and creation of virtual environments to simulation. Especially the entertainment market such as the movie and game industry have a high demand for the quick creation of complex environments in their applications. Visual modeling of large, complex systems has a long tradition in computer graphics. Most of these approaches address the appearance of natural phenomena. Much of the appeal of such renderings lies in the possibility to depict the complexity of large-scale systems, which are composed of simpler elements.Some of these systems include: the simulation of erosion [23], particle based forests [28] and cloud modeling [25]. Grammar-based generation of models (especially L-systems) are employed in computer graphics mainly to create plant geometry [26]. L-systems have evolved into very sophisticated and powerful tools [20, 27] and have been extensively used in the modeling of plant ecosystems described in [8].

 

1.1 Related Work in Urban Modeling

One approach to modeling existing cities is the use of aerial imagery to extract the buildings and streets there of, using computer vision methods. There are various research projects that rely on this approach, e.g. [15]. This method can be used to rebuild cities, but is not designed to create new models without photographic input data. The existing research work concerning the visualization of cities [6, 7, 13, 29] focuses on techniques for data management, fast real-time visualization and memory-usage optimization. In [1], Alexander et al. describe a pattern language, which consists of over 250 relevant patterns for the successful construction of cities, buildings and houses. They range from very general patterns like “Ring Roads” to very specific ones like “Paving with cracks between the stones”. Since these patterns are not formalized, they cannot be used in the automatic creation process of an urban environment. Space Syntax has been developed by Hillier [16]. Space syntax can be viewed as a set of theories analyzing the complexity of large-scale spaces, such as cities. It tries to explain human behaviors and activities from a spatial point of view and has been used in the analysis of city pedestrian flows [17] or wayfinding processes [24]. This approach is analytical and relies on the availability of city-maps. In the field of architectural interactive design one approach might be mentioned: the shape grammar developed by Stiny [31]. This method uses production rules, but instead of operating on strings, a shape grammar defines rules directly on shapes. Shape grammars have been used to generate two-dimensional patterns and in interactive design applications.

1.2 Our approach

We present a system called CityEngine which is capable of modeling a complete city using a comparatively small set of statistical and geographical input data and is highly controllable by the user. To our knowledge, there is no such system available, although one very similar project outline is presented under [34]. In [5], a method for generating urban models is presented by refinement of existing geometry. However, in this approach a basic model of the city buildings has to be created manually. Other systems [4, 32] rely on aerial pictures as the main input for building and road placement. Our CityEngine creates urban environments from scratch, based on a hierarchical set of comprehensible rules that can be extended depending on the users needs. In [33], Wegener splits the urban model into subsystems. He states that the subsystems networks, land use and housing are among the slowest changing elements in an urban environment. Therefore, in our system CityEngine, the creation of the city is reduced to generating a traffic network and buildings. Land use data is provided by the user in form of image-maps. When studying maps and aerial photographs of large cities, it is obvious that the streets follow some sort of pattern on differentscales. Roads are the transportation medium for the urban population distributed over the area. L-systems have been used in a similar application [20], support branching very well and have the advantage of database amplification [30]; this suggests their potential use to generate convincing large-scale road patterns. We have adapted the model of L-systems to enable the creation of large cities, based on the data that has been collected in [11] on four huge cities around the world, i.e. New York, Paris, Tokyo and London. Although we simplified the underlying model of the virtual city, the main design goal for the system is easy extensibility. We want to be able to add new subsystems, such as different transportation networks (underground, train) and alternative land uses. To achieve this, we extended the L-system with a higherlevel mechanism that makes the addition of new rules very easy.

 

1.3 Overview

In Chapter 2 we describe the concept and the pipeline of the CityEngine system, and the methods used therein. In Chapter 3 the idea of extended L-systems, which allow the implementation of global goals and local constraints is introduced. We demonstrate the use of this extended concept on the creation of the roadmap. Chapter 4 gives a brief overview of the generation of allotments and buildings and explains our proposed mechanism to simplify the texturing of facades. Finally, the results we achieved are shown and discussed in Chapter 5.

 

2 SYSTEM ARCHITECTURE

The CityEngine system consists of several different tools which form the pipeline that is shown in figure 1. In a first step, the input data is fed to the road-generation system, using an extended L-system described in 3.4. The areas between the roads are then subdivided to define the allotments the buildings are placed on. In a third step, by applying another L-system, the buildings are generated as a string representation of boolean operations on simple solid shapes. Finally, a parser interprets all the results for the visualization software. The visualization software should be able to process polygonal geometry and texture maps. This is the case for practically any 3D renderer. Additionally, most scanline renderers support procedural textures, so the proposed mechanism to generate facades of buildings can be incorporated into the pipeline.

Figure 1: The pipeline of the city creation tool. The dark boxes list the results and data structures of the indiviual tools in the white rectangles.

Most of the input data to build up the virtual city is represented by 2D image maps which control the behavior of the system. Those images can be easily generated either by drawing them or by scanning from statistical and geographical maps, as found in [11]. The data can be categorized into two general classes:

• Geographical Maps

    - Elevation maps

    - Land/water/vegetation maps

• Sociostatistical maps

    - Population density

    - Zone maps (residential, commercial or mixed zones)

    - Street patterns (control behavior of streets)

    - Height maps (maximal house height)

Control of the various parameters within the particular tools can be changed by the user interactively or by providing parameter files. For example, statistical measures such as the approximate area size of a block or the average number of intersections per square mile, such as in [18] can be used to change the resulting street map. In figure 2 the top pictures are examples of a geographical image showing land-water boundaries and another image depicting the distribution of the population over the area

Figure 2: Left column: Water, elevation and population density maps of an imaginary virtual city of 20 miles diameter. Right: One possible roadmap generated from this input data.

Two different L-systems are invoked for the creation of the complete city, one for street, the other for building generation. The population density of a city is influenced by the creation of streets. Through streets, people are transported by the system to the next highway [12]. We reflect this by using an approach similar to the Open L-system model [20] when creating streets. The L-system mechanism has been modified in such a way that various different road patterns can be visualized using the same production rules. According to [12], not all roads change the population density of their immediate local surroundings, e.g. roads connecting two cities. We therefore chose to consider two types of roads: highways and streets. They differ in their purpose and behavior: Highways connect areas with highly concentrated population globally, by scanning the population density input map for peaks. Streets cover the areas between highways according to local population density, giving all neighborhoods transportation access to the nearest highway. Together, these two classes form the road map of the virtual city. Once the road map is generated, the land is divided into smaller areas surrounded by streets. These areas can be geometrically subdivided to define the allotments for the individual buildings. The buildings themselves are generated by a stochastic, parametric L-system. In our system the buildings are composed by extruding and transforming an arbitrary outline. For the final visualization in the renderer facade textures are generated using a semi-procedural approach. Every facade is tiled into superimposed and nested grid structures. The grid cells resulting from this subdivision can then be assigned textures or procedural textures.

3 CREATING THE STREET MAP

3.1 Extended L-systems

An L-system is a parallel string rewriting mechanism based on a set of production rules. Each string consists of a number of different modules which are interpreted as commands. The parameters for these commands are stored within the modules. When writing a complex rule system to create a street map, there are a large number of parameters and conditions that have to be implemented to the L-system. The number of productions and their complexity grows very quickly. Every time a new constraint is implemented, many rules have to be rewritten. This makes extensibility a very difficult task. Thus, instead of trying to set the parameters of the modules inside the productions, the L-system creates only a generic template at each step. We call this generic template the ideal successor.

Therefore, the setting and the modification of parameters in the L-system modules have been ported to external functions. These functions follow a loose hierarchy to distinguish between higherlevel tasks and environmental constraints (fig. 3). We call these functions globalGoals and localConstraints, respectively. Every time the rules are applied to an existing string of modules, the following actions are executed:

• Return the ideal successor by the L-system. The parameters of the modules are unassigned.

• Call the globalGoals function. This function determines the parameter values of the dominant global goals. All parameter values are set.

• Call the localConstraints function. The parameters are checked within the local constraints of the environment. The parameter values are adjusted to fit these constraints. If this function cannot find suitable parameters, it sets the state flag to FAILED and the module is subsequently deleted.

Figure 3: Functions applied to a successor.

When invoked, globalGoals and localConstraints consider several influences that can set or change the values of the parameters, respectively. The roadmap creation tool distinguishes between the following global goals and local constraints.

• global: street patterns and population density

• local: land/water/park boundaries, elevation, crossing of streets

Through the separation of module succession and parameter calculation into other tasks, the rules for this extended L-system become much simpler. This makes it easy to add new goals and constraints without changing the production rules at all. Thus, for the creation of all our examples of roadmaps only the following set of production rules is used (we follow the notation style used in [20] and [27]):

The axiom ω initializes the L-system with a road module R and an insertion query module ?I. This initial segment needs to be located inside a legal area of the user input data, i.e. not on water or in parks.

The first three productions control the R module. The production p2 controls the road and branch creation. Two branch modules, B and a road module R plus the insertion query ?I are created. Their attributes are initialized according to the global goals which returns an array of attributes (pDel[0-2] for branch delay and deletion, pRuleAttr[0-2] for rule-specific attributes and pRoadAttr[0-2] for road data, e.g. length, angle, etc).

The R module uses the del parameter as a break flag: The globalGoals function can set this to a negative value and the R module is deleted in the next iteration by production p1. In p3 any R module is deleted if its state is set to FAILED, by the localConstraints function thereby removing the road segment. The production p5 creates a new road segment at the branch points after the delay count (del) has reached zero. The globalGoals function can inhibit branches by setting their del parameter to a negative value. Production p7 deletes the query module ?I in cases where the globalGoals in p2 set the delay of the resulting R module to a negative value. The last two productions determine the actual creation of the road, checking if all the local constraints are met by calling the localConstraints function which adjusts the values in the road attributes roadAttr. The state variable is modified by localConstraints to either FAILED or SUCCEED and determines if the road segment is created.

3.2 Global Goals for road creation

Global goals are primarily considered to set the parameters of the modules to their initial values. The system weighs the influences of all active global goals and chooses the appropriate values for the parameters. The influence of a particular goal at any point is controlled by the input image maps.

3.2.1 Population density

As mentioned above, the highways build the main connection medium between different highly populated areas of a city whereas streets develop into the residential areas and give the habitants access to the next highway [12]. The determination of the parameters of a highway segment are described as follows: Highways connect centers of population. To find the next population center, every highway road-end shoots a number of rays radially within a preset radius. Along this ray, samples of the population density are taken from the population density map. The population at every sample point on the ray is weighted with the inverse distance to the roadend and summed up. The direction with the largest sum is chosen for continuing the growth. This mechanism is illustrated in figure 4.

Figure 4: Left: The road-end of every highway shoots radial rays to find the next population peak (dark area). Right: A possible highway net, connecting population centers.

On the contrary, streets do not change their direction by following the steepest gradient of the population density map. Typically they follow the dominant street pattern. This is reasonable, since most streets in urban areas are built following a superimposed pattern plan. The created street ends still lower the population density in their environment, usually within the area of the block, according to the mechanisms proposed for Open L-systems [20]. When an area with no population is reached, the streets stop growing.

3.2.2 Road patterns

The other important global goal is the compliance of roads with the dominant patterns in that area. This applies for both highways and streets although in our urban model, streets are limited in the possible patterns they can form. In figure 5 various frequent road patterns are listed [9].

Figure 5: A selection of frequent road patterns.

Most real cities display a number of road patterns due to historical growth and different phases of city creation. In [12], Fuesser categorizes streets into two classes: main streets and settlementoriented side-roads. In his analysis, he compares raster with radial patterns. In polycentric cities raster patterns prevail, whereas in monocentric cities radial patterns dominate. Looking at the road types, Highways can represent both patterns, streets usually appear in raster or raster-related forms. In [11] the distinction of different zones in the city leads to the conclusion that the central zone (Zone 1) is of such high population density that it can be viewed as polycentric city. Therefore, in high density zones the raster pattern is dominant.

We have adopted a selection of patterns to apply on the street map and group them into different rules.

• Basic rule: This is the simplest possible rule. There is no superimposed pattern and all roads follow population density. This may also be referred to as the natural growth of a transportation network. Mainly older parts of cities show such patterns. All other rules are based on restrictions of this rule by narrowing the choices of branch angles and road segment length.

• The New York (or checkers) rule follows a given global or local angle and maximal length and width of a single block. This is the most frequent street pattern encountered in urban areas, where all highways and streets form rectangular blocks.

• Paris (or radial) rule: The highways follow radial tracks around a center that can be either calculated from the input data or set manually.

• San Francisco rule: This pattern lets streets and highways follow the route of the least elevation. Roads on different height levels are connected by smaller streets, that follow steepest elevation and are short. This pattern is usually observed in areas with large differences in ground elevation. See figure 6 for an example.

The following table summarizes the goals that the road creation follows:

Table 1: An overview of the street pattern used in the CityEngine system with a short description and an example.

Figure 6: Left: Elevation map and the resulting highway map using the San Francisco rule. Right: Street map projected onto the elevated geometry.

If more than one pattern rule is active at a given location, all of them are evaluated. The proposed parameter values are summed up and weighted according to the value in the input image grey scale map. This allows an easy blending of different street patterns over a defined area as shown below in figure 7.

Figure 7: Left: Two different street pattern control maps for New York and Paris rule. Right: The resulting street pattern of the two maps overlaid.

3.3 Local constraints

The localConstraints function adjusts the parameter values proposed by the globalGoals function to the local environment. Whenever a special situation in the environment is encountered, these values are changed. If there is no possibility to find a valid set of parameters, the function sets the state of the module to FAILED. It is then deleted from the module string by another production in the L-system. As an extension to existing L-systems our implementation allows the creation of closed loops and intersections of road branches. In the CityEngine system, streets and highways are subordinate to the same local constraints.

The localConstraints function executes the two following steps:

• check if the road segment ends inside or crosses an illegal area.

• search for intersection with other roads or for roads and crossings that are within a specified distance to the segment end.If the first check determines that the road end is inside water, a park or another illegal area, the system tries to readjust the values for the road segment in the following ways.

• Prune the segment length up to a certain factor so that it fits inside the legal area of the starting point.

• Rotate the segment within a maximal angle until it is completely inside the legal area. This allows the creation of roads that follow a coastline or a park boundary.

• Highways are allowed to cross illegal area up to a specified length. The generated highway segment is flagged. At the geometry creation stage it can then be replaced by e.g. a bridge, or two tunnel entrances on both sides. Once all road ends are checked for being inside legal territory, the system now scans the surrounding of the road ends for other roads to form crossings and intersections.

3.3.1 Self-sensitive L-Systems

The idea of L-system branches growing together and forming closed loops could not be found in existing applications, although a similar approach to the one we propose can be found in the procedural generation of blood vessels [21]. In traffic systems the dead end road is the exception. Most roads end when crossing other roads or circling back to themselves [9]. The forming of loops changes the topology from a tree-like to a netlike structure. Since we do not have an underlying model of transportation flow simulation on our roadmap, we can ignore the implications on street capacity.

At first the segment is checked for intersection with other segments. For this, all existing street segments in the surrounding area are checked for intersection with the new segment. If one is found, the road is pruned and a crossing is generated. If the localConstraints function finds a street within the given radius of the end of a segment it can modify the parameters for the following events illustrated in figure 8:

• two streets intersect → generate a crossing.

• ends close to an existing crossing → extend street, to reach the crossing.

• close to intersecting → extend street to form intersection.

If a crossing is generated, a new node and two edges in the existing street graph have to be created. After a crossing is generated, a road stops growing.

Figure 8: Examples of local constraints. Upper row: Proposed parameters by global goal. Lower row: after parameter correction.

Once the values of the parameters are finalized, the street map can be rendered or output to the next step in the pipeline. Since the system only creates straight road segments a method is needed to smooth roads with a high curvature. The road creation tool does this by implementing a simple subdivision scheme based on [3].

Figure 9 below shows an example of the creation of a roadmap using scanned maps of Manhattan island. The oldest part of Manhattan is first generated following no generation pattern. All newer parts of the city are created using the New York rule. The local constraints change the direction of the highway to follow the coastal line along the island. Note how the proposed bridges cross the water very close to the locations of where the real bridges are built.

Figure 9: Street creation system applied to Manhattan. Top row: The network after 28 and 142 steps. Middle: The final roadmap. Lower: A real map of Manhattans streets for comparison.

4 MODELING OF BUILDINGS

Once the road map is generated, the system creates the allotments for the placement of the buildings. A stochastic, parametric L-system then generates the geometry for the buildings. Every building is assigned a texture. To keep memory usage small, a semi-procedural approach to texturing has been taken.

4.1 Division into lots

After the creation of highways and streets the populated area of the city is subdivided into many small areas which we call blocks. Those have to be divided into lots for the placement of buildings, as shown in figure 10. We assume that most of these allotments are convex and rectangularly shaped. The system therefore forbids the creation of concave allotments. A block is divided into smaller units using a simple, recursive algorithm that divides the longest edges that are approximately parallel until the the subdivided lots are under a threshold area specified by the user.

In most cities there are regulations that control the maximum height of a building through the ground area of the allotment and zoning plan. Therefore, the user can control the maximum height of a building through the usage of an image map and restrict the generation of skyscrapers to certain zones. After the subdivision of the blocks, all allotments that are too small or do not have direct access to a street are discarded from the system.

Figure 10: Left: Resulting street map. Middle: Blocks created by scaling from street crossings. Right: The generated lots. Allotments too small or without street access are removed.

 

... ...