1 Introduction
Layout computation is an important tool for modeling virtual environments and planning new environments for construction. The behavior of such environments is largely dictated by the underlying networks, both at global and local scales. For example, in the context of urban planning, the transportation network determines the access patterns across a city; or, in the context of games, a welldesigned layout map can ensure graded complexity of the play area.
Often, a designer would want to create networks simply by describing how the target environment should behave. We refer to such highlevel descriptions as functional specifications. For example, functional specifications can come in the form of desired network density, transportation pattern, local features (e.g., whether deadends or branches are allowed), etc. In this paper, we study how to design networks starting only from such functional specifications.
Limited support exists for such a design paradigm. A brute force solution is to propose various network variations and rank them in an effort to design a target environment. For ranking, one can evaluate the behavior of a given network using a blackbox forward simulation (e.g., using a traffic simulator, or solving a flow problem). However, such a trialanderror approach is tedious and time consuming. This is especially so as even small changes in network topology can result in large global behavioral changes.
We observe that in network design one has to typically balance between conflicting requirements: networks should be densely connected in order to obtain low average transportation times; while, the total length of the network should be small in order to leave space for other assets. In addition, there are certain factors that may have large effects on the appearances of networks: local features, such as deadends and branches, and the distribution of the transportation destinations (denoted as sinks in this paper). Based on these observations, we produce a desirable network layout based on a novel integer programming (IP)based approach that takes as input a set of functional specifications and boundary description of the target domain. Technically, the proposed IP formulation guarantees that the designed networks are valid by ensuring that they are free of islands (see Figure 2 for examples) and offer sufficient coverage over the target domain, while having desirable quality as measured by the specified functional specifications.
We evaluate the proposed algorithm in the context of urban street layouts, floorplanning, and game level design. We identify a set of commonly appearing functional specifications (Section 3) across the three scenarios and propose how to effectively model them (Section 4). For example, Figure Computational Network Design from Functional Specifications shows different networks created by our algorithm using different functional specifications.
In summary, our main contributions are:

proposing the problem of network design directly from functional specifications;

formulating the problem as an integer optimization framework that supports common functional specifications; and

