OUP user menu

An Integrated Approach to the Procedural Modeling of Ancient Cities and Buildings

Marie Saldaña
DOI: http://dx.doi.org/10.1093/llc/fqv013 i148-i163 First published online: 17 June 2015


This article presents the ‘Roman City Ruleset’, a suite of procedural rules for creating 3D models of Roman and Hellenistic architecture and urban environments. Unlike traditional 3D modeling software, in which the user directly manipulates polygons to simulate form, procedural modeling entails the use of computer programming languages to write a semantic description of a building that then generates a polygonal model. Procedural modeling has the potential to address a number of issues related to 3D archaeological reconstructions which are of concern to digital humanists. Of particular interest for archaeologists and architectural historians is the ability to test hypothetical reconstructions of ancient architecture in a fully realized urban context. The procedural rules link each iteration of a model to its source material, allowing the degree of certainty present in each model to be accurately defined through the documentation of each step in the process of interpreting a given data set. Procedural modeling enhances the scholarly value of architectural reconstructions by providing a platform for the comparison and refutation of 3D visualizations, and advances the methodology of 3D modeling toward becoming an essential part of the digital humanist’s toolkit.

1 Introduction

The quest to interpret the many-layered picture that results from combining evidence from ancient texts, empirical archaeological data, and geographical landscape surveys has long occupied scholars of the ancient world. Today, the ever-increasing amount of data available to researchers demands that methodologies adapt as well. The use of 3D digital technology aids the task of archaeological reconstruction in many ways. Crucially, digital tools provide a means of aligning and comparing discrete data sets which juxtapose visual material alongside geographic, textual, architectural, and quantitative information. Furthermore, the methodology I present here, procedural modeling, allows for the documentation of the decision-making process and use of source data, making clear when known or interpolated factors were used in the modeling of hypothetical scenarios such as a conjectural urban plan. Finally, the resulting three-dimensional models allow the researcher to treat the city holistically as a complex phenomenon involving spatial, material, and cultural determinants.

The aim of the procedural modeling work presented here is to create a suite of rules which generate 3D models of Hellenistic and Roman architecture and urban environments from a variety of periods and contexts. The term ‘rules’ in procedural modeling refers to the computer code that generates a 3D model. Unlike traditional 3D modeling software, in which users directly manipulate polygons to simulate form, procedural modeling entails the use of computer programming languages in the textual semantic description of a building that then generates a polygonal model. This represents not only a technical but also an epistemological difference, as the choice of modeling method can influence not merely the cost or aesthetic outcome of a project, but also how information is selected, processed, and indeed what is considered to be information instead of noise. Procedural modeling provides a framework for each stage of the transmutation of data in the modeling process to be rigorously thought out and documented, allowing 3D models to move beyond visualization to become robust research tools.

2 Previous work in 3D architectural reconstruction

While I argue that it represents a paradigm shift in 3D modeling, procedural modeling is certainly not the only valid approach to creating an architectural reconstruction model. Other, more widely used methods may sometimes be quicker, easier, and more appropriate to the task at hand. In view of this caveat, some discussion of other modeling techniques is necessary in order to make clear when procedural modeling provides a distinct advantage and when it does not.

2.1 Non-procedural modeling techniques

‘Traditional’ modeling software is based on either polygon mesh or NURBS1 modeling. Polygon mesh modeling is probably the most common form of 3D software and is represented by such popular software such as 3ds Max and SketchUp.2 Polygon modeling derives 3D form from primitive geometric forms which are scaled, rotated, and transformed as necessary (Foley et al., 1993). In this it is similar to procedural modeling, except that the polygon mesh modeler manipulates the objects directly in a visual interface, pointing and clicking to modify geometry. This type of GUI is intuitive and fast, and easily learned. However, unlike procedural modeling, it does not require that the modeler ‘spell out’ in textual form the decisions which are taking place, so the record of the modeling process, along with the opportunity to attach scholarly evidence to the interpretative model, is more likely to be lost, unless the modeler takes care to document their choices.

NURBS modeling, a feature of software packages like Maya and Rhino,3 is similar to polygon modeling in this way. However, NURBS modeling uses flexible splines rather than polygons for the creation of geometry, which allows for the realistic rendering of organic forms and curved surfaces (Piegl, 1991; Rogers, 2000). Analogous to sculpture, NURBS modeling is even more intuitive than polygon modeling, and therefore also carries the risk, when used for research models, of some scholarly rigor being lost in the process. However, it does some things well that procedural models do extremely poorly, namely the representation of curved and organic forms. NURBS modeling software Rhino and Maya have increasingly incorporated ‘parametric’ features into their packages. The terms ‘parametric’ and ‘procedural’ are sometimes used interchangeably, but in practice they represent quite different concepts. Generally speaking, ‘parametric’ signifies any technique which operates through the use of parameters (Monedero, 2000). But ‘parametricism’ has taken on a specific meaning in the context of 3D modeling for architectural design (Burry, 2003).4 Within the realm of architectural reconstruction, parameteric building components can be scripted in Maya, as they were for a 3D model of the Suleymaniye Mosque in Istanbul (Chevrier et al., 2009).

