Real-time Generation of Populated Virtual Cities

Luiz Gonzaga da Silveira JrUnisinos - PIPCA - CROMOSLab

Av. Unisinos, 950Sao Leopoldo-RS, Brazillgonzaga@unisinos.br

Soraia Raupp MusseUnisinos - PIPCA - CROMOSLab

Av. Unisinos, 950Sao Leopoldo-RS, Brazilsoraiarm@unisinos.br

ABSTRACTThis paper presents a new approach for real-time generationof 3D virtual cities. The main goal is to provide of a genericframework which support semi-automatic creation, manage-ment, and visualization of urban complex environments forvirtual human simulation, called virtual urban life (VUL).It intends to minimize efforts of designers in the modelingof complex and huge environments. A versatile multi-leveldata model has been developed to support data managementand visualization in an efficient way. Moreover, a polygonpartitioning algorithm addresses the city allotment problemin an automatic way, according to input parameters andconstraints. In addition, we discuss some results of virtualpopulated city simulations developed with proposed frame-work.

Categories and Subject DescriptorsI.3.5 [Computer Graphics]: Computational geometry andobject modeling, Boundary representations, Geometric algo-rithms, languages and systems, andObject hierarchies.

General TermsAlgorithms, Design and Experimentation.

KeywordsCity modeling, Terrain Modeling, Crowd Simulation, Vir-tual Life Simulation, Polygon Partitioning and Real-timevisualization.

1. INTRODUCTIONWe have considered the problem to construct huge and

complex urban environments for real-time simulation. Sev-eral challenges arise in this context such as acquisition andmanagement of large geometric and topological models, real-time visualization, and the complexity of the virtual humansimulation. Producing a realistic and useful urban envi-ronment requires some steps such as modeling, processing,

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.VRST’06, November 1–3, 2006, Limassol, Cyprus.Copyright 2006 ACM 1-59593-321-2/06/0011 ...$5.00.

rendering, animating and displaying heterogeneous set ofmodels, such as: terrain, houses, buildings, bridges, streets,roads, natural artifacts (lakes, sky, rivers, plants), sidewalks,cars, virtual humans, and others. There are different infor-mation that can be used to virtually reproduce real cities:scan maps, aerial images and laser profiler, maps and sta-tistical information, among others. On the other hand, aprocedural process can originate a completely virtual andfictitious environment.

In this paper, we propose a generic framework for real-time generation of populated 3D virtual cities, useful forsimulating virtual urban life. It can assist designers in time-consuming and tedious interactive modeling activities, inorder to model fictitious virtual cities. It also allows todeal with captured data to virtually reconstruct real cities.Indeed, there are some differences between the input dataand general requirements (and constraints) for each type ofcities. Our claim is that a small set of proper inputs, awell-defined data model, and city artifacts and virtual hu-man repositories are necessary and sufficient to supply in-formation for modeling a virtual city. This paper presents aframework which aims to deal with cities that can be builtusing small amount of information.

The framework consists of a microkernel structure to gen-erate the city and to perform virtual human simulations.This structure separates a minimal core from applicationfunctionalities. Then, each application is responsible forsupplying information to the framework, while it imple-ments a common functional core. The interface supportsalgorithms to map input data from application to frame-work.

The city well-appearance is directly related with the di-versity of models in the repository, and the selection mech-anism. A selection mechanism chooses appropriate modelsof buildings according to city regions, input parameters andconstraints, so, instantiating them into the lots. Indeed, theallotment problem of blocks arises in the absence of aerialphotogrammetric information for the real city reconstruc-tion or for fictitious cities construction, thus being requireda block partitioning. We have proposed a naive but genericautomatic algorithm to perform block partitioning. This al-gorithm saves a lot of time compared with the user-guidedpartition approach.

We believe that a populated city, as well as the providedvisual realism, can contribute to the feeling of immersionattained by users. Moreover, it is only possible to simulatethe functionalities of a specific city, if population is able toevolve in the virtual environment. Realistic and relevant

155

simulations, involving virtual humans, require realistic ur-ban environments to be populated. This framework providesan automatic way to populate the virtual city with virtualhumans, based on population density distribution related togeographical regions and type of city zone, informed as ini-tial parameters. Then, complex simulations can be achievedfor measuring the impact of structural changes in the cityand introduction of services for the population, as well as,following the evolution of these changes, as time goes by.

The main contribution of this paper is the generic frame-work (VUL) proposed, in which the semi-automatic city gen-eration is co-related with semantic information and popula-tion simulation. The paper is structured as follows. Sec-tion 2 discusses previous work. Section 3 provides an over-view of our framework where its components and structuresare described in details. Some scenarios simulation per-formed with VUL framework can be found in Section 4, aswell as some implementation issues, while conclusions andfuture work are described in Section 5.

2. PREVIOUS WORKSTwo main approaches have been distinguished in virtual

