PROCEDURAL MODELING FOR RAPID-PROTOTYPING OF MULTIPLE BUILDING PHASES

RomeLab is a multidisciplinary working group at UCLA that uses the city of Rome as a laboratory for the exploration of research approaches and dissemination practices centered on the intersection of space and time in antiquity. In this paper we present a multiplatform workflow for the rapid-prototyping of historical cityscapes through the use of geographic information systems, procedural modeling, and interactive game development. Our workflow begins by aggregating archaeological data in a GIS database. Next, 3D building models are generated from the ArcMap shapefiles in Esri CityEngine using procedural modeling techniques. A GIS-based terrain model is also adjusted in CityEngine to fit the building elevations. Finally, the terrain and city models are combined in Unity, a game engine which we used to produce web-based interactive environments which are linked to the GIS data using keyhole markup language (KML). The goal of our workflow is to demonstrate that knowledge generated within a first-person virtual world experience can inform the evaluation of data derived from textual and archaeological sources, and vice versa.


INTRODUCTION 1.1 RomeLab: Problematics and Goals
This paper presents a multi-platform workflow for the rapidprototyping of historical urban cityscapes through the use of geographic information systems, procedural modeling, and interactive game development.
Buildings and cities evolve and change over time.While 3D reconstructions of architecture typically focus on the state of a building at one point in history, even the most focused architectural study must be seen within the larger context of the continual transformation of the built environment.Moreover, the interpretation of archaeological remains is often highly contentious and will yield multiple conflicting reconstructions, each of which creates a cascade of changes that ripple through the adjacent, reconstructed buildings and the underlying, reconstructed terrain.Therefore, the technologies used to reconstruct architectural modification must themselves be adaptable to quick yet precise interrogation of multiple iterations of a given model.
Our project, RomeLab * , investigates the historical topography and urban fabric of Republican Rome through the iterative, rapid prototyping of interactive 3D models.We employ a methodology that ties together multiple data-handling platforms, and we emphasize the scholarly value of such shifts of perspective in creating a feedback loop through which, for example, the analysis of 3D content in a first-person game engine informs the creation of procedural architectural rules, which in turn serve to arbitrate between contentious published 2D reconstruction plans.
In this sense, the term 'procedural' in our approach, instead of merely indicating the use of procedural software to produce * http://romelab.etc.ucla.eduoutputs that visually approximate our hypothesis, emphasizes the process of making and re-making iterative models and subjecting them to quantitative as well as experiential analysis in multiple platforms.The goal of our workflow is not merely to produce a game as such, but rather to demonstrate that knowledge generated within a first-person, virtual world experience can inform the evaluation of empirical archaeological data, and vice versa.Our research questions demand a computational solution, but not one that can be provided by a single software package.As scholars, we must actively mediate between the strengths of various digital tools and constantly navigate between different forms of data.

Related Work
The city of Rome has been the focus of previous work that uses procedural modeling for architectural reconstruction, most notably the Rome Reborn 2.0 project (Dylla et al., 2009).Our project, RomeLab, extends this research but differs from the previous work in three important ways.First, while Rome Reborn reconstructs the entire city of the Imperial period (320 CE), a time period with a comparatively large amount of surviving archaeological evidence, our current work focuses specifically on the Roman Forum in a much earlier time period, the Roman Republic (509-27 BCE), for which testimony from ancient authors, more than archaeological evidence, guides the reconstructions (Johanson 2009).This differing source material required the use of an entirely new dataset and the creation of new procedural rules for the architecture.Second, our work focuses on the rapid-prototyping of iterative models that demonstrate continuity and change over time and variable interpretation within one time period, rather than the exhaustive documentation of a single period.Third, we emphasize the cross-platform co-operability of models in various types of software that facilitate dialogue between different modes of research, including geographic data analysis, procedural shape grammars, and experientially-driven interaction.

GIS
Our workflow begins by aggregating archaeological data in a geographically located database.Archaeological and geological survey data from various sources is included, as well as reconstruction plans and drawings (Fig. 1).Using the GIS software ArcMap, a terrain heightmap raster is interpolated from the elevation points and contours of the survey data (Fig. 2).

