GPLAN: Dimensioned Floorplan Generation

• GPLAN is a software system that generates dimensioned floorplans from specified room adjacencies or sketched layouts, integrating graph-theoretic topology and linear optimization.
• It distinguishes between graph-input mode for generating multiple topologically distinct rectangular or orthogonal floorplans and layout-input mode for preserving user-sketched irregular designs.
• By leveraging PTGs, RELs, and network-flow models, GPLAN efficiently produces feasible floorplan alternatives that provide a robust base for further architectural refinement.

GPlan, more commonly styled GPLAN in the source publication, is a software system for computer-generated dimensioned floorplans from given adjacencies. It is positioned as a bridge between graph-theoretic floorplan research and architectural use: rather than only deciding whether a graph admits a layout, it allows a user to specify adjacency requirements and dimensional bounds through a GUI, and then produces one or many dimensioned plans satisfying those requirements. Its intended role is not to replace architects, but to generate feasible initial layouts that can later be refined by designers (Shekhawat et al., 2020).

1. Scope, input modes, and floorplan classes

GPLAN is explicitly divided into two input modes. In the first mode, the user provides an adjacency graph in which vertices represent rooms and edges represent required adjacencies. From this graph, GPLAN generates floorplans with a rectangular outer boundary, preferring a rectangular floorplan (RFP) whenever one exists and otherwise producing an orthogonal floorplan (OFP). In this graph-input mode, the system can generate multiple topologically distinct alternatives (Shekhawat et al., 2020).

In the second mode, the user draws a dimensionless layout directly on the GUI. This mode is intended especially for irregular floorplans (IFPs) with either rectangular or non-rectangular boundaries. GPLAN then assigns dimensions while preserving the adjacencies, positions, and shapes of the drawn rooms. Unlike the graph-input mode, this layout-input mode preserves the supplied topology rather than enumerating alternative topologies (Shekhawat et al., 2020).

The paper uses standard floorplan terminology. An RFP is a partition of a convex, rectangular envelope into internally disjoint rectangles. An OFP still has a rectangular outer boundary, but some rooms may be orthogonal non-rectangles. An IFP removes even the rectangular-boundary requirement. Adjacency is defined by shared wall segments. The central graph associated with a floorplan is its weak dual graph, obtained by replacing each room by a vertex and connecting adjacent rooms. GPLAN’s graph-theoretic foundation relies on the fact that the weak dual of a floorplan with only 3-joints is a planar triangulated graph (PTG) (Shekhawat et al., 2020).

This division of scope is important because GPLAN does not treat all floorplan-generation problems as instances of a single abstract optimizer. It separates the problem of topology generation from adjacency constraints from the problem of dimensioning an already supplied topology, and it uses different machinery in each case.

2. Graph-theoretic foundations for rectangular-boundary floorplans

For graph-input generation, GPLAN requires the input adjacency graph to be planar, triangulated, connected, and in practice bi-connected. If the graph is non-planar, non-triangulated, or not bi-connected, the system rejects it and reports an error. Within this admissible class, rectangular floorplan existence is governed by the theory of properly triangulated planar graphs (PTPGs) and rectangular duals (Shekhawat et al., 2020).

A PTPG is a planar triangulated graph with no separating triangle and exterior face length at least 4. The central existence result quoted by the paper is:

$$\textbf{Theorem 1. } \text{A bi-connected PTPG } G \text{ has a rectangular dual if and only if it has no more than four corner implying paths (CIPs).}$$

This theorem drives GPLAN’s logic. Given a bi-connected PTG, GPLAN first checks whether an RFP exists. The paper mentions an integrated tool called RFPchecker that evaluates this condition and can explain failure in terms of non-triangulation, separating triangles, or excessive CIPs. If an RFP exists, GPLAN constructs it; if not, it modifies the graph and constructs an OFP instead (Shekhawat et al., 2020).

For RFP construction, GPLAN extends the rectangular-dual approach of Kant and He by explicitly handling 4-completion via corner-implying paths. Starting with a bi-connected PTG, the system selects four exterior vertices $u_0,u_1,u_2,u_3$ in clockwise order, forms four boundary paths $P_0,P_1,P_2,P_3$, adds four new vertices $N,E,S,W$, connects each of them to all vertices on one boundary path, and adds the four outer edges

$(N,W),\ (N,E),\ (S,E),\ (S,W).$