cities generation: reconstruction [3, 8, 17] and paramet-ric [13, 23] based methods. The first category looks forvirtual remake real environments, which requires differentsources data, since global information given by aerial photosand 2D maps, until local information of building geometryand appearance (texture) given by photography and laserprofiler data. Reconstruction techniques are used in cul-tural heritage projects to recover architectural informationof historically important places [3, 24]. This sort of applica-tion is concerned with architectural aspects and high fidelityin the reproduction of real environments.

On the other hand, parametric methods are not neces-sarily concerned with the reproduction of real world, butnormally they intend to construct cities according to pop-ulation aspects. For example, Parish and Muller [13] haveused sociostatistical and geographical information to con-struct virtual cities. However, major part of these worksdoes not deal with virtual human simulation in generatedenvironments, consequently they do not treat some specificproblems. For instance, virtual people should evolve in thevirtual environment, being able to entry into the buildingscoming from the sidewalks, walking in parks and pedestrianzones, perceiving the semantic of the environment and be-having in a similar way in comparison with real life.

The simulation of virtual humans has been discussed inthe context of complex and structured environments. Someof these environments have been created with semantic in-formation to allow their exploration by realistic virtual hu-mans [6], and cars [19]. A navigation technique has beendeveloped over structured environments with representa-tion scheme, path planning and collision avoidance compo-nents [12]. Other research groups have concentrated theirefforts to achieve real-time simulation and visualization opti-mization [4, 18]. These works give strong attention to vir-tual human simulation approaches, while the urban environ-ment is normally modelled through an interactive system(e.g. VUEMS Modeler) [5].

Concerning complex environment designing, some authorshave proposed the usage of pattern systems to make uniformbuild constructions [1], and theories to explain the complex-ity of large spaces, such as urban environments [11]. The

latter takes into account pedestrian flow and human behav-ior in virtual environments. Recent works concentrate onmethods for automatic modeling of architecture, with dis-tinction for Instant Architecture [22].

Traditional methods for modeling virtual cities based onmanual reconstruction have provided high quality results,but require enormous amount of time and operator exper-tise to accomplish such task. On the other hand, completelyautomatic approaches have succeed in generating completelyfictitious city with low realism. This is the context of thepresent research, we intend to provide a framework wheredifferent levels of details about the environment can be pro-vided, e.g. the city maps, pictures, textures and shape ofbuildings can be useful to generate a realistic virtual repre-sentation. On the other hand, if the user just know informa-tion about the population distribution into the space and amap of the real city, the framework can also generate a vir-tual city with less compromise with real life. In addition,in every case, the virtual city can be easily populated byvirtual humans, from sociostatistical data and constraints.

Main approaches of virtual city modeling have focus ingenerated static data about the city, often omitting virtualhuman simulation. On the other hand, virtual human simu-lation approaches have employed urban environments, mod-eled by hand. Our proposal fill in the gap, providing toolsfor automatic city generation and virtual human simulation.

3. THE FRAMEWORK OVERVIEWWe propose a framework which consists of seven main

components: interface, input data, data model, city simula-tion, virtual human simulation, scene display and buildingselection, as seen in Figure 1.

ParametersTopo Mesh Terrain

Data Model

Building

Constraints

2-D Image

&

Models

Text File 2-D Map Texture D. E. M.

Building SelectionVirtual HumanSimulation

Input Data

Framework

Application

Scene Display

VULDatabase

SimulationCity

Interface

Virtual Human Models

Sources of data

Figure 1: The virtual urban life FrameworkOverview.

The interface defines relationship between the applica-tion and framework through the mapping of information of

156

sources of data (maps, textual, DEM, texture and images)from the application into the framework input data (pa-rameters, constraints, topological mesh and terrain). Thedata model stores and manages all information about thecity, including input data, through a multi-level hierarchicaldata structure. Besides, it allows human and city simula-tion components to retrieve and manipulate the stored datain an efficient way. The city simulation component createsthe city (geometrically and semantically) and also interactswith others components of the framework to control the sim-ulations. The building selection is responsible for choosingbuildings according to input parameter and constraints. Thevirtual human simulation loads virtual human models andmanages their behaviors into the city. The visualizationcomponent processes the scene and display it in real-time,allowing the users interact with the scene, mainly selectingdifferent cameras for navigation, and adjust rendering pa-rameters. The simulation performance is achieved by viewculling and levels of details for the terrain, imported datamodels and virtual humans.

The application needs to maintain repositories of build-ings, virtual humans, and different sources of data to supplythe framework core: 2-D maps, images, textures, textual in-formation and Digital Elevation Model (DEM). The globalinformation provided by these sources includes sociostatis-tical parameters (population density distribution and zoneinformation), constraints (average and maximum buildingheight, average and maximum building area, one or moreexits for each at least), terrain relief, natural artifacts andothers. Model repositories provide geometric and visual in-formation (texture) of buildings, sidewalks, streets, and arti-facts to the city. The human virtual models and animationsare retrieved from virtual human repository. The frame-work allows that new data sources could be introduced, byrequiring only the definition of hot spots which are specificfor each application (further details in next sections).

