Functionality-Independent Style-Based Procedural Building Generation

(1)

Master of Science Thesis in Electrical Engineering

Department of Electrical Engineering, Linköping University, 2017

Functionality-independent

Style-based Procedural

Building Generation

(2)

Master of Science Thesis in Electrical Engineering

Functionality-independent Style-based Procedural Building Generation

Mikael Pessa LiTH-ISY-EX–17/5099–SE Supervisor: Jens Ogniewski

isy_{, Linköpings universitet}

Examiner: Ingemar Ragnemalm

isy_{, Linköpings universitet}

Division of Information Coding Department of Electrical Engineering

(3)

Abstract

In computer graphics it is often necessary to construct a large number of objects of specific types, such as buildings. One approach is to create the models proce-durally, an approach that often renders function and appearance tightly coupled. This thesis explores an alternate solution to this problem. We propose a sys-tem for procedural building generation based on the separation of function and style. We show our approach to separating appearance from functionality, we then describe our implementation of the system and finally we create a demon-stration of its potential.

Our approach offers a large amount of control while allowing for a separa-tion between design of funcsepara-tionality and design of style. The approach could in theory allow for reuse of large databases of models and simplify the creation of procedural generation engines.

(4)

(5)

List of Figures

3.1 A few of the building models in the dataset provided by [1]. . . 6

3.2 An example showing how a building can be split into its functionality-based foundation (3.2b) and its style-functionality-based parts (3.2c). . . 7

3.3 An example of how curves can differ depending on direction. No-tice how the walls in 3.3b have a slight outward curve, while seen from another direction in 3.3c the curve appears flat. . . 7

3.4 An example of how curves seem to repeat on walls facing the same direction. . . 8

4.1 Illustration of the process of extracting the curve from a model. . . 12

4.2 An example of how curves can be stored. Here we assume the secondary direction for every curve is the standard up vector: [0 1 0]. . . 13

4.3 Process of applying a single curve (4.3a) to a model (4.3b). The model is flattened (4.3c) and each point of the model (4.3d) is curved to the right according to its height (4.3e). Note how the curving effect is at its maximum at the edge and diminishes to-wards the center of the model. . . 14

4.4 An example of a model and its extracted curves (4.4a), followed by those curves being applied to a new model (4.4b). . . 15

4.5 A second example of a model and its curves (4.5a), followed by those curves being applied to a new model (4.5b). In this case the curves were manually extracted in 4.5a. . . 16

4.6 An example showing how the curves used to generate 4.6a and 4.6b when combined creates a natural-looking blend of the two curves in 4.6c. . . 17

5.1 Example of bad non-uniform scaling. . . 20

5.2 Slots from the axis aligned bounding box of a chimney . . . 20

5.3 An example of how deformation can cause overlap. . . 21

6.1 Contour extraction process. . . 24

6.2 Door model (6.2a) and its corresponding shape (6.2b). . . 24

(9)

LIST OF FIGURES ix

7.1 The two possible versions of the model roofChinese1, with (7.1a) and without polesChinese1 (7.1b). . . 26 7.2 A model where problematic scaling issues have occurred.

Founda-tion windows and doors are wildly different scales from those of the roof. . . 26 7.3 File system layout of models and info.txt -files. . . 27 7.4 Example of an info.txt file used for database preparation . . . 28 8.1 Walls with different point densities (8.1a, 8.1b, 8.1c), and an

exam-ple of a comexam-pleted foundation in (8.1d) . . . 30 8.2 The foundation is extended towards the roof by projecting each

line upwards until collision and adding new vertices at the same density. . . 31 8.3 A few runs of the demonstration with a static functionality input

and changing style input. Figure 9.1a shows a bare result with no style input. Figures 9.1b and 9.1c show two variants with ’chinese’ as style input. And Figure 9.1d shows a result of using ’cathedral’ as style input. . . 32 8.4 A few runs of the demonstration with a static style input and

chang-ing functionality input. . . 32 8.5 Profiles examples of a short run and a long run. Left is profile

ordered by total time spent in each function, and right is ordered by self time of each function. Note that the main bottleneck for the short run in 8.5a is when writing to disk, while in the long run in 8.5b it is performing ray casts in function raysFaceIntersect. . . . 34 9.1 A few runs of the demonstration with a static functionality input

and changing style input. . . 37 9.2 A few runs of the demonstration with a static style input and

chang-ing functionality input. . . 37 9.3 A sample of the buildings generated by the demo with changing

style and functionality inputs. . . 38 9.4 Using our curve transfer and part replacement methods we attempted

(10)

(11)

Glossary

Constrained Delaunay Triangulation

A version of Delaunay triangulation where some connections are predetermined. Used in this project for leaving holes in a mesh.

Delaunay Triangulation

An algorithm for triangulation of a point set that maximizes the minimum angle of the entire set of triangles

GPU Instancing

Also known as geometry instancing, the practice of rendering multiple copies of the same mesh at once. Generally faster then doing it separately

Dominant curve

Our shorthand for the overall or most important curve of a model

Model

A set of vertices and faces that make up an object

Oriented Bounding Box

The smallest box containing a set of points oriented in the same direction as the model its encasing

Raycasting

A method for calculating if and where a line intersects a surface

Slots

(12)

xii Glossary

Sub-Model

A model that is part of a bigger model

Triangulation

(13)

1

Introduction

This chapter introduces the reasons behind the thesis and what problems it aims to solve.

1.1 Background

Generation of a large number of models is a common problem in computer graph-ics, especially within the field of video games. An important subset of this prob-lem is the generation of models of buildings, as often entire cities worth of build-ings are required.

Procedural generation is perhaps the most cost-efficient way of accomplish-ing this. Most current approaches to generataccomplish-ing buildaccomplish-ings use processes which closely tie the appearance of the building to its functionality. This usually leads to the models being entirely decorative, for example like the models in the game Sim City. Or, if they are functional buildings, it makes it difficult to change their overall appearance at a later stage. Models with different styles thus have to be en-tirely separately created, preventing reuse of both code and previous modelling.

With large databases of models available, such as TurboSquid [2] and 3D Warehouse [3], it would also be useful to find ways of reusing large sets of models in new ways.

Inspired by a paper by Lun et al. [4], we envision an approach to building generation that separates architectural style from building functionality, while allowing for reuse of both models and generation code.

Finally, since much of procedural generation is used in real time applications, it would be of interest to study the potential performance of such an approach.

(14)

2 1 Introduction

1.2 Purpose

