Text-to-Code Generation for Modular Building Layouts in Building Information Modeling
Authors: Yinyi WEI
Xiao LI
Venue: NeurIPS 2025 poster ()
Keywords: Building layout design; Modular construction; Building information modeling; Code generation; Large language models
Primary area: applications
TL;DR: A framework for generating modular building layouts from textual descriptions driven by code

Abstract: We present Text2MBL, a text-to-code generation framework that generates executable Building Information Modeling (BIM) code directly from textual descriptions of modular building layout (MBL) design. Unlike conventional layout generation approaches that operate in 2D space, Text2MBL produces fully parametric, semantically rich BIM layouts through on‑the‑fly code instantiation. To address MBLs' unique challenges due to their hierarchical three-tier structure: modules (physical building blocks), units (self-contained dwellings), and rooms (functional spaces), we developed an object-oriented code architecture and fine-tuned large language models to output structured action sequences in code format. To train and evaluate the framework, we curated a dataset of paired descriptions and ground truth layouts drawn from real‑world modular housing projects. Performance were assessed using metrics for executable validity, semantic fidelity, and geometric consistency. By tightly unifying natural language understanding with BIM code generation, Text2MBL establishes a scalable pipeline from high-level conceptual design to automation-ready modular construction workflows. Our implementation is available at https://github.com/CI3LAB/Text2MBL.

Text-to-Code Generation for Modular Building Layouts in Building Information Modeling
Yinyi Wei The University of Hong Kong wyyySconnect. hku.hk
Xiao Li The University of Hong Kong shell. 1i@hku..h...
Abstract
We present Tex12MBL, a text-to-code generation framework that generates ex- ecutable Building Information Modeling (BIM) code directly from textual de- scriptions of modular building layout (MBL) design. Unlike conventional layout generation approaches that operate in 2D space, Text2MBL produces fully paramet- ric, semantically rich BIM layouts through on-the-fly code instantiation. To address MBLs' unique challenges due to their hierarchical three-tier structure: modules (physical building blocks), units (self-contained dwellings), and rooms (functional spaces), we developed an object-oriented code architecture and fine-tuned large language models to output structured action sequences in code format. To train and evaluate the framework, we curated dataset of paired descriptions and ground truth layouts drawn from real-world modular housing projects. Performance was assessed using metries for executable validity, semantic fidelity, and geometric consistency. By tightly unifying natural language understanding with BIM code generation, Text2MBL establishes a scalable pipeline from high-level conceptual design to automation-ready modular construction workflows. Our implementation is available https///ittuub..om/CI1.. ABBTT//IIAAABT
Introduction
Modular construction has come to the fore in industrial development, replacing traditional construction with standardized 3D volumetric units manufactured off-site and subsequently assembled on-site [14]. This paradigm shift introduces new challenges in building layout design, as traditional spatial configurations must be reinterpreted within the constraints imposed by modular systems. Designing within this confined solution space resembles "dancing with shackles on," where designers must simultaneously address diverse user requirements while operating within highly restricted design environment [26, 1]. The factory-based production of modular construction draw strong parallels with industrial manufacturing processes, following trajectory toward mass customization, which seeks to reconcile standardization with the demand for individualized preferences [10, 36, 35]. Consequently, design decision-makeeee is longer designer-exclusive but user-inclusive.
To facilitate more intuitive and accessible user interaction during the early design phase, text has increasingly been adopted as input modality in industries such manufacturing and construction [19, 11, 20]. Recent text- based input methods allow users to express design intentions or preferences, supporting diverse downstream applications, e.g., CAD modeling [19], electronic device [18], and graphic layout design [21]. Although text-based methods have shown promise in generating traditional building layouts [20, 32), extending these approaches to modular building layout (MBL.) design remains non-trin non-trivial. Unlike conventional practices, modular construction is governed by the "module" concept, adding layer of complexity.
*Corresponding Author
39th Conference on Neural Information Processing Systems (NcurIPS 2025).

---

