Part 3 – Sources and Paradata

Before going into the bulk of how to model an archaeological site and why do it, I would like to spend a moment discussing the research that should be at the basis of the model itself. The fact that 3D Reconstruction is in its infancy brings many advantages and disadvantages to the table. On the one part, it is exciting to think there is so much we do not know as it means endless applications are there just waiting to be discovered. On the other hand however, there is a distinct lack of consistent methodology between projects and while some publication are clearly founded on extensive research (Dawson et al. 2011 amongst many others), others seem to be more loosely interpreted.

324t343t

Fig.1 – The first steps in modelling, based on a plan of the site to scale.

This is one of the reasons behind ‘paradata’, a term that has recently been applied to the field. To understand paradata we need to first discuss metadata. Especially in computer science, many authors have lamented the inability to replicate experiments involving code (Hafer and Kirkpatrick 2009; Boon 2009; Ducke 2012; Hayashi 2012). In the words of Marwick:

“This ability to reproduce the results of other researchers is a core tenet of scientific method, and when reproductions are successful, our field advances (Marwick 2016, pp.1).”

and

“A study is reproducible if there is a specific set of computational functions/analyses (usually specified in terms of code) that exactly reproduce all of the numbers and data visualizations in a published paper from raw data (Marwick 2016, pp.4).”

Essentially the debate is that publishing results is not enough, but that instead we should include additional information, such as settings used in a program or the raw code. This collection of information is referred to as ‘metadata’. Some authors on the other hand have taken it a step forward, arguing that we should include descriptions of the process, a discussion of the choices made and the probabilities (Denard 2009; Beacham 2011, D’Andrea and Fernie 2013). This ‘paradata’ is best described in the London Charter, which is the first attempt to creating a methodology in 3D Reconstruction:

“Documentation of the evaluative, analytical, deductive, interpretative and creative decisions made in the course of computer-based visualisation should be disseminated in such a way that the relationship between research sources, implicit knowledge, explicit reasoning, and visualisation-based outcomes can be understood (Denard 2009, pp.8-9).”

Given that a major critique in 3D Reconstruction is accuracy (Miller and Richards 1995; Richards 1998; Devlin et al. 2003; Johnson et al. 2009), paradata is our way to defend ourselves. While it is impossible to create the perfect model, by demonstrating the process behind the reconstruction allows a user to understand the interpretation given and draw their own conclusions.

Roman Villa 4

Fig.2 – A highly speculative Roman Villa. Without knowledge of the process it is impossible to know how accurate each element is.

One of the elements we have mentioned previously are sources. While the process itself has to be methodical in order to gain accurate results, the sources provide the wireframe upon which the interpretation can take place. It therefore essential that the sources are well researched and well documented. For this purpose I like the classification proposed by Dell’Unto et al. (2011), which sees different categories based on accuracy:

  • Reconstruction by Objectivity: sources based on in situ elements, like plans, 3D scans, archives.
  • Reconstruction by Testimony: illustrations, literary sources, notes.
  • Reconstruction by Deduction: elements that can be deduced from in situ remains, but that are not actually there.
  • Reconstruction by Comparison: based on other sites, this is actually quite an important one as a lot of features carry on between remains of the same regions.
  • Reconstruction by Analogy of Styles: especially for decoration, looking at other stylistic elements that have been preserved can help make the whole model look more realistic.
  • Reconstruction by Hypothesis: an essential part of reconstruction, but the most inaccurate.

Of course, the more we go down this ladder, the more inaccurate the sources are. Yet it is by combining all the different sources that we get the finished model. Paradata can help with determining which sources were used for each part of the model, and therefore provide information of the model as a whole.

house6

Fig 3 = Partly completed model of a Greek house, based on plan, excavation reports and site comparison.

In conclusion, there are many sources that can be used when constructing a model and although some are more precise than others, all of them contribute to the final result. If they are applied methodologically and the process is recorded, we can provide an accurate and reliable reconstruction.

Over the next posts I will start looking at SketchUp for modelling, although the ideas will carry over to other software such as 3Ds Max.

REFERENCES:

Beacham, R. C. (2011). Concerning the Paradox of Paradata. Or, “I don’t want realism; I want magic!”. Virtual Archaeology Review Vol.2 No.4 pp.49-52.