The purpose of this thesis is to create a system for procedural building generation that allows for the separation of style and functionality.

1.3 Problem Formulation

There are three main problems dealt with in this thesis:

1. Determine what constitutes an architectural style and how to separate it from a building’s functionality.

2. Design a system for procedural generation using the findings from question (1).

3. Determine if this approach can be made fast and reliable enough for real time use, and where the bottlenecks lie.

1.4 Limitations

We limit the work to the domain of building generation, since this is an important and common field for procedural generation of computer graphics. This domain also gives us some constant features across the models we are working on, which can be exploited.

We focus mainly on the separation of style and function, with less emphasis on creation of a good procedural generation engine.

(15)

2

Related Work

The field of procedural model generation is wide and at this point has decades of previous work behind it with many different approaches. Our method follows most closely on a research paper by Lun et al. [4] which itself follows closely on Lun et al. [5], Kalogerakis et al. [6] and Huang et al. [7]. The following section introduces some common approaches to the problems dealt with in this thesis, and in particular the approach taken by the previously mentioned papers.

2.1 Style Similarity

Lun et al. [5] and subsequently Lun et al. [4] uses a style definition based on similarly shaped geometric elements and recurring visual motifs. These in turn come from observations about human perception of style hinted at by art history and appraisal literature.

2.2 Procedural Building Generation

The most common approach to procedural building generation is to use prede-fined rules to shape the model. This is traditionally done through different design grammars, systems of describing shape originally used for describing paintings and sculptures. A notable early example is CGA Shape introduced by Müller et al. [8]. These in general generate buildings whose appearance and functionality are very tightly coupled.

The paper by Teoh [9] is an example of a procedural building generation model that will generate a very specific kind of building, in this case buildings of ancient East Asian architecture.

(16)

4 2 Related Work

into complete functional buildings. This approach use labels to apply rules to a set of building components at once, ensuring that functionality is maintained throughout the generation process. This system still couples functionality and appearance but takes into consideration functionally conflicting placements to greater degree than earlier work.

2.3 Style-Functionality Separation

Xu et al. [11], Lun et al. [4, 5], and Huang et al. [7] seek to decouple appearance from functionality by using machine learning to detect the style and/or function-ality of models independent of their counterparts. They then use these detected features to automatically create new objects in different styles with the same func-tionality, or new objects in the same style but with different functionality.

2.3.1 Assembly-based Modelling

Making complete models out of smaller interchangeable parts, so called Assembly-based modeling, was introduced by Funkhouser et al. [12] and has since seen many further developments like Duncan et al. [13] and Chaudhuri and Koltun [14]. Most research in this area focuses on organic shapes like plants, humans and animals.

2.4 Automatic Model Placement

Part of assembly-based modelling is the detection of where these sub-models should be placed. There are several approaches to this. Funkhouser et al. [12] used the Iterative Closest Point algorithm which minimizes the difference be-tween two point clouds. More recently, Kalogerakis et al. [6], Huang et al. [7] and Lun et al. [4] used a system based on "slots"; marked areas showing impor-tant contact points between parts.

2.5 Deformation

Most research in deformation of 3D-models is in the fields of destruction of the object, which is of no interest to us, and in the field of animation. In animation the goal is to keep the general shape and volume of the model being deformed constant. This approach makes them somewhat unsuitable for the style manipu-lation we are interested in. Such methods include PriMo by Botsch et al. [15] and As-Rigid-As-Possible (ARAP) Shape Manipulation by Igarashi et al. [16].

Lun et al. [4] uses a variation of ARAP deformation in their style transfer method.

(17)

3

Method

This chapter describes the methods used throughout the thesis. It accounts for the prestudy, project overview and tools used.

3.1 Prestudy

Before the main work of creating a system started, a small study was conducted to answer the first of the questions posed by the problem formulation:

What constitutes an architectural style and how do we separate it from a building’s functionality?

3.1.1 Prestudy Methods

With similar questions to ours in the literature, in particular Lun et al. [4] and Lun et al. [5], it was natural to explore these two research papers more closely. Fortunately, the authors of these papers provide both the source code and the models used in their implementation online [1], [17].

Because of this overlap in problems, and the readily available data to examine, two main methods were chosen when conducting the prestudy:

Literature And Code Examination

The style transfer done in the paper by Lun et al. [4] conducts the transfer using machine learning, which hides certain parts of the process. Despite this, their article describe rules by which they determine what separates style from func-tion. We examined these rules to determine what they mean in the context of our problem.

(18)

6 3 Method

By reading through and running the source code of Lun et al. [4], we could see how their implementation deals with the problem of transferring styles between models on a programmatic level. This allowed us to determine what parts of their implementation were directly useful to us.

Model Examination

The mentioned research papers formulate their problems around a more diverse set of models than this thesis, which means they can not use the limitations af-forded by a certain class of objects to their advantage.

The sub-class of models targeted by our approach, buildings, should have some features that are common to all (or at least most) models of the same class. These features should be exploitable to determine what provides a building func-tionality versus what provides style.

The datasets provided by Lun et al. along with their paper [1] contain a num-ber of buildings in different styles, pre-classified by the authors. See Figure 3.1. We built up our own dataset of building models consisting of these and a few models from other sources. This set of models was studied in the context of the results from the previous section to determine exactly what the common features of these buildings are.

Figure 3.1:A few of the building models in the dataset provided by [1].

3.1.2 Prestudy Results

The investigation lead to the following conclusions:

1. The theoretical approach of Lun et al. [4] imply that the style of a model are made up of two main components: their dominant curves and the use of recurring sub-models.

2. We found that, as a whole, their code is not very useful to us. It is too slow, requires too much training data and is currently not robust enough to handle complex or unfamiliar models. But the approach used for model placement is useful.

3. Using the ideas from conclusion (1) to examine the building models, we determined that such a model is made up of two main parts:

(19)

3.2 Implementation Outline 7

• A foundation of walls provides most of the functionality of the build-ing, only providing style information in the form of its curvature. • All sub-models to this foundation, such as windows, doors, roofs etc.,

can be thought of as only providing stylistic information. These only provide functionality in the form of their intrinsic classifications and placement. This makes them highly replaceable. See Figure 3.2.

(a) (b) (c)

Figure 3.2: An example showing how a building can be split into its functionality-based foundation (3.2b) and its style-based parts (3.2c).

4. We also note that if a building foundation is curved then that curve is not necessarily uniform across all walls. See Figure 3.3. This could be seen as each wall having its own independent curvature, but because this curve tends to repeat across walls in the same direction, see Figure 3.4, our in-terpretation is that these curves are directional in nature. This means each curve is tied to the direction it is facing.