The framework can export information dealt internallyin the model (input data, virtual human models, buildingmodels and other artifacts in the scene) to VUL database.It allows reproducing forthcoming simulations.

3.1 InterfaceThe framework core requires input data to generate the

city. Thus, these input data can be directly supplied by theapplication, and/or other sources of data which are avail-able. However, they need to be mapped into frameworkinput data representations. The main role of the frameworkinterface is to establish a bridge between application andframework core, allowing proper relevant data extraction.

Providing a set of algorithms to extract the data fromthe application sources could make the framework unbend-ing and restrictive. So, the framework interface defines hotspots for this purpose. Hot spots are variable aspects ofthe framework [14], which can be customized for each appli-cation needs, during the system development as well as inrun-time. In fact, they allow the introduction of dedicatedalgorithms to map the application input data to frameworkdata format according to their nature, varying from a con-text to another one. In practice, abstract classes of frame-work declare abstract primitive operations (hook method)which are implemented by concrete subclasses in the appli-cation, as illustrated in Figure 2.

The interface declares hot spot through AbstractAlgorithm.

AbstractAlgorithm+get(): FWInput#hook(): FWInput

ConcreteAlgorithm hook(): FWInput

FWInput

Constraint

TopoMesh

Terrain

Parameter

ApplData

FWContainer+add(algo:AbstractAlgorithm)+extract(): void

get() { ... FWInput *fwin = hook(); ... return fwin;}

*

Figure 2: Hot spot mechanism in the frameworkinterface.

New algorithms are implemented by specializing that class,which requires hook method implementation (ConcreteAl-gorithm class). Then, each algorithm is added to FWCon-tainer. The framework calls get method for objects in thecontainer, in order to extract input data (terrain, param-eters, constraints and topo mesh which will be detailed insection section 3.2).

3.2 Input DataThe input data component consists of the following data:

terrain, parameters and constraints, and topo mesh. Thesedata are required by the framework to generate the virtualcity. The framework has not responsibility for capturingdata, but it must be provided by the application. So, ap-plication maps its source of data to framework input datatrough the interface (Section 3.1).

3.2.1 TerrainA terrain can be defined as the surface features of an area

of land. For the computational purpose is required to definea precise mathematical model.

Definition 1 A real terrain can be described by a contin-uous function f : <2 → <, z = f(x, y), where x,y are planecoordinates and z represents correspondent elevation values.Thus, the terrain model can be defined by triangulated func-tion of f : H(f) = {(x, y, f)}, as illustrated in Figure 3.

For our purpose, a digital terrain model should be storedand managed in a compact way. The digital terrain is laidout in a grid of vertices with a fixed distance between, with2n + 1 vertices in width and depth, and n > 1. If verticesare equally spaced, the mesh has 2n quadrilaterals with 2triangles each one.

In Figure 4, terrain elevations are extracted from agrayscale image (a), where each pixel value represents ter-rain elevation. The texture images contribute with terrainappearance. Two different textures have been used to giverealistic terrain appearance: common terrain texture (b) isused to give a general appearance of terrain and a noisytexture (c), which is a small image bump-mapped, and it isused to give realism to generated terrain (d).

The terrain mesh [2] is obtained by the triangulation ofterrain elevations. For instance, data model can easily pro-

157

Figure 3: A terrain mesh.

Grayscale Image

Common Texture

(a)

(b)(c) (d)

NoisyTexture

Terrain

Figure 4: Terrain extraction from 2-D images andtexture.

vide elevation value z for any (x, y) valid pair. In general,others system components can retrieve information from ter-rain. Then, virtual human component uses this informationfor virtual human animation on the relief, while city simu-lation uses it for building placement.

3.2.2 Parameters and constraintsThe parameters refer to global information about city.

The framework defines the following global parameters: zoneinformation, population density distribution and social class.These information can be supplied by textual file or ex-tracted from maps, like zone maps. The zone informationdescribes the features of a region and defines types of theconstructions to be created. We have identified six distinctzones: residential, commercial, industrial, public, rural andmixed. Mixed zone allows inserting any type of building.The population density distribution has influence over theamount of constructions for regions, their maximum dimen-sions and allowed variation of these dimensions. Three dif-ferent social classes have been identified according to familyincomes: (A:richest, B: and C:poorest).

The social class parameter has a great influence on thecity appearance, with inclusion of more or less visually elab-orated constructions. For instance, class A regions havestylish construction. On the other hand, class C regionsmust have simplest buildings.

These parameters are strongly correlated. For instance,zone information predominates over others, defining the type

of buildings that should be provided. The population den-sity distribution jointly with social class defines buildingheight and style as well as the amount to be generated.

It is also possible to define some constraints for the envi-ronment creation, such as average and maximum height al-lowed for buildings, minimum and maximum lot dimensions,and assured exits for all lots. These information can be sup-plied interactively in time of modeling. The exit conditionfor all lots is assured in the allotment algorithm, describedlater.

3.2.3 Topo meshThe amount of information processed, stored, rendered