Procedural Modeling
Next, the building models are derived from the ArcMap shapefiles in Esri CityEngine using procedural modeling techniques.Procedural modeling facilitates the creation of lowcost models of entire urban areas that normally would be prohibitively time consuming and technologically memoryheavy to construct.Architectural attributes are defined and attached to specific locations from the archaeological database, when evidence exists, or they are assigned randomized functions that distribute variation over the urban fabric.Procedural rules were created for various building typologies, including houses, temples, basilicas, shops, and roads, thus allowing the efficient generation of a complete urban model.
The procedural rules were created to be modular in structure, meaning that semantic descriptions for different architectural elements such as Tuscan, Doric, and Ionic entablatures, pediments, and colonnades are aggregated in rules for building typologies which aggregate these components and allow for the application of specific parameters to reflect actual archaeological dimensions.
Where data is not available for Rome, the typological rules for the basilicas and houses of the Republican period are based on archaeological evidence from Cosa, Italy.The preliminary Etruscan temple type was based on descriptions in Vitruvius' De Architectura.An additional project that reconstructs the Hellenistic-Roman city of Magnesia on the Meander likewise uses the Vitruvian guideline for Ionic temples.In this case, Vitruvius himself apparently derived his rules from the temple of Artemis Leukophryene at Magnesia by the architect Hermogenes (Fig. 3).at Magnesia on the Meander.

Terrain Generation
The GIS-based terrain model is adjusted in CityEngine to fit the building elevations.The interface between the terrain and buildings proved to be one of the most critical, as well tendentious, steps in the process of reconstructing the hilly topography of the Republican Forum.The ground level of early Rome differed greatly from what can be seen and measured today, and reconstruction of the ancient terrain is complicated by the many layers of modification that have accreted over thousands of years.CityEngine facilitated the process of procedurally generating multiple versions of the street network to negotiate the difference in elevation between the documented building footprints and the reconstructed Republican-era topography (Fig. 4).In some cases the elevation of a building foundation was unknown and therefore had to be visually and procedurally calibrated to the terrain along with the streets.The adjusted terrain heightmap is then re-exported from CityEngine and converted to a RAW file for input into Unity.Usually, the process of adjustment of the terrain with the models was repeated several times in both CityEngine and Unity, as sharp elevational changes often only became apparent in the embodied viewpoint of the virtual world.
Figure 4. Aligning the terrain and models in CityEngine

Virtual World
The terrain and city models are combined in Unity, a game engine which we used to produce web-based interactive environments (Fig. 5).We utilize custom scripts to introduce avatars that can navigate the virtual world in first-and thirdperson modes, and interact with other players as they explore the space alone or collectively.† Alongside the game environment, we integrate a textual feature that is geographically linked to the model using keyhole markup language (KML).This allows for the creation of scholarly narratives that are spatially linked to specific geocoded points in the model.Therefore, first-person navigation in the game-world retains its connection to the original coordinates derived from the GIS database, helping researchers use the experiential content of the 3D model to critique quantitative and textual arguments.
Figure 5. Complete model of the Republican Roman Forum in Unity

SELECT FINDNGS
At present, the procedural modeling process supports a series of interrelated investigations into the staging and stagecraft of ephemeral events in the republican city.Ranging from a visual semiotic analysis of Roman funerary processions, to an interrogation of the evidence for the earliest Roman arenas, these studies use the surrounding context as a laboratory to be explored through avatar-based, first-person experience.The primary research goal is to pose and answer questions that require direct interaction with the multiple possibilities presented by the surrounding, hypothetically constructed, † The KML script parser and interface was developed by Tipodean, http://www.tipodean.com.diachronic environment.Our current line of inquiry is concerned with what happened in these spaces and to these spaces and not, strictly speaking, how these spaces might have appeared at one point in time.Therefore, the procedural process is, in part, a means to a different end.

The Process
The procedural process is particularly well suited to historical projects where the quantity of unknown evidence outnumbers the known data.To be sure, the process is quicker, more agile, and more efficient than traditional CAD/CAM modeling (Haegler et al., 2009).More important, the ability to fill in gaps computationally resolves the specific problems raised by reconstructing the ancient cityscape of an urban area defined by hills rather than planes.
For example, our workflow makes it easier to ask questions about sightlines when the underlying evidence requires that the fabric of the city shift slightly due to scholarly debate, or temporal change demands that the cascade of modifications to the digital environment be handled computationally rather than constructed by hand and mouse.Our research requires that we stand (virtually) at possible viewing locations to assess what could be seen, by whom, and what it might have meant.To move or simply to enlarge a building by five meters-a change that might be motivated by the building's transformation over time or a scholar's proposed alternate reconstruction-requires rebuilding the intersection between the surrounding topography, rerouting the street system, regenerating the terrain, and reevaluating the results in multiple navigational systems.The hilly topography of Rome was extremely difficult to reconcile with the disparate elevations of building remains.Working from GIS data, we oscillated between manipulating and re-generating models in CityEngine, and investigating the actual first-person scale of these changes in the Unity virtual world.In this way we were able to evaluate iteratively the changes made in the model by taking an embodied virtual walk through the procedurally generated space.We thus built a feedback loop where experiential insights were used to refine the procedural rules, which in turn generated a new model that was injected into the virtual world for re-evaluation.
Beginning and ending with a GIS, our process lets us create virtual worlds that are bounded by and fixed in geographic space.We ensure strict adherence to our original data source by "growing" our digital models directly from the documentary data we have defined within a GIS.By ending with a model that is likewise geo-enabled, the virtual world can be literally and virtually truth-tested through the use of the KML, where a user can test in the virtual world a hypothetical view from a vantage point based on a real-world coordinate, derived from a satellite image.
Figure 6.View of the performance area

