Wireframe Mesh


This section outlines the methods we used to create the build. We began with a series of 3D photomodels collected by the Gabii archaeological project and stored as a series of meshes in the .obj format. Ceramic data was collected from the Gabii Project Archaeological Recording Kit (ARK) database.

Acquiring ceramics data from the ARK Database

First a python scraper is employed to collect relevant ceramic counts for each SU in Area F returned by an ARK query. Ideally, this would be accomplished by simply making an API call to the ARK and requesting the relevant ceramic data. Due to a bug in their API that prevents such a call, we have implemented a workaround by manually performing a search on their website, downloading the HTML results page, and scraping the relevant data with the following python script.

Click to Show/Hide ceramicHTML.py

This script generates a CSV file with entries for each SU that it finds in the HTML results file, as well as how many ceramics of each type were found in that SU.

Processing Photomodel Meshes

Importing all of the Area F meshes into unity required substantial processing. Thankfully, the open source sofware Meshlab includes a tool to export current filters as a script in the .mlx format. Meshlab Server can then be run using a batch script to process a large number of meshes in a relatively short amount of time.

The first step is to process one mesh manually in meshlab using the necessary filters. Because of the quantity of meshes we sought to import into unity, we needed to simplify the meshes substantially in order to keep the file size small. We used three subsequent iterations of Laplacian Smooth and Quadratic Edge Decimation with texture (QED) in alternation. When running the QED, we used a percentage reduction rather than a targeted number of faces so that the same values could be applied to all meshes. For the first iteration of QED we reduced the number of faces in the mesh to 30%, and subsequent iterations reduced it 50%. Each iteration of Lalplacian Smooth used the default three passes to smooth the mesh.

After this, the meshlab scripting tool can be used to export the filters applied to this mesh as a .mlx script which can be run on other meshes through meshlab. See the link below for the script used in processing the meshes in this project.

Click to Show/Hide Meshlab Script

After exporting the filters as a .mlx script, we used Meshlab Server to apply the script to every mesh from area F. To accomplish this, we used the multiMesh Scripting Tool by Andrew Hazelden which is available on his website. This tool works through a series of batch scripts which run the program Meshlabserver.exe using parameters defined by the script. Meshes stored in the tool's input folder are run using the specified .mlx script and saved in the tool's output folder.

Unfortunately, the script did not work exactly as intended and it required modifications before we could get it to work. When the batch script set the command directory to the input folder, it did not save the outputs to a different folder. The problem was eventually resolved by moving the output and scripts folder to the inside of the input folder. See below for a simplified version of the batch script used for running meshlab server.

Click to Show/Hide Meshlab Server Batch Script

The batch script was able to process all of the meshes in a little less than an hour, although it took multiple attempts to get the right script, and even still a few of the meshes required manual edits to clean up minor errors. Although the script presented above did preserve the texture coordinates for the meshes, the textures still had to be manually coppied over. Additionally, the high resolution textures were too large to be of use in Unity and had to be simplified seperately.

Importing the Photomodels into Unity

After all of the meshes were simplified, they were imported into uinty by dragging and dropping them into the project Assets folder. Materials had to be created for each of the meshes to connect them to the textures. Additionally, since the meshes were georeferenced using a total station, they followed the convention of spatial coordinates in which Z represents elevation. Unity, like most video game engines, uses Y to represent elevation. To resolve this, all of the meshes were added to an empty game object which was rotated 270 degrees on the X axis. This transformed all of the meshes simultaneously so that they were right-side up.

Also, due to the extremely high quality of the original textures, the web player will crash from a memory overload if they are left unmodified. We used the batch resize feature in the GIMP plugin BIMP to shrink them considerably. The original files were 8192x8192px and we resized them all the way down to 256x256. Despite being a fraction of a percent of the original resolution, the new textures seemed to show enough detail for our purposes. The player could probably handle them being several times larger in all honesty.

Visualizing the data in Unity

Once all the processed meshes have been imported into Unity and situated in the scene, we have to implement the visualization of the ceramic data we collected above. The first step is to add a Particle System component to each photomodel in the scene that has ceramic data related to it (note that not all SUs contain ceramics). Once this has been done, a script is added to each of these photomodels that will control that Particle System. These scripts are identical from one SU to another except for the variables that get instantiated at the beginning and represent the count of each ceramic type in the particular SU that the script is attached to.

Click to Show/Hide C# Particle System Controller

With the Particle System controllers properly implemented, the last thing to do is to generate a UI with buttons that will make the appropriate function calls to the controller scripts and manipulate the Particle Systems attached to each SU.


This page contains an overview of the objectives of the project and a description of ceramic styles.