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

This paper, which received the Fortier Prize for best paper by a young scholar, was presented at the 2014 Digital Humanities Annual Conference in Lausanne, Switzerland. The full text of the talk is below. 

A expanded and revised version of this paper was published in Digital Scholarship in the Humanities and is available here.

For a technical, step-by-step overview of this workflow, see this tutorial.

This paper presents a suite of procedural rules for creating 3D models of Roman and Hellenistic architecture and urban environments. The term ‘rules’ in procedural modeling refers to the computer code that generates a 3D model. Unlike traditional 3D modeling software such as SketchUp or 3ds Max, which use 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 requires that each stage of the transmutation of data in the modeling process is rigorously thought out and documented, allowing 3D models to move beyond visualization to become robust research tools.

Procedural modeling has the potential to address a number of issues of concern to digital humanists related to 3D archaeological reconstructions. An important advantage of procedural methodology is that it allows for the rapid prototyping and interactive updating of 3D content. The use of attributes and parameters enables scholars to visualize change over time and gauge the impact of various factors on the built environment. Furthermore, these attributes and parameters can be tracked and harnessed as valuable geospatial data through the use of GIS software and of interactive visual displays. Of particular interest for archaeologists and architectural historians is the ability to test hypothetical reconstructions of ancient architecture in a fully realized urban context. Crucially for humanists, 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 thus enhances the scholarly value of architectural reconstructions by providing a platform for the comparison and refutation of 3D visualizations.

More than merely a tool or technique, procedural modeling represents a distinct methodology in that requires the modeler to critically analyze a structure and describe its part-to-whole relationships with language as a prerequisite to visual representation. Procedural modeling has its roots in computer graphics techniques, such as shape grammars and L-systems, which have two aims: describing things efficiently in order to visualize them accurately. [1] An efficient description operates with the minimum number of general rules which are informed by variable attributes. For example, rather than modeling millions of individual plants, a forest can be generated by defining the formal rules of just a few types of trees which are given a random “seed value” while causes them to be varied in size and distribution. Likewise, a large city might contain a limited number of building types which conform to certain general rules with conditionally defined parameters. For example, such a rule might state that if a building is located in a commercial zone, it will have a flat roof and a height of between 4 and 6 stories, whereas if it is located in a residential zone, it should have a pitched roof and a height of 1 – 2 stories.

Classical architecture, in particular Roman cities, are an ideal test case for the procedural modeling of archaeological sites. [2] The adaptability of classical architecture to grammatical description has been exploited since antiquity when the ‘rules’ of its orders were codified by Vitruvius. Roman cities were built around a template that arranged a core set of civic buildings on a grid-based infrastructure. This modular, systematic approach to city planning resonates with the computational mindset of the digital age. Contemporary architect Rem Koolhaas ran a studio at Harvard investigating what he called the “Roman Operating System”, while Minecraft and Civ City Rome readily adopted the Roman City as a simulation game. [3]


For archaeologists and architectural historians, procedural modeling isn’t just for generating random infill or populating large scenes. When applied to empirical and incomplete data from archaeological sites, the process of writing and re-writing procedural rules can be a knowledge-producing exercise in itself that informs and is informed by the research process. I titled this paper an “integrated” approach to procedural modeling because the workflow I will describe aims at a holistic approach to architectural data – incorporating geographic databases, published documentation, 3D models, semantic descriptive rules, and interactive displays. The examples I will describe use procedural modeling in this way – as a method for elucidating the logic of architecture as well as an efficient means of creating fully realized models of ancient cities. The procedural modeling software I used for my projects, ESRI CityEngine, was chosen largely because it is fully integrated with ESRI’s ArcGIS products and therefore readily accommodates actual data from topographic and archaeological surveys.

workflow overview

This is the true test of rule-based modeling. Applying a generalized description for a Roman temple to an actual, excavated temple site tends to show the many ways in which such generalizations fall short. On the other hand, the process can potentially lead to the discovery of elements which can be unexpectedly linked together and therefore systematized. Also, the use of three dimensions situates data in a much richer spatial context than a two-dimensional plan drawing is capable of providing. With regard to archaeological reconstruction, this helps 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.