(a) (b) (c)

Figure 3.3: An example of how curves can differ depending on direction. Notice how the walls in 3.3b have a slight outward curve, while seen from another direction in 3.3c the curve appears flat.

3.2 Implementation Outline

With results of the prestudy in hand, the work was divided into four main parts that are dealt with throughout this thesis:

(20)

8 3 Method

(a) (b)

Figure 3.4: An example of how curves seem to repeat on walls facing the same direction.

2. Automatic model positioning

3. Categorization and selection of sub-models

4. A demonstration environment that generates complete buildings

3.3 Tools and Data

To implement this system we used a number of tools and resources. These were all free and chosen to fit the needs of the project.

3.3.1 Matlab

All code for the system was written in Matlab [18]. It was chosen as develop-ment environdevelop-ment as it offers an easy and quick prototyping, good options for debugging and profiling, and lots of tools easy to access and use for most needs that could arise. The biggest drawback of using Matlab’s is that it is generally considered a slow language, and lacks a simple way of displaying 3D models.

We overlook the performance problems in our implementation. We instead see our implementation in Matlab as a minimum level of expected performance in any other language, while still dispaying potential bottlenecks.

Instead of displaying data within Matlab, it was decided to exclusively write models to disk and display them using an external program.

3.3.2 Meshlab

Meshlab [19] is an open source system for processing and editing 3D triangular meshes. All model division and inspection during the project was done using Meshlab. It was chosen because it is free and has the features required for the project.

(21)

3.3 Tools and Data 9

3.3.3 Models

The majority of the models used are from Lun et al. Lun et al. [5], provided on their homepage [1], which in turn were downloaded from Inc [3]. Additional models were downloaded from Turbosquid [2].

Using the dataset from Lun et al. [5] was an easy choice, since it offers a variety of building models in clearly defined styles. But because of the complexity of some of these models, as well as many of them being unconventional buildings, a few more models were necessary. These other models were downloaded as needed to examine specific features, to test edge case or just to add variety.

3.3.4 Database

MongoDB [20] was chosen as the database because of its easy setup. It requires little knowledge about what data will be put into it, making it good for the loosely defined data used in this project and for the quick changes needed when proto-typing.

(22)

(23)

4

Curve Transfer Implementation

This chapter deals with how we determine the dominant curve of a model and then transfer that curve onto another model.

4.1 Determining the Dominant Curves

As we found in the prestudy, the dominant curves of a model are essential to its perceived style. But since the definition of what constitutes the dominant curves of a style is somewhat subjective, we have to narrow down the meaning to something that is easier to work with.

To simplify this process we limit our definition of a curve to something that can be described as a simple two dimensional line, forgoing more complicated three dimensional curvatures. Since it would make the biggest visual impact, it is also reasonable to assume that the dominant curve is the biggest curve in a structure, the curve that describes an entire surface. If we assume this definition to be true, and that the curves are directional as previously stated, it becomes clear that we can determine the dominant curves of a model by looking at the edges of a model projected sideways.

4.1.1 Curve Extraction Algorithm

By projecting all the points of a model onto a flat plane, we get a two-dimensional point cloud. Determining the edge of this point cloud is a non-trivial problem. This is because of the difficulty deciding what points are on the inside of the edge and what points are on the edge itself, as well as where it begins and ends.

The solution we settled on was using Matlab’s boundary function, as it was easy to implement and gave the most consistently good results after some experi-mentation. The function acts like a convex hull that shrinks towards the interior

(24)

12 4 Curve Transfer Implementation (a) 5 0 -5 1 1.5 -7.5 2 2.5 3 -8 3.5 4 -8.5 4.5 (b) 7.5 8 8.5 1 2 3 4 -1 -0.5 0 0.5 1 (c) 7.5 8 8.5 1 2 3 4 -1 -0.5 0 0.5 1 (d) 0 5 0 10 20 30 40 50 60 70 80 90 100 0 (e)

Figure 4.1:Illustration of the process of extracting the curve from a model.

to envelop more points.

Beginning and endpoints are decided by taking the points between the highest and lowest points towards the edge, as beyond them would be the in the upward and downward directions. When this curve is determined, we normalize it so that the values on the axis going along the model goes from 0 to 100, while the other axis anchored with its minimum point at 0. An illustration of this process can be seen in Figure 4.1.

Repeating this process while rotating the projection plane yields a number of curves that in total describes the sideways curvature of the entire model.

An Alternative

Estimating the curves by treating the model as a point cloud leaves out all the in-formation provided by the faces of the model. An alternative solution to finding the curves that doesn’t have this drawback would be to instead use edge detec-tion techniques on an image of the projected model. We did not implement this solution due to a lack of time.

(25)

4.2 Curve Transfer 13

4.1.2 Manual Curves

When the curve extraction algorithm falls short, which can happen if the curve is too steep, it is possible to simply create the curve manually. This also means that creating new handcrafted curves is trivial. An example of a curve that needed to be created manually can be seen in Figure 4.5a.

4.1.3 Curve Structure

Once a curve is determined it has to be stored. Our implementation by default represents each curve as a number of two-dimensional points. A three sional object’s curvature would be represented by a number of these two dimen-sional curves, each with its own direction which needs to be stored alongside the points. The curvature of a model is therefore saved as a collection data structures describing individual curves. Each individual curve structure contains a set of two dimensional points and two vectors describing the directions of the curve. Alternatively we can use only one direction vector and assume the other one is the standard up direction. For an example, See Figure 4.2.

Through linear interpolation, this information can be used to apply the curve to another set of points.

0 10 20 Normal: [ 0 0 1 ] 0 10 20 30 40 50 60 70 80 90 100 0 10 20 Normal: [ -1 0 0 ] 0 10 20 30 40 50 60 70 80 90 100 0 10 20 Normal: [ 0 0 -1 ] 0 10 20 30 40 50 60 70 80 90 100 0 10 20 Normal: [ 1 0 0 ] 0 10 20 30 40 50 60 70 80 90 100

Figure 4.2: An example of how curves can be stored. Here we assume the secondary direction for every curve is the standard up vector: [0 1 0].

4.2 Curve Transfer

Transferring curves onto an existing model offers a different set of problems. Be-cause of the constraints we work under, where we do not mind deformation that does not retain volume for example, the model deformation techniques discussed in Related Work (Section 2.5) were not a good fit. We therefore decided to develop our own model deformation technique. The following section describes the

