Computational Network Design from Functional Specifications

10/30/2015
by   Chi-Han Peng, et al.
Arizona State University
UCL
0

Connectivity and layout of underlying networks largely determine the behavior of many environments. For example, transportation networks determine the flow of traffic in cities, or maps determine the difficulty and flow in games. Designing such networks from scratch is challenging as even local network changes can have large global effects. We investigate how to computationally create networks starting from only high-level functional specifications. Such specifications can be in the form of network density, travel time versus network length, traffic type, destination locations, etc. We propose an integer programming-based approach that guarantees that the resultant networks are valid by fulfilling all specified hard constraints, and score favorably in terms of the objective function. We evaluate our algorithm in three different design settings (i.e., street layout, floorplanning, and game level design) and demonstrate, for the first time, that diverse networks can emerge purely from high-level functional specifications.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 6

page 7

page 8

page 9

12/17/2019

ORC Layout: Adaptive GUI Layout with OR-Constraints

We propose a novel approach for constraint-based graphical user interfac...
02/23/2020

ORCSolver: An Efficient Solver for Adaptive GUI Layout with OR-Constraints

OR-constrained (ORC) graphical user interface layouts unify conventional...
01/15/2018

Algebraic Specifications of Wayfinding Using Cognitive Map

This paper outlines the formal representation of the environment in whic...
03/16/2013

Separating Topology and Geometry in Space Planning

We are dealing with the problem of space layout planning here. We presen...
05/30/2019

iVAMS 1.0: Polynomial-Metamodel-Integrated Intelligent Verilog-AMS for Fast, Accurate Mixed-Signal Design Optimization

Electronic circuit behavioral models built with hardware description/mod...
02/18/2021

Verifying Probabilistic Specifications with Functional Lagrangians

We propose a general framework for verifying input-output specifications...
01/17/2019

Computational Design of Lightweight Trusses