The procedural modeling of a site begins with a GIS database which aggregates published plans and survey data. Because the scene will ultimately be visualized in three dimensions, a site model of the terrain is produced using contour lines or elevation points. Building footprints are then located in the digital map, and assigned attributes that will automatically be referenced by the procedural rules and 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, and the model is generated and finally exported to a web-based viewer.

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. In order to demonstrate this, I will describe two rules which were written with very different applications in mind.

Node-hierarchy, textual, and 3D view of the Temple rule in CityEngine

In order to write effective procedural rules you must work backward to some extent, and know what the rule will be used for.  For example, the ‘Temple’ rule was written in order to accommodate a defined set of building layouts with well-documented proportional systems. Although complex, the rule must be controlled by the smallest possible number of crucial parameters. In this case, these parameters – for example the plan type, column order and column diameter — often available from archaeology. Therefore, this rule operates conditionally, using many if/then clauses, such as “If the column order is Ionic, the height of the column will be 9 times the column diameter”. Or, “If the plan is peripteral, the inner cella with have entablature on all four sides”.

Variations: Tuscan temple
Variations: Hellenistic temple and propylon

The rule follows a modular structure, whereby the main rule references several smaller rules: each of the column orders, as well as the entablature, pediment, roof, and finally a rule which calls the assets and textures. Thus, a maximum number of variations can be generated with minimal duplication of code. The smaller modules can also be referenced by other 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.

Modular structure of the rules

The ‘Early Republican Domus’ rule, on the other hand, operates slightly differently. Instead of being built upon specific building footprints from the geodatabase, it is tied to a dynamic street network and 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.

Node-hierarchy, textual and 3D view of the domus rule in CityEngine
Node-hierarchy, textual and 3D view of the domus rule in CityEngine

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

Domus rule variations
Domus rule variations

Procedural modeling can be incorporated into the workflow of a diverse range of outputs. One project that used the rules I worked on was interested in how the use of building materials in Rome changed before, during, after the reign of Augustus. [4] In order to visualize this, the dates for each building phase and its associated material were first entered into the geodatabase. I then wrote a clause into a “master rule” for the scene that determined the year to be visualized and changed the color of each building accordingly. Here, we avoided 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.

Metadata from the selected model is viewable in the sidebar

The output platform in this case is the CityEngine web viewer, which has the advantage of using webGL to operate seamlessly in web browsers, as well as 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, for example to see the extent of flood waters in the city…flood

or query the metadata using a search filter. Here, the search term “Augustus” returns all the buildings either named after or donated by Augustus, with the rest of the city greyed out.


In this project, the advantage of procedural modeling lay in the 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, as is always the case when presenting large city models on the web, 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.

RomeLab project in Unity Web player
RomeLab project in Unity Web player

The same procedural rules were used to different ends in the RomeLab project. 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. 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.

Six rapid-prototyped scenes for different phases in the forums development
Six rapid-prototyped scenes for different phases in the forum’s development

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.

Procedural rules for Rome adapted for cities in Asia Minor
Procedural rules for Rome adapted for cities in Asia Minor

Besides temples and houses, the rule suite currently comprises typologies for basilicas, stoas, curia, monumental arches, arcades, theaters, stadia, and streets. I am currently extending and adapting the Roman City rule suite to model Greco-Roman cities in Asia Minor. Specifically, in my dissertation project I will use the rules to model hypothetical reconstructions of the city grid of Magnesia on the Meander in Turkey.

Unity Web Player night scene in the Artemesion sanctuary at Magnesia on the Meander (Turkey)
Unity Web Player night scene in the Artemesion sanctuary at Magnesia on the Meander (Turkey)

Because almost nothing remains of the streets at Magnesia, the advantage of procedural modeling for my research lies in its ability to dynamically model urban networks. In order to test my research hypotheses of how regional cults and natural topographical features affected the city layout, I will be able to quickly generate entire city models that adapt to the actual terrain of the site. Of course, for the purposes of scholarship, 3D models are only as good as the value they add to research. To this end, the GIS database, as well as the text of the procedural rules, will allow my decision making process to be accessed and evaluated along with the text and visual material, either in support or refutation of my argument and perhaps adding a few unexpected discoveries along the way.