The logic of data modeling invites comparison with another 3D technique widely used in the architectural world: Building Information Modeling (BIM).5 Procedural modeling and BIM modeling are alike with regard to the emphasis on parametric management of data, yet they differ in significant ways. Like procedural and parametric models, BIM modeling software such as ArchiCAD, Revit, and Vectorworks6 create models via attributes and parameters rather than the visual manipulation of points, as in polygon mesh or NURBS modeling. However, BIM models make use of industry-specific libraries of parametric components (windows, doors, columns, slabs) and are intended primarily as a means for streamlining communication between architects and their contractors and aiding the production of construction documents and cost estimates. Because they are capable of containing a great deal of data with the model, BIM models have begun to be adopted in the cultural heritage field, for documenting vernacular architecture (Fai et al., 2013) or the preservation or refurbishment of historical buildings (Del Giudice and Osello, 2013). However, the contemporary orientation of their parametric libraries renders BIM software packages rather limited when it comes to reconstructing architecture from fragmentary archaeological remains or images (Boeykens et al., 2012).

Photogrammetry, the last 3D modeling technique I will mention, can reproduce any historical element with photorealistic accuracy and is becoming common in 3D archaeological documentation and cultural heritage.7 Using various processes, an individual object such as a work of sculpture, a column, or even an entire building may be captured using laser scanners, photographs, or structure from motion (SfM) in order to achieve an extremely point-dense, accurately photo-textured model (Böhler and Marbs, 2004; Kadobayashi et al., 2004). The software which create these models come in both open-source and commercial varieties, and include popular packages such as Photoscan and 123D Catch.8 Likewise the equipment they require can range from a simple phone camera to an expensive laser scanner. Photogrammetry is well-suited for the documentation of artifacts, as it can be used on-site as the basis for extremely accurate measurements and line drawings. For reconstruction models which rely on scant archaeological remains, however, the method is less useful.

2.2 Background of procedural modeling

In such cases, empirical evidence must be supplemented with architectural knowledge. Uniquely among computer modeling techniques, procedural modeling taps into a lineage in architectural theory dating back to antiquity. This line of thought, which was adopted by Vitruvius (1999) in the 1st century BC and later taken up variously in the 16th, 18th, and 20th centuries,9 seeks to elucidate and systematize an underlying logic of architecture. The fundamental concept of this view could be summed up by what Plato called ‘that of dividing things again by classes, where the natural joints are, and not trying to break any part, after the manner of a bad carver’ (Plato, Phaedrus, 265e). The reading of distinctions between parts, and the syntax of their joints naturally lead to an association between the logic of architectural systems and linguistic grammars. Indeed, procedural modeling can sometimes seem like a game in which large masses must be broken up into ever smaller ones until the full resolution is reached, taking care not to carve in a manner that will break any of the parts.

Procedural modeling has its roots in computer graphics techniques, such as shape grammars and Lindenmayer systems or L-systems (Prusinkiewicz and Lindenmayer, 1996), which aim to describe things efficiently in order to visualize them accurately. An efficient description operates with the minimum number of general rules that result in the widest range of variable and valid outputs. The conceptual core of procedural modeling is the work on shape grammars by Stiny and Gips (1972), who were interested in developing a computational basis for design. The computational bias inherent in procedural logic was later taken up by computer scientists looking for new techniques for graphics rendering. Similarly to L-systems, which are mathematical models for creating organic self-similar forms, procedural grammars offered an efficient way to generate multiple differentiated objects with a minimal number of rules. The procedural grammar used in this project, CGA Shape Grammars, was developed at ETH Zurich Computer Vision Laboratory and commercialized as CityEngine.10 Most current work on procedural modeling occurs within the field of computer graphics (Schinko et al., 2015), with applications in the urban planning, gaming, and entertainment industries. In recent years, archaeology and cultural heritage projects, such as the significant test cases built around ancient Rome and Pompeii,11 have also begun to explore the use of procedural modeling for the reconstruction of ancient sites (Haegler et al., 2009).