and visualized in a huge populated virtual city is enormous.Polygon meshes usually employ a list of unrelated polygons,which are described by a list of vertices and a list of faces.The vertices represent street corners, faces the blocks andedges the borders between two blocks. However, more infor-mation is required in order to simulate virtual population.For instance, if a virtual human needs to move from a placeto another one, it is required information about the (best orshortest) path to be followed.

This operation is time-consuming if the system only pro-vides a list of polygons. A planar-embedding polygonalmesh, constructed by pre-processing the polygon list, helpsto solve the path query problems because it creates andmaintains adjacency relationship among polygons. Thisstructure is called planar topological mesh, shortly topomesh, and it represents the first level in the multi-leveldata model. Details about data model are presented in Sec-tion 3.3, where furthermore levels are described.

Definition 2 Topological mesh (shortly topo mesh) is acombinatorial structure embedded in a <2 plane. It suppliesthe ability to maintain subdivisions of the plane induced bycollections of curves. In this case, these curves are straightsegments, bounded by a pair of vertices. The mesh subdividesthe plane into interconnected vertices, edges, and faces.

The topo mesh is a half-edge like data structure [21]. Itstores half-edges instead of edges. A half-edge is a directedge, useful to capture the face orientation. This structureis convenient for modeling convex or non-convex orientable2D-manifolds, as illustrated in Figure 5.

Each face is bounded by circular linked list of half-edges.The list can be oriented either clockwise or counter-clockwisearound the face. Once an orientation has been chosen, itmust be maintained to all remained faces in the mesh. Eachhalf-edge in a list has a pointer to next half-edge, the end-point vertex, a face, and its pair (oppositely oriented adja-cent half-edge). Each vertex holds its position in <3, andhas pointer to half-edge. Finally, each face has a pointer toone half-edge. The most adjacent queries are stored directlyin the data structure primitives. For instance, an adjacentface is obtained when the common half-edge is found, itstwin (opposite direction) and getting corresponding face. Ahalf-edge or list of half-edges bordering one face is retrievedby a circular query around the face.

For our purpose, vertices, edges and faces represent cor-ners, streets and blocks of a city, respectively. Half-edgescodify street directions. The data structure maintains ad-jacency relationship between city elements, which allow toimplement queries efficiently, such as: which blocks uses a

158

Face1 Face2

HE1b

HE1a V1

HE2a

V0

Figure 5: Data structure diagram: biggest arrowsrepresent half-edges and smallest ones representpointers in data structure.

corner? which street bound a block? etc. Shortest pathalgorithms can be implemented efficiently through this datastructure.

The topo mesh can be given, for example, by image seg-mentation combined with others image processing techniques,such as image quantization and labelling, as well as cor-ners detection. Such processes identify and extract a list ofsimple polygons from 2D maps and images. The Figure 6illustrates the complete process.

Color Map

Binary Image

Quantization (binary)

Names? Binary ImageY

N

Closure

Labeled Image

Corners and Edge Detection

Simple Polygons

Image Labelling

Figure 6: An extraction of simple polygons from 2-Dmaps.

A quantization is performed into the color image (map)to give a binary image. If maps contains street names, theyare removed by morphological filtering. Street and blocksare showed in different levels, then the image is labeled toidentify connected components, and SUSAN algorithm isapplied to identified corners and edges of each blocks [16].As result, a list of polygons, representing blocks of city, isobtained.

3.3 Multi-level Data ModelAn important requirement in city modeling is the abil-

ity to access, render, animate and display huge sets of het-erogeneous geometric objects. Thus, we have developed amulti-level representation scheme to address theses chal-lenges. All framework input data and spatial models re-trieved from repositories are tackled in different levels ofabstraction. Figure 7 illustrates the data model, standingout referred multi-levels.

Level-2

Level-1

Level-0

Level-3

Figure 7: Data model, standing out levels 0, 1, 2and 3.

The relationship between different levels allows informa-tion to be retrieved and efficiently used, with low overhead.Each level provides information for upper level and allows toaccess lower levels. For instance, virtual humans and build-ings need information about terrain and topo mesh, whichmust be retrieved in levels 0 and 1, respectively.

The terrain is represented by a triangulated planar meshin level-0. It is described by geometry and attributes (tex-tures) (see section 3.2.1). While, level-1 stores the topo meshrepresentation (see section 3.2.3). For example, each vertexof topo mesh retrieve its geometric elevation value into thelower level (terrain).

The topo mesh (level-1) represents a coarse grain divi-sion of the city, where edges abstract streets and sidewalks,bounded by vertices which representing street crossings andfaces the blocks. Then, each entity in level-1 is refined inlevel-2. For instance, each edge (level-1) points to a mesh(level-2), which describes sidewalks and streets (includingappearance attributes). Vertices into level-1 points to amesh (level-2), which describe street crossing and trafficsigns information. Faces in the level-1 points to a list ofpolygons (level-2), which represent lots, generated throughthe allotment algorithm (Section 3.5). A block without al-lotment has a null pointer, i.e., no references to upper level.

