(A version of this essay was published as “An Integrated Approach to the Procedural Modeling of Ancient Cities and Buildings”. Digital Scholarship in the Humanities, Vol.30, Supplement 1, Dec. 2015, pp.48-63.)

In order to read the disparate evidence for Apollo and Dionysos in a spatial context, it is necessary to expand the analytical toolset. Scholars of the ancient world have long been preoccupied with the quest to interpret the many-layered picture that results from combining evidence from ancient texts, empirical archaeological data, and geographical landscape surveys. 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 in the making of the Magnesia model. This aids in making clear when known or interpolated factors were used in the modeling of hypothetical scenarios, such as Magnesia’s conjectural urban plan. Finally, the resulting three-dimensional models allowed for the holistic analysis of the city as a complex phenomenon involving spatial, material, and cultural determinants.

The reconstruction of Magnesia used in this study makes use of a suite of procedural 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 scripting 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.

Previous Work in 3D Architectural Reconstruction

3D architectural reconstructions may be created in the service of a wide range of research agendas. The technique used to create a model should therefore be matched with the motivation for making it. 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.

Non-Procedural Modeling Techniques

‘Traditional’ modeling software is based on either polygon mesh or NURBS modeling [1]. 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. 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, 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) [2]. Within the realm of architectural reconstruction, parametric building components can be scripted in Maya, as they were for a 3D model of the Suleymaniye Mosque in Istanbul (Chevrier et al, 2009). ‘Procedural’ modeling, on the other hand, connotes the use of parameters within a rule-based modeling approach that goes beyond a means of manipulating 3D data, to imply a logic of form. The term ‘procedural’ itself reflects a focus on the process or recipe for a given set of outcomes.

Parametric modeling invites comparison with another 3D technique widely used in the architectural world: Building Information Modeling (BIM). 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 Vectorworks 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 - often off-the-shelf products ready for purchase) 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 et al., 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 (Boeykins et al., 2012).

Another method that is becoming common in 3D archaeological documentation and cultural heritage is photogrammetry, which can reproduce any historical element with photorealistic accuracy [3]. 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 et al., 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. 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.

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 articulated by Vitruvius in the first century BC and later taken up variously in the 16th, 18th, and 20th centuries [4], 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 in architecture 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. 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 (Dylla et al., 2010) and Pompeii, 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 in his Ten Books on Architecture, even if such systematic regularity rarely occurs unadulterated in practice [5]. A treatise by William J. 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 [6]. 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 et al., 2000), and meanwhile the Roman City has been readily adopted by simulation games such as Minecraft and CivCity Rome.

Choosing a 3D Modeling Technique

The purpose of 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 with strengths in different areas [7]. I chose to use procedural modeling for the modeling of Magnesia for several reasons: First, I wanted to explore the potential of script-based models to preserve decision-making processes and metadata. The ‘rules’ that create the models, therefore, were of more service to my research goals than the virtual reality aspect of modeling, and therefore the level of abstraction inherent in the procedural technique was an acceptable cost. The steep learning curve and time investment of learning the scripting language was mitigated by the longer-term goal of my work: to accumulate a robust library of procedural rules that can be expanded and amended by others to facilitate future research [8]. Most importantly, my research questions called for a method tha t would allow the iterative generation of many different models while preserving the decision structure driving the process. The first question, regarding the city plan, relied in large part on the malleability of the interactive street grid in the procedural model to allow the testing of many hypothetical reconstructions. Second, the analysis of the interface of ritual and terrain was greatly aided by the ability to quickly represent conjectural models for buildings that had great impact on the urban environment but whose spatial presence had not been considered fully due to limited evidence. Finally, though it is not included in the procedural vocabulary, the very resistance of the cave to this type of modeling underscored its significant absence from the built form of Magnesia. This insight ties into my broader argument about the way in which the cave, exemplified by the home of Apollo at Hylai, resisted architecturalization in the Greek world.

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; Frischer and Dakouri-Hild, 2008; Johanson, 2009) [9], 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.

Creating the Roman City Ruleset

The impetus for creating the ‘Roman City Ruleset’, 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 re-written as the need for new parameters arose. This process of writing and re-writing procedural rules led to the discovery of elements which could be unexpectedly linked together and therefore systematized. As will be shown below, 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. I consider this workflow 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. For more information on the ruleset, including downloads, documentation and tutorials, see the project page on GitHub. In the sections that follow, I will describe the steps that make up this workflow and how the procedural rules were written (a workflow tutorial can be found here).

Workflow overview.

Reconstructing Terrain