A Diachronic Analysis
An iterative, diachronic, embodied view of the Roman Forum (250-79 BCE) lets us track the shape and location of performances spaces as they moved, expanded, and relocated over time.
It is well known that dramatic performances and gladiatorial games were staged in the Roman Forum during the bulk of the Republic.Where precisely the games were held, and how exactly the audience was able to attend is more difficult to ascertain.By standing in the digital model, and generating versions of the city transformed over time, the shape of the performance space is revealed (Fig. 6).The central plaza transforms from a space flanked by private homes of men and gods to one closed in by the vertical forms of the early Roman basilica (Fig. 7).7).Jutting from the second story of each of these basilica were the ancient equivalent of grandstands, the maeniana, balconies from which, it is said, the Romans would gather to watch their games.The basilica served other functions, to be sure, but to let the populace watch the games from these balconies necessarily required that the monuments were sited in close proximity to the games themselves.A curious pattern emerges when viewing the diachronic development of this building type within the virtual world system (Fig. 7).The first basilica is situated on the north, next to the Roman Senate House, in close proximity to the speaker's platform of the city.The next basilica appears on the other side of the Senate House, followed by, in a few years, a rebuilding and enlarging of the first basilica.It is as if the performance space for the games has expanded from a small localized zone, closely tied to a restricted area of the Forum, to a much larger expanse, filling up the plaza itself.The next basilica, flanking the Forum, establishes a new axis for performance.The prime seats now face the central Forum, rather than the small area where the original performances will have occurred.The last basilica, that of Opimius, completes the grandstands of the original location, transforming the Forum from a place of localized performance to one that included elevated "box seats" available for almost any conceivable performance location (Fig. 6).

Expansion to Other Sites
The GIS -CityEngine -Unity workflow has proven adaptable to other sites and research agendas and should be considered a viable solution for those interested in creating data-driven, 3D representations.We are currently expanding our investigations to the Hellenistic-Roman city of Magnesia on the Meander in present-day Turkey (Fig. 3), where ongoing survey work by our team at the archaeological site will be incorporated into the modeling process.This includes the development of an extended suite of procedural typologies, such as a rule for generating classical theaters and stadiums (Fig. 8), as well as the integration of the 3D modeling work with a larger digital site survey and geodatabase.The challenge for our team will be to incorporate real-time data into the simulations, which will perhaps point out new lines of empirical research.

Documentation of Sources and Process
Procedural methods offer an efficient solution for making transparent the underlying source material used and process employed to build a 3D model.Since the need for "paradata" and transparency in the building of cultural heritage models is paramount (Bentkowska-Kafel et al. 2012), a priority for our work is the incorporation of source material into the threedimensional narrative.This entails the documentation of the entire decision-making process including the formulation of procedural rules, and the rendering of this data as interactive with the game interface.Because the legitimation of our research relies heavily on the interpretative process, rigorous documentation of each step and its and connection to the source material is essential.Thus, the work undertaken by RomeLab seeks to advance nonlinear, process-oriented and transparent Digital Humanities practice.

Figure 1 .
Figure 1.Layering source data in ArcMap

Figure 3 .
Figure 3. Two Ionic Temples generated from the same procedural rule: the temple of Artemis (top) and Zeus (bottom) at Magnesia on the Meander.

Figure 7 .
Figure 7. Building phases in the Roman Forum.Arrows indicate the newly constructed basilicas for each phase.The transformation was far from instantaneous.The first basilica appeared in roughly 210 BCE, and the next, (commissioned by and named for the censor Marcus Porcius Cato) was built in 184 BCE.The basilica Fulvia was added in 179 BCE, and the Basilica Sempronia, in 170 BCE.Fifty years later, in 121 BCE, the Roman consul Lucius Opimius constructed the Basilica Opimia alongside the temple of Concord on the northern side of the forum (Fig.7).Jutting from the second story of each of these basilica were the ancient equivalent of grandstands, the maeniana, balconies from which,

Figure 8 :
Figure 8: Theatron and Stadium at Magnesia, generated from one generic procedural rule