(26)

algo-14 4 Curve Transfer Implementation 0 10 20 Normal: [ 0 0 1 ] 0 10 20 30 40 50 60 70 80 90 100 (a) (b) (c) 0 200 400 600 800 1000 1200 -2000 -1500 -1000 -500 0 500 (d) 0 200 400 600 800 1000 1200 -2000 -1500 -1000 -500 0 500 (e)

Figure 4.3: Process of applying a single curve (4.3a) to a model (4.3b). The model is flattened (4.3c) and each point of the model (4.3d) is curved to the right according to its height (4.3e). Note how the curving effect is at its maximum at the edge and diminishes towards the center of the model.

4.2.1 The Algorithm

Since we are working with edge curves, the deformation should primarily affect the edges of the model. Our technique therefore assumes that the model being deformed is much wider than the curve being applied to it.

A zero vector is set up for each point of the model being handled. These are the accumulation vectors. While iterating through the curve structures each individual curve adds its contribution from independent calculations to these vectors before the final product is added back into the model.

The application is done by again treating the model as a flat point cloud. The direction of this flatness in each iteration of the algorithm is decided by the curve structures directional vectors.

First the position each vertex would be at according to the curve dependent only on its position in the y-direction is calculated. The resulting position of each vertex is then compared to the model’s midpoint. Any vertex that ends up behind the midpoint is given a curve change of zero. The final deformation is then given by each vertex moved distance multiplied by the ratio between the distance of the vertex from the middle and the distance from the middle to the edge.

(27)

point and added into the accumulation vectors. When all curves have been calcu-lated these vectors are added to their respective points.

A demonstration of the algorithm using only a single curve can be seen in Figure 4.3, while the algorithm in its entirety is described in pesudo-code in Al-gorithm 4.1. Examples of the complete process from extraction to application can Figures 4.4 and 4.5.

0 10 20 Normal: [ 0 0 1 ] 0 10 20 30 40 50 60 70 80 90 100 0 10 20 Normal: [ -1 0 0 ] 0 10 20 30 40 50 60 70 80 90 100 0 10 20 Normal: [ 0 0 -1 ] 0 10 20 30 40 50 60 70 80 90 100 0 10 20 Normal: [ 1 0 0 ] 0 10 20 30 40 50 60 70 80 90 100 (a) (b)

(28)

16 4 Curve Transfer Implementation -15 -10 -50 Normal: [ 1 0 0 ] 0 10 20 30 40 50 60 70 80 90 100 0 -15 -10 -50 Normal: [ 0.5 0 0.86603 ] 0 10 20 30 40 50 60 70 80 90 100 0 -10 0 Normal: [ -0.5 0 0.86603 ] 0 10 20 30 40 50 60 70 80 90 100 -10 0 Normal: [ -1 0 3.737e-16 ] 0 10 20 30 40 50 60 70 80 90 100 -10 0 Normal: [ -0.5 0 -0.86603 ] 0 10 20 30 40 50 60 70 80 90 100 -10 0 Normal: [ 0.5 0 -0.86603 ] 0 10 20 30 40 50 60 70 80 90 100 (a) (b)

Figure 4.5: A second example of a model and its curves (4.5a), followed by those curves being applied to a new model (4.5b). In this case the curves were manually extracted in 4.5a.

(29)

Algorithm 4.1Curve Application

1: function ApplyCurve(modelVertices, curves)

2: totalChange ← [0 0 0] for each point in modelVertices

3: fori = 0, k++, while k < number of curves

4: xValues ← vertices · curves[i].xVector

5: yValues ← vertices · curves[i].yV ector