Level-3 holds the spatial objects imported from reposito-ries, as buildings, human models, sign plates, plants, cars,and others. The position and orientation of these objectsare given in lower level (level-1 and level-2, respectively).

159

For instance, each lot defines building orientation, makingits exit to the sidewalk direction.

This hierarchical structure allows to achieve efficient visu-alization of city and queries for simulation. Each level canprovide a proper representation for rendering1, with geom-etry and appearance attributes (mainly textures) of storedobjects. In addition, scene nodes are encoded with level ofdetails capabilities (Details in section 3.8). Besides, pathplanning algorithms can improve the running time of anyshortest path, by performing a coarse query in level-1, andfinally refining it into level-2. At last, the selection of spatialobjects has significant improvement time during the render-ing process, because objects stored in a level can be pro-cessed without interference of objects in another level.

3.4 City SimulationThe system core is formed by a virtual city and virtual

human simulation components. The city simulation compo-nent performs the following tasks: lots partitioning, build-ings selection, sidewalks graph description (includes interestpoints to be used to guide the virtual population, as calledIPs), and exportation of scene to the database.

Once the topo mesh is defined, the city generator sub-divides each block in lots, according to input parameters,i.e. the minimum area threshold and type of building. Insection 3.5, we present our algorithm for allotment subdivi-sion, which performs recursive partitioning, until to attaininput constraints. The stop criteria are reached according tothreshold and some constraints, for instance, existing treescan forbid a lot partitioning.

After allotment process, buildings are placed on the gen-erated lots. The building selection component chooses con-venient constructions according to allotment geometry andzone information, e.g., skyscraper are only put in commer-cial area of metropolises, while houses are placed in residen-tial zones, and sidewalks and street pavement are definedaround blocks. Virtual people can walk and run in side-walks and street crossing. Then, a graph with possible pathsis generated and provided to human simulation component.Finally, all these information can be persistently stored toscene database for future simulation.

The scene database stores first three levels of the datamodel in plain files according to the type of information.Furthermore textures and images, skeleton animation andpaths are kept in their original files. Links between frame-work files and external ones are maintained in the databaseto retrieve the scene and simulation later. The terrain areexternal files (2D-maps, images, or DEMs) which are keptin original format, while topo mesh and lots are saved inWavefront OBJ format files. Building models are kept intheir original format, and new ones are saved into a 3-D for-mat (framework supports .3DS, Wavefront .OBJ and Open-SceneGraph .IVE and .OSG). Sidewalks and streets are tri-angulated and saved into OBJ format, while their texturesare kept into raster files (.PNG and .JPEG formats are pre-vailing). Character (skeleton) animations and geometriesare kept into Cal3D-format2. A VUL database saves in-formation about the generated city, by defining links to allkinds of data. For future simulation, it is firstly loaded andthe other information can also be retrieved.

1OpenSceneGraph has been adopted as rendering engine inthe framework implementation.2http://cal3d.sourceforge.net

3.5 Automatic Allotment AlgorithmAn interesting problem in the city modeling is the auto-

matic generation of lots. We propose a solution that includesblocks subdivision, according to their boundary description,zone information and population density. These parame-ters determine also the minimum and average area thresh-old as stop criterion, which can be provided textually. Avery important constraint is concerned with the avoidanceof creating lots without access to the street.

In fact, in the computational geometry point of view, wehave a polygon partitioning problem with a set of restric-tions. Considering block edges as input and average area asstop condition, we have relatively simple partitioning prob-lem. However, it can be a complex problem once we want toavoid internal, malformed and too small polygons. We havemade three assumptions in the proposed algorithm:

• Any polygon of partitioning must have at least one (orpiece of) edge of original polygon boundary;

• too small polygons are marked as not useful to built-up; and

• polygons with, at least, twice the area of specifiedthreshold, are repartitioned.

First assumption is concerned with ever create a lot whichcan be accessed from the street. It is reached by verifyingif one of two splitted edges belongs to the original polygonor else if new polygons have edges from the original one.The second assumption aims to avoid undesirable size ofpolygons, i.e. it avoids construction in small areas, whilethird assumption avoids too big ones. The pseudo-code ofthis algorithm is presented in Algorithm 1.

This algorithm returns a list of subdivided simple poly-gons (or original polygon if it can not be subdivided accord-ing to specified constraints). The partitioning algorithm isgeneric for simple polygons, and not restrict to convex ones.After the allotment process, the buildings can be insertedinto the lots. Figure 8 shows the result of allotment algo-rithm.

(a) (b)

Figure 8: Automatic allotment: (a) before and (b)after.

We have implemented a variation of this algorithm, firstlypartitioning polygons into convex subpolygons, then apply-ing Algorithm 1. The convex partitioning is performedthrough optimal Greene Algorithm [9] or approximate ofHertel and Mehlhorn [10]. These preprocessing can be in-teresting when convex lots are required.

160

Algorithm 1: Polygon partitioning