Classical architecture and its rigorous system of orders and proportions is, indeed, the architectural style most commonly cited by proponents of the mathematical logic of architecture. The adaptability of classical architecture to grammatical description has been exploited since antiquity when the ‘rules’ of its orders were codified by Vitruvius (1999), even if such systematic regularity rarely occurs unadulterated in practice. A treatise by Mitchell (1990) devoted to the subject of the logic of architecture relied heavily on classical and neoclassical examples to formulate a system for design. Many Greek and Roman cities, moreover, were built around a template that arranged a core set of civic buildings on a grid-based infrastructure.12 This modular, systematic approach to city planning resonates with the computational mindset of the digital age. In the design world, contemporary architect Rem Koolhaas ran a studio at Harvard investigating what he called the ‘Roman Operating System’ (Koolhaas, 2000), and meanwhile the Roman City has been readily adopted by simulation games such as Minecraft and CivCity Rome.

2.3 Choosing a 3D modeling technique

The purpose of the this section has been to show where procedural modeling fits within the context of other 3D modeling methods for architectural reconstruction, all of which are valid approaches which have strengths in different areas.13 Procedural modeling was chosen for the work described in the following section, for several reasons: First, it could explore the potential of script-based models to preserve decision-making processes and metadata. The ‘rules’ that create the models, therefore, were of more interest than the virtual reality aspect of modeling, and therefore the level of abstraction inherent in the procedural technique was an acceptable cost. Second, the research questions called for a method that would allow the iterative generation of many different models while preserving the decision structure driving the process. Finally, the time investment of learning the scripting language was mitigated by the longer-term goal of the work: to accumulate a robust library of procedural rules that can be expanded and amended by others to facilitate future research.14

2.4 Criteria for analysis

Of course, for the purposes of scholarship, 3D models are only as good as the value they add to research. The usefulness of 3D models for humanistic research has been thoroughly considered elsewhere (Favro, 2006; Johanson, 2009),15 therefore I will simply reiterate the basic criteria against which all 3D methodologies must be judged:

  1. The model provides insights that would not likely have arisen without it.

  2. The model provides demonstrable evidence either in support or in refutation of a hypothesis.

  3. The model effectively connects data of different types in a way which makes it easier to interrogate and analyze the data.

  4. The process of making the model has aided the understanding of the material.

If one or more of the criteria is fulfilled, the model has made a contribution to the research. This is in distinction to models which merely illustrate the arguments which were arrived at independently of the modeling process.

3 Creating the Roman City Ruleset

The impetus for creating the ‘Roman City Ruleset’,16 a library of procedural rules that generate the essential building typologies for modeling Greek and Roman cities, emerged gradually from a series of projects. Each of these investigates a different research question, but all require a comprehensive city model that could incorporate a large amount of data and yet be readily adaptable to representing different time periods, scenarios, or alternate reconstructions. In the course of realizing these projects, a workflow emerged which forms the basis of the Roman City Ruleset. The central challenge of this workflow was to integrate empirical data with procedural methods. Applying a generalized description for a Roman temple to an actual, excavated temple site in the Roman Forum, for example, tended to show the many ways in which such generalizations fall short. Therefore, the procedural rules rarely existed in a static state for long and were constantly rewritten as the need for new parameters arose. This process of writing and rewriting procedural rules led to the discovery of elements which could be unexpectedly linked together and therefore systematized. This became a knowledge-producing exercise in itself that informs, and is informed by, the research process, helping us create structural hypotheses to fill in the gaps left by incomplete remains, while allowing for the singularity of features and contexts and also the generation of plausible alternatives. This workflow is therefore an ‘integrated’ approach to procedural modeling because it aims at a holistic depiction of architectural data, incorporating geographic databases, published documentation, 3D models, semantic descriptive rules, and interactive displays. This approach is intended to be a method for elucidating the logic of architecture as well as an efficient means of creating fully realized data models of ancient cities. In the sections that follow, the steps that make up this workflow and how the procedural rules were written will be described.

3.1 Geospatial data

The workflow begins with an ArcGIS map of the site which aggregates and georeferences all relevant published plans and survey data (Fig. 1).17 A site model of the terrain is produced using contour lines or elevation points using ArcGIS Spatial Analyst’s Topo to Raster tool, which interpolates a hydrologically correct digital elevation model from the data.18 Next, a geodatabase is created which will be the container for all of the model’s metadata. Building footprints are drawn as a polygon layer in the geodatabase and fields are added that correspond to the attributes I have written into the ‘Roman City Ruleset’ and which will be displayed with the final model. In addition, fields can be created in the geodatabase that record the citation for each attribute’s source, indicate whether the value is a guess or an estimate, or provide further comments on the decision-making process associated with the model. The geodatabase is then imported to CityEngine, the procedural rules are applied to the building footprints, and the model is generated and finally exported to a web-based viewer.