Boon, P., Van Der Maaten, L., Paijmans, H., Postma, E. and Lange, G. (2009). Digital Support for Archaeology. Interdisciplinary Science Reviews 34:2-3 pp.189-205.

D’Andrea, A. and Fernie, K. (2013). CARARE 2.0: a metadata schema for 3D Cultural Objects. Digital Heritage International Congress Vol.2 pp.137-143.

Dawson, P., Levy, R. and Lyons, N. (2011). “Breaking the fourth wall”: 3D virtual worlds as tools for knowledge repatriation in archaeology. Journal of Social Archaeology 11(3) pp.387-402.

Dell’Unto, N., Leander, A. M., Ferdani, D., Dellepiane, M., Callieri, M., Lindgren, S. (2013). Digital reconstruction and visualisation in archaeology: case-study drawn from the work of the Swedish Pompeii Project. Digital Heritage International Congress pp.621-628.

Denard, H. (2009). The London Charter: for the computer-based visualisation of cultural heritage.

Devlin, K., Chalmers, A. and Brown, D. (2003). Predictive lighting and perception in archaeological representation. UNESCO World Heritage in the Digital Age.

Ducke, B. (2012). Natives of a connected world: free and open source software in archaeology. World Archaeology 44:4 pp.571-579.

Hafer, L. and Kirkpatrick, A. E. (2009). Assessing Open Source Software as a Scholarly Contribution. Communication of the ACM Vol.52 No.12 pp.126-129.

Hayashi, T. (2012). Source Code Publishing on World Wide Web. International Conference on Advanced Information Networking and Applications Workshops pp.35-40.

Johnson, D. S. (2009). Testing Geometric Authenticity: Standards, Methods, and Criteria for Evaluating the Accuracy and Completeness of Archaeometric Computer Reconstructions. Visual Resources 25:4 pp.333-344.

Marwick, B. (2016). Computational Reproducibility in Archaeological Research: Basic Principles and a Case Study of Their Implementation. Journal of Archaeological Method and Theory pp.1-27.

Miller, P. and Richards, J. (1995). The Good, the Bad, and the Downright Misleading: Archaeological Adoption of Computer Visualisation. In: Huggett, J. and Ryan, N. Computer Applications and Quantitative Methods in Archaeology. Oxford: Tempus Reparatum pp.19-22.

Richards, J. D. (1998). Recent Trends in Computer Applications in Archaeology. Journal of Archaeological Research Vol.6 No.4 pp.331-382.

Basics of Coding for Archaeology: Scripts and Text

Before reading this post, please look at my previous post. Seriously, it will mean nothing to you otherwise. Yesterday I went through the basic layout of Game Maker, and explained the difference between rooms, sprites and objects, as well as basic commands using events and actions. Today we will expand this last concept and look at how we can display prewritten text on the screen. The main aim of this series of post is to give an overview of how we can use gaming software to create programs that can help archaeology.

As we saw last time we could easily write some text on the screen by using a series of action drop boxes that game maker has prepared for us, and in some cases this is an efficient and easy approach. But I’ve found that when making a more complex program you can go insane with the number of action drop boxes you would have to use. Hence I like to use Game Maker Language to tell the program exactly what want it to do.

The first step is to create a new object. We can ignore sprites (the visual component) this time as the object is not going to be visible on screen. We can then rename the object something like text_ctrl. This object will have a series of commands attached to it that it will follow at a certain point we decide, the event. In this case the event is going to be the “Draw” event, which means the action happens at all times. The “Draw” event is like the Step event I mentioned yesterday, but the former is connected with making things appear on the screen, so anything visual usually ends up in this event. If for example we are deciding how an object moves, then the step event is more appropriate, while creating a rectangle with certain dimensions is in the realm of the Draw event.

Image

Having decided when the action happens (all times) we then go to the “control” panel and choose the “execute script” action. This is where the coding happens, and where it all gets complicated yet interesting. Copy and paste the following:

{

draw_text(50,60,“Archaeology is pretty much the best thing ever.”);

//draws the text at position, creating new line when reached position

}

Save the object and then create a room in which add the object, which will appear as a blue ball with a question mark. Then run the game (green arrow) and hopefully you should get a screen that displays the message.