house consists of three modiles: Medule Module and Modale
messures 5375mm in width, doce is installad on the south wall of Modale positiosed 2950mm from the west side; a 25mm-long bathroom (duor the south side on east wall) located to the north of Module I. posdianed to the cast, and has overall dimensions of 26755mm by 4270mm. Module is adjacent to the side Medule towards the south, messuring 1920sms length and 2470mm width, it houses the kitchhn (door at south side un the cast wall). These mociles togother form a living speeo, with undivided designated as
2-000mm
Text2MBL
in west portion. Module
Rachs
2D view
3D view
Hodule module. nun Rodala (nass: "Podule point: pditial_point, Lungth: 5375, width: 2489);
Modulio modulo 2 now (name: "Module 2", nodule: nocule.1, direction: "north", Longth: 2675,
width: 4270, aligmment: "east"
sifset_direction "none", offiset: n);
Modula module_3
(odsea 'Medula radule: nodule,2, direction: "mest", Langth: 1720, kidth: 2498 aligneant: "south"
direction
offiet:
Utils Mergoloouilssrrooule:: non List<foodul>> nodule.1, rodulc.2 2, noduio_3 1);
linit unst new (nsss:: "Unit", nodules: new Listsclodila> sodule,1, aodille_,, acdile_3 });
Roos bathroos new (non(>ame: "Bathreeee" aedile: nodule_t,, unit: unit, direction: "west", dimession: 2125, open: false);
Room kitchen new Rnom(nane: "kitchee"", module: rodule.., 3, unit: unit, regular: true);
Reom(name: "Living Room",
regular: false);
usils. artoorrfrfuulleeeeooo
aodul=_1, direction: "south", igneent:
offset:
set_dinensing
utils. CreateDoorf (roco bachroon, dirwction: "east", aligment: "south", offaet: 6, sut: "none", set, disension: B);
Utils CreateDoo (rooo kitchen, direction: "east", atignaont: "south", offset: 0, set: "none", set_ddieossio: E);
Figure I: Example of Tex12MBL.
Another challenge exists between conceptual design and construction workflows regarding output format compatibility. While previous research emphasized image-based design generation, the direct production of Building Information Modeling (BIM)-based designs remains underexplored. Unlike image representation, BIM encodes semantically rich and structured information that supports not only visualization but also a wide range of downstream tasks throughout the building lifecycle, e.g., simulation, quantity takeoff, and facility management [30, 33]. However, transitioning the output format from images to BIM introduces additional difficulties, as current approaches typically rely on error-prone post-processing methods that struggle with spatial clashes and semantic incongruity (e-g., raster to vector [23] and IFC-d reconstruction [24]). Although recent work has attempted to generate BIM component coordinates using large language models [11], research has yet to develop methodologies for automated design generation in intricate design contexts, e.g., MBL design.
To address the above challenges, we propose Tex12MBL, a framework that translates textual descrip- tions into BIM-based MBLs through fine- the-grained, action-level code over sequential time steps. This work focuses on the parametric design setting, wherein users specify precise spatial and geometric requirements through text. By extending BIM's object-oriented nature, Text2MBL hierarchically structures MBL. into four classes: Modules, Unit, Room, and Utils. To validate Tex12MBL's viability, a proof-of-concept system was implemented in Autodesk Revit [3], representative BIM platform, where custom classes and functions were developed using the Revit API [4] in C#. This action-based sequential representation delivers three merits: (1) it bridges the modality gap between textual de- scriptions and BIM-compatible format, sequential actions (i.e., BIM code) can be automatically executed to produce MBLs in a BIM environment; (2) it eliminates the need for complex geometric reasoning and spatial arrangement computations through abstraction and encapsulation with classes and functions, simplifying the inference process from both user and model perspectives; and (3) sottuenc--t-sqqueeee generation task, aligning it with established practices
reframes the problem in conditional text and code generation. To support training and evaluation, we curated data pairing textual descriptions with action-based instructions in code format from real-world housing projects. Large language models from the Qwen2.5 family [29] were fine-tuned to learn the mapping between text and BIM-based MBLs. We evaluated models from multiple perspectives: executable validity (whether the generated code can be compiled and run in the BIM environment), semantic fidelity (coherence between the input intent and the generated code), and geometric consistency (alignment of the spatial configuration). An illustrative example of the Tex12MBL workflow is provided in Fig. 1, where a textual description is translated into a BIM-based MBL.
The contributions of Tex12MBL can be summarized as follows:
We formalize the concepts of BlM-based MBLs following MBL design principles and validate the feasibility through a proof-of-concepp implementation in Autodesk Revit.
We construct dataset linking textual descriptions with based BIM code.

---

We formulate the text to BlM-based MBL task as a sequence- so-sueenee- problem and demonstrate the effectiveness of our approach by fine-tuning large language models.
2 Background
Modular construction Conventional construction methods have long grappled with persistent problems, e.g., high accident rate, project overrun, and suboptimal quality [25, 28]. Modular construction, characterized by the off-site prefabrication for on-site assembly, has progressively alleviated this predicament [14, 12]. It offers a promising resolution to the classic project management triangle of cost, time, and quality [6]. To provide theoretical foundation for MBL design, Lin et al. [22] has distilled MBI. design principles, including functional space, relationship. and intensity. While comprehensive, current MBL design processes still require extensive expertise and lack mechanisms to incorporate diverse user opinions, hindering mass customization efforts.
Building information modeling (BIM) Building Information Modeling (BIM) is a digital, object- oriented representation that captures both the physical and functional aspects of a facility, supporting its entire lifecycle [7]. Compared with traditional CAD, which primarily emphasizes geometric drafting and visualization, BIM extends beyond shapes to incorporate semantic information such as materials, spatial relationships, and lifecycle attributes [8]. Among BIM platforms, Autodesk Revit one of the most widely used tools in industry and academia. Revit not only provides modeling environment for creating detailed BIM models but also exposes APIs that allow customization and extension, enabling automated workflows and integration with external applications. While Al-driven design automation has been applied in BIM workflows [40, 34), generating semantically valid BIM models directly from textual descriptions remains largely unexplored.
Design with textual input Prior approaches to conditional building layout design have explored pixel-wise generation methods, where each pixel is identified part of specific component [27, 31]. While effective for generating artistic pictures, such approaches are ill-suited for precise, constraint- aware design scenarios. Recent advances in layout and design-related domains have emphasized the use of intermediate representations (e.g.. component coordinates) to bridge natural language and design outputs precede final rendering in workflows. AutomaTikZ [5] uses TikZ code as an intermediate for generating scientific vector graphics, while DiagrammerGPT [39] employs notions with GPT planning for open-domain diagrams. In 3D design, AnyHome [13] and Open-Universe scene generation [2] utilize scene graphs and program synthesis for indoor spatial design. Similar strategies appear in other domains, including generating electronic devices from text [18], graphic
layouts via parse- parse-then-Pee teee-thhe--lpeeee -lace [21]. and sequential CAD models through Text2CAD [19]. Collectively, these works show that code, symbolic grammars, and structured placement plans serve as critical intermediates for controllable and interpretable design synthesis. Motivated by this shift, emerging research in building layout generation from text has proposed generating component-less box coordinates via language models as intermediate representations [9, 20, 32, 11], which offer improved interpretability and adjustability that better accommodate constraint- design. However, these methods still require careful management of component ordering to avoid overlaps or inconsistencies. Furthermore, language models often struggle with capturing complex spatial relationships and geometric reasoning.
bounding
architectural
3 Text2MBL
3.1 Motivation
The overall framework of Text2MBL shown in Fig. The MBL generation process is represented as an action sequence that construct BIM model, encoded using an elaborately designed code architecture. For example, for two-module MBL, the process begins with the creation of an initial module, followed by the generation of a second module using the first as an anchor. Once the modules are established, individual units are defined within them. Next, specific rooms are assigned based on the existing units and modules, followed by the addition of other architectural elements, e.g., doors. arhhtechitellural components (e.g., modules) are created through encapsulated functions that define series of operations to cover essential architectural elements (e.g., walls and floors).
3

---

Conaepi femuzias
Woek procolure
Rosei
Product
Tepelogy
Tepeings
PI Desgaar
BIX-tmol
Tepobogy Hamadoo
Medal
Misail Fivel
CANTAYY
Flenverr
Geavety
Tegekop
Uit Sentecaoo conlii de COSTEEE
Pry MIC
class M
conuration
13 cbject mutiide
Is object rustads
PUO
Condina Mill modernng
Fanction
Teeert Clues
Lbik Elies
3
fills
Strtic pedtodi only
Thickio Asslantion
Esconatic
Candras
Novol lirgane docippion
Cislc implemenaation
Datu cunation and moldi develapmani
Figure Framework of Text2MBI.
3.2 Concept formation
Concepts are first formulated to establish the backbone of the MBL design. We adopt the MBL design principles [22] and its underlying "space without for" theory [15], positing that certain geometric problems are determined not upon the precise shape of individual objects but by their spatial arrangement (see Appendix A for further details). We extend these established principles by systematically analyzing existing MBI. examples to support a wider spectrum of MBL scenarios.
Formally, an MBL defined as L = (M,URR, E, A,C), where M = {m U = { Nu
NM
R = (r:) denote the sets of modules (i.e., physical building blocks), units (i.e., self-contained dwellings), and rooms (i.e., functional spaces), respectively. Each module and room is associated with specific geometric information (e.g., length and width). Each room r; is assigned a semantic label indicating its functionality (e.g., kitchen and bathroom). The set = {e includes architectural elements such as doors and holes (i.e., passages). The spatial relationships among components are encoded by: the adjacency matrices AA (AM, AA and the connectivity matrices C = (C-M CRR.. Adjacency matrices quantify the spatial proximity between modules contact. Connectivity matrices describe the accessibility between spaces, determined by architectural elements (e.g., doors and open walls).
based boundary
Besides adjacency and connectivity, MBL introduces an additional relationship termed conjoint, capturing the co-location of rooms within the same module. Two rooms ry and rj said to be conjoint if there exists a module m E M such that r; S m and ry S m. This relation provides auxiliary topological insight into how spatial components
organized within modular structures.
An MBL must satisfy hierarchical containment constraints. First, each unit must fully enclosed within union of one more modules: Vu, E U, uj S UmEM, m, where Mj C M. Second, each room must be nested within specific unit: Vrr RR S Mly for some uj U. These constraints serve as foundational rules and reflect the hierarchical structure intrinsic to modular architecture.
3.3 Code implementation
Based on the established concepts, we developed a proof-of-concept system by extending an existing BIM platform, Autodesk Revit, through its official C# API ensure seamlessly object-oriented integration. The implementation abstracts complex operational logic into modularized classes and functions, exposing only high-level interfaces suitable for invocation by fine-tuned language models.
The core of the system three classes: Module, Unit, and Room, with each encapsulating attributes to reflect its role in MBL designs. These classes support multiple constructors, allowing flexible

---

Table 1: Actions in TexI2MBL, exemplified via relevant MBLs, code snippets, and BIM formats.
Action
Method
MBL. (F.g.
Code (E.g.)
BIM (E.g.)
Absolute coordinate
Module module new Module(name: "Module", point: ini- tial point, length: 2800, widtl: 6880);
Module creation
Module module 3 new Module(nome: "Module mod- ule: module_ 1, direction: "south" length: 2240) widhh: 1620, aligument: "eust". [ijset_direction: "wesf", offset: 2000);
Relative po- sition
List Modules modules UJis.SpliMMeaaletmmot module 2, direction: "west-east" ratio: 0.5), 0.3),nModule mod- ule north new "rss__nuuls([[]/ vaMooddle module 2_south modules(1]:
Module split
Module operation
Module merging
Utils. morgeeeiinlsstmodddes:: new List<Modulee> module I!, modde_ 2
Combination of modules
Unit unit I new Unit(name: "Unit I", modules; new LidueMedde>> module _1 module 2_north] );
Unit initialization
Combination of direc- tional modules
Unit unit new Unitfname: "Unit 1", modules: new List=Module> module 1, module modale 3. direction: "north", dimensions: new List<double> $800, 5800, 5800
Module/Unit- based
Room living
Room "Living Room", modale: moddle, unit: wnit, regular: false);
Diretion- oriented
Room kitchen new Room(name: "Kitchen", module: module, unit: unit, direction: "south" dimension: 1800, open: true);;
Room assignment
Room kitchen new Room(nome:
"Kitchen", module: module, "southwest", length: 1600, width: 1200,
Corne- oriented
unit:
diiictddieciin:: "none", offect: O, open: true);
Room kitchen Roondnume: "Kitchen" wul: moi: bathrom, direction: "east", length: 1640, width: 1220, align- ment: "north" offset direction: "none", offset: O open: falsei:
Relative
Uiils. CreateDoor Roond rooe: bedroom 3. direction: "west". alignment: "south". offset: 0, set: "in". set_dimension: 600);
Door
Element placement
Unils. CreateHole module 2, direction: "north", align- ment: "none" offset: dimension: 2000);
Hole
instantiation based on diverse textual input. Each class provides object methods for fundamental geometric and structural operations, e.g., retrieving geometric features.
Beyond class-specific methods, a utility (Utils) class was implemented to provide static methods for both geometrical operations (e-g., midpoint calculation and concave polygon detection) and functional processes for MBL. components (e.g., creating doors and holes, splitting or merging modules).
Table presents representative atomic actions defined in Text2MBL, along with illustrative examples and corresponding code interfaces. Additional implementation details are provided in Appendix B.
3.4 Data curation and model development
After determining the input and output formats (i.c., textual descriptions and corresponding code- based action sequences), we constructed our dataset by collecting pre-accepted modular construction designs from official 2 Each design instance was manually annotated with constituents: (1) executable BIM code under the developed architecture that generates valid MBL models auto- matically and (2) corresponding textual descriptions that articulate the user's design intent following parametric design.
htttps:/www.bd. gov. ht/en//esourcee/codesss and referrence/moodulal htt.:////oooooooaeeeeeerer/enaaa htt.:/ccooooniicccccpeeeiiiiilli
iederencee/mmodlllannngeeeeed
5

---

From this process, we curated a dataset comprising 198 unique MBL designs. Each MBL instance was first annotated with its associated code-based action sequence, compiled and verified for correctness. Then, two distinct textual descriptions were independently written for each MBL to simulate diverse user expressions. The two different descriptions for a design follow different narrative sequences and structures, such as describing the components in various order. Two coding styles are considered: one utilizing named arguments (i.e., explicitly specifying the semantic roles of each parameter) and the other using positional arguments (i.e., relying solely the order of parameters). The resulting dataset is formally defined as D = { {dd [dd channe ,,, c | = 1,2,...... ..D) where dē and de are the two distinct textual descriptions, cqame and ce are the corresponding code following named argument and positional argument formats, respectively.
Due to MBL's recent inception, there is a paucity of publicly available training data specific to MBL design tasks. To alleviate data deficiency and improve generalizability, we adopt synthetic data generation in both partial and full manner.
In the partially synthetic setting, existing golden code samples are leveraged for generating textual descriptions. A mapping function T is defined convert each code sample e to a corresponding textual description d', such that d' (c).. We explored two realizations of T: a template- based approach and a model- approach. In the template-bate based variant, bank of five linguistically diverse templates was defined for each action scenario (e.g., creating module with varying parameter combinations). During generation, one template was sampled uniformly at random for each action. The model- -basd variant employed proprietary model (i.e., 1pt-4.1-mini) to convert code into textual descriptions with the prompt used in Appendix J.
In the fully synthetic setting, both code samples and associated descriptions are generated de novo. A code sample of is synthesized based on predefined grammar rules and parameter configurations that reflect plausible usage scenarios observed in realistic data. Each generated instance is then converted into a textual description d' using the mapping function described above, yielding df Te
We seek a parameterized language model (o d) that, given a description d, produces the code-based action sequence of a BIM-based MBL design L.. Concretely: é arg max. po(c d).
4 Experiment
Given the lack of existing benchmarks for this problem, our experimental objectives is twofold: (1) to quantify the performance of our proposed code-driven generation approach compared to conventional coordinate-driven generation approach hand, and (2) identify pathways for continual improvement, e.g., model selection and synthetic data generation.
4.1 Experimental setup
For the 198 MBL designs (396 pairs of descriptions and code), we partitioned them into training, development, and test sets using a 7:1:2 split, resulting in 138, 20, and 40 designs (276, 40, and 80 pairs). In the partially synthetic setting, we generated 10 descriptions per design using both template- and model-based approaches. producing 1,380 new descriptions per method. For the fully synthetic setting, we synthesized 3,000 unique code sequences from scratch and converted them into textual descriptions using the same two approaches. To compare with coordinate-drif driven generation methods 3, we derived bounding box coordinates of MBL designs. The output coordinate sequence was structured hierarchically, consisting of three segments (i.e., modules, units, and rooms): MODULE: (n [module seq] |nUnit: \n [unit seq] \nRoom: \n [room seq]. Within each segment, every component is described by its bottom-left corner, length, and width. For example, a module can be represented as [Module 1 xx=00ly= y=0 Length=3100 .0 width=54400 .0]. Detailed statistics (e.g.. the number of tokens of descriptions and code) are provided in Appendix C.
We fine-ture tune models from the Qwen2.5 family [29], leveraging their strong capabilities as backbone models. To investigate the effects of model scale and specialization, we conducted experiments using variants of Qwen2.5 across different sizes (0.5B, 1,5B, 3B, and 7B) and domains, including the vanilla series [37], the coder series [17], and the math series [38]. To ensure reliable comparison,
'w omit naming specific coordinate-driin methods (e.g.. Tex12BIM or Tell2Design) in experimental comparisons to highlight the fundamental paradigm difference between coordinate- and code-driven approaches

---

Table 2: Geometric consistency using different models and oulput formats. Positional arguments are used. Mean values over five views are reported in this and subsequent tables and figures.
Model
IoU (%)
Module IoU (%)
Unit IoU (%)
Room IoU (%)
Qwen2.5-Instro
1.5B
Coordinate
78.13
86.98
80.27
69.85
1.5B
Code
91.65
95.47
93.79
86.79
Coordinate
85.38
90.35
90.39
77.33
7B
Code
95.83
98.51
98.11
91.64
Qwen2.5- Seeen..5-ooder-nnsttee
1.5B
Coordinate
78.33
87.71
80.20
69.85
1.5B Code
94.19
97.01
95.59
90.45
7B
Coordinate
84.64
90.12
88.18
77.53
7B
Code 98.43
98.78
99.19
97.37
Tiee2.55-Math-Insse
1.5B Coordinate
78.61
87.03
85,09
67.57
1.5B Code
94.18
97.49
97.17
89.06
Coordinate
85.34
90.32
89.51
78.02
7B Code
94.86
98.07
97.46
89.86
Coople
60
MARA CaI Roce
A1 Wedle 1he Reediier
AI Med 18 Ramfleee
40 Mekk
0.8
Ram
Component-level performance on compile rate, pass rate, instance F1, argument F1, and IoU for modules, units, rooms, and elements, using Qwen2.5-Coder-33 with positional arguments.
Figure 3:
each experiment was conducted five times using different random seeds. Results are presented as mean values across all trials. More experimental details are presented in Appendix D.
evaluated models along three dimensions: executable validity, semantic fidelity, and geometric consistency. To assess executable validity, measured whether the generated code compiles successfully (compile rate) and produces functionally correct outputs (pass rate). Given that crucial design information is often embedded in code expression such class names, function names, and their arguments, we evaluate semantic fidelity using standard information extraction metrics: F1 score. We consider a complete code line representing a design action correctly generated, and (2) argument-level using argument F1, which focuses the correctness of individual arguments within such instances. To quantify geometric consistency between the generated and reference MBL designs, we employ the Intersection over Union (IoU) metric. IoU measures the degree of spatial overlap between two bounding boxes, i.e., the ratio of the area of their intersection to the area of their union.
granularities: (1) instance-level with instance F1, which measures whether
4.2 Experimental results
Output formats: code or coordinate We first evaluate model performance across different output formats, i.e., code and coordinate. As shown in Table 2, the code-driven approach demonstrated superior geometric consistency in generating MBLs, stemming from the relative positioning employed in the code architecture instead of absolute coordinates. Moreover, we note that geometric consistency metrics only quantify the degree bounding box overlap and may not fully capture critical factors encountered in real-world MBL scenarios, e.g., element placement, clash avoidance, component ordering, and support irregular geometries. Text2MBI. addresses these challenges by abstracting complex design operations into high-level interfaces, facilitating robust and interpretable MBL

---

ToU (%6
Module ToU (%6
Unit loll (16
Room Tol (%)
Tol. (%)
Module (ol)(%)
Unit fol/ (%)
Room loll (%)
100
98
99
00.02
dm -0
6= -Q00Z
96
0.03
94
0.00
92-
92-
90
90
All 122
All 2.2 2-2
522 2-2
152
All
154
2-4
154
All
All 15 5-4
Edfoct the number modules
Effect of number of rooms
Figure 4: Effect of the number of modules and rooms on geometric consistency metrics, using Qwen2.5 5-ceer5-Coder-3BB with positional rigumeets-based code output. Relative transformations (A) are computed from groups with fewer components to those with higher components counts.
(%)
JoU (%) (%)
Room (%)
IoU (%6
Module (%) Unit ToU (%) Room IoU
100
0.16
-0.6
90
-0.13
85
-0.11
80
80
0000
75
d= -0.03
70-
60
Effect of the number of modules
Edflect of the number of rooms
Figure Effect of the number of modules and rooms on geometric consistency metrics, using Owen2.5-Coder--3. with coordinate sequence output. Relative transformations (A) are computed from groups with fewer components those with higher components counts.
generation in the construction workflows. Additionally, Appendix F presents the performance of representative proprictary models, highlighting the potential of text-to-code generation for MBLs.
Component-level performance To gain deeper insights into the performance of this text-to-code generation task, we further report fine- fine-grained, component levell results in terms of compile rate, pass rate, instance F1, argument F1, and IoU for modules, units, rooms, and elements. Fig. revealed that: (1) The semantic fidelity metrics (i.e., instance F1 and argument F1 scores) achieved better results than the pass rate metric, suggesting that models were more effective extracting argument information than at producing perfectly executable code without deviations. The observation offers inspirations in practical deployment scenarios that extracted arguments can be leveraged to guide post-generation correction, enhancing the overall robustness and usability in real-world applications. (2) The pass rates for modules and rooms are notably lower than those for units and elements, likely due to their increased operational complexity and the higher number of constraints involved. For other metrics, the performance gap among components is less pronounced. As a complement, Appendix provides more results across various metrics covering different model series and argument types.
Component number effect We then group designs based on the number of modules and rooms, aiming to reveal the relative performance trends as the number components increases. The results from code output and coordinate sequence output are illustrated in Fig. 4 and Fig. 5, respectively. We observe that increasing the number of components led to a sharper performance decline in the coordinate sequence output compared to the code output. This difference be attribute to the hicrarchically designed code architecture, which replaces spatial reasoning with semantic understanding relying relative position, delivering more robust results. Additional details and discussions can refer to Appendix G.
Low resource-scenarios and data integration Though the experiments demonstrate the effec- tiveness and potential of the Text2MBL framework, a critical issue the broader deployment is

---

61.
815
1P%, 2015 ett 09% M9 1811
39h 2055 4t% M0
1955
48% 3006 19s. 306
1066 396 -0%
0011
105 360 4hs ort wes 1996.
Argentiiie medhttuttingg
Figure 6: Ratios of original training data augmented with synthetic data, using Qwen2.5-Coder-a. with positional arguments. The corresponding performance improvements for metrics are highlighted.
the lack of sufficient training data, mainly due factors: the scarcity of accessible MBL data and the high cost of annotation. To alleviate this issue and facilitate wider application of our frame- work, we adopted synthetic data generation strategy as described in Section 3.4. Though the synthetic data face issues such as rigid description logic and has demonstrated inferior performance as revealed in Appendix I. We repurpose the synthetic data for augmentation rather than standalone training. Specifically, we mixed the original training data with synthetic data for model training". As shown Fig. 6, this mixed strategy yielded substantial performance gains, especially under extreme low-resource conditions (e.g., only 10% original data available). Though the fully synthetic data may introduced noise and inconsistencies in fabricated code, integration of such data still beneficial. While model-basee descriptions are more natural than those from the template-based approach, their relative performance gains were comparable and, in some cases, even inferior. This demonstrates that, while using synthetic data alone is insufficient, leveraging it in an augmented manner can significantly enhance performance.
Table 3: Results with abstract instructions using various models and argument types.
Argument Compile (%)
Extraction Fl (%)
Abstract and conceptual instructions To as- sess the generalization capabilities of fine-tuned models, we conducted experiments using abstract trans-
Qwen2.5-Coderss
Named
68.75
99.05
and conceptual instructions. Specifically, formed detailed instructions into a skeletonized format: "Generate layout with ni module, n2 unit, ny living room, 74 bathroom, my bedroom, evaluated using two metrics: the compile rate, which reflects the successful generation of executable code, and the extraction Fl score, which quantifies the accu- racy of extracting and mentioning modules, units, and rooms.
Positional
45.00
98.36
Qwen2.5-Coder-7B
Named
92.5
100.0
ng kitchen." " Model performance
Positional
95.00
99.53
ChatGPT (gpt-4.1-min)
Named Positional
81.25
92.91
78.75
91.96
ChatGPT (gpt-4.1)
Named
87.50
96.1
The empirical results reported in Table 3 demon- strated basic generalization from detailed to ab- stract instructions, yet sill warranting further in- vestigation for smaller models and general-purpose proprietary models. Models provided with named arguments generally achieved higher performance, benefiting from the greater specificity and structure afforded by named arguments for general inputs. This suggests that while our approach can handle
Positional
82.50
94.58
*We have tried pretraining on synthetic data followed by fine-tuning original data, but observed no improvement and sometimes worse performance.

---

degree of abstraction, further improvements are necessary to robustly support the full granularities of user input styles.
4.3 Error analysis
We carefully analyzed the generated results and summarized several common types of errors made: (I) wrong argument order, (2) incorrect code structure or sequencing; (3) hallucinated or invalid arguments; (4) ballucination of of non-existent functions; and (5) invocation of incorrect functions.
While these errors highlight the current limitations in fully accurate code generation from textual de- scriptions, practical systems should incorporate post-generation validation and correction mechanisms ensure executable and user-aligned outputs, as discussed in Appendix H.
5
Discussion
While our work contributes significantly to the automation of BIM design tasks and inspire related work in both manufacturing and construction industries, several limitations remain.
First, the text-to-code generation task, we only considered the technical aspects of parametric design, relying detailed user instructions guide code synthesis. The current framework does not account for the alignment between generated code and user inputs at varying levels of granularity, nor does it address broader user-centric criteria such satisfaction usability. A thorough evaluation of these dimensions would require carefully designed user studies, which we leave for future work.
Second, we employed identical families of architectural elements (e.g., wall, floor, and door) to maintain simplicity and consistency in our developed code architecture. However, expressive designs often demand greater variation in elements properties (e.g.. width, material) and their combinations. Addressing this need could involve leveraging richer component libraries and more effective retrieval mechanisms, which plan to explore in future work.
6 Conclusion
In this work, we investigate user-inclusive parametric design in construction workflows, focusing on BIM-based MBL generation from textual descriptions. We identify the challenges posed by MBL intrinsic characteristics (i.e., hierarchy, semantics, geometry, and topology) and the output format requirements (i.e., BIM representations). We frame the problem as a code generation task, where structured code serves as executable action sequences for constructing MBLs in BIM environments. We curated a dataset from real-world modular housing projects and fine-tuned large language models to translate textual descriptions into BIM-come ELM-compatible code. Empirical evaluation of the Tex12MBL framework reveals three key insights: (1) The code-driven paradigm substantially outperforms con- ventional coordinate-basse various evaluation metrics, code-driven models exhibit strong performance, especially in extracting information from inputs, confirming the feasibility of Tex12MBL. (3) Although the pass rate remains a challenge, performance can be significantly improved through synthetic data augmentation, demon- strating the potential of TeXI2MBL. A functional plug-in has been implemented within Autodesk Revit. Future research will focus on developing more robust models capable of processing user inputs varying levels of granularity, thereby generating more accurate and executable layout code. Moreover, the expressiveness of the generated outputs will be extended to incorporate a broader range of design variations.
approaches, underscoring the effectiveness of Tex12MBL. (2) Across
Acknowledgments
The work described in this paper is supported by the Research Grants Council of the Hong Kong SAR of China (Germany/Hong Kong Joint Research Scheme, No. G-HKU502/22), the Guangdong- Hong Kong Technology Cooperation Funding Scheme (TCFS) (Ref no. GHP/321/22SZ), and the Innovation and Technology Fund (ITF) (Ref No. TP/041/24LP).
10

---

References
[1] Sherif Abdelmageed and Tarek Zayed. A study of literature in modular integrated construction- critical review and future directions. Journal of Cleaner Production, 277: 2020.
[2] Rio Aguina-Kann Kang, Maxim Gumin, Do Heon Han, Stewart Morris, Seung Jean Yoo, Aditya Ganeshan, R Kenny Jones, Qiuhong Anna Wei, Kailiang Fu, and Daniel Ritchie. Open-universe indoor scene generation using I1m program synthesis and uncurated object databases. arXiv preprint arXiv:2403.00677, 2024.
[3] Autodesk Inc. Autodesk revit. https://www.autooeskk. com/, 2022. Version 2022.
[4] Autodesk Inc. Revit api 2022. http:://wwww.etttppooooooooooo// com 2022. Software Development Kit (SDK) for Autodesk Revit 2022.
[5] Jonas Belouadi, Anne Lauscher, and Steffen Eger. Automatikz: Text-guided synthesis of scientific vector graphics with tikz. In The Twelfth International Conference Learning Representations, 2024.
[6] Nick Bertram, Steffen Fuchs, Jan Mischke, Robert Palter, Gernot Strube, and Lola Woetzel. Mod- ular construction: From projects to products. https: //ww: mckinsey. com/ capabilities operations htte:/uu-nnnngggg welighttsmmmuulll wwmdmoodaaarr/ www.uuaarooosstttoontttaaeeee
cetoo-ppooects-eeee to-orduucss 2019. McKinsey & Company. Last accessed: 2025-04-23.
[7] André Borrmann, Markus König, Christian Koch, and Jakob Beetz. Building information modeling: Why? what? how? Springer, 2018.
[8] Rabia Charef, Hafiz Alaka, and Stephen Emmitr. Beyond the third dimension of bim: A systematic review of literature and assessment of professional views. Journal of Building Engineering, 19:242-251 2018.
[9] Qi Chen, Wu, Rui Tang, Yuhan Wang, Shuai Wang, and Mingkui Tan, Intelligent home 3d: Automatic 3d-house design from linguistic descriptions only. In Proceedings of the IEEE/CVF conference on computer vision and pattern recognition, pages
2020.
[10] Giovani Da Silveira, Denis Borenstein, and Flavio S Fogliatto. Mass customization: Literature review and research directions. International journal of production economics, 72(1):1-13, 2001.
[11] Changyu Du, Sebastian Esser, Stavros Nousias, and André Borrmann. Text2bim: Generating building models using a large language model-based multi-agent framework. arXiv preprint a4Xiv:2408. 08054, 2024.
[12] Juan Du, Jingyi Zhang, Daniel Castro- Lasstr-Lacouture, and Yuqing Hu. Lean manufacturing ap- plications in prefabricated construction projects, Automation in Construction, 150: 154990 2023.
[13] Rao Fu, Zehao Wen, Zichen Liu, and Srinath Sridhar. Anyhome: Open-vocabulary generation of structured and textured 3d homes. European Conference on Computer Vision, pages 52-70. Springer, 2024.
[14] Alistair GF Gibb. Off-site fabrication: prefabrication, pre-assembly and modularisation. John Wiley & Sons, 1999.
[15] Bill Hillier and Julienne Hanson. The social logic of space. Cambridge university press, 1989.
[16] Edward Hu, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, Weizhu Chen, et al. Lora: Low-rank adaptation of large language models. In International Conference on Learning Representations, 2022.
[17] Binyuan Hui, Jian Yang. Zeyu Cui, Jiaxi Yang, Dayiheng Liu, Lei Zhang, Tianyu Liu, Jia- jun Zhang, Bowen Yu, Keming Lu, et al. Qwen2.5-coder technical report. arXiv preprint 2024.

---

[18] Peter Jansen. From words to wires: Generating functioning electronic devices from natural language descriptions. In Findings of the Association for Computationaal Linguistics: EMNLP 2023, pages 12972-12990, 2023.
[19] Mohammad Sadil Khan, Sankalp Sinha, Talha Uddin, Didier Stricker, Sk Aziz Ali, and Muham- mad Zeshan Afzal. Text2cad: Generating sequential cad designs from beginner-to-exper level text prompts. Advances in Neural Information Processing Systems, 37:7552-7579, 2024.
[20] Sicong Leng, Yang Zhou, Mohammed Haroon Dupty, Wee Sun Lee, Sam Joyce, and Wei Lu. Tell2design: A dataset for gaguuage-guided floor plan generation. In Proceedings of the 61 Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 14680-14699 2023.
[21] Jiawei Lin, Jiaqi Guo, Shizhao Sun, Weijiang Xu, Ting Liu, Jian-Guang Lou, and Dongmei Zhang. A parse-then-place approach for generating graphic layouts from textual descriptions. In Proceedings of the IEEE/CVF International Conference on Computer Vision, pages 23622-
23631, 2023.
[22] Xiao Lin, Junjie Chen, Weisheng Lu, and Hongling Guo. An edge-weighted graph triumvirate to represent modular building layouts. Automation in Construction, 157:105140, 2024.
[23] Chen Liu, Jiajun Wu, Pushmeet Kohli, and Yasutaka Furukawa. Baster-to-vector Revisiting floorplan transformation. Proceedings of the IEEE International Conference on Computer Vision, pages 2195-2203, 2017.
[24] Jiepeng Liu, Zijin Qiu, Lufeng Wang, Pengkun Liu, Guozhong Cheng, and Yan Chen. Intelligent floor plan design of modular high-rise residential building based on graph-constrained generative adversarial networks. Automation in Construction, 159:105264, 2024.
[25] Weisheng Lu, Ke Chen, Fan Xue, and Wei Pan. Searching for an optimal level of prefabrication in construction: An analytical framework. Journal of Cleaner Production, 201:236 245, 2018.
[26] GE Marjaba and SE Chidiac. Sustainability and resiliency metrics for buildings- criticall review. Building and environment, 101:116-125, 2016
[27] Nelson Nauata, Sepidehsadat Hosseini. Kai-Hung Chang, Hang Chu, Chin-Yi Yi Cheng, and Yasutaka Furukawa. House-gan++: Generative adversarial layout refinement network towards intelligent computational agent for professional architects. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, pages 13632- 13641, 2021.
[28] Mohamad Razkenari, Andriel Fenner, Alireza Shojaei, Hamed Hakim, and Charles Kibert. Perceptions of offsite construction in the united states: An investigation of current practices. Journal of building engineering, 29:101 138, 2020.
[29] Qwen Team. Qwen2.5: A party of foundation models. quen2.5/ 5/, September 2024.
[30] Rebekka Volk, Julian Stengel, and Frank Schultmann Building information modeling (bim) for existing buildings literature review and future needs. Automation in construction, 38:109-11 127, 2014.
[31] Shidong Wang, Wei Zeng, Xi Chen, Yu Ye, Yu Qiao, and Chi-Wing Fu. Actfloor-gan: Activity- guided adversarial networks for human-centric floorplan design. IEEE Transactions on Visual- izution and Computer Graphics, 2963):161--1624, 2021.
[32] Yinyi Wei and Xiao Li. Graph-augmented text-based floorplan generation. In 2024 IEEE Interna- tional Conference on Automation in Manufacturing, Transportation and Logistics (07/08/2024- 09/08/2024, Hong Kong), 2024.
[33] Yinyi Wei and Xiao Li. Knowledge-enhancee ontology-to- veetorr for automated ontology concept enrichment in bim. Journal of Industrial Information Integration, 45:100836, 2025.
[34] Yinyi Wei, Xiao Li, and Frank Petzold. Text-to-structurre interpretation of user requests in bim interaction. Automation in Construction, 174:1061 19, 2025.
12

---

[35] Yinyi Wei, Xiao Li, Chengke Wu, and Frank Petzold. Unlocking the Power of Language Models for Smart Configuraaion in the AEC Domain Using Spoken Language Understanding. Routledge, 2025.
[36] Yinyi Wei, Xiao Li, Chengke Wu, Ata Zahedi, Yuanjun Guo, and Zhile Yang. Generation for configuration: A conceptual paradigm of natural language- basedd configurator for mod- ular buildings with chatgpt. In International Symposium on Advancement of Construction Management and Real Estate, pages 1491-1501. Springer. 2023.
[37] An Yang, Baosong Yang. Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chengyuan Li Dayiheng Liu, Fei Huang, Haoran Wei, al. Qwen2.5 technical report. arXiv preprini arXiv:2412. 15115, 2024.
[38] An Yang, Beichen Zhang, Binyuan Hui, Bofei Gao, Bowen Yu, Chengpeng Li, Dayiheng Liu, Jianhong Tu, Jingren Zhou, Junyang Lin, al. @Wen2.55math technical report: Toward mathematical expert model via self celr-improveeet. arXiv preprint arXiv:2409. 22X1:2249..1222,, 2024.
[39] Abhay Zala, Han Lin, Jaemin Cho, and Mohit Bansal. Diagrammergpt: Generating open- domain, open-platform diagrams via Ilm planning. In First Conference on Language Modeling, 2024.
[40] Fan Zhang, Albert PC Chan, Amos Darko, Zhengyi Chen, and Dezhi Li. Integrated applications of building information modeling and artificial intelligence techniques in the aec/fm industry. Automation in Construction, 139:104289, 2022.
13

---

NeurIPS Paper Checklist
1. Claims
Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
Answer: [Yes]
Justification:
The contributions and scope mentioned in the abstract and introduction.
Guidelines:
The answer NA means that the abstract and introduction do not include the claims made in the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or
NA answer to this question will not be perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings.
is fine to include aspirational goals as motivation long is clear that these goals are not attained by the paper.
2. Limitations
Question: Does the paper discuss the limitations of the work performed by the authors?
Answer: [Yes]
Justification:
We have provided a discussion section of the limitations. Please refer to
Section 5 (Discussion).
Guidelines:
The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
The authors are encouraged to create a separate "Limitations" section their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g.. independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
The authors should reflect the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution is low images are taken in low lighting. Or speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness.
While the authors might fear that complete honesty about limitations might used by reviewers as grounds for rejection, worse outcome might be that reviewers discover limitations that aren't 't acknowledged judgment and recognize that individual actions in favor of transparency play impor- tant role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.
the paper. The authors should use their best
3. Theory assumptions and proofs
Question: For each theoretical result, does the paper provide the full set of assumptions and complete (and correct) proof?
Answer: [NA]
14

---

We do not have any theoretical result. Our contribution is focused on novel application in the manufacturing and construction industries.
Justification:
Guidelines:
The answer NA means that the paper does not include theoretical results.
All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated or referenced the statement of any theorems.
The proofs can either appear in the main paper or the supplemental material, but if they appear in the supplemental material, the authors are encouraged to provide short proof sketch provide intuition.
Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.
Theorems and Lemmas that the proof relies upon should be properly referenced.
4. Experimental result reproducibility
Does the paper fully disclose all the information needed to reproduce the main ex- perimental results of the paper to the extent that it affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)?
Question:
Answer: [Yes]
Justification: have provided the experimental setup in Section 4 (Experiment). We have also provided the LLM prompts that we used in Appendix J (Prompts used).
Guidelines:
The answer NA means that the paper does not include experiments.
If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is novel architecture, describing the architecture fully might suffice, or if the contribution a specific model and empirical evaluation, it may be necessary either make it possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g., in the case of large language model), releasing of a model checkpoint, or other means that appropriate to the research performed.
While NeurlPS does not require releasing code, the conference does require all submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) the contribution is primarily a new algorithm, the paper should make clear how reproduce that algorithm. (b) If the contribution is primarily new model architecture, the paper should describe the architecture clearly and fully.
(c) the contribution is a new model (e.g., a large language model), then there should either be way to access this model for reproducing the results or way to reproduce the model (e.g., with an open-source dataset instructions for how to construct the dataset).
(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome deseribe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (e.g., to registered users), but it should possible for other researchers to have some path to reproducing or verifying the results.
5. Open access to data and code
15

---

Does the paper provide open access to the data and code, with sufficient instruc- tions faithfully reproduce the main experimental results, as described in supplemental material?
Question:
Answer: [Yes]
Justification:
We have released our data and code in the link described in the abstract.
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurIPS code and data submission guidelines (https://nips.co cc/ Bellliicguidees/ooeeeuieee
wtw.mmmmsssiooiiiiio.oooooo.iiii for more details.
While we encourage the release of code and data, we understand that this might not be possible, "No" is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for a new open-source benchmark).
The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurlPS code and data submission guidelines (https: /Codeeuodeeeeeeeeeeeeee /
/ cttppscccppbbpcccc/pepcepppccccc
onnolicy))) for more details.
The authors should provide instructions on data access and preparation, including how access the raw data, preprocessed data, intermediate data, and generated data,
The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. If only subset of experiments reproducible, they should state which ones are omitted from the script and why.
At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
Providing as much information as possible in supplemental material (appended to the paper) recommended, but including URLs to data and code permitted.
6. Experimental setting/details
Does the paper specify all the training and test details (e.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
Question:
Answer: [Yes]
Justification: We have provided the data splits, hyperparameter details, training and inference setup in Section 4 (Experiment) and Appendix D (Experimental details).
Guidelines:
The answer NA means that the paper does not include experiments.
The experimental setting should be presented in the core of the paper to a level of detail that is necessary to appreciate the results and make sense of them.
The full details can be provided either with the code, in appendix, as supplemental material.
7. Experiment statistical significance
Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
Question:
Answer: [NA]
Given that there no standardized benchmark for our task, it's not applicable for our method. Moreover, each experiment has been conducted on five different random seeds to reduce the impact of randomness.
Justification:
Guidelines:
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by emor bars, confi- dence intervals, or statistical significance tests, least for the experiments that support the main claims of the paper.
16

---

The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall run with given experimental conditions).
The method for calculating the error bars should be explained (closed form formula, call to a library function, bootstrap, etc.)
The assumptions made should be given (e.g., Normally distributed errors).
It should be clear whether the error bar is the standard deviation the standard error of the mean.
is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have 96% CI, if the hypothesis of Normality of errors is not verified.
For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that are out range (e.g. negative error rates).
If error bars reported in tables or plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables in the text.
8. Experiments compute resources
For each experiment, does the paper provide sufficient information on the com- puter resources (type of compute workers, memory, time of execution) needed to reproduce the experiments?
Question:
Answer: [Yes]
Justification: We have included specific experiments compute resources in Appendix D (Experimental details).
Guidelines:
The answer NA means that the paper does include experiments.
The paper should indicate the type of compute workers CPU or GPU, internal cluster, cloud provider, including relevant memory and storage.
The paper should provide the amount of compute required for each of the individual experimental rums as well as estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g., preliminary or failed experiments that didn't itdn't make it into the paper).
9. Code of ethics
Question: Does the research conducted in the paper conform, in every respect, with the NeurIPS Code of Ethics https: / /ttp/nnnuuup.ueeee httpp.ccppuueee cc/public/ /tttcii//ieeeeeeeeiieeeeeeeeeee csGuidelines"
Answer: [Yes]
Justification:
We have followed the NeurIPS Code of Ethics.
Guidelines:
The answer NA means that the authors have not reviewed the NeurlPS Code of Ethics.
If the authors answer No, they should explain the special circumstances that require deviation from the Code of Ethics.
The authors should make sure to preserve anonymity (e.g.. there a special consid- eration due to laws regulations in their jurisdiction).
10. Broader impacts
Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
Answer: [Yes]
Justification: We have provided the positive impact of our framework in Section 1 (In- troduction) and Conclusion. We are not yet aware of any negative societal impacts as of now.
Guidelines:
17

---

The answer NA means that there is no societal impact of the work performed.
If the authors answer NA No, they should explain why their work has societal impact or why the paper does not address societal impact.
Examples of negative societal impacts include potential malicious unintended uses (e.g., disinformation, generating fake profiles, surveillance), fairness considerations (e.g., deploymentt of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology is being used intended but gives incorrect results, and harms following from (intentional or unintentional) misuse of the technology.
If there negative societal impacts, the authors could also discuss possible mitigation strategies (c.g., gated release models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms monitor how system learns from feedback over time, improving the efficiency and accessibility ML).
11. Safeguards
Does the paper describe safeguards that have been put in place for responsible release of data models that have high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?
Question:
Answer: [NA]
Justification: Our data and code poses no such risks.
Guidelines:
The answer NA means that the paper poses no such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere usage guidelines or restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
We recognize that providing effective safeguards is challenging, and many papers do not require this, but we encourage authors to take this into account and make best faith effort.
12. Licenses for existing assets
Question: Are the creators or original owners of assets (e.g., code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?
Answer: [Yes]
Justification: We have cited every dataset and other supporting architecturc/framcwwkk. to the best of our knowledge.
Guidelines:
The answer NA means that the paper does not use existing assets.
The authors should cite the original paper that produced the code package dataset.
The authors should state which version of the asset is used and, if possible, include URL.
The name of the license (c.g., CC-BY 4.0) should be included for each asset.
18

---

For scraped data from a particular source (e.g., website). the copyright and terms of service of that souree should be provided.
assets are released, the license, copyright information, and terms use in the package should be provided. For popular datasets, paperswi thcode com/ datasets has curated licenses for some datasets. Their licensing guide can help determine the license of dataset.
For existing datasets that are re-packaged, both the original license and the license of the derived asset (if it has changed) should be provided.
If this information is not available online, the authors encouraged to reach out to the asset's 's creators.
13. New assets
Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?
Answer: [Yes]
Justification: The new assets were annotated and generated via our data curation process. Please refer to Section (Tex12MBL) and Section 4 (Experiment).
Guidelines:
The answer NA means that the paper does not release new assets.
Researchers should communicate the details of the dataset/code/model part of their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent was obtained from people whose asset is used.
At submission time, remember anonymize your assets (if applicable). You can either create an anonymized URL or include an anonymized zip file.
14. Crowdsourcing and research with human subjects
Question:
For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well details about compensation (if any)?
Answer: [NA]
Justification:
The annotation work conducted by the authors.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Including this information in the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then as much detail as possible should be included in the main paper.
According to the NeurlPS Code of Ethics, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.
15. Institutional review board (IRB) approvals or equivalent for research with human subjects
Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or an equivalent approval/review based on the requirements of your country or institution) were obtained?
Answer: [NA]
Justification:
The paper does not involve human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsoureing nor research with human subjects.
19

---

Depending on the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors to adhere to the NeurIPS Code of Ethics and the guidelines for their institution.
For initial submissions, do not include any information that would break anonymity (if' applicable), such as the institution conducting the review.
16. Declaration of LLM usage
Does the paper describe the usage of LLMs if is an important, original, or non-standard component of the core methods in this research? Note that if the LLM is used only for writing, editing, or formatting purposes and does not impact the core methodology, scientific rigorousness, originality of the research, declaration is not required.
Question:
Answer: [Yes]
Our experiments included the use of LLMs for prediction and synthetic data generation, which has been described in Section 4 (Experiment), Appendix D (Experimental details), and Appendix (Prompts used).
Justification:
Guidelines:
The answer NA means that the core method development in this research does not involve LLMs as any important, original, or non-standard components.
Please refer to our LLM policy (https: : /ttp//eurppp.//// for what should or should not be described.
/LLM)
20

---

MBL design
Functional space
Intensity and geometty
Modale
Living
Modale
Bedroom
Shared length
Meddle
Rathroom
Intensity
Edge length
Unit
Kitchen
Opening length
Shared longth
Relationship
Hieranchy
Adjacency
HBL
Connectvvity
Conjoint
Geometry
Module
Unit
Figure 7: Example demonstrating MBL design principles.
A The design principles of modular building layouts
To ensure validity and quality of MBLs, three fundamental factors must be carefully considered: (1) functional space, which refers to the assignment of appropriate spatial functionalities to different areas; (2) relationship, encompassing spatial adjacency, connectivity, and conjoint (co-location) between functional components; and (3) intensity, describing the degree of spatial proximity or strength of association between adjacent spaces. These principles collectively guide the structural and semantic coherence of MBLs.
An illustrative example in Fig. demonstrates how these principles can be modeled through graph-
based representations.
B Additional details on code architecture
We provide supplementary information regarding the code architecture in this section. The system is developed within a three-dimensional orthogonal coordinate framework (X, Y, 2). Due to the consis- tent specification of elevation levels and wall height parameters across the design, the computational complexity is significantly reduced onto the woo-dimensional (X-Y) plane. Furthermore, architectural elements (i.e., walls, doors, and floors) are instantiated from uniform family templates, serving as common basis for initial modeling and can be flexibly modified during subsequent stages of the conceptual design phase. For comprehensive implementation details and reproducibility. we refer readers to our code repository.
B.1
Module class
The Module class represents primitive physical cell in an MBL design within a Revit document. Each instance encapsulates essential semantic and geometric information, including the module's s name, boundary coordinates, level, and associated architectural elements such walls and floor components. Designed for flcxibility, the class offers multiple constructors to support different initialization scenarios, accommodating inputs ranging from explicit boundary points to dimensional parameters or relative positioning based on existing modules.
Specifically, the class supports three construction strategies: (1) initialization via four explicit boundary points defining module's rectangular geometry; (2) initialization from single anchor point (i.e., the bottom-left corner) combined with specified length and width values; and (3) relative positioning based on a reference module, where the new module placed according to given direction (e.g., north, south) and edge alignment (c.g., east, west).
21

---

The class also provides methods to retrieve the module's name, level, boundary points, length, and width. Additionally, it includes methods get specific boundary points (e.g., southeast, northwest) and walls (e.g., east wall).
To support downstream spatial reasoning and manipulation, the class provides a suite of accessor methods that expose both semantic and geometric properties of the module. Additionally, utility methods are available extract specific corner coordinates (e.g. southeast, northwest) and associated structural elements, such as directional walls (e.g., the east wall).
B.2
Unit class
The Unit class is designed as an abstraction layer for organizing collections of modules and rooms within Revit document, representing self-contained dwelling space in MBL design. It encapsulates key semantic and geometric information, including a unit's label, spatial boundaries, associated building level, constituent modules, and contained rooms. It provides constructors to initialize unit based on different input parameters, such as a list of modules, boundary points, or directional placement relative to existing modules.
Specifically, the class supports three construction strategies: (1) instantiation from list of Module objects, in which the unit's geometry is inferred directly from its constituents; (2) initialization with both a list of Module objects and explicitly defined boundary points, offering more granular control when boundary specifications diverge from module arrangements; and (3) instantiation with directional placement of specific modules, where modules are programmatically arranged in specified directions (i.e., north, south, east, west) with user-defined dimensions. In the third strategy, new boundary points are computed for each module based on directional parameters, adjusted for wall offsets, and augmented with walls when absent.
In addition to accessors for geometric properties and boundary data, the class includes methods to manage room composition within unit, ensuring sematic, spatial, and hierarchical coherence.
B.3
Room class
The Room class represents functional space within Revit document, defined by its semantic role (c.g., kitchen, bedroom), geometric boundaries, centroid, elevation level, and its parent unit within the modular hierarchy. It provides a range of constructor overloads to create rooms based on different input parameters, such as modules, units, specific dimensions, or relative positions.
To accommodate different design scenarios and user requirements, the Room class offers multiple constructors. In accordance with the hierarchical constraints, the instantiation of Room object requires the explicit specification of a Room parameter, even if it is being initialized within a module.
First, room may be instantiated within specified module. In this case, if the room is considered regular, its geometric boundarics are slightly adjusted to accommodate wall thicknesses. In cases where enclosing walls are detected, these walls are automatically generated to define the space. The centroid is computed as the midpoint of the defined rectangular boundary, where a Revit room and its corresponding tag are created. If the room is irregular (e.g.. occupying residual space within module), the constructor computes a minimum bounding rectangle for the available area and ensures that the computed center does not overlap with any pre-existing rooms. Similarly, rooms can be instantiated at the unit level, operating analogously to the module-based constructor but derives the geometric boundaries from the unit-level layout.
Secondly, a constructor allows direct specification of spatial parameters, i.c., central location, length, and width. In this case, boundary points are computed based on the provided dimensions and adjusted to accommodate construction details (c.g., wall offsets, wall detection, and wall creation).
In more dynamic scenarios, the class provides directional and corner-based constructors. The directional constructor places a room along a specified cardinal direction (i.e., north, south, east, west) relative to a given module or unit. Boundary points are calculated according to the direction and spatial extent, and walls are generated accordingly. If an laen-l flag enabled, certain walls are omitted to enable spatial continuity. Similarly, the corner-based constructor enables placement in specific quadrant (i.e., southeast, southwest, northwest, or northeast), supporting directional offsets and optional open layouts via selective wall removal.
22

---

Additionally, room can be instantiated adjacent to existing room. This adjacency- aware construe- tor aligns the new room specified direction relative the reference room, computing boundaries based on alignment, offset, and dimension constraints. As with other constructors, it supports both enclosed and open configurations through wall manipulation.
Beyond initialization, the Room class also provides utility methods for querying, computing, and modifying its spatial and semantic attributes.
B.4 Utils class
The Utils class provides a comprehensive set of utility functions tailored for managing and manipulat- ing Revit elements (c.g., walls, floors, and doors) and supports a variety of advanced operations for modules (e.g., module splitting, merging, and structural modifications). Serving as a centralized utility layer, this class streamlines geometric calculations, element creation, and spatial transformations in Revit document.
Conversion utilities To address unit inconsistency between Revit (which uses feet as the standard unit) and architectural design data (typically in millimeters), the class provides conversion func- tions Foot2mm and Mm2foot, ensuring consistent unit handling across all geometric and placement operations.
Geometry calculations range of geometric utilities is included for spatial reasoning. Functions such as MidPointForLine, MidPointForRectangge. and MidPointForWal calculate midpoints for various shapes, supporting tasks like element alignment and central placement. PointInRectangle determines whether given point lies within rectangle defined by four corners, which is essential for containment checks and spatial validation.
Wall management The CreateWall function constructs wall between two 2D points (in UV coordinates), ensuring it is noom-buunding and conforms to a designated wall type. Deletion methods include Delete Willeteeeelliinoiiiiiii based wall removal. Retrieval methods such as Ger BerWallyTTwoPinngg and BerAl/WallsByTwoPeee offer querying of existing walls based boundary conditions. Additionally, GivenPoints removes short or malformed walls, preserving geometric consistency for downstream tasks.
and Delete WallGiven Wall, supporting both point-based and object-
Contour and boundary management Higher-order geometric utilities are designed for contour and boundary manipulation, serving as crucial parts MBI. generatio and rendering. Functions like Clockwise and FindNext reorder points into a clockwise sequence, ensuring consistent boundary definitions for merged or modified modules. Simplification routines such as RemoveCollinear eliminate redundant or misaligned points to maintain structural clarity. Ger GeiWallPoints further adjusts boundary definitions to account for wall thickness and the nature of angles (concave convex), optimizing placement accuracy. To facilitate collision detection and placement validation, PointInWal and PointInOne Wall determine whether a point lies within a wall specific wall section. IsConcave identifies concave angles, which is crucial for handling irregular geometries during module generation and modification.
and CemmoeeNonParallePPoiii
Floor management Floor creation is supported via the CreateFloor method, which constructs floor based on four boundary points. It uses a default floor type under an identical family to ensure geometric closure for valid floor definitions.
Door and hole management Door and hole creation is essential for spatial connectivity in MBL designs, which are considered evaluative elements in our text BIM-based MBL generation task. CreateDoor inserts a door into specified wall location, handling alignment and structural adjustments. GoorteDooroorMonn
and Create extend this functionality by allowing directional placement and offset configuration within larger spatial contexts. These methods also support the specification of advanced door profiles, such as recessed or protruding forms. Simplified variants and GreuteDuorOnMidppee Forrooo ForRoom enable automatic door
like CreateDoord MororOmiioooooooooaaoo placement at wall midpoints. Openings (or holes) are created using CreateHole, which facilitates inter- module connections by defining voids (i.c., passageways) based on alignment and size parameters.
23

---

Table 4: Statistic on the token counts (including average, maximum, and minimum) for different
output types, i.e., code with named arguments, positional arguments, and coordinate.
No. of token
Output type
Avg.
Max.
Min.
Code w/ named argument
506.9
1,444
111
Code w/ positional argument
362.6
1,060
77
Coordinate
315.3
841
95
Table 5: Statistic across different splits the average number of tokens and sentences in descriptions and code snippets (with named arguments), as well as the average counts of MBL components, including modules, units, rooms, and elements (doors and holes).
Description
Code
MBL. component
Split
Scnt.
Token
Sent.
Token
Module
Unit
Room
Element
Train
5.7
225.0
13.2
506.9
2.8
1.1
4.3
4.5
Dev
5.6
221.0
12.7
492.4
2.5
1.1
4.5
4.3
Test
6.2
231.5
13.5
523.1
2.7
1.2
4.6
4.7
All
5.8
225.9
13.2
508.7
2.7
1.1
4.4
4.5
Advanced module operations In MBL design, there are advanced operations to manage modules, providing flexible and dynamic spatial configuration. MergeModules combines multiple modules into single module by removing internal walls and creating new boundary walls. Conversely, SplitModule divides a module into two smaller modules based on specified direction (i.e., north- south or west-east) and a ratio, offering dynamic mechanism for adaptive space planning.
B.5
Framework extension
In this study, we focus on modular building layouts composed of rectangular modules, a design choice motivated by prevailing practices in the architecture, engineering, and construction (AEC) industry. The adoption of rectangular modules aligns with the principles of industrialized construction, particularly design for manufacturing and assembly (DfMA) and efficient transportation logistics, which are critical drivers in contemporary modular construction. Consequently, both our methodology and accompanying codebase optimized for buildings assembled from rectangular modules, reflecting the predominant approach in woald projects.
Despite this specific focus, our system is designed to be readily extensible to accommodate a broader range of modular geometries. The code architecture is developed with the principle of low coupling and high cohesion, whereby each class and function encapsulates a well-defined responsibility. This modular architecture enables straightforward extension: for example, although the current Module and Utils classes are tailored to rectangular modules, the architecture supports the seamless integration of additional geometric representations. Non-rectilinear modules, such as those with polygonal or curved shapes, can be incorporated by subelassing the existing Module class (e.g., creating Modygo or CurvedModule subclasses) and implementing the necessary geometric methods (such PointInPolygon These extensions can introduce new descriptors and functionalities without disrupting the integrity of the existing rectangular module implementation, thus ensuring both robustness and future adaptability.
C Detailed data statisties
This section provides more detailed statistics of the data used.
In current progress, we only consider four primary living room, bedroom, bathroom, and kitchen. With the flexible code architecture, additional room types can be easily incorporated needed for future applications.
types commonly found in MBL designs:
Table 4 displays the token statistics for different output types, including code and coordinate formats. The coordinate outputs, which encode bounding box information, result in comparatively shorter

---

Table 6: Statistics on average sentence and token counts for code, along with the average number of MBL components, the original training set and the fully synthetic data.
Code
MBL component
Source
Sent.
Token
Module
Unit
Room
Element
Original
13.2
506.9
2.8
1.1
4.3
4.5
Full
13.8
574.3
3.0
1.7
5.2
3.3
Table 7: Statistic token counts (including average, maximum, and minimum) for descriptions in original training set and synthetic data, using template- and model-based approaches both partially and fully synthetic settings.
Source
Avg.
Max.
Min.
Original
225.0
605
40
Partial (template-hasee)
254.5
712
45
Partial mmddll-based)
203.6
482
64
Full (template-basee) bbsed)
322.0
1,038
24
Full (model-based)
352.1
1,031
46
sequences. In contrast, the code outputs encapsulate more detailed semantic and structural information through arguments, providing more necessary details for figh-fidelity BIM model generation.
The statistics for the different dataset splits presented in Table 5.
Table 6 provides the comparison between ground truth code and generated code the fully synthetic setting.
The statistical comparison of token counts between the original training data and the synthetic data is illustrated in Table 7. The analysis encompasses both template- and model-based generation approaches under partially and fully synthetic settings. In the partially synthetic setting, the generated textual descriptions closely align with the original data in terms of length, reflecting the constraints imposed by the real input. In contrast, fully synthetic data exhibits significantly longer token sequences, which can be attributed to the increased variability and verbosity introduced by randomly generated code.
D Experimental details
To ensure computational feasibility within our hardware constraints, we employed Low-Rank Adapta- tion (LoRA) [16] for fine-tuning. All linear transformations in the model, including the query-, key-, value-, output-, gate-, up- and nown-projection matrices, were equipped with LoRA adapters. The model operated with a maximum input and output length of 800 and 1,600 tokens, and computations were performed using 16-bit BrainFloat precision. Fine-tuning was conducted using learning rate of 3e-4 and batch size of 2; to effectively simulate batch size of 4, gradient accumulation over 2 steps was applied. Training proceeded for epochs, and model selection was based on the highest evaluation scores observed models and loU was used for coordinate-drives models. LoRA-specific hyperparameters were set with rank of 64, a scaling factor (alpha) of 64, and an adapter dropout rate of 0.1. During generation after fine-tuning, the model was restricted to producing at most 1,600 new tokens, utilizing greedy decoding. All experiments were performed on server equipped with four NVIDIA GeForce RTX 4090 GPUs and a 64-core Intel Xeon Platinum 8370C CPU operating at 2.80 GHz.
the development set, where argument Fl was used for code-driven
E Model selection and argument types
This section evaluates model performance across different model series and argument types. From the results summarized in Table 8, two key observations emerge.
Firstly, across different model series, though pretrained on extensive code corpora, the coder series performed comparable to their vanilla counterparts in this code generation task. In contrast, the math
25

---

Table 8: Results across executable validity, semantic fidelity, and geometric consistency using different models and various argument types.
Model
Compile (%)
Pass (%)
Instance F1 (%)
Argument Fl (%)
IoU (%)
Qwen2.5-
0.5B
Named
98.25
45.50
87.96
93.33
90.51
0.5B
Positional
99.00
49.25
89.28
93.66
93,02
1.5B
Named
92.00
63.25
92.56
95.86
95.71
1.5B
Positional
98.75
62.25
91.91
96.08
91.65
3B
Named
96.50
73.25
94.05
96.03
95.79
3B
Positional
98.75
71.75
93.98
96.35
95.87
7B
Named
95.75
78.25
95.53
97.41
96.07
Positional
99.5
76.00
94.96
97.48
95.83
Qwen2.5-Codee Instruct
0.5B Named
95.00
49.00
88.12
93.80
89.07
Positional
99.50
47.50
87.59
93.82
1.5B Named
96.25
65.00
92.34
95.69
95.45
1.5B Positional
98.25
60.75
91.16
95.65
94.19
3B
Named
94.00
69.50
94.11
97.11
95,06
Positional
99.00
72.00
93.92
97.42
95.62
7B
Named
96.5
77.50
95.01
96.96
97.65
7B
Positional
99.00
79.25
94.81
96.58
98.43
Qwen-2.5-Math- Instssruuu
1.5B Named
97.50
59.75
91.68
95.4
94.08
1.5B Positional
97.25
53.25
90.19
94.69
94.18
7B Named
96.75
70.25
93.40
96.45
96.26
7B Positional
99.50
68.50
92.42
95.94
94.86
Table 9: Performance (%) of results delivered by the ChatGPT API using gpt-4. 1-mini and gpt-4. 1.
Instance F1 (%)
Argument F1 (%)
Output type
Compile (%)
Pass (%)
IoU (%)
ChatGPT (gpt-4.1-mini)
Code w/ named argument Code w/ positional argument Coordinate
90.00
6.25 3.75
68.89 68.33
83.62 84.37
88.40
93.75
94.80
27.06
ChatGPT (gpt-4.1)
Code w/ named argument Code w/ positional argument Coordinate
97.50
22.50
78.54
90.49
90.03
93.75
23.75
76.67
88.52
88.95
29.94
series, while exhibited strong performance in mathematical reasoning tasks, lagged behind in this fine-grained specialized code generation context. Furthermore, for all model types, performance generally improved with larger model scales, highlighting the advantage of increased capacity.
Second, when considering argument type effect, positional arguments yielded higher compile rate across models, likely due to their shorter token lengths and syntactic simplicity. However, for other metrics, both argument types demonstrate comparable performance.
F Performance of proprietary models
Proprietary large language models have become increasingly accessible and are often deployed as co-pilots for practical tasks. To assess their applicability, we evaluated two representative proprietary models, i.e., apt-4.1-min and g,t-4.1, on the MBL. generation task, using code and coordinates as outputs, respectively. The specific prompts used for this evaluation refer Appendix J.
26

---

Table 10: Evaluation on combinations of various numbers of modules, units, and rooms. Case counts are indicated in parentheses. Qwen2.5-Coder-3B was fine-tuned output code with positional arguments.
Instance FI (%)
Argument Fl (%)
Module IoU (%)
Unit IoU (%)
Room IoU (%)
Number
Pass
IoU (%)
Module
All (80)
72.00
93.92
97.42
95.62
97.69
96.09
93.56
<2 (38)
79.47
92.72
96,49
95.79
99,43
96.23
93.36
>2 (42)
65.24
94.61
97.95
95.56
96.57
96.14
93.95
Unit
All (80)
72.00
93.92
97.42
95,62
97.69
96.09
93.56
(64)
77.50
96.61
98.73
97.22
97.37
97.29
97.00
(16)
50.00
85.16
93.02
92.33
93.66
88.07
Room
All (80)
72.00
93.92
97.42
95.62
97.69
96.09
93.56
<4 (32)
79.38
90.58
94.98
94.10
99.26
94.58
90.47
>4 (48)
67.08
95.17
98.29
97.01
97.01
96.84
95.25
Table 11: Evaluation on combinations of various numbers of modules, units, and rooms. Case counts are indicated in parentheses. Qwen2.5-Coder-3. was fine-tuned to output coordinate sequences.
Number
IoU (%)
Module IoU (%)
Unit IoU (%)
Room IoU (%)
Module
All (80)
81.94
87.87
87.99
72.63
<2 (38)
87.51
99.66
97.85
75.32
>2 (42)
78.21
81.84
82.67
70.07
Unit
(80)
81.94
87.87
87.99
72.63
(64)
83.84
85.65
87.06
78.88
2 (16)
78.03
94.88
90.19
63.78
Room
All (80)
81.94
87.87
87.99
72.63
<4 (32)
87.11
99.54
97.33
74.44
> 4 (48)
79.98
84.02
85.11
71.84
As shown in Table 9, although the model rarely produces fully correct code, it demonstrates strong ability to extract accurate information from unstructured text inputs, particularly with respect to geometric details. Notably, the generation of coordinate sequences remains significant challenge, suggesting that precise spatial reasoning continues to limitation for current proprietary models in design-related domains.
G Effect of the number of modules, units, and rooms
In this section, group MBL designs based on the numbers of constituent components, i.c., modules, units, and rooms, to assess the impact of component numbers. More components generally correspond to more complicated spatial arrangement, thus raising task difficulty. Each group was formed to ensure both comparative diversity and sufficient sample size.
Table 10 displays the performance when code is used as the output format. As the number of compo- nents increased, we observe a general decline pass rates, reflecting the heightened difficulty of generating syntactically and semantically correct code in more complex MBI. scenarios. For modules and rooms, other evaluation metries remained relatively stable even exhibited improvements. This suggests that the designed code architecture effectively captures MBL design principles, reducing the
27

---

Application Layer
User interface
3D view
2D view
Processing Layer
Template-
Syntas correction
amandment
Genersted code
Compile check
cheek
Model Layer
Fine-tuned langunge model
Generated code
Figure 8: The flow diagram of applying Tex12MBL in BIM.
burden on models to reason about each component in isolation. These results highlight the strength of the TeX framework in shifting the challenge from low-level spatial reasoning to high-level semantic understanding.
The performance trend observed for units, however, is less straightforward. Since the unit is an intermediate concept between module and room, and the maximum number of units in the test set limited to two, it does not reliably indicate overall layout complexity. In fact, designs with one unit contain an average 2.8 modules and 4.3 rooms, whereas those with two units include 2.3 modules and 5.6 rooms. Consequently. Module IoU is lower for designs with one unit, while Room IoU is higher, reflecting the subtle trade-off's in layout composition.
Similarly, Table reports the results with coordinate sequences as the output format. In contrast to the code-based representation, performance dropped more sharply the number of modules and rooms increased. This is expected, as coordinate- based outputs relied on independently inferring component coordinates, making harder for models generalize across complex scenarios. Results for different unit groupings were consistent with those observed in Table 10. The steeper performance drop compared with code output further validates the superiority the proposed Text2MBL framework.
H Application and deployment
The application and deployment of the proposed Text2MBL are depicted in Fig. 8, which comprises three interconnected layers: the model layer, the processing layer, and the application layer.
At the top, the application layer provides expressed in natural language. These requirements are ultimately translated into BIM-based MBLs, enabling direct user interaction with the design process.
interface through which design requirements be
At the foundation lies the model layer, responsible for fine- ene-tuning language models to produce domain-speciffe code. This code is designed to be executable within BIM environments, facilitating the automated generation of initial MBLs in the early design phase the construction workflow. However, discussed in Section 4.3, the raw code generated by the model may occasionally contain emrors that impede successful rendering.
To address this, processing layer is introduced between the model and application layers, functioning as a post-generation refinement stage. This layer ensures compatibility and correctness through two-step validation process: compile check and pass check, both grounded in the code architecture formalized in Section B. Fach class and function the generated code adheres a predefined schema, allowing automated detection and correction of syntax- errors during the compile check.
28

---

19% 20th
12h
Figure 9: Application of synthetic data with varying numbers (in the partially synthetic setting) and ratios (in the fully synthetic setting), using 3-Coder-3B with positional arguments.
100
80
90
60
Coeqlia
80
Canplle
Pin nac
Incance (10
Inkinee
lnvamee
Aguuran TT
Atpuras 71
60
origin
orgile
origin
sugmentstion 10% original data
augmenntation 200 original data
sugmentition 40% original data
100
95
95
90
90
Pan nae
80
85
Italace
8.5
Invamee 20.00
Arpanee (S)
Aspunee (1 Extl
Tall (4)
70
75
origin
orggia
origin
sugmentstion 60% original data
mugmentation 800% original data
mugmentation
100% original data
Figure 10: Performance with nx augmentation with partially synthetic conplate-derived data on x of the original data, using Qwen2.5 5ven2.5-Codder313 with positional arguments.
For the pass check, templates and default parameter values are leveraged to repair semantically incomplete or incorrect code segments, ensuring that the final output is executable. The feasibility is demonstrated by strong compile rate and information extraction metrics. The compile rate reflects the system's ability to successfully execute code and generate BIM models. Minor errors that arise during instruction interpretation can often be resolved through compile check, supporting iterative refinement. Meanwhile, information extraction metrics evaluate the system's 's capability to accurately identify key parameters and capture the intended structure of MBLs within BIM. High performance on both metrics suggests that the system is well-suited for initial deployment in practical settings.
After processing, the refined code is executed and deployed in BIM environments construct MBLs, which users can further review and customize as needed.
I Performance of synthetic generated data and augmentation scale
To enrich the training data for MBL generation, we adopt a synthetic data generation strategy. In the partially synthetic setting, we augmented the original training set by generating ten textual descriptions for each available code sequence. In the fully synthetic setting, we constructed code sequences from scratch, which are then converted into corresponding textual descriptions. Both settings were implemented with remplate-based approach (by using predefined templates to constitute

---

100
100
80
60
80
ferawa (1
Aspanea F100
(1
40
70
Canalk nic Di
20
Af fall (4))
fecance 21 2h0
40
60
origin
orgin
origin
sugmentition
10% original
augmenttation original data
augmentation 40% original
100
100
90
85
Asgicaon (7)
Eall
80
lall
70
75
70
origin
orggin
origin
2
augmentittin 60% original
augmentattion
original data
niggmentttion 100% original data
Figure 11: Performance with nx augmentation with partially synthetic model-generatie data x% of the original data, using Qwen2.5-Coder-33 with positional arguments.
textual descriptions) and model-based approach (by utilizing ChatGPT via gpt-4.1-minn to produce natural language descriptions).
We first evaluated on the ground truth test set using solely synthetic training data. As shown in Fig. 9, training exclusively on synthetic data led suboptimal performance. Although the information extraction ability exhibited relatively strong, the pass rate, which directly reflects code generation quality, was notably low. Among the synthetic strategies, the model- -ased approach yielded higher performance than the template- based one, due to its more fluent and diverse language. However, overall performance remains unsatisfactory. We attribute this discrepancy to the rigid and repetitive description logic of synthetic descriptions, limiting models ability to generalize beyond seen patterns. Despite being constructed entirely from fabricated code, the fully synthetic dataset achieved performance comparable to that of the partially synthetic counterpart. This result suggests that well designed synthetic data, even when entirely artificial, can support model training to some extent.
We then assess the effect of different augmentation scales using synthetic data under partially synthetic and fully synthetic settings using template- and model-based approaches. The results of utilizing partially synthetic complate-drrvee data, partially synthetic model-genee godel-ggnerated data, fully synthetic template-derived data, and fully synthetic model-generated data are presented in Fig. 10, Fig. 11, Fig. 12, Fig. 13, respectively.
These four tables reveal that, in low-resource scenarios, incorporating synthetic data markedly boosted model performance across all evaluation metrics, highlighting the utility of synthetic data as valuable supplement when real-world training data is limited in MBL design contexts. As the proportion of original data increased, most metries (i.e., compile rate, instance FI, argument Fl, and IoU) remained stable in a high level. However, the pass rate lagged behind other metrics and obtained continuous improvements with synthetic data, implying that it is more challenging criterion and may require more sophisticated strategies for further improvement. Moreover, when the proportion of original data reached moderate to high levels (e.g., 60% to 100%), further scaling of synthetic data (e.g., with scale factors of 4 or 5) yields diminishing or even negative returns. This saturation effect suggests that excessive synthetic augmentation may introduce redundancy or noise, which can undermine the benefits of additional training data.
30

---

Prompts used
In this section, we provide the prompts utilized in our study.
J.1 Prompts used for the direct use of proprietary models
To fully leverage the capabilities of proprietary models (i.e., gpt-4.1-min) in our implementation), we designed structured prompts tailored to each task. Each prompt begins with high-level task descrip- tion to guide the model's understanding, followed by task-specific contextual information (e.g., core classes and functions within the code architecture). We then specify detailed task requirements and include illustrative examples to further constrain the model's output space and promote consistency, The actual input is appended the end of the prompt to trigger the desired generation behavior.
Figure 14, 15, and 16 depict the prompt templates used for three tasks: synthetic data generation (i.e., translating source code into textual descriptions). code generation (i.e., producing BIM code from textual descriptions). and coordinate generation (i.e., inferring spatial coordinate sequences from textual descriptions), respectively. During synthetic data generation, the temperature to encourage output diversity. For code and coordinate generation, the temperature was set to 0 for deterministic decoding.
to 0.5
J.2 Prompts used for fine-tuning large language models
During fin-tuning, we employed straightforward instruction prompt to guide the model: Please transform the given description into code- aade-immlemeeted modular building layout.
31

---

50
90
80
80
(1.0%
(19))
60
20
40
60
origin
ongin
origin
Rugmsentiaion 10% original
sugmentiation original data
sugmentation 40%
100
100
95
90
(1
8.5
larawa (6)
(11
Exll
80
75
75
origin
origln
origin
2
sugmentition 60% original
augmentattinn original data
sugmentitiin 100% original data
Figure 12:
Performance with augmentation with fully synthetic template-derived data 2% of the original data, using Qwen2.5-Coder-B3 with positional arguments.
100
80
Aquasen
40
70
20
40
60
origin
orgiin
origin
2
augmentition
10% original
augmentatiinn odginal data
aigmentition 40% original
100
100
95
90
Coup
85
lell
50
75
origin
orggin
origin
2
sugmentition 600% original data
augmentatiion odiginal data
augienntttion 100% original datz
Figure 13: Performance with augmentation with fully synthetic model-generated data 2% of the original data, using Qwen2.5-Coder-3B with positional arguments.
32

---

Prompt synthetic data generation
Overviow
You are tasked with generating textual descriptions for Modular Building Layout (MBL) designs derived from Ci- Revit API Acting interface layer, your role interpret the exccutable code produce clear, structured, and semantically accurate descriptions.
# Core Classes and Functions
H# Module Class Represents
physical design document.
** *Coestructors:*
"csharp
Introduction
##t Unit Class
Organizes collections modules an MBL. design.
document, representing self-contained dwelling space
**Constructors:**
"ssaarp
Inproduction to constructory
Room Class
Represents functional modules units within Revit documentt.
*Coonstrictors:*
'shaarp
Introduction constractony
Utils Class
Provides advanced operations for modifying and enhancing MBL MBL. designs.
* **Functions:*** **
"ssharp
Introduction to functions
Task Requirements
1. Analyse the provided
carefully generate coreesooning textual descriptions
2. You reatrange the description logic, but be maintain the bicrarchical containment constraints: each unit
must be fully enclosed within a union of one or more modules and each room must be nested within specific unit
3. During generation,
employ diverse vocabulary and 4. Only ouipet the textual deseription;
enhance variation
include any explanations comments, additional
Exampies Implementations
Phinee domonstrattonns
Input Code
Input
Figure 14: prompt used for using the proprietary model synthetic data generation.
33

---

Prompt for code generation
Overview
You tasked with generating oode Modular Ruilding Layout (MHL) design Revit based textual descriptions. As specialist with exportise in both archilectural modular design and Revit API programming, you will translate descriptions exocutable code using provided framework.
Functions
Module
Represents fundamental physical cell in MBL design within Revit document.
**Coostructers:*
" "cshasp
Introduction to constructory
Organizes collections of modulles and rooms within Revit document, representing self-contained dwelling in MBL design.
""Coostriccoor.**
"csharp
Introduction
All Room Class
Represents functional spaces in modules units within Revä document.
*"Constrictors.*
"ssharp
to constructory
All Utils Class
advanced operations modifying enhancing designs.
"Functionn:
csharr
Introduction to finctions
Task Requirements
1. Analyvc the provided textual deseription of'a building layoul
2. Generate valid cods implementing the described MBL design using framowork above
3. Ensure code comrctness and acherence the provided API
4. Follow a systematic approach similar to the provided examples
5. Only output the CF code; do not include explarations, commenis, additional text
Examples Implementations
Tiree demonstrations
Input Textual Description
Figure 15: prompt used for using the proprictary model in code generation.
Prompt for coordinate generation
# Overview
You lasked with generating precise spotial coorditates components (i.c., modules, units, rooms) Modular Building Layout (MDL) designs based on textual descriptions, As specialist with expertise in architectural modular design, you will
descriptions coordinate sequences.
Tiik Requirements
Analyze the provided description building layout
2. Generate coordinates each component (ie, module, unit, and room) for the description
3. Follow a systematic approuch similar to the provided examples
4. Only output the coordinate sequence, do not include any explanations, comments, addirional text
# Examples Implementations
Three demonsirations
Input Textual Description Impur
Figure 16: prompt used for using the proprietary model coordinate generation.
34


Reviews:
[{"review_id": "ueYDMVJLH8", "reviewer": "Reviewer_HG8y", "summary": "This paper proposes a framework called Text2MBL, which aims to directly generate executable Building Information Modeling (BIM) code from textual descriptions of modular building layout (MBL) design. The framework leverages an object-oriented code architecture to address the unique challenges posed by the three-tiered hierarchical structure of MBLs (modules, units, and rooms), which traditional 2D layout generation methods struggle to handle. To train and evaluate Text2MBL, the authors created a dataset consisting of paired real-world modular housing project descriptions and BIM layouts, and fine-tuned large language models (from the Qwen2.5 family) to output structured action sequences in code.", "questions": "1. Based on the examples provided (e.g., the rectangular modules in Figure 1 and Table 1) and the descriptions of the Module class (e.g., `rectangular geometry`)  and Utils class (e.g., `MidPointForRectangle`, `PointInRectangle`) in Appendix B, the system appears primarily designed for regular geometric shapes such as rectangles. However, real-world architectural designs often include irregular geometries (e.g., curved walls or polygonal modules). Can the current system handle such non-rectilinear geometries? If not, how extensible is the current code architecture to support more complex geometric forms?\n2. How can the input burden be lowered to support more natural and conceptual language? The introduction states that the use of text is intended to “facilitate more intuitive and accessible user interaction,” but the current framework (as shown in Figure 1) requires very specific geometric and spatial inputs. Can the model understand more abstract or high-level descriptions, such as “create a spacious living room connected to a kitchen”? If not, how might the system be extended in this direction?\n3. The \"Text2BMI\" in L49 is confusing.", "limitations": "yes", "rating": 4, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 2, "originality": 2, "strengths_and_weaknesses": "Strengths:\n\n1. The unique “module-unit-room” hierarchy of MBLs introduces structural constraints and complexity. Text2MBL explicitly targets these issues through its tailored design.\n2.  The paper builds a dataset based on real-world modular housing projects, pairing textual descriptions with BIM code. To mitigate data scarcity, both partially and fully synthetic data generation strategies are adopted.\n\nWeaknesses: \n\n1. The paper fails to compare with key related methods, especially **Text2BIM**. It is unclear how Text2MBL extends, improves upon, or addresses challenges not solved by Text2BIM (such as MBL’s inherent hierarchy and constraints).\n2. As shown in Figure 1, the current framework requires users to specify highly detailed spatial parameters—such as precise module dimensions (length, width), door positions (e.g., on the south wall, 2950mm from the west side), and alignment configurations (e.g., south wall, 2950mm from the west side). Requires very specific and detailed input, which will not be the preferred form of input for actual users.\n3. Although the authors fine-tune multiple variants from the Qwen2.5 family and briefly mention GPT-4.1-mini in the appendix, the paper lacks a more systematic comparison of different large language models on the proposed task.\n4. While the introduction explicitly states that “design decision-making is no longer designer-exclusive but user-inclusive” (line 27) and that textual descriptions are intended to “facilitate more intuitive and accessible user interaction” (line 28), the paper includes no user study or usability evaluation (e.g., user satisfaction, interaction efficiency). The Discussion section (Section 5) relegates user-centered evaluation to future work, creating a disconnect between the paper’s stated motivation and its actual methodology.", "was_revised": true, "final_justification": "Thanks for the detailed responses and additional experimental results, which have addressed most of my concerns. Therefore, I raised my rating to borderline accept.", "rebuttal": "We feel great thanks to the reviewer’s professional and constructive comments. We have carefully summarized the valuable weaknesses and questions identified by the reviewer into the following five areas: (1) level of user interaction detail, (2) method comparison and improvement, (3) motivation and conceptualization, (4) framework extension, and (5) typo rectification.\n\nTo enhance understanding, we address each area separately, providing a thorough explanation of the modifications made.\n\n**1 Level of user interaction detail (W2 and Q2):**\n\nOur current framework is grounded in the paradigm of parametric design, wherein the manipulation of explicit spatial and geometric parameters is standard practice during the architectural and structural design phases. This approach is consistent with prior works on floorplan generation from textual descriptions [1], which similarly utilize precise input. Based on this, our work can provide a robust BIM foundation for subsequent stages in the lifecycle of modular buildings—a capability that necessitates detailed and unambiguous specification of components. Therefore, our evaluation emphasizes metrics related to exact code execution and the accuracy of information extraction, ensuring the practical applicability.\n\nWe acknowledge, as the reviewer notes, that other approaches focus on high-level room layout or furniture configuration (e.g., through retrieval mechanisms) using more general or abstract user input [2, 3, 4]. However, our current scope remains on parametric design, which we believe is essential for ensuring downstream BIM usability and compliance with industrialized construction standards. We agree that future design tools should integrate both paradigms, and we view our contribution as a foundational step toward this broader goal.\n\nTo address the reviewer’s question regarding support for more abstract or conceptual descriptions, we conducted additional experiments to evaluate the framework’s generalization capability. Specifically, we tested the system on vague and high-level instructions (e.g., “Generate a layout with x module, x unit, x living room, x bathroom, x bedroom, x kitchen”). We report the compile rates (i.e., the successful generation of executable code) and extraction F1 scores (measuring the accurate extraction and mention of modules, units, and rooms).\n\n|Model and output|Compile|F1|\n|-|-|-|\n|Qwen2.5-Coder-3B|||\n|Name|68.75|99.05|\n|Position|45|98.36|\n|Qwen2.5-Coder-7B|||\n|Name|92.5|100|\n|Position|95|99.53|\n|Gpt-4.1-mini|||\n|Name|81.25|92.91|\n|Position|78.75|91.96|\n|Gpt-4.1|||\n|Name|87.5|96.11|\n|Position|82.5|94.58|\n\nThese results demonstrate initial generalization capabilities of language models trained and further validate the applicability of our framework. We agree with the reviewer that lowering the input burden to support more natural and conceptual language is an important direction for future work. Achieving this will likely require (1) improved input/output modeling at varying granularity, (2) curriculum learning strategies, and (3) systematic user studies to evaluate usability. We are actively exploring these avenues and consider them a priority for future research.\n\nIn response to the valuable feedback, we will make the following revisions in our final version. We will first clearly articulate the intention and scope of our work. Then, we will incorporate additional generalization experiments in the Experimental section. The implications of them will be discussed in the Discussion section.\n\n[1] Leng et al., Tell2design: A dataset for language-guided floor plan generation, ACL 2023\n[2] Yang et al., Llplace: The 3d indoor scene layout generation and editing via large language model, 2024\n[3] Fu et al., AnyHome: Open-Vocabulary Generation of Structured and Textured 3D Homes, ECCV 2024\n[4] Aguina-Kang et al., Open-Universe Indoor Scene Generation using LLM Program Synthesis and Uncurated Object Databases, 2024\n\n**2 Method comparison and improvement (W1 and W3):**\n\nWe appreciate the reviewer’s emphasis on the need for a thorough comparison. Text2MBL introduces a new paradigm by encapsulating design details within structured code, exposing only function and class interfaces. This enables a code generation approach that inherently captures the hierarchical and constraint-based nature of BIM-based MBL, which is a core challenge in parametric design. In contrast, Text2BIM adopts a coordinate-driven method, directly generating geometric coordinates without modeling deeper design semantics or structural constraints present in MBL, as compared in our manuscript. As discussed in the manuscript, this limitation often necessitates extensive post-processing and human intervention when adapting such outputs to BIM workflows, e.g., careful management of component sequencing and resolving geometric overlaps or inconsistencies. By comparison, Text2MBL produces outputs that are immediately compatible with BIM environments and can be seamlessly integrated into real-world design workflows, significantly reducing the need for additional processing and facilitating practical deployment during the design phase. In our work, we omit naming specific coordinate-driven methods (e.g., Text2BIM or Tell2Design) in experimental comparisons to highlight the fundamental paradigm difference between coordinate- and code-based approaches.\n\nWe acknowledge the reviewer’s suggestion for a more comprehensive evaluation of different LLMs. In response, we have expanded our experiments to include more models. The comparative results are summarized in the table below:\n\n|Model and output|Compile|Pass|Instance F1|Argument F1|IoU|\n|-|-|-|-|-|-|\n|Gpt-4.1-mini||||||\n|Name|90|6.25|68.89|83.62|88.4|\n|Potision|93.75|3.75|68.33|84.37|94.8|\n|Coordinate|-|-|-|-|27.06|\n|Gpt-4.1||||||\n|Name|97.5|22.5|78.54|90.49|90.03|\n|Potision|93.75|23.75|76.67|88.52|88.95|\n|Coordinate|-|-|-|-|29.94|\n|Gemini-2.5-flash||||||\n|Name|95|21.25|73.58|83.49|84.81|\n|Potision|92.5|7.5|65.13|75.61|88.47|\n|Coordinate|-|-|-|-|23.94|\n|Gemini-2.5-pro||||||\n|Name|97.5|36.25|84.18|88.57|90.24|\n|Potision|98.75|35|84.95|92.02|93.86|\n|Coordinate|-|-|-|-|30.72|\n\nIn line with our preliminary findings, we observe that while the model seldom generates fully correct code, it exhibits a notable capacity to extract accurate information from unstructured textual inputs. However, generating correct coordinate sequences remains particularly challenging. This suggests that precise spatial reasoning and the reliable translation of geometric details continue to pose significant limitations for current proprietary models in this domain.\n\nTo address the points outlined above, we will thoroughly revise the Experiment section to provide a clearer distinction between the different paradigms employed. Additionally, we will expand Appendix F to present a more comprehensive set of results for various LLMs.\n\n**3 Motivation and conceptualization (W4):**\n\nOur study is situated within the paradigm of parametric design, where users provide detailed textual inputs specifying precise design requirements. Accordingly, our evaluation methodology primarily focuses on the accurate comprehension and execution of these instructions, measured through objective, quantitative metrics such as code correctness and information extraction accuracy.\n\nWe fully acknowledge that as the system evolves to handle more conceptual or ambiguous user inputs—such as general, natural language utterances—a comprehensive user study will become essential. Such studies would assess user satisfaction, interaction efficiency, and overall usability, providing a richer understanding of user experience in more open-ended scenarios. We agree that this is a critical direction, and as noted in Response 1, we have provided some extended experiments and identified it as important future work.\n\nIn response, we will revise and extend both the Introduction and Discussion sections to better clarify our motivation and elaborate on future research directions informed by our findings.\n\n**4 Framework extension (Q1):**\n\nOur work focuses on modular building layouts, where the modules are rectangular. This design choice aligns with emerging trends in the AEC sector, i.e., industrialized construction. Rectangular modules are favored due to principles such as design for manufacturing and assembly, as well as efficient transportation, which are key considerations in modular construction. As a result, our study and corresponding codebase are tailored to buildings composed of rectangular modules, which currently represent the majority of real-world modular construction projects.\n\nWe appreciate the reviewer’s interest in the generalizability of our system. The code architecture is developed with the principle of low coupling and high cohesion, ensuring that each class has a clear, distinct responsibility. Each class and function were completely implemented with full details to allow deployment and application. This separation of concerns facilitates extensibility. For instance, while the current Module and Utils classes focus on rectangular modules, our architecture allows for the integration of additional geometric representations. For non-rectilinear geometries (e.g., curved or polygonal modules), one could extend the Module class by introducing new subclasses (e.g., PolygonalModule or CurvedModule) and corresponding utility methods (e.g., PointInPolygon). These new classes can define their geometric descriptors and methods without interfering with the existing rectangular implementation.\n\nTo reflect the points raised above, inspired by the reviewer’s constructive suggestions, we will expand the method description section to provide a more detailed explanation of the potential extensions of our proposed framework.\n\n**5 Typo rectification (Q3):**\n\nWe have carefully re-examined the manuscript to ensure clarity and consistency throughout. For example, “Text2MBL” should be inserted as mentioned by the reviewer."}, {"review_id": "CKFgIDYmLi", "reviewer": "Reviewer_9xp5", "summary": "The authors propose Text2MBL, a text-to-code generation framework that translates natural language descriptions of modular building layouts (MBLs) into executable code for Building Information Modeling (BIM) systems. Addressing the unique challenges posed by MBLs (e.g., hierarchical structures, spatial relationships, and semantic complexity), the authors design a proof-of-concept implementation in Autodesk Revit. They curate a dataset of 198 MBL designs paired with multiple textual descriptions and code sequences, including both real and synthetic examples. Experiments with fine-tuned Qwen2.5 models show that the code-output approach outperforms coordinate-output baselines in terms of compile rate, semantic fidelity (F1 scores), and geometric consistency (IoU). Additional analyses demonstrate the benefit of synthetic data augmentation and the challenges associated with component complexity.", "questions": "- As a non-expert in the architecture and construction domains, I found myself wondering how representative the use of Autodesk Revit is for real-world applications. Given that previous works like Text2BIM employed Vectorworks, could the authors elaborate on what BIM tools are most widely adopted in industry? Specifically, what domain-specific languages or software platforms are considered essential or standard in BIM-based workflows?", "limitations": "No specific concern", "rating": 4, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "**Strengths**\n\n1. **Novel integration of BIM, code generation, and spatial design**: The paper introduces a new task and methodology for text-to-BIM code generation, which bridges natural language understanding and structured building architectural modeling.\n2. **Comprehensive system implementation and dataset curation**: The authors provide a full implementation in Autodesk Revit with detailed class designs and a paired dataset of real and synthetic MBLs, facilitating both reproducibility and future research.\n3. **Strong empirical results and insightful error analysis**: Across multiple metrics and model scales, the proposed code-driven generation method consistently outperforms coordinate-based baselines. The authors provide fine-grained error analysis and show effective use of synthetic data in low-resource scenarios.\n\n**Weaknesses**\n\n1. **Lack of external validation and user-centric evaluation**: The work would benefit from qualitative assessment by domain experts (e.g., architects, engineers) or user studies to evaluate the practical value of the generated outputs. Table 2 reports very high scores for top models—does this indicate that the benchmark is too easy and already saturated, or that the model is close to being deployable in real-world settings?\n2. **Insufficient discussion of related LLM-based design tools**: The paper briefly mentions works like Text2BIM and Tell2Design, but does not provide detailed comparisons. Additionally, recent research on LLM-guided scientific graphics generation, such as *AutomaTikZ* [A] and *DiagrammerGPT* [B], is highly relevant and should be discussed to position the contribution more clearly within the broader landscape of text-to-structured-design systems\n\n[A] Belouadi et al., AutomaTikZ: Text-Guided Synthesis of Scientific Vector Graphics with TikZ, ICLR 2024\n\n[B] Zala et al., DiagrammerGPT: Generating Open-Domain, Open-Platform Diagrams via LLM Planning, COLM 2024", "was_revised": true, "final_justification": "I have checked the rebuttal and other reviews, and I appreciate the authors' detailed response to my questions. The rebuttal content did not introduce sufficient content to change my evaluation, so I maintain my original rating.", "rebuttal": "We are grateful to the reviewer for the thoughtful and constructive review. We have carefully organized the corresponding concerns into the following three areas: (1) BIM tools and standards, (2) external validation and realistic deployment, and (3) insufficient discussions on related design approaches.\n\nTo ensure clarity, we have provided a point-by-point response to the comments, with detailed explanations of the revisions to be made.\n\n**1 BIM tools and standards (Q1):**\n\nWe appreciate the opportunity to clarify BIM tools and standards.\n\nThe architecture, engineering, and construction (AEC) industry employs a diverse ecosystem of BIM software, including Autodesk Revit and Vectorworks. Among these, Autodesk Revit is widely regarded as the representative software, particularly in medium to large-scale construction projects and in academic research on parametric and generative design workflows. However, with the proliferation of diverse software solutions, ensuring interoperability across these platforms for various stakeholders remains a challenge. To address this, buildingSMART developed the Industry Foundation Classes (IFC) standard, which serves as a platform-agnostic, open specification for representing and exchanging BIM data. IFC enables seamless communication and data exchange between tools, ensuring that a model authored in one software can be interpreted in another.\n\nIn this work, we selected Revit as the implementation environment for two reasons. First, Revit provides highly comprehensive and well-documented programmable APIs (primarily in C#), enabling researchers and developers to build robust and fine-grained extensions that operate as first-class citizens within BIM environment. This makes it particularly suitable for prototyping intelligent design agents and automation systems. Second, Revit offers seamless export capabilities to the IFC format, ensuring that any BIM models generated through our system can be readily imported into other IFC-compliant platforms. In this way, although our pipeline is demonstrated within Revit, the resulting models remain compatible with the broader BIM ecosystem.\n\nWhile previous studies, such as Text2BIM, utilized platforms like Vectorworks, our focus on Revit aligns with industry adoption patterns and enables deeper integration with parametric design tools (e.g., Dynamo) and advanced automation workflows. Moreover, the underlying methodology is conceptually transferable to other BIM tools that support programmable interaction and IFC export.\n\nAdditionally, we wish to clarify our design decisions regarding model representation. While IFC is indispensable for interoperability, it is verbose and semantically redundant, resulting in large file sizes and high token counts when parsed for downstream tasks such as natural language processing. Our code architecture significantly compresses BIM models into concise, encapsulated classes and functions. For example, representing an MBL with five modules, one unit, and six rooms requires 7503 lines (215607 tokens) in IFC, but only 20 lines (884 tokens) using our architecture, facilitating more efficient learning and reasoning with much more structured representations.\n\nWe acknowledge that we did not sufficiently elaborate on the motivations and backgrounds. In response to this valuable feedback, we will expand the Introduction and Background sections to provide a more comprehensive explanation of BIM tool adoption, standards, and our rationale for selecting Revit.\n\n**2 External validation and realistic deployment (W1):**\n\nOur current study focuses on text-based parametric design systems for BIM-based MBL, emphasizing the accurate parsing of detailed user instructions and the generation of structured code under multi-layered constraints (e.g., hierarchy, topology, semantics). As such, our evaluation has prioritized quantitative metrics to objectively measure the system’s ability to interpret user intent in executable code. Other related studies that employ qualitative evaluation often rely on broader, more conceptual inputs, which can lead to variations in the generated output depending on different potential parameters.\n\nWe acknowledge that we did not sufficiently address the generalization of our system to higher-level, more abstract user instructions. In response, we have conducted additional experiments in which the models were prompted with abstract specifications (e.g., “Generate a layout with x module, x unit, x living room, x bathroom, x bedroom, x kitchen”). We report both the compile rates (i.e., successful generation of executable code) and extraction F1 scores (measuring the accurate extraction and mention of modules, units, and rooms).\n\n|Model and output|Compile|F1|\n|-|-|-|\n|Qwen2.5-Coder-3B|||\n|Name|68.75|99.05|\n|Position|45|98.36|\n|Qwen2.5-Coder-7B|||\n|Name|92.5|100|\n|Position|95|99.53|\n|Gpt-4.1-mini|||\n|Name|81.25|92.91|\n|Position|78.75|91.96|\n|Gpt-4.1|||\n|Name|87.5|96.11|\n|Position|82.5|94.58|\n\nThese results demonstrate basic generalization from detailed to abstract instructions, yet sill warranting further investigation for smaller models (e.g., low compile rates for 3B models).\n\nRegarding real-world deployment and application, we focus on two primary aspects: compile rate and information extraction metrics. Compile rate reflects the system’s ability to successfully execute code and generate BIM models. Even if minor errors occur during instruction interpretation, these can often be rectified through multi-turn interactions, thus supporting iterative refinement. In contrast, information extraction metrics assess the system’s capacity to accurately identify key parameters and capture the intended structure of MBLs within BIM. High performance on both dimensions suggests that the system is suitable for initial deployment in practical settings. However, it is essential to note that this does not imply the problem is trivial or that the benchmark has been saturated; current pass rates remain low, even when provided with detailed instructions. Moreover, as previously discussed, robustly handling general or abstract user instructions remains an open challenge, underscoring the need for ongoing research to enhance the system’s comprehensiveness and reliability. Therefore, we recognize the importance of extending our framework in future work through: (1) Collaborating with architects and engineers to qualitatively assess generated outputs with diverse detail levels; (2) Conducting systematic studies to evaluate usability and user satisfaction across varying granularities; and (3) Developing curriculum learning strategies and improved input/output modeling to address the challenges of abstract instruction.\n\nIn response to this useful comment, we will revise the Experiment section to include new experimental results. We will also clarify the limitations of our current evaluation and explicitly outline future directions in the Discussion section.\n\n**3 Insufficient discussions on related design approaches (W2):**\n\nPrevious approaches, such as Text2BIM and Tell2Design, primarily employ coordinate-driven methods, where user instructions are mapped to spatial arrangements or explicit geometric coordinates [1, 2]. While Text2BIM focuses on general building design from conceptual natural language, Tell2Design generates floorplans using explicit spatial coordinates from detailed user inputs. In our study, we intentionally avoid referencing specific coordinate-driven approaches by name in experimental comparisons to emphasize the paradigm-level distinction between coordinate-centric and our high-level, programmatic representation based on our designed code architecture. However, we acknowledge that a more explicit discussion of these works would provide clearer context for our contributions.\n\nAutomaTikZ [3] utilizes TikZ as an intermediate representation for text-to-scientific-graphic generation, which conceptually aligns with our approach of using an intermediate, human-readable code architecture. In our work, we develop our own “TikZ,” a domain-specific programming interface with complete implementation tailored for BIM-based MBL. This interface encapsulates complex operations into abstract classes and functions, facilitating conditional language modeling with LLMs. While both AutomaTikZ and our system leverage code format as an intermediate form, our approach is distinct in its focus on parametric building design and BIM integration, considering multiple design constraints, as opposed to general scientific graphics.\n\nDiagrammerGPT [4] employs a two-stage pipeline comprising planning and generation for diagram synthesis. Our Text2MBL system similarly integrates a planning component, but this is embedded within the code architecture rather than separated as an explicit module. Consequently, the LLM outputs directly correspond to parametric design code with extracted parameters. We appreciate the reviewer’s suggestion and recognize that incorporating a dedicated planning stage could further generalize our system to broader or more abstract input scenarios as discussed in Response 2. We will discuss this as a promising direction for future work.\n\nWe sincerely thank the reviewer for these insightful suggestions, which are instrumental in more clearly positioning our work within the rapidly evolving field of text-to-structured design systems. In the final version, we will expand the Introduction and Background sections to explicitly discuss the similarities and distinctions between Text2MBL and other approaches.\n\n[1] Leng et al., Tell2design: A dataset for language-guided floor plan generation, ACL 2023\n[2] Du et al., Text2BIM: Generating building models using a large language model-based multi-agent framework, 2024\n[3] Belouadi et al., AutomaTikZ: Text-Guided Synthesis of Scientific Vector Graphics with TikZ, ICLR 2024\n[4] Zala et al., DiagrammerGPT: Generating Open-Domain, Open-Platform Diagrams via LLM Planning, COLM 2024"}, {"review_id": "fa2YZ89cqJ", "reviewer": "Reviewer_ZzJA", "summary": "Motivated by applications in user-inclusive design in construction workflow, this paper presents Text2MBL, a text-to-code generation framework that takes in textual description and generates executable Building Information Modeling (BIM) code for modular building layout (MBL) design. \n\nTo account for MBLs’ hierarchical three-tier structure (module, unit, and room), the authors design a specific object-oriented code structure and fine-tune LLMs to generate code of this structure. Specifically, the output takes the form of action sequences that when execuetd in BIM environment produce MBLs.\n\nTo fine-tune the LLM, data is curated from real-world housing projects, and synthetic data is shown to enhance peformance significantly when used for augmentation.\n\nText2MBL is shown to outperform conventional coordinate-based approaches in geometric consistency, and perform strongly on executable validity, semantic fidelity.", "questions": "- The only baseline is coordinate-based approach. Is this predominantly limited by the fact that few existing methods output BIM-based MBLs? Is it entirely unreasonable to compare with other text-to-floorplan methods (in aspects such as no missing entity, correct inter-entity relation, geometric consistency IoU, etc.)?\n- It is mentioned that critical factors such as element placement, clash avoidance, component order, and support for irregular geometries, are addressed by Text2MBL by “abstracting complex design operations into high-level interfaces” (line 223-224). What exactly does this mean?\n- The relationship between BIM and MBL is not explicitly explained. How does “BIM model” relate to “MBL” (line 102-103)? What is different about “BIM-based MBL” compared to standard MBL?  Also, for someone not familiar with the specific application domain, the use of “BIM” (without definition up front) in the introduction can be a source of confusion.", "limitations": "Yes.", "rating": 5, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 2, "strengths_and_weaknesses": "Quality\n- [Strength] The method used (synthetic data augmentation, code format, LLM finetuning)  is not particularly complex but is well grounded in the application and well supported by experimental result.\n- [Strength] Result analysis is comprehensive.\n- [Strength] There are multiple discussions of limitations.\n\nClarity\n- [Strength] The paper is generally well written, and a comprehensive appendix is provided.\n\nSignificance\n- [Strength] This work is clearly well grounded in application, and practitioners can likely benefit from it.\n- [Strength] Code and data are both released, and a functional plug-in is deployed on a representative BIM platform. Deployed as detailed in Appendix H.\n- [Weakness] The current model is not particularly expressive, which can be a topic of future work.\n\nOriginality\n- [Strength] The specific task, generating BIM-based MBL from text is underexplored, and this work proposes a new method that outperforms existing method.\n- [Weakness] There are lines of works in the vision community that tackeles the general text-to-scene task that are not mentioned as related works. For example, “AnyHome” generates house floorplan from text and eventually a detailed mesh, and “LLplace” and “Open-Universe Indoor Scene Generation using LLM Program Synthesis and Uncurated Object Databases” generate code or structured program for 1-room scene. Constraints for modular construction can likely be inserted by fine-tuning the LLM or modifying the prompt.\n- [Weakness] The high-level insight that code-driven approach is effective has been discussed in various works in the LLM community.", "was_revised": true, "final_justification": "I appreciate the authors’ thorough response to my questions and concerns and will maintain my rating of ‘accept’.", "rebuttal": "We would like to thank the reviewer for the insightful and constructive feedback. We have carefully extracted and categorized the valuable concerns into the following three areas: (1) concept confusion, (2) method comparison and performance, and (3) discussion on LLM-based design tools.\n\nFor ease of review, we have structured our response to correspond with each area, including thorough revision notes where applicable.\n\n**1 Concept confusion (Q2 and Q3):**\n\nWe recognize that the introduction of “BIM” and “BIM-based MBL” without a proper definition may confuse, especially for readers less familiar with the domain. We appreciate the opportunity to elaborate on these foundational aspects.\n\nBIM is a digital process for creating and managing rich, structured representations of a building’s physical and functional characteristics. Unlike traditional CAD drawings, which only capture geometric information, BIM integrates geometry, spatial relationships, material properties, and construction metadata into a parametric model. For example, in a BIM model, a “wall” is not just a line but an object with height, thickness, material type, thermal performance, and construction sequence attributes. BIM platforms allow designers to collaboratively develop models that are used across the lifecycle of a building—for design coordination, clash detection, scheduling, cost estimation, and facility management.\n\nWe focus on BIM due to its importance in industrialized construction, which emphasizes prefabrication and integrates manufacturing expertise. Modular construction represents a masterful synthesis, utilizing factory-made modules that are transported and assembled onsite. Consequently, lifecycle management for MBLs becomes more critical. BIM is undoubtedly the best choice for representation. Unlike standard MBLs, which may only define spatial configurations abstractly or on 2D plans, BIM-based MBLs are instantiated as parametric objects within BIM, allowing for more downstream applications.\n\nThe process of authoring BIM-based MBLs is significantly more complex than producing schematic MBLs. It requires precise element placement, avoidance of geometric clashes, consideration of component order, and support for irregular module geometries from module operations. These challenges are compounded by the hierarchical relationships among modules, units, and rooms. Current coordinate-driven approaches in MBL design are typically insufficient for these tasks, as they do not address the requirements inherent to BIM instantiation.\n\nTo address these challenges, Text2MBL abstracts complex design operations into high-level interfaces. Specifically, we have developed an architecture of classes and functions that encapsulate essential operations at a semantic level. By “abstracting complex design operations into high-level interfaces,” we mean that rather than relying on language models to generate low-level, step-by-step manipulations (which we found to be unreliable in our preliminary attempts), we provide a set of robust, reusable abstractions. For example, the operation of merging modules involves a sequence of geometric and semantic updates—removing internal walls, generating new boundaries, and validating against existing elements—which are encapsulated within dedicated functions, and only one interface is exposed. Similarly, the placement of an indented door requires calculations for positioning, wall modifications, and consistency checks, all of which are implemented within our codebase rather than delegated to language models.\n\nWe have adopted this approach after observing that LLMs currently struggle to generate accurate and executable code for these specialized BIM operations using BIM APIs, both because of the niche nature of BIM APIs and the need for precise geometric reasoning.\n\nWe appreciate the reviewer’s feedback and will revise the manuscript to define BIM and MBL clearly and to elaborate on the motivations for BIM-based MBLs in the Introduction and Background sections.\n\n**2 Method comparison and performance (W1 and Q1):**\n\nWe apologize for not clearly articulating the novelty and scope of our problem. Our work, to our knowledge, is the first to research BIM-based MBLs generation from textual instructions. Existing approaches in BIM community focused on generating BIM models using coordinate-based methods, without modeling the hierarchical, geometric, and semantic relationships inherent in MBLs. Most prior floorplan generation methods in vision community output images based on general user instructions, rather than detailed, parametric BIM representations with explicit hierarchical and semantic structures.\n\nWe agree with the reviewer that, in principle, it would be informative to compare our approach with other methods using metrics such as entity coverage and inter-entity relational correctness. However, we note that prior works typically target different outputs (e.g., images) and problem formulations, often with more general instructions and less parametric detail. Our focus is on parametric BIM design, where the generated outputs must satisfy strict code constraints and be executable within BIM. Accordingly, our evaluation has emphasized metrics such as code compile and pass rates, as well as information extraction scores for argument accuracy, which directly reflect the practical applicability of the generated BIM-based MBLs.\n\nThe reviewer’s insightful comment encouraged us to reflect more deeply. As user instructions grow more abstract, different evaluation metrics and baselines become necessary. This motivates us to explore further. We have added experiments where models were given abstract instructions (e.g., “Generate a layout with x module, x unit, x living room, x bathroom, x bedroom, x kitchen”). We report both the compile rates and extraction F1 scores (measuring the accurate extraction and mention of modules, units, and rooms).\n\n|Model and output|Compile|F1|\n|-|-|-|\n|Qwen2.5-Coder-3B|||\n|Name|68.75|99.05|\n|Position|45|98.36|\n|Qwen2.5-Coder-7B|||\n|Name|92.5|100|\n|Position|95|99.53|\n|Gpt-4.1-mini|||\n|Name|81.25|92.91|\n|Position|78.75|91.96|\n|Gpt-4.1|||\n|Name|87.5|96.11|\n|Position|82.5|94.58|\n\nThe new extraction F1 scores directly address entity coverage. While our main baseline remains the coordinate-based approach, as it is currently most relevant for BIM outputs in industry, we recognize the value of broader comparisons, especially as user instructions become more abstract and align closer to previous text-to-floorplan methods.\n\nRegarding model expressiveness, the relatively high compile rates and information extraction metrics suggest that the models are already suitable for initial BIM-based MBL generation in real-world settings. Improving the pass rates and enhancing the ability to handle more complex or general specifications is an important direction for future work.\n\nIn response to the thoughtful feedback, we will revise the Experiment section to clarify our definition, evaluation, and include new experiments. We will also update the Discussion section to address the potential for incorporating additional baselines and evaluation metrics as the field evolves, and as user instructions become more diverse and abstract.\n\n**3 Discussion on LLM-based design tools (W2 and W3):**\n\nWe appreciate the opportunity to clarify the distinctions from prior research, e.g., for scientific diagrams [1,2] and indoor scenes [3,4,5], which we regretfully did not sufficiently discuss.\n\nWhile these prior works have made substantial advances in text-to-scene design across various domains, our focus is specifically on architectural and structural design with an emphasis on parametric modeling, construction constraints, and seamless integration with BIM and MBL workflows. In contrast, much of the vision-based text-to-scene generation literature focuses on arranging objects within a single room or general scene configuration, typically relying on object retrieval and placement guided by general and conceptual descriptions, rather than the constraints and principles necessary for architectural practice and downstream construction.\n\nWe also acknowledge that the high-level insight of using code-driven approaches for generation has been explored in previous research, such as in scientific diagram synthesis with TikZ [1] and specialized scene description languages for indoor scenes [5]. However, our work distinguishes itself by introducing a domain-specific code representation tailored for BIM environments with full implementation. This representation is designed to encapsulate complex architectural logic and construction requirements, thereby reducing the burden on LLMs to handle intricate reasoning or low-level geometric generation. For instance, operations that may require multiple steps or ad hoc commands in prior scene description languages can be accomplished with a single, semantically meaningful command in our system, maintaining consistency across modules, units, and rooms. Furthermore, the implementation is closely aligned with BIM software, supporting direct interoperability and real-world applicability.\n\nIn response to this insightful comment, we will revise the Introduction, Background, and Discussion sections to position our contributions relative to these important works more thoroughly and to clarify the novelty and practical significance of our code representation and BIM integration.\n\n[1] Belouadi et al., AutomaTikZ: Text-Guided Synthesis of Scientific Vector Graphics with TikZ, ICLR 2024\n[2] Zala et al., DiagrammerGPT: Generating Open-Domain, Open-Platform Diagrams via LLM Planning, COLM 2024\n[3] Yang et al., Llplace: The 3d indoor scene layout generation and editing via large language model, 2024\n[4] Fu et al., AnyHome: Open-Vocabulary Generation of Structured and Textured 3D Homes, ECCV 2024\n[5] Aguina-Kang et al., Open-Universe Indoor Scene Generation using LLM Program Synthesis and Uncurated Object Databases, 2024"}, {"review_id": "K8yjcGKtP7", "reviewer": "Reviewer_UQki", "summary": "This paper proposes a new method for generating BIM models in a text-guided manner by representing BIM as executable code and framing the generation task as a sequence-to-sequence problem. The main technical contributions include:\n-\tA code representation scheme specifically designed based on Modular Building Layout (MBL) principles.\n-\tA newly curated dataset containing paired textual descriptions and corresponding structured BIM code.\n\nThe authors fine-tuned a large language model using the proposed dataset to generate structured BIM code, and evaluated the performance using metrics related to code validity, semantic fidelity, and geometric consistency. The experimental results demonstrate the effectiveness of the proposed code representation in enabling autonomous BIM generation.", "questions": "1. It would be helpful to understand how the large language model performs in a zero-shot setting. Specifically, could the authors report the performance of the pre-trained model (without fine-tuning) under both the proposed code representation and the coordinate-based representation? Such a comparison would not only help validate whether the proposed code representation is more suitable for the task but also provide insights into the effectiveness of the proposed dataset.\n\n2. What is the generalization capability of the fine-tuned model? Since the model is trained on a specific dataset, there is a risk that it may overfit to the style or phrasing patterns in the training examples. The reviewer would like to know how well the model performs when given free-form, less structured textual inputs — for instance, a broad requirement such as: \"I need a house with a living room, three bedrooms, a bathroom, a kitchen, and a balcony.\"", "limitations": "yes", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "Strengths:\n- The paper is well-written and clearly presented.\n- The technical contribution centers on the design of a code representation tailored for BIM generation, which aligns well with MBL modeling principles. In addition, the authors have curated a new dataset consisting of paired textual descriptions and corresponding executable BIM codes, which is an important resource that supports future research in this area.\n- The experimental evaluation is relatively comprehensive, covering multiple aspects such as code validity, semantic fidelity, and geometric consistency.\n\nWeakness:\n- The model architecture lacks significant innovation. The approach mainly relies on fine-tuning an existing large language model using a newly constructed dataset, without introducing substantial modifications to the underlying architecture or training methodology. As a result, the technical novelty of the work may be limited. Additionally, the reviewer would like to raise a few concerns about the performance of the large language model; see “questions” for more details.", "was_revised": false, "final_justification": "", "rebuttal": "We would like to express our sincere gratitude to the reviewer for the thoughtful and constructive comments. After a thorough analysis of the reviewer’s comments, we have synthesized the key points into three areas: (1) framework novelty, (2) zero-shot setting evaluation, and (3) generalization capability.\n\nTo facilitate review, we have prepared a detailed response to each point raised.\n\n**1 Framework novelty (W1):**\n\nWe regret not having clearly stated our motivation and contributions in our manuscript. We appreciate the opportunity to clarify the motivation and contributions of our work. We acknowledge that our approach does not propose architectural innovations or new training methodologies for LLMs. Instead, our focus is on addressing the unique challenges of MBL generation within BIM environments, a domain characterized by complex model structures and intricate design constraints.\n\nRecognizing that progress in this area depends not only on model architecture but also on the quality and specificity of the data and task formulation, we undertook a comprehensive review of existing MBL designs and systematically distilled key design principles relevant to text-based generation. Building upon this foundation, we carefully constructed a new dataset and developed a code architecture to represent MBLs in BIM environments using modular classes and functions. This enables the encoding of high-level commands implemented with detailed operational logic, facilitating a new paradigm for automating MBL generation in this context.\n\nIt is worth mentioning that our proposed framework introduces an efficient and expressive model representation for BIM-based MBLs by encoding design intent and structural information as action sequences in a code format. While our experimental comparisons include coordinate-based approaches, such representations are inherently limited in capturing complex design requirements—such as hierarchical relationships, component sequencing, non-rectilinear geometries, and rich semantic associations—essential in practical MBL applications. Therefore, it is inapplicable to represent BIM models with coordinates in design-construction workflows in real-world settings. The Industry Foundation Classes (IFC) standard is widely adopted for BIM interoperability to serialize BIM models; however, its verbose and semantically redundant structure leads to substantial file sizes and high token counts, posing challenges for downstream tasks, particularly those involving natural language processing or machine learning. In contrast, our code architecture compresses BIM models into succinct, encapsulated classes and functions, dramatically reducing both the representation size and complexity. For instance, an MBL comprising five modules, one unit, and six rooms typically requires 7503 lines (215607 tokens) in IFC format, whereas our approach achieves equivalent expressivity with only 20 lines (884 tokens). This compact and structured representation not only enhances computational efficiency but also facilitates more effective learning and reasoning in data-driven applications.\n\nWhile our work leverages established large language models, we believe our contributions lie in integrating domain-specific knowledge with LLM capabilities, formulating a novel code architecture for BIM-based MBLs, creating a corresponding dataset, and demonstrating practical workflows for BIM-based MBL generation. We have conducted extensive experiments to validate the effectiveness of this framework. We maintain that while powerful backbone models are constantly evolving, the fundamental challenge lies in capturing the core of the problem and developing succinct yet effective solutions to address domain-specific scenarios.\n\nIn response to this useful comment, we will revise our Introduction, Experiment, and Discussion sections to more explicitly articulate our motivation, clarify the scope of our contributions, and discuss the significance of our approach in the broader context of BIM and automated code generation.\n\n**2 Zero-shot setting evaluation (Q1):**\n\nWe sincerely appreciate the reviewer’s thoughtful suggestion regarding the evaluation of LLMs in the zero-shot setting. We agree that reporting the performance of pre-trained models—without any fine-tuning—on both our proposed code representation and the conventional coordinate-based representation would provide a clearer assessment of the suitability of these approaches, as well as further insights into the effectiveness of the proposed dataset.\n\nIn Figure 6, we have shown smaller fine-tuned models in low-resource scenarios. Our additional experiments used several state-of-the-art, general-purpose LLMs, including GPT-4.1, GPT-4.1-mini, Gemini-2.5-pro, and Gemini-2.5-flash, in the zero-shot scenario. For each model, we evaluated performance on the proposed code representations (using named arguments or positional arguments) as well as on the coordinate-based representation, using the metrics introduced in the main paper. The results are summarized in the following table:\n\n|Model and output|Compile|Pass|Instance F1|Argument F1|IoU|\n|-|-|-|-|-|-|\n|Gpt-4.1-mini||||||\n|Name|90|6.25|68.89|83.62|88.4|\n|Potision|93.75|3.75|68.33|84.37|94.8|\n|Coordinate|-|-|-|-|27.06|\n|Gpt-4.1||||||\n|Name|97.5|22.5|78.54|90.49|90.03|\n|Potision|93.75|23.75|76.67|88.52|88.95|\n|Coordinate|-|-|-|-|29.94|\n|Gemini-2.5-flash||||||\n|Name|95|21.25|73.58|83.49|84.81|\n|Potision|92.5|7.5|65.13|75.61|88.47|\n|Coordinate|-|-|-|-|23.94|\n|Gemini-2.5-pro||||||\n|Name|97.5|36.25|84.18|88.57|90.24|\n|Potision|98.75|35|84.95|92.02|93.86|\n|Coordinate|-|-|-|-|30.72|\n\nThese results indicate that, in the zero-shot setting, though it is sill challenging for modern LLMs to output totally accurate code, they exhibit a strong capacity to extract and structure information from unstructured textual descriptions, especially when using our proposed code representations. However, generating precise coordinate sequences remains a significant challenge for all evaluated models, with performance of IoU on the coordinate-based representation substantially lower than that for code representations. This suggests that spatial reasoning based on raw coordinates is still a major limitation for current LLMs in this context. Moreover, conventional approaches still fall short in generating MBLs within BIM environments with multiple constraints. In contrast, our proposed framework can dynamically generate the corresponding code for on-the-fly BIM model installation.\n\nThese findings reinforce the value of our code-based formulation and indicate that it is more tractable for LLMs, especially in zero-shot scenarios. Additionally, the results suggest that our dataset provides a challenging and informative benchmark for future model development.\n\nWe acknowledge this valuable feedback, and we will update the Experiment section and the corresponding appendix to incorporate these new results and further clarify their implications.\n\n**3 Generalization capability (Q2):**\n\nWe sincerely appreciate the reviewer’s insights, which are truly enlightening and invigorating. We agree that evaluating the fine-tuned model’s performance on free-form and less structured inputs is crucial to understanding its broader applicability, generalization capability, and potential limitations. Our current work is primarily focused on parametric design scenarios that utilize detailed and structured inputs, rather than general, configurator-style user requirements. However, we recognize the importance of addressing a wider range of input granularities, and this suggestion highlights an important direction for our future research.\n\nTo address this valuable concern, we have conducted additional experiments in which the models were provided with more abstract and less structured instructions (e.g., “Generate a layout with x module, x unit, x living room, x bathroom, x bedroom, x kitchen”). We evaluated the models on two metrics: compile rate (i.e., successful generation of executable code) and extraction F1 score (measuring the accurate extraction and mention of modules, units, and rooms). The results are summarized below:\n\n|Model and output|Compile|F1|\n|-|-|-|\n|Qwen2.5-Coder-3B|||\n|Name|68.75|99.05|\n|Position|45|98.36|\n|Qwen2.5-Coder-7B|||\n|Name|92.5|100|\n|Position|95|99.53|\n|Gpt-4.1-mini|||\n|Name|81.25|92.91|\n|Position|78.75|91.96|\n|Gpt-4.1|||\n|Name|87.5|96.11|\n|Position|82.5|94.58|\n\nThese results indicate that the models exhibit a basic level of generalization to free-form and less structured queries, though performance varies by model size. In particular, larger models tend to generate more accurate and executable outputs, while smaller models are more prone to errors in code generation. This suggests that while our approach can handle a degree of abstraction, further improvements are necessary to robustly support the full granularities of user input styles.\n\nWe are grateful for the feedback, which has motivated us to both broaden our experimental evaluation and to consider a more comprehensive discussion of generalization in the manuscript. We will update the Experiment and Discussion sections accordingly to reflect these new findings and to clarify the scope and limitations of our current approach."}]

Author rebuttal:

Meta-review: This paper introduces Text2MBL, a framework for generating Building Information Modeling (BIM) code from textual descriptions of modular building layouts (MBLs). The core idea involves using an object-oriented code architecture tailored to the hierarchical structure of MBLs (modules, units, rooms) and fine-tuning large language models (LLMs) to output structured action sequences in code. A dataset of paired descriptions and ground truth layouts was curated from real-world projects to train and evaluate the framework.

Strengths: The reviewers consistently highlight the novelty of the task formulation, which bridges natural language understanding and structured architectural modeling. The comprehensive system implementation in Autodesk Revit and the curation of a paired dataset of real and synthetic MBLs are also praised. The code-driven generation method consistently outperforms coordinate-based baselines, as demonstrated by the strong empirical results. 

Weaknesses: A major concern is the limited comparison with related LLM-based design tools, especially Text2BIM and other relevant works in text-to-scene generation. Some reviewers point out that the current framework requires highly detailed spatial parameters as input, which may not be preferred by actual users. The lack of external validation through user studies or domain expert evaluation is also noted. The relative ease of the benchmark, suggested by the high scores, is questioned, with some reviewers wondering if the task is too easy and whether the model is close to real-world deployability.

The authors addressed many of the reviewers' concerns during the rebuttal phase. They provided additional experimental results, including zero-shot evaluations and experiments with more abstract instructions. They clarified the distinctions between their work and related approaches, and they also detailed the potential extensions of their framework. The reviewers generally acknowledged that the authors adequately addressed their concerns, and some reviewers raised their scores accordingly.

Overall, this paper presents a technically sound and well-executed approach to a novel and relevant problem. While the limitations regarding comparisons to other methods and the need for more user-centric evaluation are valid, the strengths of the task formulation, system implementation, and empirical results outweigh these concerns. Therefore, the AC recommends accepting this paper.
Decision: Accept (poster)