Abstract
This paper examines knowledge implications of digitally modeling existing buildings through a comparative analysis of modeling practices in Revit and Rhino. The paper introduces the concept of Manual Schematic Modeling (MSM), an approach distinct from conventional highly-detailed, semantically-enriched parametric modeling. Through an MSM case study, software-specific decisions are shown to uniquely inform architectural knowledge production. Results suggest that the use of multiple epistemological frameworks, i. e., digital modeling software platforms, can inform architectural knowledge production even if these frameworks appear to be mutually incommensurable. This work challenges the presumed value of a single, comprehensive digital model and argues for the value of diverse modeling approaches for existing buildings.
Keywords
Introduction
Digital modelmaking continues to open opportunities for meaningfully recording the existing built environment. This paper aims to expand those opportunities through inquiring into implications for the processes of digital modelmaking. In this context, this paper explores knowledge for digitally modeling existing buildings, focused on how software applications – specifically, Revit and Rhino – impact and inform subjective processes of interpretation.
The paper is centered around the question of architectural epistemology, that is, the study of ways in which knowledge about architecture is produced, organized, and disseminated. In the specific context of digitally modeling the existing built environment, the paper highlights the capacity of modeling processes and artifacts to produce architectural knowledge that has meaning and significance beyond mere geometric replication. The paper argues that this epistemological significance is rooted precisely in modelmakers’ decisions that lead to semantically relevant knowledge. While these decisions often rely on tacit knowledge, digital modeling software necessitates explicit decisions regarding what to model and how to represent it within an ontological framework. The tension between tacit understanding and explicit decision-making is central to semantic enrichment, which is a process of making tacit knowledge explicit.1,2
The paper thus holds implications for knowledge practices, i. e., practices related to the production, organization, archiving, and dissemination of architecturally specific knowledge. 3 Modelmakers’ explicit decisions shape representational artifacts in the form of process iterations. These artifacts stand as visual paradata – that is, process data that captures decision-making – thus highlighting the necessary and significant relationships between digital modeling and archival practices. Alongside process iterations, visual paradata in digital modelmaking typically consists of elements such as logged decision-points, screenshots of a model construction process, version logs, and annotations within models (e. g., text or comments in a Rhino model). Process iterations function as “auto-archived non-verbal paradata”, 4 automatically documenting the interpretive choices that inform semantic enrichment of digital models.
While prior work has examined various applications of software for heritage documentation,5–8 comparatively few studies critically analyze how software ontologies influence tacit knowledge and interpretive decisions in modeling existing buildings.9–11 This work attempts to address this gap by foregrounding digital modeling as a set of dynamic, interpretive practices. Modelmaking can preserve not only static information but also process iterations, as these hold potential to inform interpretation and knowledge production. By comparing knowledge practices characteristic of Revit and Rhino in existing-building modeling, this paper examines how software can fundamentally shape the analysis and representation of existing buildings, influencing the specifics of modeling processes and thereby informing meaningful interpretations. In this way, the paper complements traditional modes of heritage documentation research and offers an enhancement to those traditional modes by revealing how modeling software mediates architectural interpretation through ontological constraints.
The paper uses a comparative approach to examine modeling processes for an existing building using both Revit and Rhino. Two purposes are served by this approach. First, it highlights the role of software ontologies in shaping architectural knowledge, and second, it emphasizes the essential importance of engaging multiple epistemological frameworks in architectural knowledge-production work, even when these frameworks provide apparently incommensurable results. This paper introduces Manual Schematic Modeling (MSM), an approach with aims and methods distinct from conventional archaeometric approaches. Models resulting from this approach are themselves open to ambiguous reading and can thus inform tacit knowledge in new ways. The methodological framework guiding this analysis is a comparative study, in which MSM serves as a lens to evaluate software-mediated knowledge production.
This paper begins with a brief background section, proceeds to introduce both theoretical and practical concerns relevant to Revit and Rhino, and then offers a case analysis of select modelmaking processes and decisions in each application. The analysis is followed by a discussion exploring significant questions, and the paper concludes with suggestions for further research.
Background
Examining knowledge practices related to digital modeling is contingent on acknowledging models and modeling as legitimate subjects of study,12–15 and particularly on ascribing a degree of autonomy to that study, i. e., that the study of models and modeling is related to, but not wholly identical with, the study of referents or “originals.” 16 Existing buildings embody multiple and possibly conflicting concepts of reality,17,18 and the same can be said of models. Nevertheless, epistemologies of models and epistemologies of buildings have distinct concerns.
Digital models may operate as tools in architectural design processes; alternatively, they may inform the interpretation and analysis of existing buildings. Digital models of existing buildings may respond to motivations such as conservation, renovation, materials recovery, performance simulations, or scholarly research. 19 While some motivations for modeling existing buildings are clearly pragmatic, others more strongly suggest the need for critical interpretation and may rely more heavily on unstated or tacit assumptions. Yet even apparently pragmatic motivations for digital modeling necessarily involve interpretive processes. The choice to model is itself an implicit privileging of certain modes of inquiry over others.20,21
Moreover, the motivations for digitally modeling existing buildings generally differ from motivations for the use of digital models in design processes.22–24 In architectural design, the absence of an existing built referent and the need to test design alternatives are overriding factors. These factors are evidently not present in existing-building modeling. Yet, architectural design, with its capacity to examine multiplicities of meaning, may effectively import its tactics into the study of existing buildings. 25 When this occurs, digital models of existing buildings assume a creative and provocative analytical dimension. 26
Modelmakers’ interpretive decisions do more than document geometry; they constitute acts of architectural analysis and critique that iteratively shape new understandings of existing buildings. 27 Through these choices, modelmakers develop understandings of formal, spatial, and geometrical attributes, with the aim of progressively integrating disciplinarily specific ideas into coherent models. In this way, reconstructing existing buildings digitally generates new knowledge. 11 This reflects, in part, the fact that existing-building models always reflect the evidence on which they are based, which is itself never complete. 28 For this reason, a modelmaker’s decisions, like design decisions considered generally, are provisional and temporary, reflecting ongoing and iterative processes of negotiation, refinement, familiarity-building, and understanding. For example, Masinton and Jago 28 characterize existing-building modelmaking processes as “a series of negotiations” between modelmakers, scholars, and evidence, while Lin 29 encourages the “temporary use of incomplete and inconsistent ideas” to allow digital modelmakers to explore conceptual possibilities.
This context reinforces the idea that digital modeling processes for existing buildings are characterized by tacit assumptions on the part of modelmakers, i. e., “pre-understandings”,
30
“scaffoldings”,
31
or “pre-existing mental images.”
32
Such assumptions include the following. First, digital modeling software conventionally involves an inherited knowledge function invoking both Cartesian and perspectival representation that underlies every decision made with the software’s aid. Decisions are taken, explicitly or implicitly, with respect to coordinate geometry and in anticipation of perspectival or orthographic visualization.
33
Second, digital modeling software triggers a temporal knowledge function that encourages or demands specific decisions at specific times in modelmaking processes, e. g., initial ideas require explicit responses. In what becomes a cyclical process, explicit decisions lead to modeled geometry, visualizations of which are themselves subject to ambiguous readings, further informing tacit knowledge (Figure 1). Cycle of tacit knowledge and explicit decisions.
Among the most consequential of a modelmaker’s explicit choices is the choice of an ontology or framework in which software-related decisions are made. 34 In this context, ‘ontology’ refers to a software-defined framework that determines the categories, relationships, and entities that are deemed valid within a digital model. 10 Ontologies both enable and constrain the concepts and relationships that a modelmaker can formally express, influencing both representational scope and interpretive potential.10,35–38 Ontologies begin by acknowledging different kinds of conceptual relationships as either legitimate or not. For example, Revit and Rhino have distinct ontologies, meaning that each application admits concepts and relationships in unique ways. 39 Revit, as building information modeling (BIM) software, formally represents knowledge in a hierarchical structure involving categories, families, types, and instances. 40 Within a BIM ontology, modeled entities have distinct, nameable properties, often aligning with AEC industry assumptions concerning the division of labor, material sources, and fabrication processes typical of large construction projects. 41 It is BIM’s explicit incorporation of geometric, numerical, and verbal modes of information, particularly in quantifiable form, that is the source and meaning of the term “building information modeling.” 42 In contrast, Rhino is a geometry modeler rather than a building information modeler. That is, Rhino organizes information by properties that are generally applicable to the act of modeling rather than being in any way specific to modeling buildings. Because of this ontological difference between the two software applications, working with Revit is like working with a predefined kit of flexible parts, each of which has its relationships with other parts “built in,” while working with Rhino is inherently more flexible, less constrained by predetermined categories. Thus, a modelmaker faced with the question of constructing (say) a window either needs to be abidingly concerned with the window’s informational attributes, its parameters, and its hierarchical position within the model considered as a whole, as in Revit, or simply as an outcome of modeled geometry organized into layers, as in Rhino. Within heritage studies, the epistemological consequences of the distinction between parametric approaches and direct (i. e., “reality-based”) approaches remain open to investigation.6,8,43–46
Manual schematic modeling
This paper introduces Manual Schematic Modeling (MSM) as an approach distinct from the conventional pursuit of highly-detailed, semantically-enriched, parameterized digital models.2,23,47 While MSM is not specific to any particular software application, Rhino’s open-ended ontology supports MSM by enabling modeling unconstrained by predefined architectural categories. In this sense, Rhino provides a conceptual affordance, i. e., an openness to exploration, that differs from Revit’s emphases on semantic consistency and high development of modeled detail. In one sense, MSM could be associated with a conventional LOD (i. e., a level of development) of 300, that is, “a model nearer to the reality but, however, with a high deviation between virtual and real model.” 48 However, the LOD framework assumes that digital models are necessarily valued in terms of their geometric fidelity to their referents, i. e., subject to ground-truth validation. MSM assumes instead that the model, and particularly the process of its construction, should be valued according to the conceptual insights it triggers and how these insights may inform new knowledge. 12 These insights may be, but need not be, contingent on geometric accuracy. For example, as will be discussed in detail later in this paper, a structural grid could serve as a kind of conceptual tool for organizing knowledge about a building, without that grid necessarily being modeled in a way known to be geometrically accurate. In a similar way, two-dimensional diagrams in architecture may uniquely prompt conceptual insight without being strictly accountable to building geometry. 49
By making explicit the conceptual assumptions embedded in modeling software, MSM exposes how different approaches shape the kinds of architectural knowledge that models can generate. 24 It explores the degree to which approaches such as BIM and HBIM can have epistemological effects on modeled results.8,12,50 To this end, MSM addresses both practical parametric strategies and theoretical issues of disclosing architectural significance that may not otherwise be obvious. 3
MSM differs from traditional HBIM approaches to semantic enrichment. Traditional methods apply enrichment after creating a geometric model (i. e., enrichment added to modeling), whereas MSM develops semantic meaning within the process of modeling (i. e., enrichment through modeling). MSM avoids the problem of achieving geometrically accurate or archaeometric models, 51 aiming instead at identifying and articulating conceptually meaningful questions about how buildings may be understood and conceptualized through the act of digital representation. This amounts to a bidirectional enrichment process in which the act of modeling is seen to provoke deeper understanding of its built referent.
Furthermore, MSM assumes that semantic enrichment is a process that resides in “readers” as well as “writers” of models. In this way, MSM functions similarly to analytical approaches that predate the use of digital models in architecture. For example, Herdeg 52 suggests that viewers of his analytical diagrams will continue to expand upon his drawn interpretations, and that “[s]ometimes, surprising new interpretations arise, even years after a particular study is committed to paper.” In this context, MSM concentrates on foregrounding conceptual relationships within existing buildings that are like those relationships that emerge during design processes, 53 i. e., in the form of “tangible speculation.” 54 Examples of applications or scenarios for MSM include: low-detail visualizations, where geometric accuracy is secondary to conceptual clarity; renovation planning, particularly in space-planning or adjacency studies; pedagogical modeling exercises, where students are learning about limitations and capabilities of modeling software; and historical reconstructions, where there may be a lack of detailed information about past conditions. These and similar applications could be amenable to testing consistent with the MSM approach.
MSM can be situated within several established interpretive frameworks in modeling, representation, and heritage documentation. Following Suárez’s inferential conception of scientific representation, 55 MSM treats models as tools for generating insights rather than isomorphic records. As an approach, MSM broadly aligns with Hodder’s contextual archaeology, which similarly emphasizes interpretive pluralism and multiple readings of material evidence. 56 MSM’s foregrounding of process aligns with the London Charter’s emphasis on paradata documentation.57,58 MSM adheres to best practices for paradata documentation, including transparency, i. e., a commitment to provide information about the creation and interpretation processes of data, particularly in interpretive decision-making. The MSM approach also resonates with Drucker’s distinction between ‘capta’ (taken/interpreted) versus ‘data’ (given/objective) in humanities visualization, privileging interpretation over claims of objective recording. 59 Like Latour and Lowe’s discussion of the “migration of the aura,” 16 MSM acknowledges that digital models achieve new forms of authenticity through their interpretive processes rather than mere mimetic replication. Moreover, MSM extends architectural diagramming traditions as exemplified by Herdeg, 52 adapting these analytical approaches to three-dimensionally modeled digital environments while maintaining their emphasis on conceptual insight over comprehensive description. In a related approach similarly challenging conventional emphases on geometric accuracy in digital modeling, Christenson 60 demonstrates how parametric approaches can reveal latent design logics. Fundamentally, MSM acknowledges that the modeling process itself generates unique and potentially significant inquiries relevant to producing knowledge about existing buildings. 61 In this context, “the modeling process” refers to the cumulative decisions made from setup through construction until the model is deemed sufficiently complete for purpose. The discussion of the modeling process does not propose to gauge the software applications’ relative efficiency but is rather focused on the softwares’ conceptual effects as these may inform thinking about the building.
Critically, MSM does not aim to replace conventional approaches to highly-detailed, semantically-enriched, parameterized digital models – only to present a distinct form of study. MSM recognizes the importance of epistemic diversity, that is, the values that inhere in multiple modes of inquiry (e. g., distinct software applications). Revit’s categorically organized modeling environment encourages thinking about building elements as predefined, interrelated components with rich semantic data, but Rhino’s flexible geometry remains open to spatial exploration and conceptualization. Thus, while each software approaches architectural epistemology in fundamentally different ways, they nevertheless produce knowledge, i. e., their incommensurability is productive. For example, MSM may uncover formal structures that are missed by a BIM-based analysis, while BIM is more likely to reveal industry-aligned hierarchies that are bypassed in MSM.
Guidance for different levels of expertise.
These graduated strategies demonstrate MSM’s adaptability to modelmakers’ evolving experience across multiple projects. For example, a novice MSM user will likely find the act of tracing existing documentation to be an effective starting point, acknowledging that tracing can operate across scales (i. e., from overall volumes to details). An intermediate user will likely continue to find tracing an effective starting point but will additionally find that speculating about otherwise undocumented conditions can be productive. Advanced users will, of course, rely on their prior experience over multiple projects to inform their choice for a starting point: they are likely to be more aware of the downstream implications of initial decisions, and can base their approach on past successes. Beyond modeling approaches, documentation strategies also scale with experience. Across experience levels, documentation in the form of paradata remains essential, and strategies are again assumed to be cumulative. Screenshots constitute a simple but effective strategy for documentation, appropriate at any level of experience, but it is the advanced user who is most likely to benefit from navigating multiple “saved” iterations of their developing models to inform their documentation practices. Fundamentally, MSM encourages multiple pathways, each capable of generating meaningful architectural insight regardless of a modelmaker’s technical sophistication or a model’s level of geometric accuracy.
Process results
This section of the paper describes the comparative study of two models constructed using an MSM approach. The models are constructed using two different software applications (Rhino and Revit). In both cases, the same building is modeled, so that modelmaking decisions can be more easily compared. The description is framed not simply to describe modeling workflows, but explicitly as a demonstration of MSM’s epistemic affordances. Although the discussion assumes an advanced level of MSM use, it is presented in a way designed to be accessible to users with varying levels of experience.
The Federal Archive Building, located in Greenwich Village, was selected as a case study for reasons related both to its representative form and structure and its susceptibility to digital modeling. First, its constructional characteristics (a multi-story gridded structure with exterior bearing walls, combining warehouse and office functions) exemplify common patterns found in typical late-nineteenth-century American commercial buildings. Its combination of repetitive elements, layered facade articulation, and prominent structural grid made it suitable for comparing how different modeling ontologies address architectural relationships and hierarchies. The building is sufficiently complex (e. g., including an unusual transition from a concrete frame structure at its lower levels to a steel frame at its upper levels) to meaningfully test different software capabilities without overwhelming the study scope. The availability of comprehensive documentation 62 provided adequate source material for a comparative study. While prior analysis of the Federal Archive Building 60 employed parametric modeling to examine perceptual consistency across modelled variations, the present study maintains an ontological focus in its comparison of Revit and Rhino.
Rhino
This section of the paper examines how MSM principles operate within Rhino’s ontology and workflows. The Rhino modeling process began by preparing and interpreting archival documentation, a step that foregrounded the tacit assumptions embedded in source materials. Detailed plan and section drawings from source documentation
62
were scanned and subsequently minimally processed in Photoshop to maximize legibility and image registration. The scanned drawings were saved as .jpg files and selectively traced. Examination of the scanned plans and sections strongly implied that the Federal Archive Building is structured on sets of aligned columns and beams (Figure 2). (a) Plan, and (b) Section drawings of Federal Archive Building showing aligned columns and beams. Redrawn from source documentation.
62