The purpose is to transform the graph into a PTPG without separating triangles. Once the graph is 4-completed into a PTPG, GPLAN follows the rectangular-dual pipeline based on regular edge labelling (REL) and induced horizontal and vertical $st$-graphs. The workflow given in the paper is: 4-completion, computation of a regular edge labelling, extraction of horizontal and vertical $st$-graphs, generation of horizontal and vertical rectangular dual information, and assembly of the required rectangular dual (Shekhawat et al., 2020).

This makes GPLAN a concrete implementation of a specific combinatorial tradition in floorplanning: PTGs, PTPGs, CIPs, RELs, rectangular duals, and $st$-graphs are not auxiliary concepts but the core representational layers through which topology is decided.

3. Orthogonal and irregular floorplan generation

When an RFP does not exist, GPLAN constructs an orthogonal floorplan rather than failing outright. The paper identifies three explicit causes of RFP nonexistence: the graph has more than four CIPs, the graph has separating triangles, or the exterior face is triangular. In these cases, GPLAN modifies the graph by adding extra vertices and, when necessary, extra triangulating edges so that the modified graph becomes a PTPG admitting an RFP. It then constructs an RFP for the modified graph and finally merges the rooms corresponding to the added vertices into neighboring rooms, thereby producing an OFP for the original graph (Shekhawat et al., 2020).

The second input mode is especially important for irregular plans. Here GPLAN does not solve the existence problem from an adjacency graph; instead, the user supplies a concrete dimensionless layout. If some rooms are orthogonal non-rectangles, GPLAN partitions them into a minimum number of rectangles using the cited rectilinear polygon partitioning method. If the outer boundary is non-rectangular, GPLAN inserts extra temporary rooms so that the whole arrangement becomes rectangular for the purpose of network-flow dimensioning. After optimization, the auxiliary rooms are deleted and partitioned rectangles belonging to the same original room are recombined. The result is a dimensioned IFP that preserves the given adjacency graph implicitly encoded by the sketch, along with room position and shape (Shekhawat et al., 2020).

This suggests a sharp methodological distinction inside GPLAN. Graph-input mode is a topological generator under rectangular-boundary assumptions. Layout-input mode is a topology-preserving transformation tool for irregular and user-sketched designs.

4. Dimensioning by linear optimization on $st$-graphs

After a topological solution is generated, GPLAN performs dimensioning as a linear optimization problem on network-flow-like $st$-graphs. Widths and heights are optimized separately using the vertical and horizontal $u_0,u_1,u_2,u_3$0-graphs. The paper states the model as:

$u_0,u_1,u_2,u_3$1

subject to

$u_0,u_1,u_2,u_3$2

$u_0,u_1,u_2,u_3$3

where $u_0,u_1,u_2,u_3$4 is the maximum dimension of room $u_0,u_1,u_2,u_3$5, $u_0,u_1,u_2,u_3$6 is the total inflow to vertex $u_0,u_1,u_2,u_3$7, and $u_0,u_1,u_2,u_3$8 is the total outflow from vertex $u_0,u_1,u_2,u_3$9. The paper notes that the scan typography is imperfect, but its intended interpretation is that flow conservation enforces geometric consistency and lower/upper bounds enforce user dimension constraints (Shekhawat et al., 2020).

The worked example exposes the kinds of generated constraints. The paper lists flow-balance equalities such as

$P_0,P_1,P_2,P_3$0

$P_0,P_1,P_2,P_3$1

and dimension bounds such as

$P_0,P_1,P_2,P_3$2

$P_0,P_1,P_2,P_3$3

These are shown separately for width and height through the vertical and horizontal $P_0,P_1,P_2,P_3$4-graphs (Shekhawat et al., 2020).

The paper states that GPLAN improves on the earlier model of Upasani et al. by replacing direct width/height minimization with an objective based on the gap to the maximum bounds, resulting in smaller total floorplan area. In practice, the software uses the dual-simplex method, chosen because it is much faster than stochastic alternatives and allows all topological candidates to be dimensioned within a reasonable time. Feasibility is therefore conditional: GPLAN produces a dimensioned plan when the resulting linear constraints are satisfiable, rather than guaranteeing feasibility under arbitrary inconsistent user bounds (Shekhawat et al., 2020).