Despite its many advantages, procedural modeling does have a few drawbacks. Not least of these is the limited choice of software platforms. I have relied entirely on CityEngine for my work. Although it is the main commercially available procedural software, it is currently being targeted and developed for the urban planning, production design, and gaming markets, and is therefore not necessarily optimized for scholarship or teaching. Furthermore, procedural engines are based on proprietary high-level graphics programming languages which are extremely time- and resource-consuming to produce, and therefore few open-source alternatives exist. There are inevitably pitfalls to any methodology that is tied to a single software. Like all digital projects, procedural models are subject to obsolescence if they are not carefully preserved and archived so that their substantive content remains available and usable even as the rate of change in software platforms and hardware infrastructure increases exponentially. It is my hope that if procedural modeling becomes more widely adopted as a research method, more alternatives will become available.

A second concern which should be more thoroughly addressed is that of annotation, attribution, and vetting. In order for procedurally-generated models to be viewed as scholarly output there must be must be a framework in place for reviewing, annotating, and publishing the work. Fully annotated, text-based rules certainly go a long way toward providing this, but how legible is this content to non-specialist peer reviewers, or those interested in vetting the historical sources and arguments? How can such models be ‘published’? Although procedural modeling certainly preserves the decision structure of a model, at present, we lack a means of taking the paradata associated with the rules and turning it into a human-readable exposition of data to support a scholarly argument. One possible approach would be to use a Python to script to generate a formatted report as the models are generated. This would require additional annotation within the rules that reveal sources, or indicate which parameters are randomly interpolated and which are based on archaeological evidence. A further question is how this report could be integrated with the 3D content, or kept separate.

Another challenge is rule-based modeling’s inherent bias for finding isomorphism and ignoring singularities. In other words, how do we deal with the ubiquitous cases where the so-called ‘rules’ turn out to be broken? How can researchers invested in procedural modeling avoid the trap of over-generalization? Can procedural modeling instead be used as a tool for analyzing difference?The process-oriented nature of procedural modeling helps researchers to avoid common 3D visualization traps such as aiming for photorealistic verisimilitude, or arriving at one ‘true’ reconstruction. Yet it must be acknowledged that the hierarchical nature of rule-based modeling could remain limiting in many ways.

Last but not least, procedural modeling carries a steep learning curve and is not a methodology to be undertaken lightly. The time it takes to learn the scripting language, at least for a researcher such as myself with no programming background, is significant. This makes procedural modeling difficult to incorporate into a collaborative or teaching workflow where most of the work will be done by undergraduates with only a few weeks to absorb the new technology and produce a project. One way of addressing this would be to allow students to work with an already complete, clearly written set of rules, and indeed a goal for my work on Roman Cities is to produce just such a ruleset, which could be adapted and utilized by anyone with modest 3D modeling experience.

My aim here has to been to introduce procedural modeling as a powerful new methodology that has yet been underexploited by the Digital Humanities. Contrary to traditional 3D modeling methods, procedural modeling forces the investigator to approach visual and 3D content through a rigorously syntactic and process-oriented framework. This framework preserves the hierarchy of decisions that result in a given 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] Stiny, George, and James Gips. 1972. “Shape Grammars and the Generative Specification of Painting and Sculpture.” In The Best Computer Papers of 1971, edited by O Petrocelli, 125–35.

[2] Rome was the site of another early application for procedural modeling of ancient cities. See the Rome Reborn Project. The procedural aspects of this project were published in Dylla, Kimberly, Bernard Frischer et al., 2010. “Rome Reborn 2.0: A Case Study of Virtual City Reconstruction Using Procedural Modeling Techniques,” in CAA 2009. Making History Interactive. 37th Proceedings of the CAA Conference March 22-26, 2009, Williamsburg, Virginia (Archaeopress: Oxford, 2010) 62-66. Also see Procedural Pompeii.

[3] Rem Koolhaas, “Roman Operating System”, Mutations (2001).

[4] Project led by Diane Favro, with Brian Sahotsky.