To coordinate the modeling, a building grid was modeled in Rhino using the scanned plans as a basis. Decisions about establishing a grid involve assumptions about relationships between, on one hand, vertical features in the building (such as the exterior wall, the interior light court, the stairs and elevators), and on the other hand, the horizontal grid of columns and beams. In some cases, these relationships could be assumed based on the scanned drawings. For example, the drawings implied that certain beams were centered on columns. In other cases, relationships could be assumed based on standard construction practice. For example, the drawings do not describe the precise location of steel or concrete beams within the building’s exterior masonry wall, but this can be reasonably inferred.
In Rhino, the concept of a “building grid” carried no specific ontological meaning; it was a conceptual entity that operated as a device whereby the modelmaker could establish and enforce relationships between modeled elements (a key MSM strategy of conceptual foregrounding rather than semantic completeness). The grid was modeled using lines. Rhino’s block function made it possible to group objects together into a single entity, such that the entity may be efficiently duplicated throughout the model and made accessible to global updating if necessary. Once the building grid was drawn in correspondence to a single building floor, it was defined as a block and then copied to appropriate vertical heights within the model corresponding to additional floor levels.
However, inspection of the scanned drawings revealed that the building grid evidently changes from lower to upper floors. This change reflects a change in constructional technology from a concrete frame structure at the lower levels to a steel frame structure at the upper levels (Figure 3). (a) Grid at lower levels. (b) Grid at upper levels. (c) Grid changes from lower to upper levels.
The reference documentation does not include any elevation drawings.
62
Thus, knowledge concerning the building’s exterior enclosure was developed based on examining section drawings (including wall sections) and plan drawings. Inspection of the documentation suggested the possibility of modeling the exterior enclosure through profile extrusion, a procedure that is consistent with a major component of Rhino’s ontology. Rhino’s “sweep1” command operates to extrude or sweep a profile along a defined rail (Figure 4). A rail may consist of a single curve, straight or non-straight, or it may consist of an arbitrary series of endwise-connected curves (i. e., a polyline) that may be globally open or closed. (a) Profiles for exterior wall. (b) Horizontal sweeps from profiles.
The ground-level exterior-surface perimeter of the building was traced from the scanned floor plans and then offset to form a continuous rail. Because profile extrusions were present in the original documentation, a “rail” could be inferred from the traced plan profile of the building. Figure 4(b) illustrates the result of “sweeping” the traced wall profiles along a defined exterior rail. This approach to profile extrusion based on scanned documentation established a series of vertically stacked “loops” whose shape in plan was derived from the plan of the building. Each individual “loop,” then, was the modeled consequence of extruding an individual profile along a rail in the plan-shape of the building.
Rhino’s ontology also enables profile extrusion in a direction normal to a planar curve or to an established “construction plane,” which by default corresponds to a conventional x, y plane. Elements from the exterior wall were traced at different floor levels and then, using Rhino’s extrudecrv command, were vertically extruded (Figure 5). Model as a result of vertical extrusions.
This method of profile extrusion produced a “fence” roughly corresponding to the building’s exterior envelope. In the next step, the horizontal and vertical models were combined (Figure 6). (a) Horizontal sweeps. (b) Vertical extrusions. (c) Model as a combination of horizontal sweeps and vertical extrusions.
In this approach, openings in the building’s exterior masonry wall (such as window openings) emerged as the consequence of the interplay between vertical and horizontal, a kind of weaving. The “form” of the building’s enclosure was positively modeled, and “space” became equivalent to a conceptual void, i. e., leftover. In other words, openings were not modeled positively but emerged as a consequence of modeled form (Figure 7). Window openings as consequence of woven geometry.
Rhino’s ontology does not include formal concepts of architectural elements such as walls, floors, windows, and doors. In Rhino, constructing a “window” – in the present case, an assembly of entities corresponding to a wood frame and window glass in the referent building – involves ultimately the same set of modeling tools that might be used to construct any other kind of assembly. Material-digital relationships in a Rhino “window,” or in any other Rhino-modeled assembly, may be formally encoded by assigning certain quantifiable properties, such as the degree of rendered opacity of a modeled element. To the extent that a modeled assembly representing a window repeats within a model, Rhino’s block command can be used for effective management. The block command groups selected elements according to their modeled locations in space, with reference to a base point. The block may be copied throughout the model. If the block is subsequently “redefined,” Rhino will globally update all copies of the block with the new definition. Critically, the block command can be used to group any collection of modeled elements, and blocks may be nested within each other. Thus, for example, a single window can be defined as a block. A pair of blocks representing two identical windows, separated in space by a fixed distance, may also be defined as a block. Several identical pairs of windows, along with windows of other types may be grouped as a block.
The idea of a “window” in Rhino is a consequence of geometry as interpreted by a modelmaker or a viewer – unlike Revit, where windows are nameable as objects, Rhino provides no unambiguous mechanism for identifying windows as objects. Objects can be associated in a block and given a descriptive name, but the blocking and naming procedure is not specific to modeling windows or any other constructional element. In the Rhino model, individual windows were defined as blocks, then nested within pairs and large groups as described, and finally copied to the appropriate locations around the building perimeter (Figure 8). Nested blocks in Rhino. (a) Single window defined as a block. (b) Two windows defined as a block. (c) Group of windows defined as a block. (d) Block distributed into building model.
It is important to recognize that the “nested block” strategy derives from Rhino’s ontology and not from a corresponding physical characteristic of the Federal Archive Building. Modeling a different building, say one with an explicitly modular approach (e. g., a unitized curtain wall), would offer a clearer opportunity to align a “nested block” strategy to the physical attributes and practices of construction. But in the present case, the “nested block” strategy involved the modelmaker’s interpretation of efficiency, as distinct from any desire to faithfully model a process of physical assembly or construction.
In summary, the Rhino modeling process exemplifies MSM’s emphasis on leveraging modeling procedures to reveal conceptual relationships, rather than attempting to achieve archaeometric fidelity. As the following section will explain, the “nested block” strategy differs epistemically from Revit’s approach to modeling windows. In this way, Rhino’s ontology will be seen to enable a kind of conceptual affordance that differs from Revit’s hierarchical approach.
Revit
This section of the paper illustrates how MSM’s priorities translate into Revit, highlighting how Revit’s ontology frames interpretive decisions differently than Rhino. At a fundamental level, Revit approaches digital modeling in a way that is tightly bound to industry-based assumptions about assembling new buildings. Its modeling logic is designed to support clearly-defined constructional entities with a minimum of ambiguity, all with the aim of supporting the production of clear and unambiguous construction documents in a collaborative and cross-disciplinary work environment. This section of the paper emphasizes how Revit’s built-in assumptions or logic impact the modelmaker’s latitude in interpreting the building on a conceptual level.
In Revit, establishing a building grid is not merely a constructive act, but an ontological commitment that shapes how subsequent modeled elements relate and behave within the software’s parametric framework. Recall that in Rhino, a building grid does not exist as a defined ontological feature. Revit explicitly incorporates what Rhino only implies, namely, that a building grid is an explicit ordering device to which modeled features can be aligned and parametrically locked. Building grids in Revit are by default orthogonal, and the software operates in a way to reinforce that default expectation (Figure 9). This becomes potentially problematic in cases where features within the referent building are themselves not mutually orthogonal, as is the case with the Federal Archive Building. Thus, special care was taken in modeling to ensure that any slightly-off-axis gridlines were drawn correctly, particularly because those gridlines were meant to be placed non-orthogonally in the model. Screenshots of Revit warning messages.
To construct a wall in Revit, a wall line was established, loosely analogous to establishing a “rail” in Rhino for horizontal sweeps. Based on the scanned documentation, a wall line was drawn in Revit, on an expected ground plane, to coincide with the baseline of the exterior face of the building’s exterior wall at ground level (Figure 10). (a) Volume of the whole building model. (b) Detail of single wall line at model base.
Once a wall line was established, a wall could be placed in one of several orientations relative to that line – e. g., centered on the line or face-coincident with the line. Any wall in Revit is necessarily subject to a defined wall type, incorporating information concerning the internal structure of the wall. In Revit, wall types are particularly well-suited to situations where the wall to be modeled is of consistent construction over an extended area. For example, if a wall is of consistent construction around a building’s entire perimeter, a single wall type could be defined. If a wall is not of consistent construction, multiple wall types could be used, or walls could be supplemented with features like sweeps. The exterior masonry wall of the Federal Archive building can be understood as being of consistent construction except to the extent that the wall includes features that deviate from a uniform plane, corresponding to pilasters, piers, arches, and window recesses (Figure 11). Exterior wall incorporating deviations from a uniform plane.
This situation led to a decision to model the exterior wall as an assembly of distinct walls, layered so that the front (or exterior) face of one wall was coincident with the rear (or interior) face of the next wall, and so that their combined thickness would correspond to the total thickness of the exterior wall. Revit’s ontology does not formally incorporate the concept of a single entity consisting of multiple walls but neither does it prevent this approach. Based on inspecting the documentation, it was ultimately decided to model the exterior wall as consisting of four layered wall assemblies, parallel and separated by distances to coincide precisely with the defined thickness of each layer (Figure 12). This approach compares with Pauwels et al.’s approach to multiple, adjacent wall types in a Revit model.
63
(a) Volume of the whole building model. (b) Detail of offset wall lines at model base.
Profile editing, a method for modifying or customizing the boundary of a wall segment viewed in elevation, is a characteristic feature of Revit’s ontology.
64
The boundary of such a segment is rectangular by default. Profile editing may involve either or both of two operations, here referred to as perimeter editing (making changes to the outside boundary of the segment) and hole editing (introducing, deleting, or modifying openings within the segment). Of the four layered wall assemblies referred to in the preceding paragraph, three of them were modified using profile editing (Figure 13). The remaining assembly, which happened to be the third layer in order from the exterior, was the only one constructed as completely solid, i. e., its elevation profile was a simple rectangle. This solid assembly was designed to receive or “host” window objects, which when placed, effectively create their own openings in the wall. For this reason, profile editing (specifically, hole editing) was not required on the third layer. (a) Four sub-walls with edited profiles. (b) Four sub-walls assembled into the exterior wall. (c) Detail view of exterior wall assembly.
Revit’s ontology considers windows as parametrically defined objects or families. Considered as families, windows are of a type that must be hosted within a system family, e. g., by walls. As editable families, windows are defined and edited within Revit’s Family Editor, a modeling environment subsidiary to Revit’s main environment. For the Federal Archive Building, windows corresponding to the various types of windows observed in the documentation were modeled in the Family Editor (Figure 14). Thus, the effect of placing windows within the third sub-wall was essentially that of “punching” openings into an otherwise continuous wall. Window in wall as visualized in Revit’s Family Editor.
Discussion
Epistemological and ontological contrasts between Rhino and Revit.
Consistent with the MSM approach, these differences shaped distinct understandings of the building, as the following discussion illustrates. In Rhino, the building’s exterior wall was modeled as a weaving-together of extruded horizontal and vertical elements. This was practically possible based on source documentation that depicted plan-profiles and section-profiles. Because extrusions and sweeps are no more specific to buildings than to other real-world entities that could be modeled, the approach in Rhino was unconstrained by ontological assumptions related to modeling buildings. By contrast, in Revit, the building’s exterior wall was explicitly modeled as a “wall,” though one that was composed of four sub-walls, only one of which hosted window elements. Each of the two understandings carries some significance to architectural knowledge production. Considering the building’s exterior wall as an interwoven composition highlights a dynamic interplay of alternating solids and voids (Figure 15(a)). Considering the exterior wall as a composition of sub-walls suggests that the building’s exterior walls transcend simple “envelopes” and are conceptually separable into discrete layers that contribute to a modeled whole (Figure 15(b)). Neither interpretation is necessarily truer or more correct than the other; and while they are not strictly contradictory, they affirmatively highlight distinct conceptualizations. To a certain extent the interpretations may be seen as incommensurable, in that they each operate with distinctly identifiable and original concepts. Consider the following example. Revit’s ontology foregrounds the assumption, common in the construction industry, that “windows” are identifiable objects that can be placed (or “hosted”) within walls. This recognition of the industrial reality of construction is important to any comprehensive understanding of the building. At the same time, Rhino’s approach to modeling windows enables an analysis at the level of broad conceptual moves, largely unconstrained by the building’s constructional specifics. The two approaches are thus both uniquely productive of knowledge concerning the building, and incommensurable, in that they describe logics that are distinct and independent. The approaches are divergent but complementary. This productive incommensurability of the two approaches contributes to an understanding of the building that goes beyond superficial appearance. (a) Diagram of woven facade (b) Diagram of layered facade.
The construction of windows in both Rhino and Revit further illustrates how software ontologies condition interpretation, with Rhino highlighting the importance of emergent form and Revit emphasizing parametric hierarchies. In Rhino, the windows were a consequence of modeled form, having emerged dynamically as the space “left over” after the exterior wall was woven from horizontal and vertical components. Nested blocks were repeatedly copied, filling the leftover space with modeled assemblies that were interpreted as representing wood-framed windows with translucent glass (Figure 16(a)). In Revit, windows explicitly operate as families with window-specific parameters. Windows can be understood, as in Rhino, as compositional elements that “nest” into groups (Figure 16(a)), or, as in Revit, as isolated objects capable of “punching” openings into walls (Figure 16(b)). Again, neither interpretation is in a sense truer or more correct; rather, they offer distinct and architecturally meaningful concepts. And again, insofar as the interpretations offer a degree of uniqueness or incommensurability (with original elements, ordering procedures, and results), the software applications combine to contribute to architectural knowledge production. Ultimately, this combination results in a form of epistemic diversity with practical consequences: Revit excels at triggering inquiry into constructional practices and industrial norms, while Rhino prompts open-ended inquiry into rhythms and patterns that exist beyond the scope of any specific component of construction. (a) Diagram of multiple nestings (b) diagram of punched openings.
Could windows be modeled prior to modeling walls? Initially it may seem that the modeling approach in Rhino requires the wall to be built (i. e., ‘woven’) before the windows could be modeled and placed: without the modeled wall, there is no obvious way for the modelmaker to know the sizes and dispositions of the windows. In Revit, the Family Editor exists precisely to support the modeling of components such as windows independently of (potentially prior to) the modeling of system families such as walls. Thus, in Revit, a window cannot be modeled without explicitly assuming a wall (of variable thickness) into which the window can be placed. However, a ‘window’ in Rhino consists simply of modeled geometry, and as such, it bears no necessary hierarchical relationship to, or time-dependence on, any other geometry in the model.
Recognizing that modeling need not follow a fixed sequence raises the question of completeness: How does a modelmaker know when to stop modeling? Perhaps this question could be answered in terms of predefined standards. Alternatively, the MSM approach reframes ‘completeness’ not as a technical threshold, but as a condition reached when a model triggers productive inquiry. In this way of thinking, construction of the model could be deemed ‘complete’ if, at any point during its construction, any of the following instances occur: (a) a novel interpretive insight is triggered; (b) latent formal, spatial, or constructional relationships are made visible; (c) a new interpretive hypothesis is articulated.
For example, in the present study, the Rhino model’s woven facade became ‘complete’ once it revealed the interplay of solids/voids as a conceptual lens, while the Revit model of layered walls became ‘complete’ when it triggered a meaningful recognition of constructional logic as distinct from software ontology. Critically, the notion of ‘completeness’ should not be confounded with an expectation that the modelmaking process must conclude with a single model. Software makes it trivially easy to produce multiple models of a single building. Multiple models could embody different approaches to ‘completeness’, building iteratively into a collection. This notion of ‘completeness’ aligns with Herdeg’s view of drawings as open-ended provocations rather than definitive records. 52 Divergent notions of ‘completeness’ reveal how modeling workflows are not simply efficient technical processes but epistemic acts that give structure to architectural inquiry.
Nevertheless, the question of ‘completeness’ is linked to the issues of assessment and validation. Insights that arise during a modeling process (i. e., prior to model finalization) could be assessed and validated through iterative peer feedback. In this context, validation need not be restricted to demonstrable adherence to geometric accuracy; it could recognize the importance of novel insight for its own sake. Assessment with respect to LOD expectations, similarly, need not prioritize geometric accuracy or fulfill conventional expectations for “completeness,” if models are understood as being fit for specific purposes. A novice user faced with the need to choose between the use of one software or another should have a clear expectation of context and purpose. If a digital model is a sole-author endeavor aimed at exploring conceptual nuance, Rhino will likely be appropriate, while a collaborative team-based environment aimed at coordinating multiple agendas within complex logistical constraints suggests the use of Revit. Teams may also be able to make effective use of multiple models of a single building, leveraging epistemic diversity of various software applications. Ultimately, the coexistence of multiple, potentially incommensurable interpretations emerging from different modeling ontologies raises important epistemological questions about architectural knowledge production. Critically, the study does not suggest a relativistic stance wherein all interpretations hold equal validity. Instead, the argument is simply that distinct ontologies lead to contextually grounded forms of knowledge. Thus, a model’s value lies not in its comprehensive nature or its supposed universal applicability but precisely in its capacity to reveal architectural relationships that might otherwise remain obscured. This epistemological approach acknowledges that architectural understanding emerges not from a single authoritative model but from the interpretive dialogue between different modeling systems.
Limitations and future work
In this paper, an existing building was modeled using two different software applications. Selected model-making decision processes from both cases were compared to highlight their epistemological significance and consequences for knowledge production.
BIM models are widely acknowledged for their usefulness and practical utility, particularly in complex or large-scale projects involving coordination between different disciplines involving different needs for information. 41 Research strongly suggests that BIM models, if sufficiently enriched and integrated, could operate to “fully represent and comprehend” existing buildings, 65 addressing in a single model “materials, construction components, and old memories in addition to the geometric shape.” 46 The discipline of cartography, however, offers an important counterpoint to this suggestion. As is well known, cartographic projection systems inevitably introduce distortion (e. g., of shape or of area). Individual maps leverage projection systems as they highlight selected spatial phenomena (e. g., climate, migration) at the expense of obscuring or omitting others. Thus, multiple maps may be drawn to inform understanding, even if individual maps provide apparently conflicting views of reality. 66 As a practical matter, cartography recognizes the difficulties inherent in projecting a curved surface onto a flat plane. But more than geometry is at stake. Reliance solely on a single mode of abstraction, whether in mapmaking or modelmaking, risks what Winther 67 refers to as “pernicious reification,” i. e., inappropriate universalization, narrowing, and/or ontologizing.
By contrast, the MSM approach, as exemplified here using Rhino, prioritizes interpretive exploration over the exhaustive integration of comprehensive information. The evidently uniform superficial appearance of the apparently complete models in Figure 17 visually obscures the fact that they constitute different kinds of knowledge structures with distinct affordances. Future work has an opportunity to directly address the unique affordances that exist within apparently complete models, insofar as these result from different modelmaking processes. Revit model (L); Rhino model (R).
This study’s findings are constrained by their dependence on a single building type and software pair, which could limit generalizability to other modeling contexts or scales. The salient ontological differences that arise between Revit and Rhino are not the same as those that would arise between other software pairings (e. g., ArchiCAD and Sketchup). And, as with any interpretive methodology, the present study reflects the modelmaker’s own preconceptions and disciplinary training, which necessarily shaped how MSM principles were developed and implemented.
Where HBIM conventionally prioritizes geometric fidelity and semantic completeness, MSM treats ‘completeness’ as a function of conceptual insight. While this approach aligns with Lin’s 29 advocacy for temporary inconsistencies in exploratory modeling, it challenges HBIM’s assumption that ‘full’ representation 65 is necessary for meaningful heritage knowledge production. Moreover, an MSM approach may not satisfy heritage documentation needs requiring precision in dimensions or in simulated material qualities and physical behavior.68,69 Nevertheless, the ontological distinctions between Revit and Rhino highlight a need for software interoperability frameworks that preserve epistemic diversity, respecting the unique capabilities of distinct software applications. Thus, future work in this area can be expected to address hybrid workflows such as are suggested by the use of the Rhino. Inside.Revit plugin. 5 Finally, to the extent that MSM’s open-endedness may challenge conventional evaluation metrics (e. g., LOD), future work could aim to develop new rubrics or protocols for interpretive success.
The London Charter, 57 in addressing computer-aided representations of existing buildings, acknowledges the importance of “manifold interpretative interventions,” “multiple possible stories,” and “highly speculative experiments … evaluated on their own terms.” According to the Charter, documented visualization promises to “affect our assumptions about the nature, aims and methods of research and communication in the heritage domain.” While purely manual methods, such as those discussed in this paper, are rarely reported,70,71 they represent a unique opportunity to identify and explore conceptually rich ideas concerning existing buildings and their digital representation. The present work suggests the inherent promise in constructing architectural knowledge using multiple systems and tools that may, by choice and design, achieve a kind of productive incommensurability, that is, the recognition that different forms of architectural knowledge derive value precisely for their unique association with particular software applications.
In conclusion, the case study demonstrates how the distinct ontologies of Revit and Rhino, as explored through MSM, lead to different yet complementary forms of knowledge. Revit’s highly-structured, data-driven insights, together with Rhino’s flexible and exploratory insights, contribute to an epistemically diverse understanding of the building beyond what either software could achieve in isolation. Thus, the Manual Schematic Modeling approach offers a methodological alternative to conventional approaches, uniquely acknowledging digital modeling as an essential knowledge-generating process in architecture.
Footnotes
Funding
The author received no financial support for the research, authorship, and/or publication of this article.
Declaration of conflicting interests
The author declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
