-
Automatic Generation of Urban Virtual Environments
Tiavina Tantely, NivolalaUniversity of AntananarivoAntananarivo,
Madagascar
e-mail:[email protected]
Tahiry,AndriamarozakaniainaUniversity of
AntananarivoAntananarivo, Madagascar
e-mail: [email protected]
Jean-Pierre, JesselPaul Sabatier University
Toulouse, France
e-mail:[email protected]
ABSTRACTThis paper presents an approach to automatic city
gen-eration relying on the existing set of models. First,
ahierarchical database containing the main elements ofan urban
environment is created, and then proceduraltechniques are applied
in order to generate the environ-ment with the data from the
database, for the chosencity. This approach adds randomness while
keeping con-trol on the main features of the environment.
KeywordsCity generation, 3D database, 3D visualization,
virtualworlds, computer graphics, declarative modelling
1. INTRODUCTIONUrbanization is occurring rapidly, and since
2008, morethan half of the world population lives in cities.
Thosecities inspired a number of resulting urban virtual
envi-ronments, and predictably, many new applications be-gan to use
them as a platform to integrate numerousinformation on cities
coming from various resources.These environments are used for
visualisation and ex-ploration of urban landscapes as well as to
assist in vari-ous other tasks as they offer plentiful
possibilities in thefield of city, traffic or disaster management
as well asthe creation of virtual worlds.
Models of 3D cities, in an effort to get closer to thereal ones,
are becoming increasingly complex in termsof spatial and thematic
structures. In order to storeall this information, standardized
data models, ensur-ing consistent and inter-operable data
structure, haveto be built. On the other hand, all the progress
madein computer graphics and hardware enables 3D virtualworlds to
be more and more complex visually speaking.As visual quality of
video games improves with each newgeneration of graphics hardware,
the user expectationsincreases proportionally. To manage the
display of thisquantity of data, a possible alternative to manually
cre-ating large amounts of models is to apply proceduraltechniques,
along with the use of a few models. Indeed,a complex city
containing many different models wouldtake a long time to build
manually, and to minimizethe costs of world’s creation, the
generation of objectswith a procedural approach, not only adds
controllablerandomness to the world but also gives varied
results.
Our work is focused on creating a hierarchical databasemodel
that contains the basic elements of an urban envi-ronment, and from
these data, our system will automat-
ically generate a city respecting the architectural stylein the
database, which will keep control on the costs ofcreation and the
general appearance of the cities.
2. RELATED WORKSPast research has tackled the problem of
automatic citygeneration, each one focusing on a particular
aspect.Several standards exist to represent city data : the
IFCstandard [9] is a file format generally used in the build-ing
and construction industry to describe, exchange andshare
information. One of the most popular data mod-els focusing on
cities as a whole is CityGML [7]. The3DCityDB project [14] aims to
reuse the main featuresof CityGML, while simplifying the complex
data modelfor a more compact database and improve the speedof
queries, our model is also largely influenced by thelatter. The
QUASY model [2] has similarities withCityGML but it adds semantic
extensions to the usualbasic models.
Another interesting approach is to reconstruct city mod-els from
facade photographs [12], to take these facadesand generate
variations [1], or to use terrestrial scandata [4], laser scanning
and digital ground plans [3].
The use of grammars, L-systems in particular, showedsuccessful
results in the modeling of plants. Grammarshave been extended to
the modeling of architecture sincethe introduction of the shape
grammars [15], later, othernovel shapes extended this initial
grammar, introducingnew concepts and operations, namely : the Split
Gram-mar [16] CGA Shape Grammar [11].
Procedural methods were used for the CityGen system[10] in order
to create cities interactively by direct ma-nipulation of
parameters of the generation algorithm viaan interactive interface.
Undiscovered Worlds [6] gener-ate pseudo-infinite virtual worlds by
vertical extrusionof floor plans, which is possible only by
generating thevisible part of the world at once.
3. OVERVIEWWe present a system that allows the user to feed
thedatabase using custom models for each chosen city andthen
generate a virtual world respecting this urban style.The creation
of this system is done in two steps:
• The design and feeding of the database.
• Procedural generation of cities from this database.
The rest of this paper will be structured as follows: inthe next
section, we describe the methods used for therepresentation of the
main features of cities and the
-
feeding of the database. Section 5 focuses on the ran-dom
generation of cities from these key items. Section6 presents the
results of our system and the last sec-tion concludes the paper and
provides some prospectsof evolution.
4. THE DATABASE4.1 Database designThe database is based on
PostgreSQL and its spatialextension PostGIS that adds new geometric
and geo-graphic types to the database. It will represent the
ge-ometric and thematic aspects of a city. A geographicalregion
will contain a set of cities, and a city is madeup of buildings,
streets, cars and other items that willbe called urban objects, the
latter are generic objectswhich may contain everything that is not
a building.
The solid model of buildings is geometrically representedusing
Boundary Representation [8] or BRep. A solid isrepresented by its
bounding surfaces, a surface by itsedges, and the edges by vertices
defined by 3D coor-dinates. In our case, a simplified model is
used: allgeometries will be stored as polygons and aggregationsof
polygons, as any surface-based 3D object containedin the
environment may be modeled using these. Allspatial objects are
built from polygons compositions.Aggregations are done between
solid and representativesurfaces. We also introduce a table
containing appear-ance data (textures and colors which are typical
of thecity in question) which are attached to geometric
sur-faces.
In addition to surface-based elements, we introduce
thepredefined objects for the cases where a geometricallycomplex
element is instantiated multiple times for oneor more buildings.
They are 3D models that are firstnormalized and then stored as such
in the database,they will be called each time they should be
instantiatedin the environment, and each reference will contain
thecorresponding transformation matrix.
To keep consistency between the entities, the geomet-ric
elements are linked with the thematic elements withthe same level
of hierarchy [13]. The building itself iscomposed of bounding faces
that may contain openings.A building may have other facilities
outside (fireplace,balcony ...). Respecting the spatial and
semantic con-sistency, buildings are associated with geometric
solids,bounding surfaces (walls, roof) and openings (doors,windows)
with geometrical surfaces and predefined ob-jects,
respectively.
Figure 1. Simplified model of the database’s geometries
4.2 Database feedingThe feeding of the database is done through
model in-sertion via Blender and its Python API. The
databasecurrently will only contain 2D data, 3D objects are
mod-eled using primitives in 2D with 3D coordinates. We
willdirectly use the geometric polygon, as edges or
isolatedvertices are not representative in a city.
Preliminary operations: Before executing the scriptthat will
perform the transition to the database, the user
must manually perform some operations in Blender. Allmeshes of
the same urban object must be grouped. Inthe case of a building,
this group should be assigned acustom property named ’type’ with
the value ’building’,this property may be omitted for a generic
urban object.In the database, bounding surfaces may contain
open-ings, in order to respect this constraint, the openings(doors,
windows) must have a parent-child relationshipwith the bounding
surface (wall, roof) they are attachedto. All these entities will
also have a custom propertythe value of which will be their
function (’wall’, ’roof’,’door’, ’window’). In case the user does
not assign anytype or function to the objects in the scene, they
willbe inserted into the database as generic objects. If anobject
in a building group has no custom property, thescript will assume
that this is a building facility andinsert it into the
corresponding table.
Inserting surface-based objects: The objects arefirst identified
by theme. The solid forming these ob-jects are inserted first.
Afterwards, the script retrievesall the object’s thematic
components. For the build-ing, meshes that do not have parents are
collected first,meaning : roofs and walls, and for each object, an
entryin the bounding surface table is inserted. The corre-sponding
polygons and their vertices are then retrieved;with this list of
vertices, a polygon entry will be insertedinto the geometric
surface table. Note that wheneverwe are dealing with a polygon,
should it be concave,our script will break it down into a set of
smaller andconvex polygons, this will serve us later during the
gen-eration step. After that, appearance data is extractedfrom the
above multi-surfaces and inserted into the cor-responding
tables.
Inserting predefined objects: Children of each bound-ing surface
are collected and here comes into play theconcept of predefined
objects as the same window willoften be reused for one or more
buildings. Said windowis stored only once as a 3D model in the
predefined formtable under a unique name. Each time it is used, a
newtable entry is created as a reference to the entry in
thepredefined form table that uses it, accompanied by
atransformation matrix to store the translation, rotationand scale
to apply this new instance. All these itemsare standardized before
export.
Figure 2. Preparing the predefined object before exporting
Their local center is placed at the center of gravity,
theirlocation is moved to the origin of the scene and theirlocal
pivot is oriented so that the front face of an open-ing is
perpendicular to the x axis. To correctly orientthis pivot, we’ll
refer to the position of the opening onceproperly placed against
its closing surface. At that time,this opening is properly oriented
along the x and y axesto make its front face perpendicular to the x
axis, itshould rotate around the z axis. The value of the rota-tion
angle applied to correct the orientation is the angleformed between
the x axis and the normal of the nearestpolygon constituting the
wall that is also the parent of
-
the said opening.
5. THE CITY GENERATIONThe last step is the generation of a
simplified city fromthe database models. This city consists of a
street andbuildings on both sides of the street. This part is
car-ried out with the Unity3D engine. The terrain and thestreets
are placed first. After querying the base on aparticular town, we
will get a number of buildings, ur-ban objects and cars.
5.1 BuildingsTo each building are attached child elements :
bound-ing surfaces which are a composition of convex polygons,and
openings: predefined objects accompanied by theirtransformation
matrices. To generate polygon-based el-ements, a simple
triangulation is performed using thecoordinates of the polygon
vertices [5]. Next we deter-mine the UV texture coordinates in
order to project a2D image correctly on the surface of a 3D model
by cal-culating the coordinates of the triangles in the imageused
as the texture attached to the triangles of the 3Dobject. We can do
this by valuing which axis of eachpolygon must be eliminated so
that we can keep onlytwo axes in 2D which are normalized between 0
and1. As for the predefined objects, they are instantiatedat the
origin, then the rotation, translation and scaleextracted from the
transformation matrix are appliedbefore they are attached to the
building.
Adjustments on buildings: When a building is gen-erated from a
database, we calculate its bounding box toensure the placement of
buildings at random positionswhile checking for collisions. Next, a
pivot is attachedto that building. The pivot is positioned in the
centerof the bounding box, and the x axis is oriented towardsa
door, because often buildings are oriented in respectto a front
door.
Once all database buildings are generated, the existingbuildings
are cloned and placed on a random, unoccu-pied position on the
terrain. Once the clone is placed,we calculate the rotation to be
applied to it. We choosethe building rotation so that its door is
facing the streetby default (the x axis of its pivot, previously
calculated,points to the street). Lastly, we try to adjust the
scaleof the resulting building, if necessary, an item that
willserve as a reference for comparison to correct the build-ing
scale should be chosen. The value of the verticalheight of the door
was chosen because, out of all theelements of a building, this
value is less subject to varia-tion in their style (they must, at
least, have a minimumheight). However, we allow a margin of more or
less20 % compared to the standard height. The standardheight is
calculated relative to the only element that waspresent before any
generation: the street and its width.Finally, the new scale applied
to the building will havea difference in scale between the standard
height of thedoor and its current height.
Thematic elements: For each building clone placedon the terrain,
its thematic elements are selected, andinstead other ones are
placed selected in the databasethat belong to the same city and are
of the same type.In order to do this, thematic components of the
buildingare individually selected. We start by retrieving bound-ing
surfaces which are isolated by type (‘wall’, ‘roof’),and for them,
random appearance data is retrieved inthe database for the same
type of element and with the
selected city. These new appearances are applied to
thecorresponding surfaces.
We then retrieve the transformation matrix of the build-ing
predefined objects by the type (‘door’ and ‘win-dow’), and the
predefined objects of the same type areretrieved from the database
for the same city and placedinstead of the previous predefined
object using the ma-trix saved above. The dimensions of the
previous open-ing are temporarily stored to prevent any
inconsisten-cies and applied to the new opening. The
standardiza-tion of their orientation before export enables the
reuseand exchange of their rotations. For openings and espe-cially
windows, for each bounding surface of the originalbuilding, it is
randomly chosen whether or not windowswill be attached to it on the
condition that at least onebounding surface contains these
openings.
5.2 Urban objects and vehiclesUrban objects are generated like
buildings, except thatthey are not decomposed into thematic
elements, andare simply composed of polygons and/or predefined
itemsthe generation of which has been covered above. Theyare also
generated after the buildings and cover a largerarea of the terrain
than the latter.
The vehicles are similar to urban objects by their designand
extraction from the database. Once all the basic ve-hicle models
are selected, they are randomly generatedalong both sides of the
street, facing opposite directions.Once generated they are animated
to move towards theend of the street, and once this goal is
achieved, theydisappear and are regenerated at the beginning of
thestreet, and so on.
6. RESULTSTypical buildings of three test cities, each with
somecommon features for their respective buildings and
awell-characterized urban style, were inserted into thedatabase : a
typical colorful city of Madagascar, an-other American city with
skyscrapers with flat roofs andidentical windows and a Norway
village with woodenwalls, stave and tiled roofs, and wooden windows
anddoors. The terrain and the street were placed first andbuildings
and urban objects were generated on areasunoccupied by the
street.
6.1 Output
Table 1. Geometric elements from the databaseRegion Cities
Build-
ingsMulti-Surfaces
Prede-finedele-ments
ConvexPoly-gons
Mada-gascar
1 4 10 52 67
America 1 5 5 195 42Norway 1 6 20 59 120
Table 2. Thematic elements from the databaseRegion Build-
ingsUrbanob-jects
Vehi-cles
Boundingsur-faces
Open-ings
Mada-gascar
4 1 3 25 50
America 5 0 2 25 195Norway 6 2 2 43 53
-
Table 3. Generated elements for each cityRegion Build-
ingsBoundingsur-faces
Vehi-cles
Open-ings
Facili-ties
Mada-gascar
150 900 40 1875 37
America 150 750 40 8325 0Norway 150 1200 40 1325 148
Figure 3. Screenshot of a town from Madagascar
Figure 4. Screenshot of a town from Norway
Figure 5. Screenshot of an American city
We can see that despite applying the variations, thegeneral
style of the cities remains faithful to the overallstyles of the
individual buildings. The more contrast be-tween colors, textures
and overall shape of buildings, forexample, in Antananarivo, the
more the resulting citylooks disparate, contrarily to the Norway
town, whichseems more uniform.
7. FUTURE WORKWe presented a system capable of generating a city
froma set of predefined elements for each urban style of in-serted
cities. The work we have done so far was focusedon a method that
associates the use of a database of ur-ban models and a procedural
method for the visualiza-tion of a city, and our contributions have
been focusedon this hybrid approach, using the coupling
betweenstatic elements, and the models created manually, andthen
using procedural methods on these elements to de-compose these
models and create cities containing var-ious items, while keeping
some control and respectingthe urban style of it. We were able to
model and gener-ate random cities, exchanging architectural
elements inorder to obtain variations on an infrastructure, as
wellas ensuring that the number of models stored in thedatabase is
reduced to a minimum. While this systemcan play a useful role in
the construction of an urbanmodel, this is achieved through
compliance with estab-lished standards and good initialization when
modeling.And thus, the system still has gaps and future researchcan
be suggested in the following areas :
The first perspective of evolution is to further automatethe
model’s import into the database, so as to avoidhaving to manually
name the descriptive elements of abuilding, an algorithm should be
developed capable torecognize the thematic elements from distinct
character-istics such as the position relative to certain
componentsand, thus, reduce the user’s tasks to a minimum.
It would also be useful to integrate other thematic el-ements
into the category of urban objects, as well asfor the buildings
themselves. Buildings could be clas-sified by function (e.g.,
residential, commercial, indus-trial) and their creation and
placement follow a numberof rules to ensure the coherence of the
whole environ-ment. In our future works, the procedural aspect will
beexplored in more depth, we especially consider taking inan amount
of input data in order to extract derivationrules, our database
could then consist of primary shapesto use these rules on.
Finally, the system should consider a more complexstreet network
which could be done via input data onthe street patterns and other
information about the ter-rain pertaining to the streets shape.
References[1] F. Bao, M. Schwarz, et al. “Procedural facade
variations from a single layout”. 2013.
[2] J. Benner, A. Geiger, et al. “Flexible generationof semantic
3D building models”. 2005.
[3] C. Brenner. “Towards fully automatic generationof city
models”. 2000.
[4] C. Dold and C. Brenner. “Automatic matching ofterrestrial
scan data as a basis for the generationof detailed 3D city models”.
2004.
[5] A. Fournier and D. Y. Montuno. “Triangulatingsimple polygons
and equivalent problems”. 1984.
[6] S. Greuter, J. Parker, et al. “Undiscovered worlds–towards a
framework for real-time procedural worldgeneration”. 2003.
[7] G. GROGER, T. H. Kolbe, et al. Open GeospatialConsortium OGC
City Geography Markup Lan-guage (CityGML) Encoding standard.
2012.
[8] J. F. Hughes, A. Van Dam, et al. Computer graph-ics:
principles and practice. 2014.
[9] Industry Foundation Classes.
[10] G. Kelly and H. McCabe. “Citygen: An interactivesystem for
procedural city generation”. 2007.
[11] P. Müller, P. Wonka, et al. “Procedural modelingof
buildings”. 2006.
[12] P. Müller, G. Zeng, et al. “Image-based proceduralmodeling
of facades”. 2007.
[13] A. Stadler and T. H. Kolbe. “Spatio-semantic co-herence in
the integration of 3D city models”.2007.
[14] A. Stadler, C. Nagel, et al. “Making interoper-ability
persistent: A 3D geo database based onCityGML”. 2009.
[15] G. Stiny. “Introduction to shape and shape gram-mars”.
1980.
[16] P. Wonka, M. Wimmer, et al. Instant architecture.2003.