evaluating the generated networks in three different design contexts, and demonstrating that nontrivial and desirable network layouts can emerge only from highlevel functional specifications.
2 Related Work
Layout modeling. There are various layouts that have been modeled in computer graphics. In some of these layout computations, transportation networks have no significant role, e.g., in the distribution of vegetation [Deussen et al. 1998]. However, there are many examples of layouts that have at least some network aspect to them. In furniture layouts of Yu et al. Yu:2011:MIH, the existence of obstaclefree walking paths was a consideration in modeling the objective function. Several biologically inspired simulations also model networks. For example, Runions et al. Runions:2005:MAV generate leaf venation patterns that result in fascinating graphs. River networks can be modeled using hydrological principles [Génevaux et al. 2013]. Another important problem is the layout of building floorplans [Merrell et al. 2010] or game levels [Ma et al. 2014], because the rooms and hallways also induce a network.
Street modeling. Initial work on street network modeling focused on algorithms to synthesize street networks that resemble existing ones. One approach is to grow street segments greedily until the available space is filled [Parish and Müller 2001, Weber et al. 2009]. An alternative version is to first sample points on the street network that are connected in a subsequent algorithm step [Aliaga et al. 2008]
. Chen et al. Chen:2008:IPS proposed the use of tensor fields to guide the placement of street segments. One way to improve synthesis algorithms is to optimize the quality of street networks to include local geometric and functional quality metrics, such as street network descriptors
[AlHalawani et al. 2014], sunlight for resulting buildings [Vanegas et al. 2012], the shape of individual parcels [Yang et al. 2013, Peng et al. 2014b], or the shape of individual roads interacting with the environment [Maréchal et al. 2010]. There are some initial attempts to include global traffic considerations into the layout process. A simple first step is to compute a traffic demand model and use this model to modify street width or to guide expansion of the street network [Weber et al. 2009, Vanegas et al. 2009]. The connectivity of the road network is also a fundamental requirement for generating highlevel roads connecting cities and villages [Galin et al. 2011]. A recent paper describes how to design traffic behavior in an urban environment [GarciaDorado et al. 2014]. This paper touched on many aspects of traffic design that would make a great addition to our proposed system. While most of the proposed components are complementary to our paper, one important component of this system is an algorithm to modify an existing street network by making lowlevel random modifications. Instead, we focus on the complementary problem of generating the initial coarse network only from functional specifications.Modeling methodology. From the methodology side, there have been multiple interesting approaches in the recent literature that are suitable to model interesting shapes. The first approach is procedural modeling using grammars, e.g., [Prusinkiewicz and Lindenmayer 1990], that enables a user to write rules for shape replacement. The second approach is to learn new shapes when given a database of existing shapes, e.g., [Kalogerakis et al. 2012]
. This approach requires machine learning techniques, such as graphical models, to encode the relationships between different shape components. The third approach is to use optimization to compute forms from a functional description, e.g.,
[Bao et al. 2013]. Our methodology follows the last line of work.Network design by IP has also been explored in other fields (e.g., telecommunication [Koster et al. 2010], transportation [Luathep et al. 2011]). However, the approaches are quite different – we consider networks as graphs to be embedded in a 2D plane, while other approaches often consider networks as abstraction models.
3 Functional Specifications
Our goal is to allow users to create networks simply by describing a set of functional specifications on how the generated networks should behave. We studied commonly used design practices from the relevant literature [Southworth and BenJoseph 1995, Meyer and Miller 2000, Handy et al. 2003, Southworth and BenJoseph 2003, Marshall 2005, Board 2010]. From these works, we recommend [Association 2006] for a simple introduction to urban planning standards in general and [Ortúzar and Willumsen 2011] for a more technical introduction to transportation models. In the context of floorplanning, circulation is a fundamental concept in architecture (cf., [Ching 1996]) that is considered in the design of every building. For games, we referred to RPG game maker [Enterbrain, Inc. 2015] and different game design blogs (e.g., http://www.vgleveldesign.com/levellayouttypes/ and online book http://pcgbook.com/). We identified a set of recurring considerations and summarize them as functional specifications that we describe next.
Density. The desired density of a network encodes the average spacing between the network edges.
Network lengths versus travel distances. For networks with comparable densities, two extreme cases can happen. On one extreme, the total network length can be minimized. On the other extreme, networks can facilitate more efficient travels, usually toward certain destination locations predefined on the domain. In our framework, the user can give a relative preference between the two.
Traffic types. We support three types of traffic for a target network: interiortoboundary, interiortointerior, and boundarytoboundary traffic. Networks arising from different types of traffic specifications tend to look quite different (e.g., Figure 6a, e, d, in respective order). Users can indicate a preference among the three.
Sink locations. A key function of networks is to facilitate accesses to certain predefined destination locations, i.e., sinks. We allow the shape of a network to be controlled by the distributions of such sinks. Intuitively, a network tends to look like a rootlike structure grown from the destination locations. The user can select the sink location to be: (i) all of the boundary, or (ii) only at a subset of the boundary, or (iii) at the interior of the target domain.
Local features. There are certain local features that can have profound effects on the appearances of the target networks. Examples are deadends, branches, and Tjunctions. Users can determine if any of such features should be forbidden or just appear with lower frequency.
User specifications. We provide two ways to directly control the generated networks. First, specifying certain locations as obstacles that the generated network must avoid. Second, enforcing certain routes to appear in the generated network, for example, a direct route between two boundary locations to boost throughtraffic.
4 IPbased Network Design
In this section, we introduce an integerprogramming (IP)based optimization approach for designing networks from the functional specifications described in Section 3 on a given problem domain. We assume that the domain, given as a piecewise linear 2D polygon, is discretized into a polygonal mesh, . Our goal is to select a subset of the edges in as the network. We consider a selected network to be valid if it satisfies two constraints: (i) A noisland constraint that ensures accesses to specified destination locations (i.e., sinks) predefined on the domain. (ii) A coverage constraint that ensures the network sufficiently covers the whole domain (i.e., all vertices in are within a distance to the network).
We rate such valid networks based on a set of quality measures: First, we prefer networks with smaller total length as longer networks are often more expensive to build and maintain, and take up more usable space from the domain. Second, we prefer networks with shorter travel distances to the sinks (from every vertex in the network). As these are mutually competing goals, our objective function measures the quality of the solutions as a weighted sum of the two.
We also support two additional quality measures: (i) ensure quick accesses between any two locations in the network by a pointtopoint constraint (note that this is not guaranteed if we only optimize for quick accesses to the sinks.); and (ii) introduce measures for controlling the local features (e.g., deadends, branches, and Tjunctions) in a network. Before describing how we encode such quality measures, we begin with the following definitions.
Definition 4.1
A network is a subset of the edges in . An edge is active if it is in the subset; otherwise, it is inactive. A vertex is active if any of its adjacent edges are active; otherwise, it is inactive. The sinks are a predefined subset of the vertices in .
We use Boolean indicator variable, , to model the active/inactive states of every edge, , for with being the number of edges in .
Noisland constraint. Our goal is to design networks without islands, while still allowing loops in the networks. We proceed as follows: First, without changing the definition of a network, we distinguish each halfedge, (i.e., goes form vertex to ), as active or inactive, by a Boolean indicator variable , for with being the number of vertices in . Our goal is to assign each active halfedge, , a distance value that roughly encodes the distance of toward the closest sink vertex along the active halfedges in the network. We model the distance value of halfedge as a nonnegative continuous variable, , for with being the sum of the lengths of all halfedges in . To achieve this goal, the following requirement should be satisfied:
Proposition 4.2
For a halfedge to be active, at least one of its succeeding halfedges (i.e., the halfedges that go from but not go back to ) also needs to be active and be assigned a distance value smaller than the distance value of , except if is a sink vertex.
We model this requirement as: For every succeeding halfedge, , for , where is the onering neighborhood of , of every halfedge in such that is not a sink vertex,
(1) 
(2) 
where, are auxiliary Boolean variables associated with every halfedge, , one for each of its succeeding halfedges, , for , . is the length of halfedge . Note that can be true only if: (i) is active (enforced by inequality 1), and (ii) has a smaller distance value than the distance value of by at least the length of (enforced by inequality 2).
Next, the following inequality ensures that for to be active, at least one of its auxiliary variables must be true: For every halfedge in , , such that is not a sink vertex,
(3) 
To illustrate noisland constraints, on the right, we show the topmiddle part of Figure 2(d) with vertex indices. As all edges have uniform lengths, constants , , all equal to one. Continuous variables , , , and are assigned to be , (arbitrary), , and . Therefore, by inequality 2, and are false and is true. This allows to be true by inequality 3.
We now prove that that the requirement in Proposition 4.2 forbids islands in networks. Assume a network contains one or more islands and the requirement is still met. There exists at least one weakly connected component that is not connected to the sink vertices (i.e., an island). Within this island, there cannot exist any active halfedge that has no succeeding active halfedges, otherwise the requirement is immediately violated. Therefore, there must exist at least one loop of active halfedges in the island, denoted as , , … , is the number of vertices in the loop. Since none of these vertices are sinks, , a contradiction.
Note that the requirement does not forbid loops in networks. One example is shown in Figure 2.
Finally, we say that an edge is active if and only if at least one of its two halfedges is active: For every edge in , ,
(4) 
where, and are the Boolean indicator variables of ’s two halfedges. is the Boolean indicator variable of .
The above formulation above was inspired by an IP formulation of the Traveling Salesman Problem [Miller et al. 1960]. However, unlike theirs, the new formulation allows loops involving the starting nodes (i.e., sink vertices).
Coverage constraint. We expect a network to sufficiently cover the whole domain. We take a simple coverage model such that an active vertex covers itself and its nearby vertices within a distance threshold. Alternatively, different coverage models (to determine which vertices are covered by an active vertex) can be used for different design scenarios. A network sufficiently covers if all the vertices in are covered. We model this as described next.
We denote the active/inactive states of every vertex in , , as Boolean indicator variables , . Since a vertex is active if and only if at least one of its adjacent edges is active, we have the following constraint: For every vertex in , ,
(5) 
, where is the set of edges that are adjacent to .
We can now encode the coverage requirement as: For every vertex in , ,
(6) 
where denotes the set of indicator variables of the vertices that cover .
Objective function. We want to minimize two aspects of a network. First, the total length of the network. Second, the total travel distances to the sinks. The first term can be expressed as the summation of all edge indicator variables multiplied by each edge’s length. The second term can be expressed as the summation of all distance values of halfedges. Thus the objective function takes the form:
(7) 
where is the length of edge , is the weight for the total length term, and is the weight for the total travel distance term. Note that when is set to zero, the distance values may not be assigned correctly and have to be calculated in a postprocess. In Figure 3, we analyze how the assignments of versus affect the optimization results.
Pointtopoint constraint. Here, our goal is to constrain the travel distances between any two vertices in the network, not just the travel distances to the sinks. While explicitly modeling such constraints is possible, it would be prohibitively expensive since we need to model every possible paths between every possible pairs of vertices. Below, inspired by the construction of spanners for graphs [Baswana and Sen 2007], we describe a costeffective way to approximate our goal.
We first partition into a set of submeshes (i.e., a connected set of faces), , is the number of submeshes. , , . . We assume the partition is given by the user. We say that two submeshes are adjacent to each other if they share common edges. Next, we randomly sample one vertex in every submesh. For sampling, we consider vertices that are not adjacent to any other submeshes, unless such vertices do not exist. For every pair of adjacent submeshes, we red exhaustively enumerate the set of paths (i.e., a consecutive sequence of edges) connecting the two sampled vertices with topological lengths not greater than the length of a shortest path between the two vertices plus a tolerance value (we use ).
For every such set, we require that at least one of the paths is active (i.e., consisting of active edges). In summary, we require the network to connect every pair of adjacent submeshes by connecting their respective sampled vertices. One example (for Figure 1c and g) is shown on the right. They are modeled as follows.
Let be a Boolean indicator variable indicating the presence of the th path among the set of paths connecting two sampled vertices (of submesh ) and (of submesh ), for and with being the size of the set. Let , denote the edges on path , is the size of the path. We have:
(8) 
For every set of paths connecting sampled vertices and :
(9) 
As shown in Figure 1c and g, enforcing such constraints leads to networks that are more tightly connected, which in turn have quicker accesses between any two vertices in the network. Users can control the strength of the pointtopoint constraint by the density of the partitions. While this approach is computationally cheap, it can overconstrain the resulting network. Therefore, we consider alternative ways that better balance flexibility and computational cost as a direction for future work.
Next, we introduce quality measures for controlling local features in a network.
Deadend avoidance. We may desire networks that have no deadends, i.e., an active vertex that is adjacent to just one active edge. To achieve this, we give every halfedge, (from vertex to ), a nonemptiness Boolean indicator variable, . is true if any of the ’s adjacent edges, excluding the edge of , is active. It is false otherwise. It is modeled as follows.
For every halfedge in , ,
(10) 
, where is the set of edges adjacent to .
Deadends can then be avoided by the following constraints:
For every halfedge in , ,
(11) 
Branch avoidance. It is simple to avoid branches (i.e., a vertex with more than three adjacent active edges) in a network by the following constraint: For every vertex in , ,
(12) 
, is the set of edges adjacent to . Enabling branch avoidance constraint leads to cyclelike networks (see the game level design example in Figure 10b).
Local configuration control. We identify certain local
configurations of active edges as undesirable, which include: (i) zigzags and (ii) edges that are too close to each other. Their occurrences can be strictly forbidden or minimized.
As shown on the right, for each halfedge, , we identify two undesirable configurations. The presence of each configuration on is denoted by a Boolean indicator variable, , where equals for zigzags and for edges that are too close to each other. This is modeled as follows: For every that denotes the presence of the th undesirable configuration on halfedge ,
(13) 
, where denotes the set of edges comprising the th undesirable configuration on .
To forbid the presence of any of such configurations, simply enforce all to be false. As this constraint can be too strict, we can instead minimize the occurrence of such configurations by adding the weighted summation of to the objective function.
In a similar way, we can forbid or minimize the occurrence of Tjunctions as follows. For each halfedge pointing to a valence vertex, , the presence of a Tjunction on is denoted by a Boolean indicator variable, , modeled as follows:
For every halfedge in , ,
(14) 
where, is the edge indicator variable of ’s edge, and to are the edge indicator variables of the other three edges adjacent to (see right figure). Again, we can forbid Tjunctions by enforcing all to be false, or minimize their occurrence by adding the weighted summation of to the objective function.
We now rewrite the objective function as follows:
(15) 
where, is the length of edge , is the weight for the total length term, is the weight for the total travel distance term, , , are the weights for minimizing the occurrences of the two undesirable configurations, and is the weight for minimizing the occurrence of Tjunctions.
User specifications. Users can explicitly specify certain combinations of vertices and/or edges to be inactive or active in a network. It is straightforward to impose these specifications by constraining the corresponding vertex or edge indicator variables to be true or false. Examples of such specifications can be seen in Section 5.
5 Applications and Results
Our results are categorized by different design scenarios: urban street layouts (Section 5.1), floor plans for large facilities such as offices and hospitals (Section 5.2), and game level design (Section 5.3). The large variety of the results demonstrate the versatility of our IPbased approach.
5.1 Urban street layouts
We aim at generating street layouts at the scale of city blocks to a small city. Based on the hierarchical nature of realworld road networks, we lay out the streets in four levels. First, a coarse network of major roads (e.g., freeways or arterial roads) that partitions the city into several subregions. Second, for each subregion, a denser network of collector roads with the purpose of collecting traffic from the local roads. Third, grown from the collector roads, an even denser network of local roads that roughly span the whole subregion. Fourth, there may be some culdesacs grown from the streets at the previous two levels.
We assume that the network of major roads is designed by the user. Afterwards, for each subregion, our pipeline to create the street layouts is as follows (see Figure 4).

We first compute a dense network of street segment candidates in the form of a semiregular (i.e., most vertices are of valence ) quad mesh, , wherein the quads are roughly of uniform size and their shapes are close to a square. This assumption is based on the observation that realworld urban street layouts often favor 90degree intersections. In practice, the input problem domain is quadrangulated by the patchwise quadrangulation algorithm in Peng et al. Peng:2014:EQ:2577382.2541533.

Beginning at the subregion level, an initial street network is computed by selecting a subset of segments of the dense network using the IPbased approach described in Section 4.

The geometry of the street network (i.e., positions of the vertices along the street edges) is further improved by a snakebased smoothing algorithm described in the appendix.

If the last level is not reached, we generate a denser network for the next lower level. To do so, we need to increase the resolution of the mesh by a CatmullClark subdivision scheme without vertex repositioning for greater degrees of freedom of the IP computation. The process starting with step 2 is then repeated at a lower level on the subdivided mesh.
Functional specifications. A user can specify the function of the street network using the terms discussed in Section 4 as follows.

Density. The density of the street network is directly controlled by the coverage range of the IP.

Network lengths versus travel distances. These two competing requirements are controlled by the weights for the total length term () and the total travel distance term () of the IP’s objective function.

Traffic types (i.e., interiortoboundary, interiortointerior, and boundarytoboundary traffic). By default, we assume that all boundary vertices of the domain mesh are designated as sinks for the IP. This naturally leads to networks that cater to interiortoboundary traffic while implicitly discouraging traffic of the other two types (Figure 6a and b). To specifically encourage interiortointerior traffic, the pointtopoint constraint of the IP can be used (Figure 6e). To specifically encourage boundarytoboundary traffic (i.e., throughtraffic) in certain directions, simply enforces a shortest path without inner branches in the desired direction (Figure 6d).

Sink locations. The overall shape of a street network can be controlled by the distribution of the sinks. Designating all boundary vertices as sinks leads to street networks that are roughly omnidirectional toward the boundary. Alternatively, we can designate only a subset of the boundary vertices as sinks, which leads to networks that tilt toward the particular sink vertices (see Figure 6c).

Local features. The IP formulation offers direct control over the local features of the generated street networks, including deadends, branches, Tjunctions, and streets that are too close.

Obstacles. The user can easily specify certain locations as obstacles (e.g., water, malls, rail tracks) by enforcing the corresponding vertices or edges to be inactive.
In Figure 6 and Figure Computational Network Design from Functional Specificationsac, we show how distinct street networks for the same subregion can be created by different functional specifications. In Figure 5, we show a citylevel result that consists of multiple subregion layouts tied together by major roads. In Figure 7, we consider a practical scenario of designing a street layout for an empty land surrounded by existing streets.
Traffic simulation.. We use SUMO to do traffic simulations to evaluate our functional specifications about the traffic types 9.
5.2 Floorplanning
Our network generation method is a complement to the tilingbased floorplanning method in Peng et al. Peng:2014:CLD:2601097.2601164, of which a major shortcoming is that it is computationally expensive to model the corridors (i.e., the passage areas connecting the rooms) in a building. In their approach, the corridors are limited to have a treelike topology, and every level of the tree branches needs a new set of corridor tile templates. Our network IP formulation offers a more general way to model the corridors. We describe our approach next.
We now assume that the given building footprint is discretized into a quad mesh, . A computed network represents the corridors for the building. We replace the coverage constraint by a room tiling constraint as follows. As detailed in [Peng et al. 2014b], the user first defines a set of room templates describing the admissible room shapes as combinations of squares, such as a 2x2 square room, a 3x2 long room, and an Lshaped room, with the possibility of having nonvalence 4 vertices within (see Figure (a)a top). We then enumerate all possible potential placements of the rooms on . Each potential placement is practically a connected set of faces on (see Figure (a)a bottom).
Our goal is to find a subset of all the possible potential room placements such that no two overlap and together they fully cover ’s faces. We denote the presences of each potential room placement in the subset as Boolean indicator variables , for with being the number of all potential placements. It follows that: For every face on , ,
(16) 
where , , denotes the set of indicator variables of the potential room placements that cover . For faces denoted as obstacles, we change the righthand side of the equation to zero.
In addition, a room has to be connected to the corridors (i.e., active edges of the network) and cannot have corridors in its interior, modeled as follows: For every potential room placement, ,
(17) 
where , , denotes the set of indicator variables of the inner edges of , and,
(18) 
where , , denotes the set of indicator variables of the boundary edges of .
In summary, the IP formulation for floorplanning comprises of the original network IP formulation (see end of Section 4) but with the coverage constraints (Equation 4  6) replaced by the room tiling constraints (Equations 16  18).
Our floorplanning approach inherits all the functional specifications for modeling networks/corridors (see Section 5.1) except that the density aspect is now determined by the userspecified admissible room shapes. In addition, as the presences of rooms are explicitly expressed as Boolean variables, users can precisely control the occurrences of each room type using linear constraints. In Figure (b)b, we show several floor plans for an office building with distinct functions. In Figure Computational Network Design from Functional Specificationsd, we show a floor plan for a large facility.
5.3 Game Level Design
We aim to solve one interesting problem in game level design: how to partition a problem domain into blocks (e.g., rooms or caves) such that the ways the blocks are connected (i.e., their connectivity graphs) are constrained to ensure various aspects such as difficulty and playability? The problem may come with additional requirements that makes it difficult, such as: (i) there is a limited number of admissible shapes for blocks; (ii) the problem domain has a fixed boundary (e.g., a castle or a dungeon) and the space needs to be fully utilized; and (iii) the connectivity graph needs to satisfy certain requirements. For example, obviously, all the blocks need to be reachable from certain starting points. Or, whether branches or deadends are allowed. Here, we propose an IPbased approach that jointly solves a connectivity graph and a configuration of the building blocks that completely fill the problem domain.
We start from the IP formulation for floorplanning (Section 5.2). The rooms are interpreted as the blocks in a game level in a similar sense. However, we take a different interpretation of the networks: instead of presenting the corridors in a building, we now interpret networks as the the ways the player can traverse the blocks. As seen in Figure 10, the network can be understood as a geometric realization of the connectivity graph of the building blocks (assuming that a block is traversed by at most one connected part of the network). This is realized by replacing the floorplanning’s constraints about the relationships between rooms and corridors (Equation 17 and 18) by the following constraints:
For a room (i.e., block) to appear in a game level, at least one of its inner edges need to be active, and all of its boundary edges need to be inactive. That is,
For every potential room placement, ,
(19) 
where , , denotes the set of indicator variables of the inner edges of , and,
(20) 
where , , denotes the set of indicator variables of the boundary edges of .
Based on this similar IP formulation, our game level approach has the same functional specifications as our floorplanning approach. In the context of game level design, we can constrain the game level type to be: (i) branching, by allowing branches in the connectivity graph (Figure 10a), (ii) circular, by forbidding branches and designating a single sink (Figure Computational Network Design from Functional Specificationse), or (iii) linear, by forbidding branches and designating two sinks on the boundary (Figure 10b).
To demonstrate the usability of our approach in game level design, we use RPG Maker [Enterbrain, Inc. 2015] to create actual, playable game levels based on our results. One example is shown in Figure 11.
5.4 Timing and Analysis
We implemented our algorithms using C++ and report timings on a desktop computer with a 2.4 GHz eightcore CPU and 8 GB memory. We use Gurobi gurobi to solve the IP problems. The timing statistics (except for the citylevel result) are shown in Table 1. In practice, as it is difficult to find a global optimum, we also accept suboptimal solutions (fulfilling all hard constraints) computed within reasonable time limits.
The IP can become infeasible due to hard constraints  for example, it would apparently become infeasible if the coverage constraint requires that all vertices need to be covered and edges being too close are forbidden. However, the Gurobi solver promptly identifies a problem as infeasible.
Mesh  , ,  Dead  Time  

edge  vars  , ,  end  Branch  PtP  (seconds)  
Fig Computational Network Design from Functional Specificationsa  657  6092  5 , 1 , 5 , inf , 0  N  Y  N  379/366/49 
Fig Computational Network Design from Functional Specificationsb  657  7470  0 , 1 , 5 , inf , 10  N  Y  Y  168/274/34 
Fig Computational Network Design from Functional Specificationsc  657  6231  1 , 0 , 5 , inf , 0  N  Y  N  456/467/ 
Fig Computational Network Design from Functional Specificationsd  1012  11338  1 , 0 , 5 , inf , 0  N  Y  N  920 
Fig Computational Network Design from Functional Specificationse  782  12056  1 , 0 , 5 , inf , 0  N  N  N  4927 
Fig 1a  312  2241  1 , 0* , 5 , inf , 0  N  Y  N  132 
Fig 1b  312  2241  0 , 1 , 5 , inf , 0  N  Y  N  35 
Fig 1c  312  2281  0 , 1 , 5 , inf , 0  N  Y  Y  11 
Fig 1d  312  2766  0 , 1 , 5 , inf , 0  N  Y  N  24 
Fig 1e  312  3865  1 , 0* , 5 , inf , 0  N  Y  N  74 
Fig 1f  312  3865  0 , 1 , 5 , inf , 0  N  Y  N  56 
Fig 1g  312  4751  0 , 1 , 5 , inf , 0  N  Y  Y  26 
Fig 4L3  1200  6960  1 , 0 , 5 , inf , 0  N  Y  N  86 
Fig 4L4  1200  1930  1 , 0 , 5 , inf , 0  Y  Y  N  2 
Fig 6a  535  4432  1 , 0* , inf , inf , 0  N  Y  N  121/218/23 
Fig 6b  535  4432  0 , 1 , 5 , inf , 0  N  Y  N  174/318/76 
Fig 6c  535  5304  0 , 1 , 5 , inf , 0  Y  Y  N  70/294/46 
Fig 6d  535  5036  5 , 1 , 5 , inf , 0  N  Y  N  12/223/43 
Fig 6e  535  5651  5 , 1 , 5 , inf , 0  N  Y  Y  73/195/114 
Fig 7  543  4415  0 , 1 , 5 , inf , 0  N  Y  N  229/500/1 
Fig (b)b1  520  7986  1 , 0 , 5 , inf , 0  N  Y  N  1018 
Fig (b)b2  520  7876  1 , 0 , 5 , inf , 0  N  Y  Y  188 
Fig (b)b3  520  7944  1 , 0 , 5 , inf , 0  N  Y  N  201 
Fig (b)b4  520  7944  1 , 0 , 5 , inf , 0  Y  Y  N  1507 
Fig 10a  782  11411  1 , 0 , 5 , inf , 0  Y  Y  N  3359 
Fig 10b  657  9643  1 , 0 , 5 , inf , 0  N  N  N  2958 
*: 1e4. :L1. :L4.
For the citylevel result (Figure 5), the statistics for the subregions are shown in the additional material. The sum of computation times is 7844 seconds. However, as the computations for each subregion are independent, they can be done in parallel. When done in parallel, it takes about 2300 seconds (using a time limit of 1000 seconds for level 2, 1200 seconds for level 3, and 100 seconds for level 4) to compute a comparable result.
The main limitation is performance. As it usually takes a few minutes to solve a mediumsized urban layout problem, interactive speed is not yet achieved. A restriction of the IP formulation is that new additions/modifications should be linear, otherwise, the problem becomes too expensive to solve.
5.5 Comparisons with Other Approaches
In this section, we show that it is advantageous in terms of performance to formulate network problems into IP form and solve with a specialized IP solver (e.g., Gurobi).
Manual solution. We first compare our solutions to some trivial solutions created manually. In Figure 12, We manually create solutions to achieve the same optimization goals as in Figure 1a. Such solutions use more edges than our IPbased solution. We also attempted to create floorplanning results by hand. We find that it is very challenging to create full room tilings manually, let alone jointly finds a valid network that satisfies the given constraints.
Stochastic search. For comparison, we implemented a stochastic searchbased approach to solve the network problems. Beginning at a trivial solution (e.g., every edge is active), the approach iteratively performs the following types of operations to alter the current solution: (i) deleting a single edge, (ii) deleting a pair of adjacent edges, (iii) deleting a triple of consecutive edges, and (iv) adding a single edge. At each iteration, we enumerate all possible feasible operations, rank them according to the new objective values (the lower the better), and pick one to perform. We pick operations in a simulated annealing sense (i.e., the higher ranked the larger chance to be picked, and such tendency becomes more absolute at each iteration). The approach stops when there are no feasible solutions or a time limit is reached. As shown in Figure 13, we find that such a stochastic approach cannot compete with the IPbased approach in terms of speed and result qualities.
6 Conclusions and Future Work
We proposed an algorithm for the computational design of networks for layout computation, such as street networks, building floor plans, and game levels. The user provides highlevel functional specifications for the target problem domain, while our algorithm jointly realizes the connectivity and the detailed geometry of the network. While there is a considerable amount of work on using functional specifications for evaluating networks, to the best of our knowledge, this is the first attempt to synthesize these layouts purely based on functional specifications.
In future work, it is interesting to consider multimodal transportation networks (e.g., public transportations) for a richer variety of urban street layouts. We would also like to tackle other network design problems by our IPbased approach, such as the layouts of residential houses, automated warehouses, and electrical layouts. In addition, while the meshes used in this paper are all quadrilateral because of our target applications, new design problems may necessitate the need for more kinds of mesh tessellations, such as a hybrid of quad and triangle meshes.
References
 [AlHalawani et al. 2014] AlHalawani, S., Yang, Y.L., Wonka, P., and Mitra, N. J. 2014. What makes London work like London. Computer Graphics Forum (Proceedings of SGP 2014) 33.
 [Aliaga et al. 2008] Aliaga, D., Vanegas, C., and Benes, B. 2008. Interactive ExampleBased Urban Layout Synthesis. ACM Trans. on Graph. 27, 5.
 [Association 2006] Association, A. P. 2006. Planning and Urban Design Standards. Wiley.
 [Bao et al. 2013] Bao, F., Yan, D.M., Mitra, N. J., and Wonka, P. 2013. Generating and exploring good building layouts. ACM SIGGRAPH 32, 4.
 [Baswana and Sen 2007] Baswana, S., and Sen, S. 2007. A simple and linear time randomized algorithm for computing sparse spanners in weighted graphs. Random Struct. Algorithms 30, 4 (July), 532–563.
 [Board 2010] Board, T. R. 2010. Highway Capacity Manual. Transportation Research Board.
 [Chen et al. 2008] Chen, G., Esch, G., Wonka, P., Müller, P., and Zhang, E. 2008. Interactive procedural street modeling. ACM Trans. on Graph. 27, 3, 103:1–9.
 [Ching 1996] Ching, F. 1996. ARCHITECTURE: Form, Space, and Order. John Wiley & sons.
 [Deussen et al. 1998] Deussen, O., Hanrahan, P., Lintermann, B., Měch, R., Pharr, M., and Prusinkiewicz, P. 1998. Realistic modeling and rendering of plant ecosystems. In Proceedings of SIGGRAPH 1998, 275–286.
 [Enterbrain, Inc. 2015] Enterbrain, Inc., 2015. RPG Maker VX Ace.
 [Galin et al. 2011] Galin, E., Peytavie, A., Guérin, E., and Benes, B. 2011. Authoring hierarchical road networks. Computer Graphics Forum 29, 7, 2021–2030.
 [GarciaDorado et al. 2014] GarciaDorado, I., Aliaga, D. G., and Ukkusuri, S. V. 2014. Designing largescale interactive traffic animations for urban modeling. Computer Graphics Forum.
 [Génevaux et al. 2013] Génevaux, J.D., Galin, E., Guérin, E., Peytavie, A., and Beneš, B. 2013. Terrain generation using procedural models based on hydrology. ACM Trans. on Graph. 32, 4 (July), 143:1–143:13.
 [Gurobi Optimization, Inc. 2014] Gurobi Optimization, Inc., 2014. Gurobi optimizer reference manual.
 [Handy et al. 2003] Handy, S., Paterson, R., and Butler, K. 2003. Planning for street connectivity: Getting from here to there. In Planning Advisory Service Report.
 [Kalogerakis et al. 2012] Kalogerakis, E., Chaudhuri, S., Koller, D., and Koltun, V. 2012. A Probabilistic Model of ComponentBased Shape Synthesis. ACM Trans. on Graph. 31, 4.

[Kass et al. 1988]
Kass, M., Witkin, A., and Terzopoulos, D.
1988.
Snakes: Active contour models.
International Journal of Computer Vision 1
, 4, 321–331. 
[Koster et al. 2010]
Koster, A., Kutschka, M., and Raack, C.
2010.
Towards robust network design using integer linear programming techniques.
In Next Generation Internet (NGI), 2010 6th EURONF Conference on, 1–8.  [Luathep et al. 2011] Luathep, P., Sumalee, A., Lam, W. H., Li, Z.C., and Lo, H. K. 2011. Global optimization method for mixed transportation network design problem: A mixedinteger linear programming approach. Transportation Research Part B: Methodological 45, 5, 808 – 827.
 [Ma et al. 2014] Ma, C., Vining, N., Lefebvre, S., and Sheffer, A. 2014. Game level layout from design specification. Computer Graphics Forum 33, 2, 95–104.
 [Maréchal et al. 2010] Maréchal, N., Guérin, E., Galin, E., Merillou, S., and Mérillou, N. 2010. Procedural generation of roads. Computer Graphics Forum 29, 2, 429–438.
 [Marshall 2005] Marshall, S. 2005. Streets & Pattern. Spon press, New York.
 [Merrell et al. 2010] Merrell, P., Schkufza, E., and Koltun, V. 2010. Computergenerated residential building layouts. ACM Trans. on Graph. 29, 6, 181:1–181:12.
 [Meyer and Miller 2000] Meyer, M., and Miller, E. 2000. Urban Transportation Planning. McGrawHill.
 [Miller et al. 1960] Miller, C. E., Tucker, A. W., and Zemlin, R. A. 1960. Integer programming formulation of traveling salesman problems. J. ACM 7, 4 (Oct.), 326–329.
 [Ortúzar and Willumsen 2011] Ortúzar, J. d. D., and Willumsen, L. 2011. Modelling Transport. Wiley.
 [Parish and Müller 2001] Parish, Y. I. H., and Müller, P. 2001. Procedural modeling of cities. In Proceedings of SIGGRAPH 2001, 301–308.
 [Peng et al. 2014a] Peng, C.H., Barton, M., Jiang, C., and Wonka, P. 2014. Exploring quadrangulations. ACM Trans. Graph. 33, 1 (Feb.), 12:1–12:13.
 [Peng et al. 2014b] Peng, C.H., Yang, Y.L., and Wonka, P. 2014. Computing layouts with deformable templates. ACM Trans. Graph. 33, 4 (July), 99:1–99:11.
 [Prusinkiewicz and Lindenmayer 1990] Prusinkiewicz, P., and Lindenmayer, A. 1990. The Algorithmic Beauty of Plants. SpringerVerlag, New York.
 [Runions et al. 2005] Runions, A., Fuhrer, M., Lane, B., Federl, P., RollandLagan, A.G., and Prusinkiewicz, P. 2005. Modeling and visualization of leaf venation patterns. ACM Trans. on Graph. 24, 3, 702–711.
 [Southworth and BenJoseph 1995] Southworth, M., and BenJoseph, E. 1995. Street standards and the shaping of suburbia. Journal of the American Planning Association 61, 1, 65–81.
 [Southworth and BenJoseph 2003] Southworth, M., and BenJoseph, E. 2003. Streets and the Shaping of Towns and Cities. Island Press, Wasington DC.
 [Vanegas et al. 2009] Vanegas, C. A., Aliaga, D. G., Beneš, B., and Waddell, P. A. 2009. Interactive design of urban spaces using geometrical and behavioral modeling. ACM Trans. on Graph. 28, 5.
 [Vanegas et al. 2012] Vanegas, C. A., GarciaDorado, I., Aliaga, D. G., Benes, B., and Waddell, P. 2012. Inverse design of urban procedural models. ACM Trans. on Graph..
 [Weber et al. 2009] Weber, B., Müller, P., Wonka, P., and Gross, M. H. 2009. Interactive geometric simulation of 4D cities. Computer Graphics Forum 28, 2, 481–492.
 [Yang et al. 2013] Yang, Y.L., Wang, J., Vouga, E., and Wonka, P. 2013. Urban pattern: Layout design by hierarchical domain splitting. ACM Trans. on Graph..
 [Yu et al. 2011] Yu, L.F., Yeung, S.K., Tang, C.K., Terzopoulos, D., Chan, T. F., and Osher, S. 2011. Make it home: Automatic optimization of furniture arrangement. ACM Trans. on Graph. 30, 4, 86:1–86:11.
Appendix
Snakebased smoothing. We use the active contour model (snakes) [Kass et al. 1988] to smooth the coarse street networks generated by the IP approach, which tend to contain many sharp turns (e.g., stairshaped) due to the nature of quad meshes. We give a summary of the algorithm as follows.
A snake is a distinct nonempty sequence of active edges that connects a distinct sequence of vertices (i.e., no branches nor loops). Moreover, the valence of the first and last vertices of a snake cannot be ; that is, a snake must end at non valence vertices. We first decompose a street network into snakes. It is straightforward to see that a network can be decomposed into nonoverlapping snakes that together fully cover the network. Note that snakes can include intersection vertices of the street network, i.e., an active vertex that connects to more than two active edges, from its interior. After the snakes are extracted, we subdivide each snake so that the smoothing algorithm, described next, may have a higher degrees of freedom.
The snakebased smoothing algorithm minimizes the energy associated with each snake, which can be understood as deformable splines. We consider three types of energies: tension, stiffness, and inertia. Assuming that a snake is represented by , where is the parametric domain and is the time (i.e., iteration), for each vertex, the energies are defined as follows.

Tension energy, . Minimizing the tension energy makes the snake act like a membrane. A higher weight for this energy leads to shorter lengths.

Stiffness energy, . Minimizing the stiffness energy makes the snake act like a thin plate. A higher weight for this energy leads to smoother turns.

Inertia energy, . This energy is used to prevent the snake from moving too far away from its original position.
The overall energy is defined as a linear combination of these three energies for all vertices:
(21) 
Here, , , and are the weights of the three energies.
We use different settings of weights at different levels of the street layout hierarchy. Streets at higher levels use higher stiffness weights (smoother corners) while streets at lower levels use higher inertia weights (fewer deformations). Additional heuristics are used to make sure the street intersections are close to 90
angles.We use gradient descent to optimize the snake energy. The gradient of the snake energy is:
(22) 
We take adaptive steps in the direction of until the changes stabilize.
Comments
There are no comments yet.