6: scale ← 100/(min(yValues)-max(yValues)

7: yValues ← (yValues-max(yValues)) · scale

8: curveValues ← curves[i].curveInterpolation(yValues)/scale

9: newXValues ← xValues+curveValues

10: newMidX ← (max(newXValues) - min(newXValues)/2

11: distanceRatio ← (newXValues - newMidX/abs(max(newXValues)-newMidX)

12: distanceRatio[distanceRatio < 0] ← 0 13: totalChange ← totalChange+distanceRatio*curveValues*curves[i].xVector) 14: end 15: modelVertices ← modelVertices+totalChange 16: returnmodelVertices

4.2.2 Combining Curves

An additional feature of this approach is that any number of different curves can be trivially and naturally combined. Simply by appending the curves to each other before running the algorithm. For an example of this, see Figure 4.6.

(a) (b) (c)

Figure 4.6: An example showing how the curves used to generate 4.6a and 4.6b when combined creates a natural-looking blend of the two curves in 4.6c.

4.2.3 Removing Curvature

The same algorithm can also be used to remove the curves of a curved model by first calculating its curves, and then applying the negative versions of those curves back onto the model. Any other curve can then of course be applied to the

(30)

(31)

5

Automatic Positioning Of Models

Use of automatically selected sub-models means there needs to be a way of au-tomatically determining where these should be placed. Our implementation fol-lows that of Lun et al. [4], where each model is assigned a number of slots that are used to ensure that both placement and scaling are correct.

5.1 Slots

In the Lun et al. paper Lun et al. [4], slots are defined as marked areas that represent connection points between models.

In our implementation we define slots as a number of vertices, usually 8, which are used to determine placement and scaling of a sub-model by deter-mining a transformation through point matching. In the standard case each slot marks the eight corners of a model’s oriented bounding box (see Figure 5.2), but other ways of determining slots can be used depending on use case.

In the example of procedural building creation we use these slots to mark out where doors, windows, chimneys etc. are to be placed on the foundation. We then compare these to the slots of the model we are trying to place and find the transformation matrix that best fits one set to the other. A last step is then ap-plied where each placed slot checks that it is inside the boundaries of its allowed placement, such as keeping a door above ground level.

It is usually useful to allow for non-uniform scaling, since it makes for more accurate fitting. But if the uniformity is too extreme the outcome will look unnat-ural, see Figure 5.1. Our solution to this problem is presented in section 5.3.

(32)

20 5 Automatic Positioning Of Models

Figure 5.1:Example of bad non-uniform scaling.

5.2 Determining Slots

As previously stated slots in the standard case are found on the corners of the model’s axis-aligned bounding box. In cases where the model is part of another model, such as a house, it is often better to pick the slots using the intersection between the models. Since the intersection is often shallow, it can be better to just pick 4 slots instead of the usual 8. If the model parameters are well known this can be extended to 8 using information like overall model height, but if left at 4 slots this is one reason that the standard 8 slots are not always available.

8 -6 10 12 -4 14 -2 -1 16 0 1 -6 -5 -4 16 -3 14 12 1 10 0 -1 -2 8

Figure 5.2:Slots from the axis aligned bounding box of a chimney

Another possible reason for reducing the number of slots is if the lower num-ber it seems good enough for determining the transformation matrix. It might also be a welcome way of improving performance in the case when a large num-ber of models are being placed.

5.3 Placement

Once the slots are in place they need to be matched up. This is done through minimizing the error between two sets of slots in a least squares sense.

There is a decision to be made during placement whether to scale in a uni-form or non-uniuni-form fashion. Our implementation proposes non-uniuni-form scal-ing with per-model limits on the scalscal-ing. This approach both ensures that the resulting model is as adaptable as possible to allow for consistent functionality, while keeping the model from scaling in unnatural ways. The way we implement our scaling limits is described in section 7.2.

There are lots of previous work on natural ways of performing non-uniform scaling, like Kraevoy et al. [21] and Miao and Lin [22]. These approaches were

(33)

5.3 Placement 21

considered for this project but were ultimately decided against and left for future improvement because of time limitations.

5.3.1 Problems With Slots and Changing Models

Using slots for automatic placement interacts naturally with deforming models. Since slots themselves are simple vertices, they can be easily fed into the same algorithms that curve the models they are attached to.

Some special care has to be taken to ensure that they do not interfere with the algorithm, and in our solution we therefore treat them separately from the rest of the vertices, using the limits calculated from the rest of the points in the model.

In some cases however, the curvature can distort the shape of the bounding box in such a way that the slot fitting procedure becomes unreliable. If for exam-ple the curve causes the model to reach outside the bounding box of the slots, the resulting positioning can cause the models to intersect.

Figure 5.3:An example of how deformation can cause overlap.

This is shown in 5.3, where two interconnected models are deformed with a curve. As the curves get stronger the adapting slots make sure that the models still connect at the same point. But since the curve moves the models further and

(34)

(35)

6

Simplifications and Optimizations

Certain operations such as intersection finding and limit testing take a lot of time, which increases with the complexity of the models. To solve some of these problems we introduce some optional simplifications, which we call Contours and Shape Models. Both of which aid with computations and reduce noise in the input data without significantly affecting human workload.

6.1 Contours

When trying to keep functionality intact during building generation it is often important that the building is traversable. Therefore we must be able to add openings in the walls that match whatever is put there. Our solution to this problem is the use of contours.

A contour is a flat outline taken from the model. We create a contour by first projecting a model onto a flat plane and calculating the convex hull of this flat model, see Figure 6.1. We then return depth to it by placing it in the middle of the model it was taken from. The result is a number of vertices that can be used to create holes in buildings. Other uses include checking that no part of the model is outside reasonable limits. For example a door extending beyond the wall it is placed on.

The contour can be transformed just like the real model, but can be precal-culated and generally consists of far fewer vertices. It can, therefore, make up a minimal-case example for the real model, and can be useful in speeding up calculations in other places where using the full model is too computationally expensive.

(36)

24 6 Simplifications and Optimizations 4 3.5 3 1 1.5 2 2.5 3 3.5 4 3 3.5 4 1 1.5 2 2.5 3 3.5 4

Figure 6.1:Contour extraction process.

6.2 Shape Models

Another technique employed in our solution is the use of shape models. These are models that represent a simpler version of the real model. They are used for all calculations instead of the real model, such as determining slots, curvature or contour. This technique greatly speeds up calculations when dealing with big complicated models, as well as offers extra control over both placement and functionality.

(a) (b)

Figure 6.2:Door model (6.2a) and its corresponding shape (6.2b). For example, in Figure 6.2 the door on the left is the full model, while the shape model is on the right. The shape model offers a better description of the doors functionality by better matching the shape of the door’s natural wall open-ing. It also removes high polygon areas such as the doorknob, making it it a more computationally efficient model to work with.

(37)

7

Categorization and Selection

Piecing together functional models from a selection of sub-models requires a sys-tem for categorizing and searching through the selection, as well as a syssys-tem for determining what rules of style to follow.

7.1

7.2 Rules

Rules represent how the sub-models of a model should be used, and what addi-tional parts might need to be attached to complete the style in question.

These rules are stored on a per model basis. This means that if a certain sub-model is chosen, that sub-sub-model might have rules for at exactly what height it should be placed on the parent model, or for how often it should to be repeated.

An example of how a rule can work can be seen in Figure 7.4 where the rule connections-polesChinese1+0.5 is applied.

When the model roofChinese1 is selected, it requests the model with name polesChinese1 to be loaded in 50% of the time. This increases the variability while maintaining style rules.

Another common rule that greatly affects both the functionality and the ap-pearance of the model is relative scaling. Some models only work when the other

(38)

26 7 Categorization and Selection

(a) (b)

Figure 7.1:The two possible versions of the model roofChinese1, with (7.1a) and without polesChinese1 (7.1b).

models are at certain scales, see Figure 7.2. The models must therefore contain rules specifically about how to scale in relation to the other models.

Figure 7.2: A model where problematic scaling issues have occurred. Foun-dation windows and doors are wildly different scales from those of the roof.

7.3 Database

Our approach uses a database that contains an entry for each model, which in turn contains all categories, rules and other data belonging to the model. Other data includes information such as slots, directional vectors and contours.

Having all this data available and searchable means we can limit the conflict between the functionality and appearance even further. The designer of the func-tionality can decide only to search for parts whose rules are compatible with the functionality constraints of a building. The parts in turn can be implemented entirely separately by an artist.

(39)

7.3 Database 27

7.3.1 Pre-Database Representation

Since sub-model partitioning and categorization is done manually, there needs to be a somewhat simple format for entering the data into the database. Our solution to this is a an implementation based on a filesystem division of models.

Our main directory of all models is a folder called Archive, with each set of sub-models populating one folder in this directory. When populating the database, the program searches through each directory looking for files with the name info.txt. The text files contain metadata, located alongside each set of sub-models. In Figure 7.3 and Figure 7.4 the folder setup and the respective info.txt file of one of these model folders can be seen.

(a) (b)

Figure 7.3:File system layout of models and info.txt-files.

Every entry of a sub-model’s metadata starts with a single line representing the sub-model’s unique name. Every subsequent line represents a data point starting with the name of the data point, followed by the data values. An entry is terminated with a single punctuation mark.

The program reads these line by line, and uses the data provided to populate the database, calculating and storing information like slots and curves according to the information provided.

One sub-model can consist of several filenames. The entry’s model will then be viewed by the program as the merger of these files. Having this division al-lows for using further divisions of models where necessary, without having to duplicate data.

(40)

mod-28 7 Categorization and Selection foundationChinese1 class foundation filename roofConnector.ply normal 0 0 1 up 0 1 0 style chinese rules curve-0 . baseChinese1 class base filename base.ply normal 0 0 1 up 0 1 0 style chinese slotType intersect-foundationChinese1 . roofChinese1 class roof filename roof.ply shape roofShape2.ply normal 0 0 1 up 0 1 0 style chinese slotType intersect-foundationChinese1 rules connection-polesChinese1+0.5 . polesChinese1 class poles filename poles.ply normal 0 0 1 up 0 1 0 style chinese slotType surround-foundationChinese1 .

(41)

8

Demo Environment

In order to present the potential of style transfer as a model for creating procedu-rally generated buildings, we built a simple demo environment that produces a procedurally generated building using only style as its input.

8.1 Implementation

The initial plan was to use an external procedural building generation engine. However, it was decided that the ones available would take too much time to get into and offered too little control in their raw form. It was therefore decided to create a very simple building generator. Our implementation suffers in the variation of buildings it creates, acting instead as a simple proof of concept of the power of functionality-independent style-based building generation.

The implementation is based on code that was originally used for testing curve transfer, and is thus fairly simple. The program flow is described below.

8.1.1 Choosing Parts

The first part concerns functionality, as the classes of parts necessary for the func-tionality are chosen. This could be done at a later stage, but by setting these limits up front we can better control the complexity of the created model needed in subsequent steps.

In the list of classes there always needs to be a foundation part included, these are added automatically.

(42)

30 8 Demo Environment

8.1.2 Style Choice & Search

As style input for the demonstration is a string containing the name(s) of the style required. The program then searches through the database for models with matching classes and styles and loads one of each, together with any rules associ-ated with them.

If a foundation part is chosen, it will provide the style curves to be applied onto the new foundation.

8.1.3 Foundation Creation

A complexity estimate is made based on the minimum distance between two con-secutive points on the curve provided. A foundation for the building is then created using this estimate to determine the density of vertices necessary. The building is made up of a number of straight walls connecting at the sides, with opposite walls of equal length.

Each wall is made up of two parallel planes. The back plane being a simple four vertex square, since the inside wall should not be curved. The outside wall is made up of a grid, with the number of vertices making up the grid determined by the previously mentioned complexity estimate. If there is no curve, then there is no need to have a complex grid and the front wall is also made up of a single square. If the curve has very tightly placed vertices the grid might have to be high density. Examples of walls can be seen in Figure 8.1.

(a) (b) (c) (d)

Figure 8.1: Walls with different point densities (8.1a, 8.1b, 8.1c), and an example of a completed foundation in (8.1d)

At this point a number of slots are created using information about the newly created foundation and the rules set by functionality and style choices. A struc-ture describing the connection is created for each set of slots.

8.1.4 Roof Placement

Before any other operations or placements are performed, the roof (or roof shape) is fitted to the foundation. The foundation is then extended upwards toward the the roof by projecting each vertex on top of the wall upwards and seeing at what

(43)

8.2 Test Runs 31

height it interact with the roof. New vertices are then added to the wall between the top and the intersection point. These vertices are added at the same intervals as the points of the wall below it. See Figure 8.2 If there is no roof, this step is skipped and the roof is instead created by adding a plane on top of the walls.

(a) (b)

Figure 8.2:The foundation is extended towards the roof by projecting each line upwards until collision and adding new vertices at the same density.

8.1.5 Hole Placement and Triangulation

Next, every sub-model that needs to create a wall opening is dealt with. Their contours are fitted according to the models’ slots, and then projected onto both the front and back of the walls they are attached to. Finally, they are added to the set of wall vertices.

Each wall is given faces using constrained Delaunay triangulation, with the constraints around each hole and around the edges of each wall. The faces in each opening is then removed. Finally an extra set of faces is added between the holes on the front and back side of each wall, filling in the space between walls.

8.1.6 Curving and Final Adjustments

The entire wall structure is now merged together and curved according to the previously established curves, including all slots. Each sub-model is fitted a final time and their transformation matrices stored. Each model is then loaded into memory, transformed and added to the foundation model before it is all written to disk.

8.2 Test Runs

As a demonstration of the potential of our approach, we run two versions. The first has a static functionality input, to show the potential for difference brought on by style alone. In the second version we introduce some random elements in

(44)

8.2.1 Static Functionality, Changing Style

This test run uses a simple static building functionality setup: four walls, one door and windows evenly spaced out around the building. The resulting building, with no style input can be seen in Figure 9.1a.

We then run the algorithm a couple of times with different style inputs, to show the possible differences brought out by the style rules. See Figure 8.3. Note how in Figure 9.1b and 9.1c the same style input has been used for both but two very different buildings were generated.

(a) (b) (c) (d)

Figure 8.3: A few runs of the demonstration with a static functionality input and changing style input. Figure 9.1a shows a bare result with no style input. Figures 9.1b and 9.1c show two variants with ’chinese’ as style input. And Figure 9.1d shows a result of using ’cathedral’ as style input.

8.2.2 Changing Functionality, Static Style

In this test we add some simple random elements to the functionality creation. We vary the number of walls, length of those walls and number of windows. We then run through these a few times with a consistent style input. Results are shown in Figure 8.4

(a) (b) (c) (d)

Figure 8.4: A few runs of the demonstration with a static style input and changing functionality input.

(45)

8.2 Test Runs 33

8.2.3 Performance

Run times for the demonstration generally range between 1 and 25 seconds, de-pending mostly on the complexity of the models being loaded. There are two main bottlenecks, as can be seen in the table of runtime profiles in Figure 8.5.

The first bottleneck is I/O, particularly when writing to disk. This is a minor problem, since if the result is required to be written to disk then the application itself is probably an offline job. I/O on the loading end could be easily improved by asynchronously loading models in the background. This is possible since we know what models will be needed at the start of the program, long before most of them are needed.

The second bottleneck is ray tracing. In our implementation this is employed primarily when extending the foundation to intersect with the roof. It therefore depends almost entirely on the complexity of the foundation and the complexity of the roof model. Since the foundation point density is chosen by the program-mer, this can be tuned according to the needs of the system. For the roof, using proper simplified shape models as described in Section 6.2 can greatly reduce the problem.

(46)

(a)

(b)

Figure 8.5: Profiles examples of a short run and a long run. Left is profile ordered by total time spent in each function, and right is ordered by self time of each function. Note that the main bottleneck for the short run in 8.5a is when writing to disk, while in the long run in 8.5b it is performing ray casts in function raysFaceIntersect.

(47)

9

Results

The results of the thesis are split into three separate sections where we describe the results and discuss their implications:

Style-Functionality Separation is where we describe our approach to separat-ing style and function. We discuss how well this accomplishes its goals and brseparat-ing up its shortcomings.

Demo Environment and Performance is where we discuss our demo environ-ment. This includes how it displays the potential of our approach and where it falls short.

Other Applications is where we present some interesting side results of the methods used in this thesis. They come from small tests and do not have any proper place in the broader scope of this paper. We thought them appropriate to include here anyway, as they tie into the inspirations for this project and may have interesting implications.

9.1 Style-Functionality Separation

This thesis set out to find a way of procedurally generating buildings while sepa-rating their appearance from their functionality.

9.1.1 Proposed Approach

We first looked at what makes up a distinct architectural style. From literature we determined that similar overall curves and recurring geometric elements are the main signals of an architectural style.

In the context of buildings, we determined that the most important curve to keep is the overall curve of the building foundation. Everything not directly part

(48)

36 9 Results

of the foundation such as windows, doors, roofs etc. are recurring geometric elements, which are placed according to rules intrinsic to themselves.

We proposed a method of detecting the dominant curve of a model and a way to transfer that curve onto other models. This method also allows for natural melding of different curves.

We also proposed a system for reusing sub-models, the parts that make up the model of a building, in a procedural generation system.

Our system allows for separation of function and appearance by applying two sets of rules. One set of rules is defined by the designer of the procedural building engine, while the other is defined by the sub-models later applied to the procedural building.

By tying the architectural rules to each sub-model in a database we make them searchable. This means that in the procedural generation we can search only for parts with compatible rules, and thereby disconnect the designer of the building functionality from the designer of the architectural style.

9.1.2 Problems

This approach’s main drawback is that it requires a lot of additional work in the form of creating metadata for each model. For this thesis we only took apart and created metadata for a total of thirteen out of our total pool of over 200 models. This was partly because of the constant changes during the development, but it also points at the effort needed to create the data and rules necessary.

Our implementation of the approach does not include a mature way of creat-ing these rules or enforccreat-ing them. A more complete set of rules would be neces-sary to properly implement our system.

Our implementation suffers in the details, such as when it comes to determin-ing curves. It quite often chooses the wrong curve if provided with even slightly off models and it cannot handle tight curves at all. This could just be a matter of tweaking the implementation, but we suspect using a method based on edge detection would give better results.

9.2 Demo Environment and Performance

As a proof of concept of our proposed approach we built a demo environment. This demo environment uses our concepts to create simple procedural buildings that showcase the strengths of the approach, examples of which can be seen in Figures 9.1, 9.2 and 9.3. Building this demo also let us examine the expected performance of our method.

(49)

9.2 Demo Environment and Performance 37

(a) (b) (c) (d)

Figure 9.1: A few runs of the demonstration with a static functionality input and changing style input.

(a) (b) (c) (d)

(50)

38 9 Results

Figure 9.3:A sample of the buildings generated by the demo with changing style and functionality inputs.

(51)

9.3 Other Applications 39

9.2.1 Implementation

Our implementation creates the procedural building in a number of steps, blend-ing a set of rules together from a functionality standpoint and from a style stand-point.

It creates a building by loading the parts needed, creates a foundation while taking the rules provided into consideration, and adds every part into its correct place before writing the result to disk.

9.2.2 Problems

Our implementation of a procedural building engine is extremely limited, as it only creates very simple buildings, with generally repetitive elements. It also does not contain a good way of implementing the set of rules we propose through-out this thesis beyond hard coding them into the generation.

9.2.3 Performance

The demo is built in Matlab, a language not known for its performance, and only minimally optimized. Despite this our demo generation times were between 1 and 25 seconds depending on model complexity. An average around 70-90% of that being I/O in the low complexity range. In the high-complexity range I/O dips down to being around 20% of runtime, with the a majority of the time spent performing raycasts.

Performance Possibilities

We see a potential for good performance with our approach. To show this we propose a few possible solutions for the two main bottlenecks we saw in our implementation.

Reducing raycast time come down to adjusting implementations and using good shape models.

I/O issues could be dealt with through asynchronous loading, and by skip-ping writing to disk. And, because of the reuse of models, both within models and across several procedurally generated buildings in the same style, there is potential for using GPU instancing when displaying the models in a real time application.

9.3 Other Applications

Because the approach used in this thesis was heavily inspired by Lun et al. [4], we thought it interesting to try our style transfer approach in the context of furniture models. By applying the same curve transfer and part replacement methods used throughout this paper to furniture models, we attempted our own version of the style transfer done by Lun et al. [4]. For simplicity we forwent the database

(52)

ap-40 9 Results

results were promising, as can be seen in Figure 9.4, and hint at possible applica-tions outside the field of building generation.

(a) (b) (c)

Figure 9.4: Using our curve transfer and part replacement methods we at-tempted to transfer the style of 9.4a onto 9.4b resulting in 9.4c.

(53)

10

Conclusions

This thesis has proposed a system for procedural building generation which at-tempts to separate style from functionality in the context of procedural building generation.

In this final chapter we summarize the conclusions drawn around the success of this project and its potential applicability. We then present what we think are the main problems met throughout this thesis, and recommend areas of interest for future research.

10.1 Conclusions

This thesis has proposed a system for procedural building generation that solves the problems we set out to solve, namely the separation of style and functionality. Our proposed approach shows promise in both its flexibility and its performance. While we deem the system we used good enough to showcase the potential of our approach, the realization of this promise is held back by the procedural generation engine used for this project. If our system could be coupled with a better engine, the results it could achieve and its limits could be much better explored.

If we imagine our approach used in a fully mature implementation, its biggest drawback is that it requires a lot of human work in creating the metadata our system requires.

Ultimately, we consider this project a success. Our approach could in theory allow for reuse of large databases of models and simplify the creation of procedu-ral generation engines. In the context of video game creation, it could decrease conflicts between artists, programmers and game designers.

(54)

42 10 Conclusions

10.2 Possible Future Development

There are a lot of interesting future work to be done in this area. As stated in the previous section, there are two main things lacking in our implementation. One is a good building generation engine to couple with our system, and the second is improvement in categorization and creation of metadata.

The first problem is the lack of a good system for creating buildings based on separate rules. We therefore propose combining our ideas with a more rigorous rule-based system for procedural building generation such as Leblanc et al. [10]. We only stumbled upon this work late in development and did not have time to incorporate it into the thesis. But on the surface it sounds like a good fit for further exploration.

The second area of concern is the creation of metadata. Creating architectural and functional rules is time-consuming work. Several of our sources for this work incorporate machine learning in efforts to categorize both style and functionality. If such a system could be used to actually determine the architectural rules and functional rules of an arbitrary object, then they could automatize part of the work required to create the databases we envision.

(55)

Bibliography

[1] Zhaoliang Lun, Evangelos Kalogerakis, and Alla Sheffer. Elements of style: Learning perceptual shape style similarity, . URL http://people.cs. umass.edu/~zlun/papers/StyleSimilarity/. Cited on pages viii, 5, 6, and 9.

[2] Turbosquid. Turbosquid. URL https://www.turbosquid.com/. Cited on pages 1 and 9.

[3] Trimble Inc. 3D Warehouse test. URL https://3dwarehouse. sketchup.com/. Cited on pages 1 and 9.

[4] Zhaoliang Lun, Evangelos Kalogerakis, Rui Wang, and Alla Sheffer. Func-tionality preserving shape style transfer. ACM Transactions on Graphics, 35 (6), 2016. Cited on pages 1, 3, 4, 5, 6, 19, and 39.

[5] Zhaoliang Lun, Evangelos Kalogerakis, and Alla Sheffer. Elements of style: Learning perceptual shape style similarity. ACM Transactions on Graphics, 34(4), 2015. Cited on pages 3, 4, 5, and 9.

[6] Evangelos Kalogerakis, Siddhartha Chaudhuri, Daphne Koller, and Vladlen Koltun. A probabilistic model for component-based shape synthesis. ACM Trans. Graph., 31(4):55:1–55:11, July 2012. Cited on pages 3 and 4.

[7] Haibin Huang, Evangelos Kalogerakis, and Benjamin Marlin. Analysis and synthesis of 3d shape families via deep-learned generative models of sur-faces. Computer Graphics Forum, 34(5), 2015. Cited on pages 3 and 4. [8] Pascal Müller, Peter Wonka, Simon Haegler, Andreas Ulmer, and Luc

Van Gool. Procedural modeling of buildings. ACM Trans. Graph., 25(3): 614–623, July 2006. Cited on page 3.

[9] Soon Tee Teoh. Generalized descriptions for the procedural modeling of an-cient east asian buildings. In Proceedings of the Fifth Eurographics Confer-ence on Computational Aesthetics in Graphics, Visualization and Imaging, Computational Aesthetics’09, pages 17–24. Eurographics Association, 2009. Cited on page 3.

(56)

44 Bibliography

[10] Luc Leblanc, Jocelyn Houle, and Pierre Poulin. Component-based modeling of complete buildings. In Proceedings of Graphics Interface 2011, GI ’11, pages 87–94. Canadian Human-Computer Communications Society, 2011. Cited on pages 3 and 42.

[11] Kai Xu, Honghua Li, Hao Zhang, Daniel Cohen-Or, Yueshan Xiong, and Zhi-Quan Cheng. Style-content separation by anisotropic part scales. ACM Trans. Graph., 29(6):184:1–184:10, December 2010. Cited on page 4. [12] Thomas Funkhouser, Michael Kazhdan, Philip Shilane, Patrick Min,

William Kiefer, Ayellet Tal, Szymon Rusinkiewicz, and David Dobkin. Mod-eling by example. ACM Trans. Graph., 23(3):652–663, August 2004. Cited on page 4.

[13] Noah Duncan, Lap-Fai Yu, and Sai-Kit Yeung. Interchangeable components for hands-on assembly based modelling. ACM Trans. Graph., 35(6):234:1– 234:14, November 2016. Cited on page 4.

[14] Siddhartha Chaudhuri and Vladlen Koltun. Data-driven suggestions for cre-ativity support in 3d modeling. ACM Trans. Graph., 29(6):183:1–183:10, December 2010. Cited on page 4.

[15] Mario Botsch, Mark Pauly, Markus Gross, and Leif Kobbelt. Primo: Cou-pled prisms for intuitive surface modeling. In Proceedings of the Fourth Eurographics Symposium on Geometry Processing, SGP ’06, pages 11–20. Eurographics Association, 2006. Cited on page 4.

[16] Takeo Igarashi, Tomer Moscovich, and John F. Hughes. As-rigid-as-possible shape manipulation. ACM Trans. Graph., 24(3):1134–1141, July 2005. Cited on page 4.

[17] Zhaoliang Lun, Evangelos Kalogerakis, Rui Wang, and Alla Sheffer. Func-tionality preserving shape style transfer, . URL https://people.cs. umass.edu/~zlun/papers/StyleTransfer/. Cited on page 5. [18] Mathworks. Matlab. URL https://www.mathworks.com/products/

matlab.html. Cited on page 8.

[19] Paolo Cignoni, Marco Callieri, Massimiliano Corsini, Matteo Dellepiane, Fabio Ganovelli, and Guido Ranzuglia. MeshLab: an Open-Source Mesh Processing Tool. In Vittorio Scarano, Rosario De Chiara, and Ugo Erra, ed-itors, Eurographics Italian Chapter Conference. The Eurographics Associa-tion, 2008. ISBN 978-3-905673-68-5. doi: 10.2312/LocalChapterEvents/ ItalChap/ItalianChapConf2008/129-136. Cited on page 8.

[20] Inc MongoDB. Mongodb. URL https://www.mongodb.com/. Cited on page 9.

[21] Vladislav Kraevoy, Alla Sheffer, Ariel Shamir, and Daniel Cohen-Or. Non-homogeneous resizing of complex models. ACM Trans. Graph., 27(5):111:1– 111:9, December 2008. Cited on page 20.

(57)

Bibliography 45

[22] Yongwei Miao and Haibin Lin. Salience-based feature preserving resizing for 3d models. In SIGGRAPH Asia 2013 Posters, SA ’13, pages 13:1–13:1. ACM, 2013. Cited on page 20.

Functionality-Independent Style-Based Procedural Building Generation

Master of Science Thesis in Electrical Engineering

Department of Electrical Engineering, Linköping University, 2017