Image

What you are doing is running a script. You are telling the program to draw a piece of text, using what is called a function (draw_text), and you are giving it some parameters to follow. First of all, you are telling it where the text goes. The rooms are divided up by a grid, each point of which is recognisable by an x and a y. The point in the top left corner has an x of 0 and a y of 0, while all other points on the screen have an x and a y depending on where they are. The further down they are on the page, the more the y is going to increase, and the further across the point is, the higher the value of x. In this case we have told the program that we want the text to be at the point x=50 and y=60.

We then told it what we want to say, using a “string”, which you can recognise because they are within the “ ”. Within the “ “s you can write whatever you want, and use whatever symbols you want, without making any difference to the code itself. Outside them any small change can really create problems with the code.

A few more things to notice. I’ve used the brackets { and } to open and close a part of text I want to be separate from other parts of text. This means it will work as a block, and if many functions are within it they too form a block. At the moment they seem pointless, but they will become more and more important. Also, the ; closes a function, making space for another, while the ( and ) brackets are used to specify the parameters of the function. Finally the // and everything that follows is a comment, a way for me to put a note to myself to know what is going on. The program recognises the //s and ignores anything that follows on the same line.

A last piece of code is a slightly extended version of the one before:

{

draw_text_ext(50,60,”Archaeology is pretty much the best thing ever, except for making origami, because at least origami doesn’t pretend it has an edge that is nowhere near where you expect it, meaning you spend three days looking for something you thought would take you two minutes to find.”,-1,150);

//draws the text at position, creating new line when reached position

}

The function here is draw_text_ext() and it allows a few more things to take place. First of all It sets a limit to the line you are writing, in this case x=150. When the code gets to that point it automatically creates a new line underneath, at a distance specified by the -1 (which for some reason is the standard number to use). This way you can write long pieces of code without running out of the screen.

Image

Using Gaming Software for Archaeology

Image

Say you have a large archaeological site with many features and much to show. Say you want your site to be accessible to everyone who has an interest in it, regardless of their knowledge of the period or of archaeology in general. How would you go about showing what you have found in the most appealing and simple way to the general public?

Of course there is not one single answer to this question, and many methods of public engagement are available to you. However I’d like to suggest a newer and more visually stimulating way of presentation, by combining archaeology with gaming software.

I personally enjoy playing around with Game Maker from time to time, a program specifically designed to create games in a simple fashion, and that can easily be adapted to create any type of program. But beware, Game Maker is not an easy program. Behind a simple-looking interface hides a complex script writing process that means you have to know at least a bit of programing to do anything good.

Given the nature of the program the possibilities are endless, and the final result depends solely on the imagination and time available. One of the projects I was working on was to create an interactive plan of sites, which allowed the user to select different time periods and then click on the features to receive information about them. Having already created a 3D version of the plans in Sketchup for a different project I decided to use these again in order to save time and improve the visuals.

Image

I then proceeded to create a mechanism by which clicking on the features would direct you to another “room” where the information was. This was done by creating invisible boxes on the 2d surface and then telling it what to do when a specific box was selected. I then created buttons to go through the different time periods using a similar principle. Finally I wrote the code and made sure it appeared within a box next to an image of the selected feature.

ImageImage

I cannot give you the exact way in which I achieved this unfortunately for a number of reasons, first of which it would be pages and pages of text and code, but the basic idea is that I played around with the software until I achieved what I wanted: a series of snapshots of the site in 3D that allow navigation through time and that show exactly what we have found with images and text.

Image

Another project I’m currently working on in instead a program for kids that allows them to interact with a roman soldier and help him carry out tasks. The aim of this is of course educational, and it displays the archaeological finds in a fun and interesting way that kids will enjoy. This one is made using a series of rooms that change every time you click on a certain portion of the map, depending on what the task is, i.e. if the soldier asks you to find the enclosure, then clicking on the enclosure changes the text.

Image

And these are only some of the ideas that can be made into reality. As odd as it may sound to use gaming software to create archaeology, the potential is great. Games like Assassin Creed or Skyrim have massive cities within them, with which the player can interact, so how much harder can it be to reconstruct entire sites and allow players to walk through them in order to learn more about them?