Trusses are load-carrying light-weight structures consisting of bars con...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

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 well-designed 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 high-level descriptions as functional specifications. For example, functional specifications can come in the form of desired network density, transportation pattern, local features (e.g., whether dead-ends 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 black-box forward simulation (e.g., using a traffic simulator, or solving a flow problem). However, such a trial-and-error 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 dead-ends 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 non-trivial and desirable network layouts can emerge only from high-level 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 obstacle-free 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 high-level roads connecting cities and villages [Galin et al. 2011]. A recent paper describes how to design traffic behavior in an urban environment [Garcia-Dorado 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 low-level 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 Ben-Joseph 1995, Meyer and Miller 2000, Handy et al. 2003, Southworth and Ben-Joseph 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.vg-leveldesign.com/level-layout-types/ 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: interior-to-boundary, interior-to-interior, and boundary-to-boundary 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 root-like 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 dead-ends, branches, and T-junctions. 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 through-traffic.

4 IP-based Network Design

In this section, we introduce an integer-programming (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 no-island 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 point-to-point 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., dead-ends, branches, and T-junctions) in a network. Before describing how we encode such quality measures, we begin with the following definitions.

Figure 1: Example results. Sink vertices are marked in red. The coverage range is two edges wide. The distance values of active half-edges are colored (see legends for color ranges). Boundary edges are excluded from the calculations. We forbid dead-ends and edges that are too close to each other. (a) to (c): A typical urban layout scenario such that all boundary vertices are sinks. The first two use different weights to optimize for (a) numbers of network edges and (b) sum of distance values. Note that we do not specifically constrain the maximum of distance values. (c): A result that also optimizes for distance values but with the point-to-point constraint enabled (sampled vertices are marked in yellow). (d): We now constrain a boundary vertex (top middle) to be the sole sink. (e) to (g): A typical floorplan scenario such that a few inner vertices are sinks (e.g., elevators). Similarly, they differ by different optimization weights and whether point-to-point constraint is enabled.
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 .

Figure 2: The impact of no-island constraints. The coverage range is one edge wide. (a) The problem domain is first discretized into a mesh. (b) A network (i.e., a subset of the edges) that sufficiently covers the domain using the fewest possible number of edges. However, the solution may consist of many disconnected parts. (c) Simply forbidding degree-1 vertices is not enough to guarantee the network to be free of islands, as it is still possible to form disconnected loops. (d) Our no-island constraint guarantees that the network is entirely connected to the sink (red vertex). Here we show the distance values assigned to each active half-edge.

No-island 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 half-edge, (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 half-edge, , a distance value that roughly encodes the distance of toward the closest sink vertex along the active half-edges in the network. We model the distance value of half-edge as a non-negative continuous variable, , for with being the sum of the lengths of all half-edges in . To achieve this goal, the following requirement should be satisfied:

Proposition 4.2

For a half-edge to be active, at least one of its succeeding half-edges (i.e., the half-edges 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 half-edge, , for , where is the one-ring neighborhood of , of every half-edge in such that is not a sink vertex,

(1)
(2)

where, are auxiliary Boolean variables associated with every half-edge, , one for each of its succeeding half-edges, , for , . is the length of half-edge . 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 half-edge in , , such that is not a sink vertex,

(3)

To illustrate no-island constraints, on the right, we show the top-middle 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 half-edge that has no succeeding active half-edges, otherwise the requirement is immediately violated. Therefore, there must exist at least one loop of active half-edges 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 half-edges is active: For every edge in , ,

(4)

where, and are the Boolean indicator variables of ’s two half-edges. 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 half-edges. 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 post-process. In Figure 3, we analyze how the assignments of versus affect the optimization results.

Figure 3: Optimization results with a gradual change of (to minimize network lengths) versus (to minimize travel distances). In general, a larger leads to smaller network lengths but larger travel distances, while a larger leads to the opposite. We use the same setting as in Figure 1.

Point-to-point 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 cost-effective way to approximate our goal.

We first partition into a set of sub-meshes (i.e., a connected set of faces), , is the number of sub-meshes. , , . . We assume the partition is given by the user. We say that two sub-meshes are adjacent to each other if they share common edges. Next, we randomly sample one vertex in every sub-mesh. For sampling, we consider vertices that are not adjacent to any other sub-meshes, unless such vertices do not exist. For every pair of adjacent sub-meshes, 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 sub-meshes 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 sub-mesh ) and (of sub-mesh ), 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 point-to-point 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.

Dead-end avoidance. We may desire networks that have no dead-ends, i.e., an active vertex that is adjacent to just one active edge. To achieve this, we give every half-edge, (from vertex to ), a non-emptiness 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 half-edge in , ,

(10)

, where is the set of edges adjacent to .

Dead-ends can then be avoided by the following constraints:

For every half-edge 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 cycle-like 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) zig-zags and (ii) edges that are too close to each other. Their occurrences can be strictly forbidden or minimized.

Figure 4:

Generating street layouts. The first level layout (major roads) is designed by the user. Afterwards, for each sub-region, we generate layouts in three levels of decreasing coverage ranges. For each level, a rough street network is first generated by the IP-based approach (shown in gray). Afterwards, the geometry of the generated street network is realized by a smoothing process (the last two levels are smoothed in one pass). The mesh is subdivided at the third level for increased degrees-of-freedom. Dead-ends are typically allowed only at the last level.

As shown on the right, for each half-edge, , we identify two undesirable configurations. The presence of each configuration on is denoted by a Boolean indicator variable, , where equals for zig-zags 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 half-edge ,

(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 T-junctions as follows. For each half-edge pointing to a valence- vertex, , the presence of a T-junction on is denoted by a Boolean indicator variable, , modeled as follows:

For every half-edge 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 T-junctions 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 T-junctions.

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.

We show example results in Figure 1. In summary, the IP formulation consists of a linear objective function in Equation 15 and linear constraints in Equations 1 - 1113, and 14.

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 IP-based 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 real-world 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 sub-regions. Second, for each sub-region, 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 sub-region. Fourth, there may be some cul-de-sacs 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 sub-region, our pipeline to create the street layouts is as follows (see Figure 4).

  1. We first compute a dense network of street segment candidates in the form of a semi-regular (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 real-world urban street layouts often favor 90-degree intersections. In practice, the input problem domain is quadrangulated by the patch-wise quadrangulation algorithm in Peng et al. Peng:2014:EQ:2577382.2541533.

  2. Beginning at the sub-region level, an initial street network is computed by selecting a subset of segments of the dense network using the IP-based approach described in Section 4.

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

  4. 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 Catmull-Clark 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.

Figure 5: A city-level street layout. To mimic a coastal town setting, different functional specifications are used for different sub-regions: (1a-d) Downtown layouts with a higher density, a stronger interior-to-interior traffic, and no dead-ends. (2a-d) and (3a-c) Suburban layouts that either favor (2a-d) shorter network lengths or (3a-c) shorter travel distances to the boundaries. (4) A gated community with a single entrance to the boundary. (5) A lower density part of the city with a sparser layout. (6) A beach-front area. Dead-ends are specifically allowed for the level-2 roads.
Figure 6: Diverse street layouts resulting from different functional specifications. The first two layouts are optimized for (a) minimal network lengths and (b) minimal travel distances to the boundary, using different specifications of the optimization weights. The travel distances are shown in the bottom-left corners. (c) A layout with a single exit on the left. We also prefer a tree-like structure for this case, which is realized by allowing dead-ends on the second (collector roads) level. (d) A layout that encourages through-traffic in the vertical direction. This is realized by enforcing a shortest path connecting the two user-specified vertices (green) without inner branches on the second level. Note that through-traffic in other directions (e.g., horizontal) are implicitly discouraged. (e) A network that better supports interior-to-interior traffic, realized by the point-to-point constraint with a user-specified partition.
Figure 7: Planning a street layout for an empty land surrounded by existing streets and with a historic site that should be preserved. To optimize travel times, instead of designating all boundary vertices as sinks, we place sinks only on the intersections of the existing streets (red vertices). The historic site is preserved by marking the corresponding vertices (black) as obstacles. On the right, we show the IP result of the level-2 roads. The distribution of the active half-edges indicate the shortest paths toward the intersections (sinks) while the distance values encode the shortest distances.
  1. Density. The density of the street network is directly controlled by the coverage range of the IP.

  2. 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.

  3. Traffic types (i.e., interior-to-boundary, interior-to-interior, and boundary-to-boundary 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 interior-to-boundary traffic while implicitly discouraging traffic of the other two types (Figure 6a and b). To specifically encourage interior-to-interior traffic, the point-to-point constraint of the IP can be used (Figure 6e). To specifically encourage boundary-to-boundary traffic (i.e., through-traffic) in certain directions, simply enforces a shortest path without inner branches in the desired direction (Figure 6d).

  4. 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 omni-directional 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).

  5. Local features. The IP formulation offers direct control over the local features of the generated street networks, including dead-ends, branches, T-junctions, and streets that are too close.

  6. 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 Specificationsa-c, we show how distinct street networks for the same sub-region can be created by different functional specifications. In Figure 5, we show a city-level result that consists of multiple sub-region 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.

(a)
(b)
Figure 8: (a) Top: a set of room templates. Bottom: several potential room placements on a mesh. (b) Floor plans for a four-story office building. Note that they consist of both the corridor network and the tiling with room templates. (1) A floor plan with a single sink predefined on the building entrance (bottom middle). The network is constrained to pass through the four elevator locations. Some faces are denoted as obstacles to be occupied by the elevators. (2) A floor plan sharing the same locations of the elevators (as sinks). (3) A floor plan that has a single sink and a large obstacle area for a roof garden. (4) Another floor plan with a single sink. Dead-ends are allowed for the network.

Traffic simulation.. We use SUMO to do traffic simulations to evaluate our functional specifications about the traffic types 9.

Figure 9: SUMO traffic simulations.

5.2 Floorplanning

Our network generation method is a complement to the tiling-based 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 tree-like 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 L-shaped room, with the possibility of having non-valence 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 right-hand 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 user-specified 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

Figure 10: Game level designs. The templates for blocks are shown on the left. We constrain the largest room, which encodes a special encounter, to appear exactly once. (a) A design with a tree-like connectivity graph of the blocks. The root is constrained at the castle entrance (lower middle), realized by designating the corresponding vertex to be the sole sink. The player starts at the entrance and explores the whole level in a multiple-choice manner. (b) A design with a linear connectivity graph from the upper-left corner to the bottom-right corner. The player explores every block in the level in a one-by-one manner.

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 dead-ends are allowed. Here, we propose an IP-based 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).

Figure 11: We use RPG maker [Enterbrain, Inc. 2015] to turn the game level design in Figure Computational Network Design from Functional Specificationse into an actual, playable game level. Each room type is given a different function, e.g., 2x2 blocks are for passages, 3x2 blocks are for enemy encounters, 3x3 blocks are for supplies, and the single 5x5 block is for a boss level. We use additional furniture to separate the blocks that are traversed by more than one connected parts of the connectivity graph.

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 eight-core CPU and 8 GB memory. We use Gurobi gurobi to solve the IP problems. The timing statistics (except for the city-level result) are shown in Table 1. In practice, as it is difficult to find a global optimum, we also accept sub-optimal 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

*: 1e-4. :L1. :L4.

Table 1: For every example shown in the paper, we show the number of edges in the mesh, the parameters for the IP, and the times to obtain the shown solutions. inf (i.e., infinite) means the corresponding features is forbidden. Y means the feature is allowed and N means forbidden. For urban street layouts, the times to calculate the results of level-2, level-3, and level-4 are shown.

For the city-level result (Figure 5), the statistics for the sub-regions are shown in the additional material. The sum of computation times is 7844 seconds. However, as the computations for each sub-region 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 medium-sized 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 IP-based 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.

Figure 12: (a) Our IP-based solution to find a network that cover the mesh (coverage range is two edges wide) with the fewest possible number of edges while avoiding zig-zags and edges that are too close. (b) and (c) Two manual results for comparisons. Our strategy is to start at one side of the boundary or a corner and grow edges as far as possible. Zig-zags and edges that are too close are avoided. (d) An optimal solution that allows zig-zags and edges that are too close, found by our IP approach.

Stochastic search. For comparison, we implemented a stochastic search-based 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 IP-based approach in terms of speed and result qualities.

Figure 13: Comparing to a stochastic search-based approach. We run the approach multiple passes and pick the best solution. Even with a much longer time, the stochastic approach cannot find solutions of comparable 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 high-level 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 multi-modal 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 IP-based 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 Example-Based 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.
  • [Garcia-Dorado et al. 2014] Garcia-Dorado, I., Aliaga, D. G., and Ukkusuri, S. V. 2014. Designing large-scale 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 Component-Based 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 EURO-NF 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 mixed-integer 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. Computer-generated 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. McGraw-Hill.
  • [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. Springer-Verlag, New York.
  • [Runions et al. 2005] Runions, A., Fuhrer, M., Lane, B., Federl, P., Rolland-Lagan, A.-G., and Prusinkiewicz, P. 2005. Modeling and visualization of leaf venation patterns. ACM Trans. on Graph. 24, 3, 702–711.
  • [Southworth and Ben-Joseph 1995] Southworth, M., and Ben-Joseph, E. 1995. Street standards and the shaping of suburbia. Journal of the American Planning Association 61, 1, 65–81.
  • [Southworth and Ben-Joseph 2003] Southworth, M., and Ben-Joseph, 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., Garcia-Dorado, 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

Snake-based 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., stair-shaped) due to the nature of quad meshes. We give a summary of the algorithm as follows.

A snake is a distinct non-empty 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 non-overlapping 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 snake-based 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.