3.2 Encoding architecture

So far, the process seems fairly automatic. However, this belies the thought and scholarship that must go into the authorship of the rules, which I consider to be the heart of the procedural methodology. Procedural rules are only ‘automated’ on the graphics end—the modeling still has to be done from scratch, albeit in a textual rather than visual interface. This means that procedural rules may be as general, or as specific, as the author writes them, just as a prose description of a building may be a generic gloss, or an in-depth study of a single structure. Which approach to take is entirely at the discretion of the modeler, and there are valid reasons to choose both.19 When care is taken to discern evidence from conjecture, the writing and use of procedural rules need not be an attempt to impose a generalized, unified theory on diverse instances. Instead, the differentiation to be found in the built environment will serve to enrich and diversify the rule (Fig. 2). The advantage of writing procedural rules is, then, the ability to express concisely and quantitatively the degree of known differentiation for a given variable—not only in semantic form, but in visual, three dimensional form as well.

Fig. 2

Models generated from the ‘basilica’ and ‘porticus’ rules

Although it aids in the efficiency of scene generation, there are some drawbacks to the way in which shape grammar-based procedural languages enforce a hierarchical structure upon the rules. Because a change applied to a parent shape affects all of its child shapes, one must deconstruct a building’s design in a very top-down way in order to model it. However, this may not be the way in which the building was conceived by its architects or builders. Furthermore, it is often the case that a historical building is the accretion of many layers of additions and alterations over time, in which the pieces are unrelated and stuck together and not reflective of a unified top-down schema that mirrors some Platonic abstract ideal. In a practical sense, too, shape grammars are limited by their language. For example, CGA shape grammar does not have a vocabulary to describe curved or radial geometry, and therefore building types such as theaters, stadia, and tholos temples can only be ‘hacked’ in terms of polygon splits. My rules for a theater or stadium, for example, would seem to have been a simple exercise in symmetrical, radial geometry (Fig. 3). However, the procedural grammar was not well-equipped to describe such geometry, which made the writing of this rule a rather tortuous and long-winded process.20

Fig. 3

Models generated by the Stadium/Theater rule

3.2.1 Temple rule

Therefore, in order to write effective procedural rules it is necessary work backward to some extent, taking into consideration the rule’s intended purpose and use. For example, a defined set of building layouts with well-documented proportional systems gave the ‘Temple’ rule (Fig. 4) a set of constraints that determined its structure (Wilson Jones, 2009). In this case, the crucial parameters—for example plan type, column order, and column diameter—are often available from archaeology. Therefore, this rule operates ‘conditionally’, using many if/then clauses, for example: case peripteral || closedAlae:offset(-column_diameter/2,inside)s(scope.sx-n*2+column_diameter,'1,'1)center(xz)Cella1(n) This translates to a phrase that might sound like: ‘If the peristyle is peripteral or has closed alae, the cella will have a space the width of one intercolumniation on either side’.

Fig. 4

Variations generated by the Temple rule

A procedural rule that uses CGA shape grammar works from the most undifferentiated level of massing and breaks that volume down into ever-smaller parts which give the model its detail. In the Temple rule, the first steps establish the correct width, length, and elevation of the stylobate. Then, the parameters set by the GIS-imported object attributes tell the rule what kind of steps to give the podium. Next the cella and peristyle are extruded as basic masses. Depending on what plan type and column order have been specified in the parameters, these masses are then split further according to the proportional system that has been defined in the attributes. Finally, non-procedural assets are inserted into the subdivided geometry to form columns and column capitals, roof tiles, and antefixes.21 The temple chooses between three versions of columns assets, each with a different resolution, depending on the level of detail selected in the procedural rule. This greatly simplifies the process of exporting models for different outputs, such as high-resolution rendering versus low-polygon models for interactive online models.

3.2.2 Domus rule