Input: (Polygon P, AverageArea AA)Output: List of subdivided polygonsinlist ← P // current list of polygonoutlist ← void // output list of polygonfor all poly in inlist do

bedge ← polybiggest−edgev1 ← subdivide bedge at midpointline← trace perpendicular straight linevlist← intersect (poly, line)vlist← lexisort(vlist)v2 ← internal−visible (vlist.prev(v1 or vlist.next(v1))pedge← make−edge(poly,v1,v2)polygon1 ← partition(poly,v1,v2)polygon2 ← partition(poly,v2,v1)if (polygon1.area() < AA) && (!polygon1.isisland())then

outlist← polygon1

elseinlist← polygon1

end ifif (polygon2.area() < AA) && (!polygon2.isisland())then

outlist← polygon2

elseinlist← polygon2

end ifend forreturn outlist

3.6 Building SelectionAfter allotment, buildings need to be selected and placed

into appropriated position. Complete buildings are availableinto a repository or can be assembled through three specificparts: base, middle, and roof, while textures are selected togive realistic appearance to the buildings. Automatic selec-tion requires the identification of models according to inputparameters. This task is performed by the building selectioncomponent, using data mining techniques [7], which is im-plemented in this work through decision tree methods. Weemphasize that this decision does not intend to be the bestchoice, but it just a choice.

Each building or part of it, into the database, has storeda detailed description and classification according to inputparameters. Such description is coded into a binary deci-sion tree structure, in order to help the building selectionprocess. For instance, commercial buildings are selected tocommercial zone and residential houses and buildings areselected to residential zones. The fine tuning about decisionbetween house and building choice is performed accordingto zone information and population density. Figures 9 and10 show some pictures of a generated city.

3.7 Virtual Human SimulationAn important consideration is concerned with the rela-

tionship between terrain elevation and virtual human walk-ing. When a virtual human walks, next places it should gocan have different elevation of the current one. Although theframework does not intend to simulate virtual humans move-ment and animation, the level-2 of data model can providenecessary information to do that in the generated virtual

city. The places where the virtual characters can walk aswell as the obstacles to be avoided are informed in level-2data structure. This data can be retrieved by accessing theelevation f in level-0 related to (x, y)-plane coordinate.

The “steering behaviors” technique was chosen to simu-late the movement of virtual humans in the generated cities[15]. The virtual characters follow paths avoiding collisionwith other characters as well as with obstacles. The city gen-erator creates graphs for walking-trough, where mentionedpathfinder algorithms can be applied. It supplies informa-tion in order to perform the character’s movement in thevirtual cities. To achieve realistic scene, human skeletonanimation is performed by each character jointly with skindeformation. Third-party libraries have been employed toperform these tasks (Cal3D and OpenSteer), as briefly men-tioned in Section 4.1.

3.8 Real-time VisualizationThe large amount of processed, rendered and visualized

data requires mechanisms to achieve performance for real-time simulation. The framework supports frustum culling,occlusion culling, continuous (CLOD) and discrete (DLOD)level of details, based on Cal3D and OpenSceneGraph fea-tures. The scenegraph stores scene objects in nodes whichsupports level of details management, being CLOD for ter-rain and DLOD for other objects (like buildings, tree, post-lamp and others), respectively. These city objects, exceptterrain and building, have been represented by impostors indifferent resolutions. They are switched at run-time accord-ing proximity to camera.

Terrain LOD is performed by a ChunkedLOD algo-rithm [20]. It is view-dependent algorithm to aggregateprimitives, achieving low CPU overhead and high trianglethroughput. It required a heavy preprocessing stage to gen-erate high detailed meshes (chunks), stored in a tree struc-ture. The chunk at the root of the tree is a low-detail rep-resentation, and higher detail being added at leaves direc-tion. When, chunks are close to the camera, child nodesare reached and rendered. When chunks are far from thecamera, parent nodes are select to be rendered.

Low resolution impostors are loaded and rendered whenthey are far from the camera, and they are changed by highresolution version when they are close to (threshold) thecamera. Only visible objects are rendered and displayed,while entities out of frustum are not considered (paged off todisk). Indeed, the entire scene can be saved into a databasefor further simulation.

4. RESULTS: VIRTUAL LIFE SIMULATIONA fictitious city has been constructed with virtual urban

life framework, from images and textures (terrain), topomesh directly supplied, textual information (parameters andconstraints), external 3D-models (buildings, cars, virtualhumans) and billboards (trees and post lamps). Table 1resumes spatial resolution and sizes (compressed) of inputraster images and textures.

A terrain with 20480x20400 m2 has been created, withapproximately 1600 blocks and 6400 lots. Table 2 shows 3D-models description for buildings, cars and virtual humans.To avoid exhaustive listing, just the smallest and largestmodels are showed. Figures 9 and 10 show the generated

3More than one used - the largest one has been listed

161

Image Dimensions (px) Size (bytes)

Terrain Elevation 512x512 92.5 KBCommon Texture 2048x2048 7.36 MB

Noisy Texture 128x128 12 KBDetail Texture3 128x128 64.5KB

Tree 128x128 64.3 KBAsphalt 128x128 6.2 KB

Post lamp 128x128 96.5 KB

Table 1: Applied Input Images

city, emphasizing different zones.

Models Smallest (KB) Largest (KB)

Buildings 988 2420Cars 45 850

Virtual humans 105 7256

Table 2: 3D-models of Buildings, Cars and Virtualhumans (including textures)

Figure 10: A virtual city: mixed area, with buildingsand few houses.

For this simulation, we include a population of 1250 vir-tual humans walking through the streets into a small regionof the city formed by four blocks. A dozen of cars, trees andpost lamp are also present in the scene. Figure 11 illustratesvirtual humans walking in a generated terrain and Figure 12shows virtual humans walking in the generated city.

For this simulation the near and far plane of view frustumare set to 10 and 3000. The application window has beenset to 720x480 pixels, with 32bpp of color resolution. Thesimulation run in a Pentium 4 HT, 2.8 GHz and 1GB ofmain memory, with a graphics device GeForce 6600 with256 MB.

We have obtained frame rate between 100 and 150frame/sec (average), considering entities of Table 1. In-cluding the population, the frame rate is decreased to 20-30frame/sec (average). The allotment algorithm has generatedbetween four and six lots for each block. Table 3 shows thecomputational time measured during the simulation. Themeasured time for terrain modeling is the sum of loadingtime, triangulation process, textures mapped and displayprocess, while allotment time is spent time for applying theproposed algorithm to all blocks. The other time defini-tions refer to time for loading external models and puttinginstances of them into the terrain (by using a procedural

Figure 11: Virtual human beings walking on theterrain.

Figure 12: Virtual human beings walking in the city.

method). The allocated memory for terrain with 25000 tri-angles is about 3.5MB, while 166.5 MB has been allocatedwith the whole application.

Parameter time (s)

Terrain 0.61Allotment 1.03Building 0.98

Cars 0.5Trees 0.18

Post Lamp 0.03

Table 3: Computational time (average) obtainedduring the city simulation.

4.1 Implementation IssuesWe have implemented the framework and an application

to show its functionalities. The code has been written inC++ language. The OpenSteer4 library is the natural choicefor steering behaviors, while Cal3D library was chosen toproduce the virtual characters animation. An intermediatelayer between Cal3D and steering was created due to the factthat Cal3D library does not deal with the movement of thecharacters in the virtual world, but only with body anima-tion. This layer controls automatically the animation of onecharacter (movement of legs and arms) due to the trajecto-

4http://opensteer.sourceforge.net

162

Figure 9: A virtual city: residential area. (a) landscape view, (b) and (c) details.

ries processed in OpenSteer library at each frame. To eachanimation keyframe, the displacement of the character fromprevious position is computed and then the body animationis updated. For visualization, OpenSceneGraph5 has beenemployed. Its synergy with Cal3D and GDAL6, make easierthe visualization of animated human and geometric data ofcity relief.

5. CONCLUSIONS AND FUTURE WORKThis paper described a new approach for real-time para-

metric generation of 3D virtual cities for behavioral simu-lation. In contrast to similar works, our approach does notdepend on aerial photographic images, however it can beused if it is available. The most important: our approachallows to create live cities, i.e., populated cities useful inbehavioral simulations.

Framework structure offers portability, high extensibility,scalability and transparency. However, it has liabilities con-cerned with performance (pay the price for flexibility andextensibility), and complexity in design, but minimize ap-plication developer work.

A framework based on information extraction of topo map,social parameters and constraints, and automatic allotmentis presented. Polygon partitioning and non-convex poly-gon splitting algorithms are proposed to solve the lot par-titioning problem. Sidewalks and streets information areextracted from topo maps to supply semantic informationto virtual human generation and simulation.

In addition, we showed a generated city which was easilypopulated by using our framework. This city does not intend

5http://www.openscenegraph.org6http://www.gdal.org

to reproduce a real environment, but aims to provide a placewhere behavioral simulations can occur. Other cities couldbe generated, once the input data could be provided.

As future work, we intend to provided a service com-ponent allowing the framework to introduce new city ele-ments, like hospitals and streets, and to simulate the popu-lation behaviors. We intend to build behavioral simulationsdealing with complex situations, such as hazardous events,dynamic changes in the environment, vehicles simulations,among others. We believe the framework can improve visualquality of building architecture by aggregating methods forautomatic modeling of architecture [22]. Slightly geometryand texture warping can help to diversify shape and appear-ance of constructions, reducing the designer efforts.

AcknowledgementsThis research was developed as part of the CIDIS project atCROMOSLab/UNISINOS, Brazil. It was supported by theCNPq/Brazil Proc. Number: 506455/2004-1. The authorswish to thank Andre Tavares for his valuable help in thevirtual human simulation.

6. REFERENCES[1] C. Alexander, S. Ishikawa, and M. Silverstein. A

Pattern Language: Towns, Buildings Construction.Oxford University Press, 1977.

[2] M. de Berg, O. Schwarzkopf, M. van Kreveld, andM. Overmars. Computational Geometry: Algorithmsand Applications. Springer Verlag, 2nd edition edition,2000.

[3] M. Dikaiakou, A. Efthymiou, and Y. Chrysanthou.Modelling the walled city of Nicosia. In D. Arnold,

163

A. Chalmers, and F. Niccolucci, editors, VAST 2003,pages 57–65, Brighton, United Kingdom, 5–7, Nov.2003. Eurographics Workshop Proceedings.

[4] S. Dobbyn, J. Hamill, K. O’Conor, and C. O’Sullivan.Geopostors: A Real-Time Geometry / ImpostorCrowd Rendering System. In SI3D ’05: Proceedings ofthe 2005 symposium on Interactive 3D graphics andgames, pages 95–102, New York, NY, USA, 2005.ACM Press.

[5] S. Donikian. VUEMS: a virtual urban environmentmodeling system. In Computer Graphics International,Hasselt-Diepenbeek - Belgium, Jun. 1997.

[6] N. Farenc, R. Boulic, and D. Thalmann. An informedenvironment dedicated to the simulation of virtualhumans in urban context. In P. Brunet andR. Scopigno, editors, Eurographics’99, volume 18,pages 309–318, Milano, Italy, 1999.

[7] U. M. Fayyad, P. S. G. Piatetsky-Shapiro, andR. Uthurusamy. Advances in Knowledge Discoveryand Data Mining. MIT Press, 1996.

[8] W. Forstner. 3d-city models: Automatic andsemiautomatic acquisition methods. In D. Fritsch andR. Spiller, editors, Photogrametric Week’ 99, pages291–303, 1999.

[9] D. H. Greene. Computational Geometry, volume 1,chapter The decomposition of polygons into convexparts, pages 235–259. Computational Geometry,Greenwich, Conn., 19983.

[10] S. Hertel and K. Mehlhorn. Fast triangulation ofsimple polygons. In L. N. C. Science, editor, Proc. 4thInternat. Conf. Found. Comput. Theory, volume 158,pages 207–218. Springer-Verlag, 1983.

[11] B. Hillier. Space is the Machine: A ConfigurationalTheory of Architecture. Cambridge University Press,1996.

[12] F. Lamarche and S. Donikian. Crowds of virtualhumans : a new approach for real time navigation incomplex and structured environments. In M.-P. Caniand M. Slater, editors, Eurographics’04, volume 23,pages 509–518, Grenoble, France, 2004.

[13] Y. I. H. Parish and P. Muller. Procedural modeling ofcities. In Computer Graphics Proc. (SIGGRAPH2001), pages 301–308, 2001.

[14] W. Pree. Design Patterns for Object-OrientedSoftware Engineering. Addison-Wesley, 1995.

[15] C. W. Reynolds. Steering behaviors for autonomouscharacters. In Game Developers Conference, pages763–782, San Jose, California - USA, 1999.

[16] S. Smith and J. Brady. SUSAN - a new approach tolow level image processing. International Journal ofComputer Vision, 23(1):45–78, May 1997.

[17] Y. Takase, N. Sho, A. Sone, and K. Shimiya.Automatic generation of 3d city models and andrelated applications. International Archives of thePhotogrammetry, Remote Sensing and SpatialInformation Sciences, XXXiV(5), 2003.

[18] F. Tecchia and Y. Chrysanthou. Real-time renderingof densely populated urban environments. InEurographics Workshop on Rendering Techniques2000, pages 83–88, London, UK, 2000.Springer-Verlag.

[19] G. Thomas and S. Donikian. Modeling virtual citiesdedicated to behavioural animation. In M. Gross andF. Hopgood, editors, Eurographics’00, volume 19,pages C71–C79, Interlaken - Switzerland, 2000.

[20] T. Ulrich. Chunked lod: Rendering massive terrainsusing chunked level of detail control.http://www.vterrain.org/LOD/Papers/index.html,Nov. 2005. (last access).

[21] K. Weiler. Edge-based data structures for solidmodeling in curved-surface environments. IEEEComputer Graphics and Applications, 5(1):21–40, Jan.1985.

[22] P. Wonka, M. Wimmer, F. Sillion, and W. Ribarsky.Instant architecture. ACM Trans. Graph.,22(3):669–677, 2003.

[23] C. Yap, H. Biermann, A. Hertzman, C. Li, J. Meyer,H. Pao, and T. Paxia. A different manhattan project:Automatic statistical model generation. In IS&TSPIESymposium on Electronic Imaging, San Jose, CA -USA, Jan. 2002.

[24] C. Zach, A. Klaus, J. Bauer, K. Karner, andM. Grabner. Modeling and visualizing the culturalheritage data set of graz. In Conference on Virtualreality, Archeology, and Cultural Heritage, pages219–226, New York, NY, USA, 2001. ACM Press.

164