The workflow begins with an ArcGIS map of the site which aggregates and georeferences all relevant published plans and survey data. 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 (DEM) from the data. Reconstructing and modeling ancient topography is as much of an interpretative process as the modeling of ancient buildings. When it is available, archaeological data that shows the elevation of a building’s foundation can aid in the reconstruction of the ancient terrain level. However, this is rare in Magnesia, where most of the city lies several meters below the modern topography, and is obscured by erosion, building accretion, and other factors. Geophysical surveys of the modern landscape, particularly a 2003 survey by the Turkish government, provided the elevation points and contour lines which were used to reconstruct the macro-features of Magnesia’s terrain, such as the location of steep slopes, ravines, and flat areas. For the larger area including Mt.Thorax for which no maps were available, this data was combined with contours derived from a terrain model ‘grabbed’ via SketchUp’s Google Earth interface [10]. The two datasets were combined in ArcMap to create the overall terrain model.

Ideally, the data would be modified to reflect the accretion of silt in the plain which covers most of Magnesia’s urban structures [11]. The Artemision, Stadium and Theatron have been mostly excavated to the depth of their ancient ground level. Yet, for the rest of the city, there was simply not enough information to determine the amount by which the terrain should be adjusted. Because silt accretion mostly affects the flat area of the plain and therefore would alter the terrain in degree rather than profile of slope, it was decided to use the modern terrain elevation as the basis for the present reconstruction. The area of Magnesia that the city grid would have covered is fairly flat, with a slope affecting only the southernmost blocks. It is presumed that the grid did not extend into the foothills (Humann, 1904, p. 21; Bingöl, 2007, p. 128). Consequently, the alignment of the grid with the terrain does not present any particular challenges, as it does at more steeply-sloping sites such as Sagalassos, Priene, and Pergamon.

Also conjectured is the course of the Lethaios River, which certainly has changed in the course of millennia. Indeed, the outline shown in Humann’s drawings from 1904 does not correspond exactly to the winding of the modern riverbed. In this case, as with the terrain model, I have followed contemporary data, since the shape of the river in Humann’s day was still far removed from its course in antiquity, and determining the precise route at that time is beyond this scope of this study.

Geospatial Data

Screenshot from the Magnesia geodatabase.

When setting up a digital map, 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.

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

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. However, the procedural grammar was not well-equipped to describe such geometry, which made the writing of this rule a rather tortuous process [12].

Models generated by the Stadium/Theater rule

Temple Rule

In order to write effective procedural rules it is necessary to 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 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.” This statement might be expanded or modified by additional clauses to express changes in this particular proportional rule over the course of antiquity.

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 [13]. 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.

Domus Rule

While it re-uses pieces of the same code that makes up the Temple rule (e.g. colonnades, textures, colors, and assets), the ‘Domus’ rule, 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, although general principles were derived from analogous evidence from other sites. 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% -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.

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

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.

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. 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 = 10
attr 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.

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. Mark Wilson Jones (2000, 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-61 passim). The detail he provides as well as 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 re-configured 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/3
const m = M*.375
const 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.

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/3
else: length/2
const m = M*.375
const p = m*.0933
const 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 on which will be tackled in the next phase of the digital project. 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.

Application to Research Questions

In order to more effectively demonstrate the research potential of procedural modeling and the Roman City Ruleset, I will briefly introduce two prior projects centered on the city of Rome before addressing aspects of modeling specific to Magnesia on the Maeander. The two Roman projects are a methodological ‘lineage’ for Magnesia, and they also illustrate the range of outputs that are possible to achieve with the same core workflow.

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 and during the reign of Augustus [14]. In order to visualize this, the dates for each building phase and its associated material were first entered into the geodatabase [15]. 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 greyed 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 [16].

Screenshot from the Augustan Rome project

In the Augustan Rome project, the advantage of procedural modeling lay in the relative ease 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 re-purposed for a high-resolution detailed rendering, or simplified if the research goal does not require realism.

RomeLab

The challenge of dynamically streaming procedural content in a gaming context was taken up in another project, RomeLab, which also makes use of the Roman City Ruleset [17]. In contrast to the diagrammatic rendering of the previous example, here the procedurally-generated models were exported to the Unity game engine, 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. One of the many research objectives the model served was the investigation of the spatial impact of temporary and permanent structures on performance and spectacle in the Roman Forum. 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. Factors 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.

Screenshot from RomeLab, in Unity game engine.

Modeling Magnesia