While it reuses pieces of the same code that makes up the Temple rule (e.g. colonnades, textures, colors, and assets), the ‘Domus’ rule (Fig. 5), which I wrote for the Roman City Ruleset to describe Roman houses, operates slightly differently. It can either be built upon specific building footprints from the geodatabase, or tied to a dynamic street network that updates automatically as the streets are changed. This rule was meant to generate city infill for a much larger area than is actually known through archaeology, and not much evidence exists about the actual appearance of ordinary houses from the period in question. Therefore, this rule operates primarily in a ‘stochastic’ mode, generating random variations to mimic the variegated texture of an urban fabric. A typical clause would be: case backyard == false:split(z){∼1*rand(.8,.9): Mass |'rand(.01,.05): NIL} (‘for any given row of houses with no backyard, make the depth of each individual house a random value between 80% and 90% of the maximum depth’). The goal here is not a detailed single building, but that the overall massing be of the appropriate scale, level of density, and form to provide a plausible holistic view of the city. Of course, if a researcher possessed much data for houses, the rule could be written to reflect that. The beauty of procedural modeling is that is malleable to the researcher’s source material and aims.

Fig. 5

Variatons generated by the Domus rule

The Domus rule begins with lots that are generated from a street network. This street network might be imported as line shapefiles from GIS, or drawn by hand. Each time a street is moved or altered, the blocks and lots that adjoin it are parametrically altered as well. The initial steps of the Domus rule compensate for any slope that might be found in the underlying terrain and by constructing a level foundation for the lot. The lot is then subdivided, randomly, into houses of varying widths within a margin that is determined by a factor set in the attributes. Each house is set back from the road to a slightly different degree, in order to provide realistic variation in the streetscape. Finally the undifferentiated mass of each house is extruded and given a random seed variable that it will carry through all the subsequent steps of the procedural rule. This randomized variable will be used at different stages to ensure that each house is unique and slightly different from its neighbors. Each distinctive feature of the domus is slightly varied each time the seed is updated: the color of the walls and roof, the height of the floors, the number of floors, whether or not the house has an atrium, front porch, or back yard, the width and number of windows and doors. Some attributes can be determined manually if a specific house type is desired. For example, choosing attr houseType = SHOPS will generate the façade of each house as a shop with a wider opening and a counter. An extended portico can be created in front of a row of houses by choosing attr porch = FRONT PORCH", whereas if no porch is desired, attr porch = NONE can be chosen. For a realistic and randomly varied assortment, attr porch = MIXED would be the default setting.

3.2.3 Integrated structure of the rules

The suite of rules was designed to minimize duplication of code, therefore certain functions, such as colors, textures, and common architectural elements such as colonnades, entablatures, and roofs were separated into modules which are referenced by each collating rule, such as a building type. A maximum number of variations can thus be generated with minimal duplication of code. Modules can be referenced by many different building types, for better consistency and efficiency. The suite of rules thus acts like a library of modular building blocks which can be combined to form different typologies, which in turn make up a city.

3.2.4 Attributes and parameters

Attributes and parameters reflect one of the most malleable and interesting aspects of the procedural modeling process, because it is through these that variation and specificity are introduced. Attributes are the descriptors, named by the modeler, that inform a given model.22 Some examples for the Temple rule define elevation, column order, and door width. Parameters are the values which fulfill the attribute, for example: attr elevation = 10attr order_ = “IONIC”attr door_width = 1.3 As in the Temple and Hellenistic Houses rules described above, attributes may be hard-coded, stochastic, conditional, or probabilistic. Attributes can take their values from objects (usually from the geodatabase attribute tables), or they can be ‘mapped’ onto the scene using a graphical map layer.

3.3 Use and documentation of sources

Each of the rules of the Roman City Ruleset was written around a ‘default’ set of proportional relationships that aims to appropriately accommodate actual data inputs. The rules were designed to model buildings that are no longer extant or have limited evidence, so the formal schema were derived from many sources, including comparable buildings, historical documents, and contemporary analysis. A simple example of the incorporation of primary and secondary sources into a ‘default’ rule, and its application to a specific reconstruction, is the Monumental Arch rule (Fig. 6). Mark Wilson Jones (2000, p. 58) outlined 22 ‘propositions’ concerning the principal proportions of the Arch of Constantine, many of which take as a common module the column height, which also equals one-third of the overall length of the building. Wilson Jones argues that the proportions of this Late Antique monument (c. 315 AD) were based on the Arch of Septimius Severus, built a century earlier, and that the use of simple arithmetic relationships based on squares and triangles (ad quadratum and ad triangulatum) in both monuments was typical of Roman elevation design in the Imperial period (Wilson Jones, 2000, pp. 60–1 passim). The detail he provides and the rationale of the ‘representativeness’ of this proportional scheme make it a good starting point for a procedural rule. But because the arches I will model are more likely to be known merely by the dimensions of their foundations rather than the height of their columns, I have reconfigured Wilson Jones’ primary dimension (2000, p. 59, fig. 13) as a factor of the overall length. This allows the modules to be expressed as: const M = length/3const m = M*.375const p = m*.0933 If one simply wanted to model the Arch of Constantine, these terms would be sufficient. But the design of monumental arch facades was incredibly diverse and inventive, and the rule must be robust enough able to accommodate a variety of different inputs. The Fornix Fabianus, for example, was a single arch, built in the Roman Forum in 121 BC, and survives only in fragments (Richardson, 1992, p. 154). In order for the procedural rule to be useful in representing the Fornix Fabianus, Wilson Jones’ proportional scheme was combined with the evidence provided by an extant arch closer to the Fornix Fabianus in form and date: the Augustan Arch at Susa, from the late 1st century BC.

Fig. 6

Triple and single arch generated from the Monumental Arch rule

Using the rubric of Wilson Jones’ modules, I found that the proportions of the arch at Susa could be expressed in the same terms with an additional expression as well as the variable attribute arch_type, thus: @Group("General",2)@Range("SINGLE", "TRIPLE")attr arch_type = "SINGLE"const single = arch_type == "SINGLE"const triple = arch_type == "TRIPLE" const M = case triple: length/3else: length/2const m = M*.375const p = m*.0933const k = p*4.75 The writing of procedural rules is essentially this process repeated over and over, as each application of the rule will be based on a different type of input and require a re-examination of the relevance of the source material.

Tracking the source for each expression in the rule is therefore essential. A simple working solution is to ‘comment’ the appropriate line of code with a citation and/or notes: const M = length/3 // cf. Wilson Jones (2000, p. 59, fig.13) While ‘constants’ such as this one are internal to the rule, the ‘attributes’ (such as ‘arch_type’) are modifiable in each instance. Therefore, the source of the variable attributes attached to an individual model must also be documented. This can be done at the level of the geodatabase in the form of a bibliographic note that specifies how attributes were derived from sources. Any attributes not cited in this note are understood to be default values, and for these the annotated code provides the citation, as demonstrated above. The best way to present such annotation as part of the final model is a challenge that I am currently working on. It is hoped that eventually a more streamlined workflow for presenting annotations of the code and geodatabase will be developed, perhaps though a Python script or other customized interface, since this functionality is not provided in the software. For the present,we shall have to be content that the relevant information is being preserved, and is readily accessible.

4 Application to research questions

4.1 Augustan Rome

The Augustan Rome project is an example of how procedural modeling can be incorporated into the workflow of a diverse range of outputs. In this case, the research question concerned how the use of building materials in Rome changed before, during, after the reign of Augustus (Fig. 7).23 In order to visualize this, the dates for each building phase and its associated material were first entered into the geodatabase.24 I then wrote a clause into a ‘master rule’ for the scene that determined the year to be visualized and changed the color and form of each building accordingly. Here, we chose to avoid realistic colors and textures in order to diagrammatically visualize change over time, and to highlight the visual impact of certain building materials, such as brick, travertine, and marble. The output platform in this case is the CityEngine web viewer, which has the advantage of using webGL to operate seamlessly in browsers, while preserving all the metadata from the original geodatabase. A user can compare different time periods side-by-side with a slider to change between views, turn layers on and off, or query the metadata using a search filter. For example, the search term ‘Augustus’ returns all the buildings either named after or donated by Augustus, with the rest of the city grayed out. In order to show the impact of a flood on the city, a layer showing the extent of the flood level can be toggled on and off.25

In the Augustan Rome project, the advantage of procedural modeling lays in the relative ease26 with which we were able to turn a large database of the buildings and topography of Augustan Rome into a comprehensive city model, with all the metadata attached and visible in the final 3D product. One challenge we faced was making the 3D content simple enough to keep the file size small for ease of downloading and streaming. Therefore much of the detail we were capable of generating had to be sacrificed. Procedural modeling helps simplify the process somewhat by allowing for level of detail to be built into the procedural rules by the author. Therefore, the same model may be easily repurposed for a high-resolution detailed rendering, or simplified if the research goal does not require realism.

Fig. 7

Screenshot from the Augustan Rome project

4.2 RomeLab

The challenge of dynamically streaming procedural content in a gaming context was taken up in another project, RomeLab,27 which also makes use of the Roman City Ruleset (Fig. 8). In contrast to the diagrammatic rendering of the previous example, here the procedurally generated models were exported to the Unity Game Engine,28 which allowed the creation of a web-based, multiplayer game environment where up to 30 avatars can ‘walk’ through the space at one time, interact with objects, or even fly above the city streets.29 Once again, one of the principal advantages of procedural modeling in this case was its ability to easily rapid-prototype alternative reconstructions. In one phase of the project, six different ‘scenes’ representing different building phases were presented side-by-side (Saldaña and Johanson, 2013). The first-person avatar perspective provided a different, very instructive viewpoint from which to judge the impact that results from even a slight alteration to terrain elevation or building proportions. Impacts such as these are sometimes extremely difficult to appreciate in a standard birds-eye view of a 3D model, let alone in a two-dimensional drawing.

Fig. 8

Screenshot from RomeLab, in Unity game engine

4.3 Procedural Magnesia

My procedural modeling work on the Roman City Ruleset began with RomeLab, extended to Augustan Rome, and now comprises typologies for temples, houses, basilicas, stoas, curia, monumental arches, arcades, theaters, stadia, streets, and colonnaded avenues.30 My most recent project, ‘Procedural Magnesia’, expands the ruleset to model cities in Asia Minor through the Hellenistic and Roman periods. This work uses the procedural Roman City Ruleset to create a holistic city model that serves as a test-bed for hypothetical reconstructing the urban plan and ritual landscape of Magnesia on the Maeander (Fig. 9).

Fig. 9

Screenshot from Procedural Magnesia

5 Future directions and concluding thoughts

Eventually, I plan to make the Roman City Ruleset available to others who are interested in adapting, expanding, and making use of it for their own research. I am also interested in working with large data sets to comparatively model multiple cities. Another possible direction for future work is suggested by recent developments in computer vision work on procedural modeling, which attempt to reverse-engineer procedural rules from existing buildings (Mathias et al., 2012; Vanegas et al., 2012; Thallera et al., 2013). This is an approach which could hold potential for architectural historians, perhaps as a method of ‘distant reading’ large corpora of buildings and comparing the findings against theoretically driven procedural rules.

My aim in this paper has to been to introduce procedural modeling as a powerful new methodology that has yet been underexploited by the Digital Humanities, perhaps because the technical focus of much of the literature has obscured its potential for directly addressing humanistic concerns. Procedural modeling allows the investigator to approach visual and 3D content through a rigorously syntactic and process-oriented framework, and preserves the hierarchy of decisions that result in a visual interpretation of archaeological evidence. Although the use of 3D models in support of scholarly arguments is still in the early stages, procedural models are extremely information-rich and the ways in which they can be used to aid research are just beginning to be explored.


  • 1 NURBS stands for ‘non-uniform rational B-spline’ (Rogers, 2000).

  • 2 3ds Max is an Autodesk product, the industry standard for rendering and animation: http://www.autodesk.com/products/3ds-max/overview. SketchUp, formerly a Google product, is now produced by Trimble, and is considered a ‘user-friendly’ 3D modeling package: http://www.sketchup.com/.

  • 3 Autodesk Maya is a powerful but complex software which is good at simulating physical dynamics, such as liquids, fire, and air: http://www.autodesk.com/products/maya/overview. McNeel Rhinoceros is a simpler NURBS modeler optimized for the jewelry and industrial design fields, though also used widely in architecture: https://www.rhino3d.com/.

  • 4 With a capital ‘P’, ‘Parametricism’ most likely refers to the controversial manifesto by Patrik Schumacher (2008).

  • 5 A useful summary of BIM can be found at http://www.graphisoft.com/archicad/open_bim/about_bim/ and http://www.autodesk.com/solutions/building-information-modeling/overview. See also Azhar (2011).

  • 6 Graphisoft ArchiCAD: http://www.graphisoft.com/archicad/; Autodesk Revit: http://www.autodesk.com/products/revit-family/overview; Nemetschek Vectorworks: http://www.vectorworks.net/.

  • 7 Many examples of projects that incorporate these techniques can be found in the International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences: http://www.isprs.org/publications/archives.aspx.

  • 8 Agisoft Photoscan: http://www.agisoft.com/; Autodesk 123D Catch (free app) http://www.123dapp.com/catch.

  • 9 An early proponent of procedural methods for architectural design was Rodrigo Gil de Hoñatón (c.1500–1577), who devised structural and proportional rules for the design of Gothic churches. In the 18th century, Enlightenment theorists Marc-Antoine Laugier and Quatremère de Quincy posited an origin for architecture in the classical vocabulary of ancient Greece, precisely because of the (procedural) linguistic analogy that underpinned its system of interrelated parts, and because they saw language as a prerequisite to culture and civilization. In the 20th century, architects saw the similarities between procedural logic and computational processes as potential for new design methods (see work by Stiny, Gips, and Mitchell, discussed below).

  • 10 A precedent for my current project is Pascal Mueller’s 2010 PhD dissertation which used classical temples as a case study for demonstrating the potential of CGA shape grammar, the procedural language that eventually became the core of ESRI CityEngine. Mueller’s (unpublished) dissertation and Parthenon rule, which is distributed as an example with CityEngine software, were indispensable in my efforts to master CGA shape grammar. Mueller, as one of the principal authors of the CGA shape grammar language, was a co-founder of ETH spin-off company Procedural, which first released CityEngine. However, his work was oriented to the field of computer science and his study of temples focused on peripteral temples of the Doric order. The rules I present here are my own work, as a full restructuring and rewriting of the code, with the addition of much new material, was necessary to implement a wider agenda geared toward a humanities audience. For an overview of the architectural application of CGA shape grammar, see Mueller et al. (2006).

  • 11 See the Rome Reborn Project, http://romereborn.frischerconsulting.com/. The procedural aspects of this project were published in Dylla et al. (2010). My work on Rome for UCLA’s RomeLab investigates the Roman Forum of ca.186–160 BC, some 500 years before the period represented by Rome Reborn, therefore the procedural content of RomeLab is entirely original work. On Procedural Pompeii, see http://www.esri.com/software/cityengine/resources/casestudies/procedural-pompeii (accessed 3 September 2014).

  • 12 Though much research has been done on this topic, I will mention here two important works: On Greek grid-planned cities and housing, see Hoepfner and Schwandner (1986); On Roman architectural urbanism, see MacDonald (1988).

  • 13 Most 3D projects, including my own, involve a combination of modeling software and approaches. In the case of my project, it was unrealistic to procedurally model sculptural architectural elements (such as a Corinthian column capital), and so these were modeled in other software and imported as assets. The procedural rule controls which asset is selected and where it is placed (to suit attributes such as level of detail, or column order, for example).

  • 14 The procedural rules described in the article were developed by the author over a period of 5 years.

  • 15 See also the principles for cultural heritage visualization set out in the London Charter (2009): http://www.londoncharter.org/.

  • 16 The ‘procedural rules’ mentioned and cited below all belong to the ‘Roman City Ruleset’, were written for Esri CityEngine, and are the work of the author.

  • 17 To ‘georeference’ means to ‘[align] geographic data to a known coordinate system so it can be viewed, queried, and analyzed with other geographic data. Georeferencing may involve shifting, rotating, scaling, skewing, and in some cases warping, rubber sheeting, or orthorectifying the data’ (ESRI GIS dictionary, http://support.esri.com/en/knowledgebase/GISdictionary/popup/georeferencing)

  • 18 A ‘hydrologically correct’ terrain realistically models watershed distribution and properties. An overview of the ‘Topo to Raster’ tool, with references of technical papers, can be found at: http://desktop.arcgis.com/en/desktop/latest/tools/spatial-analyst-toolbox/h-how-topo-to-raster-works.htm#GUID-989894B7-1C35-4B46-8142-ACF3BFA6553C.

  • 19 For example, a generic rule for a massing model when scant evidence is available, or an architecturally complex rule to compare dimensioning schemes on two similar buildings.

  • 20 Because of the lack of radial functions, the segments in the sphendone (rounded part) of the stadium or theater have to be manually drawn in ArcGIS (currently an imperfect process as well) and each face separately named numerically.

  • 21 I have chosen to import these detailed elements as non-procedural assets due to their complex, idiosyncratic, or curvilinear geometry.

  • 22 For more on how attributes operate within the CityEngine software, see the manual at http://cehelp.esri.com/help/index.jsp?topic=/com.procedural.cityengine.help/html/manual/toc.html.

  • 23 This project was led by Diane Favro at UCLA’s Experiential Technologies Center. Project Web site: http://etc.ucla.edu/projects/augustan-rome.

  • 24 For this project, much of the data were drawn from Lothar Haselberger’s Mapping Augustan Rome (2002).

  • 25 The 3D terrain model follows the reconstructed contour map of the Digital Augustan Rome project (see http://digitalaugustanrome.org/volumes/read/making-the-map). A plane at 15 m above sea level was intersected with this terrain, and the areas where this plane appears above the terrain designates the flood extent.

  • 26 The current version of the model, the result of several iterations, was the product of several months’ discontinuous labor but was built on the procedural rules of the Roman City Ruleset, which had been in development for several years.

  • 27 RomeLab (http://romelab.etc.ucla.edu/) is led by Chris Johanson at UCLA’s Experiential Technologies Center.

  • 28 Unity Game Engine: http://unity3d.com/.

  • 29 The code that powers the multiplayer server was developed specifically for RomeLab.

  • 30 A taxonomy of the rules with images, a list of parameters, and documentation are being compiled at http://www.mariesaldana.com/projects/procedural-buildings/.


View Abstract