The architectural constraints handled are primarily adjacency requirements, rectangular or preserved non-rectangular topology, room width bounds, room height bounds, implied area control through width/height combination, rectangular boundary in graph-input mode, and preservation of positions and shapes in layout-input mode. By contrast, the paper explicitly does not present a general aspect-ratio model or explicit orientation constraints (Shekhawat et al., 2020).

5. Enumeration, software workflow, and empirical behavior

A major claimed contribution of GPLAN is the generation of multiple topologically distinct floorplans. The paper defines two floorplans as topologically distinct when they have the same weak dual graph but different horizontal and vertical adjacency structures. For RFPs, GPLAN enumerates alternatives by iterating over different possible boundary paths and, for each boundary, finding different RELs using the concept of a flippable item from Eppstein et al. For one example graph, GPLAN examined 154 possible boundaries and generated 1300 topologically distinct RFPs in 282.45 seconds (Shekhawat et al., 2020).

For OFPs, the enumeration procedure is broader. GPLAN enumerates all ways to augment a bi-connected PTG into a PTPG; if the graph has $P_0,P_1,P_2,P_3$5 CIPs, there are

$P_0,P_1,P_2,P_3$6

ways to choose which four remain as corners after adding extra vertices, and each separating triangle may be removable in three possible ways. For each augmented PTPG, GPLAN generates all possible RFPs as above, then merges the extra rooms in all valid ways to obtain OFPs. On the example corresponding to the paper’s Figure 17b, GPLAN generated 256 topologically distinct OFPs in 26.56 seconds (Shekhawat et al., 2020).

At the implementation level, GPLAN is developed in Python and provides a GUI through which the user can draw an adjacency graph or a dimensionless layout, enter dimensional constraints for each room, request multiple floorplans, check RFP existence via RFPchecker, and generate dimensioned output plans. The illustrated workflow is input graph or layout, topology generation or preservation, dimensional input, linear optimization, and dimensioned floorplan output (Shekhawat et al., 2020).

The case studies emphasize both regeneration and design support. In one example, GPLAN re-generates the Villa Trissino floorplan by extracting its underlying adjacency graph and then generating a corresponding dimensioned plan; it also generates topologically distinct alternatives to that historical plan. In another, the Banstead Home School Plan is drawn directly in the GUI and then dimensioned, illustrating the dimensionless-layout mode for a complex existing plan (Shekhawat et al., 2020).

6. Assumptions, limitations, and terminological ambiguity

GPLAN’s assumptions are explicit. It assumes orthogonal geometry; graph-input mode assumes adjacency graphs are planar triangulated and bi-connected; the system focuses on floorplans with 3-joints; RFP generation depends on PTPG/CIP theory; OFPs are produced by graph augmentation and room merging; and IFP generation from graphs is not solved directly, so the user must provide the dimensionless IFP topology explicitly (Shekhawat et al., 2020).

Its limitations are equally explicit. Although GPLAN can generate very many solutions, the paper notes that users cannot inspect all of them manually, so future work is needed to rank or filter solutions using boundary preferences, daylight, circulation, and other architectural criteria. GPLAN does not automate circulation design, detailed functional reasoning, or comprehensive architectural evaluation. For irregular floorplans, it does not generate topologically distinct alternatives from an adjacency graph; it only dimensions a user-supplied layout. The authors stress that architects still need to refine the generated layouts (Shekhawat et al., 2020).

A recurring source of confusion is nomenclature. In the architectural context considered here, GPLAN denotes the floorplan-generation system just described. Later literature uses visually similar names for unrelated systems: GenePlan is a domain-dependent generalized planner for classical PDDL domains (Murray et al., 10 Mar 2026); G-PlanET is a benchmark and modeling framework for grounded planning for embodied tasks with LLMs (Lin et al., 2022); GPlan in Amap denotes a generative framework for spatiotemporal intent-sequence recommendation (Wang et al., 27 May 2026); and GenPlan denotes a generative sequence-model planner for adaptive behavioral planning (Karthikeyan et al., 2024). These works are conceptually adjacent only at the level of “planning” as a broad label; they are not extensions of GPLAN’s floorplan methodology.

Within architectural computation, GPLAN remains notable for combining graph theory and linear optimization into a user-facing system that turns adjacency requirements or sketched layouts into dimensioned floorplans. Its significance lies less in black-box generation than in its explicit synthesis pipeline: weak-dual graph reasoning for topology, REL and $P_0,P_1,P_2,P_3$7-graph constructions for rectangularization, and flow-based optimization for dimension assignment (Shekhawat et al., 2020).