Much of the Roman City Ruleset was originally written for the city of Rome in the 2nd c BC – 1st c AD and in order to model Magnesia had to be expanded to adapt to Greek models which extend back to the 5th c BC. The Magnesian case study, while falling within the architectural vocabulary of classicism, belongs to a different culture and environment, and chronologically precedes the Roman exempla. Therefore, nothing from the ruleset was assumed, and all definitions were examined for their appropriateness to the present context. Some of the rules, such as the Temple rule, had already been developed with Hellenistic precedents in mind and needed little modification since they were already quite comprehensive. Therefore, it was a simple matter to conjecturally represent the temple of Dionysos as an Ionic building, based on prototypes from Pergamon and Teos. The Roman temple was based on the similar footprint of the temple dedicated to Augustus in Antioch in Pisidia. The Theater/Stadium rule was custom-written around the Magnesian examples, as was the altar of Artemis. Some general rules such as bridges and streets were easily integrated, while in other cases, for example the city walls, the rule was written as simply as possible to avoid an excess of detail which would not have contributed to the purposes of this study. The baths and apodyteria are represented as generic mass models, since we only have enough evidence to determine an approximate scale. For the temples of the Dioscuri and Sarapis, of which nothing is known except their locations and dedicatory inscriptions, simple massing models are used as well. No matter the complexity, each rule was built around temporally-inflected attributes in order to visualize the development of the city over time. Four versions of the city model were created, representing the Archaic, Classical, Hellenistic, and Roman periods.

Conjectured procedural representation of the Roman temple north of the Lethaios River.

The Hellenistic era houses were modeled based on the type of Priene as represented by Hoepfner and Schwandner (1987, p.171, Fig. 172). As such they show very little variation in plan or elevation, and since we have no evidence of Hellenistic houses from Magnesia and do not know how they were aligned to major streets, I have chosen to leave the visualization of the housing fairly generic and to vary the orientation of the housing within individual blocks somewhat more than is allowed in Hoepfner and Schwandner’s reconstructions. In this version, orientation is procedurally controlled, with house lots being automatically aligned according the width of adjacent streets.

Insula model with regular orientation (left); with mixed/random orientation (right).

The case study of Magnesia tests the efficacy of the Roman City Ruleset in modeling a complete city in multiple temporal variations from start to finish. It serves as a trial of the ruleset’s adaptability to different eras and contexts within the classical world. The model’s usefulness for the purposes of this study will be an indication of the viability of the procedural methodology and holistic urban models for future research. Far from being a modeling exercise which exists solely within the confines of a single project, the procedural rules that drive the reconstruction of Magnesia are designed to form the basis of a continually growing and evolving library of architectural knowledge for Greco-Roman world.

My aim 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. 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 datasets 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 (Vanegas et al, 2012; Mathias 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’ or ‘thick reading’ large corpora of buildings and comparing the findings against theoretically-driven procedural rules. 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.

Notes

[1] NURBS stands for “non-uniform rational B-spline” ↑
[2] With a capital ‘P’, ‘Parametricism’ most likely refers to the controversial manifesto by Patrik Schumacher (2008). ↑
[3] Many examples of projects that incorporate these techniques can be found in the International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences. ↑
[4] 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 eighteenth 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 twentieth 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). ↑
[5] See Wilson Jones (2009, passim) on the problems of applying Vitruvian theory in the field. ↑
[6] 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). ↑
[7] Most 3D projects, including this one, involve a combination of modeling softwares 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 (for example, to suit attributes such as level of detail or column order). ↑
[8] The procedural rules described here were developed over a period of five years. It should be noted that my approach pushes the limits of the CGA shape grammar and therefore required a period of time to master the scripting language. It is, however, possible to use procedural modeling in a way which makes use of simpler rules but derives many of the same benefits of GIS-based 3D analysis. ↑
[9] See also the principles for cultural heritage visualization set out in the London Charter (2009): ↑
[10] The terrain download feature can now be performed in the current release of CityEngine (2018) with certain types of licenses, eliminating the contouring step.↑
[11] A good example of this process is Romano, et. al., “Making the Map”, from the Digital Augustan Rome project. This article demonstrates the challenges of modeling historical terrain even for a site as well-documented as ancient Rome. ↑
[12] 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. ↑
[13] I chose to import these detailed elements as non-procedural assets due to their complex, idiosyncratic, or curvilinear geometry. ↑
[14] This project was led by Diane Favro at UCLA’s Experiential Technologies Center. ↑
[15] For this project, much of the data was drawn from Lothar Haselberger’s Mapping Augustan Rome (2002). ↑
[16] The 3D terrain model follows the reconstructed contour map of the Digital Augustan Rome project. A plane at 15 meters above sea level was intersected with this terrain, and the areas where this plane appears above the terrain designates the flood extent. ↑
[17] RomeLab is led by Chris Johanson at UCLA’s Experiential Technologies Center. ↑