[back]

(links updated Feb. 2001)
Page Built and Maintained by Eileen Vote  

SYSTEM IMPLEMENTATION:

Data Modeling Possibilities

The Archave system was initially developed to allow users to access a three-dimensional model of the Great Temple site excavations and to interact with site data, trenches and artifact finds.  It was posited that, since the Brown excavation team had kept good records of the stratigraphy, layers and balks in the various trenches of the site and in situ architectural and artifact finds, it would be possible to visualize the data via a three-dimensional model in a VR environment.   Also, It was originally thought that it would allow archaeologists working at the site the ability to identify, process and compare find locations better than simply using the site database because they would have the advantage of comparing finds in different trenches, levels and deposits all together.  The model that runs in the cave presents site features and in situ architecture derived from an ongoing digital survey of the site and recorded measurements in the trenches.  

Process:

  • As the user becomes acquainted with the site conditions, the excavation trenches can be shown in the context of the site data along with associated stratigraphy, excavation layers, bulk finds and special finds.  

  • The user can interact with the system and turn different data models (architecture, excavation layers or artifacts) on or off to visually isolate a specific area.


Figure 1, 2, 3.  Users interacting with the model of the site with architectural elements reconstructed (columns and roof).

Data Visualization  

It was our first inclination to represent the data unearthed at the site in a realistic manner.  Thus, visualizing the site, trenches and artifacts in the system would be as natural as it is on the excavation.  However, attempting to display things in a realistic manner presents some processing difficulties and, as we observed in preliminary tests, is currently not the optimal way of viewing the data for analysis (van Dam, et al 2000: 37).

Color Blocking:

  • We decided that doing a simple join between the trenches and database would be a good first step.

  • After we had the basic model of the in situ architecture and trenches built,  we attempted to look at the individual trench loci with pottery concentrations plotted as a color range from white to dark red.  

  • We used what we call a color block method, which means we simply gave each locus a color definition (from pottery concentration) generated from the database and defined it as an opaque color range in red (see also Reilly 1990: 136). 


Figure 3 . Data modeled using ArView with 3D Analyst plug-in.

With this method of representing the data, navigating in the system proved very difficult because the opacity of the trenches blocked visibility.   Also, observing ranges in the different layers was not possible because the opacity of upper layers and architecture eclipsed the view associated layers.  Therefore, despite our attempts to simplify queries so that users see important areas easily, the current color blocking method made it impossible to see loci under or behind trenches in the immediate field of view and it did not allow the user to view more than one artifact type at once. 

GIS Software:

This was also a problem we encountered when we attempted to run our model using ESRI’s GIS software, ArcView with the plug-in 3D Analyst ('Arcview GIS' and 'Arcview 3D Analyst' from Environmental Systems Research Institute, Inc.).  The GIS software does not have the capability of loading each locus as a unique entity and interfacing it with the finds database.  If one wants to get a similar plot of finds using ArcView, it is necessary to abstract the trenches and define standard heights for each locus.   The result, as shown in figure 3, is more of a three dimensional bar chart, which allows the user to see where high concentrations of one object type exist (here pottery concentrations).   Unfortunately it is impossible to identify the location of the finds in relation to the architecture and adjoining trenches.


Figure 4.. Data modeled using
ArView with 3D Analyst plug-in.

Cluster Modeling

Our next attempt to visualize the artifact data came from the natural inclination to want to see all the objects uncovered in their in situ positions with associated architecture and trenches.  Therefore we simply called up all the objects in their find locations.   In situations where we had only a bulk count of finds in a locus, we defined the find positions universally throughout that locus.   Each object is represented as a triangle; red indicates pottery, yellow is coin finds, green is bone finds (figure 4).    In addition to visualizing all objects as abstract entities, we defined the loci as semi-transparent so that the user could see through trenches and loci to areas with relevant concentrations.


Figures 5,6,7.

In this attempt we came closer to providing a format that users could easily understand and use.  However, fine-tuning is necessary to mitigate the visual problems that accompany this method.   For example, the universal placement of triangles in a locus containing bulk finds can be confusing if there are many finds in a general area in between several loci.  To solve this problem we will need to define tighter parameters for the triangles within each locus.  Also, at this point, the ability to identify key areas is a function of triangle size and density.   We’d like to explore how manipulating the sizes of finds (triangles) and their colors and using different shapes can affect query results.   There has been extensive work in the area of understanding human visual search strategies when looking for information in complicated two-dimensional data sets (Wolfe 1996). Our approach tries to include some strategies from this area of research but also advances some three-dimensional search strategies.

Interface Possibilities

Figure 8. Top plan of Great Temple site minus trenches. 
This model is used to assimilate the user and aid in
navigation through the site at life-size scale.

Physical Interaction:

Along with the need to visually refine the system there is also a need to improve the user’s physical interaction with it.   Since the tasks necessary to complete analysis with three-dimensionally referenced data are complex, it will require the development of expressly designed interaction techniques. 

  • The ideal interface is undetectable and unobtrusive to users while they maintain involvement in task completion.  

  • Unfortunately, analysis and understanding excavation site and associated physical evidence, creates specific needs not often addressed by generalized user interface techniques.  For example, without control of the scale of the environment and movement in the system, the user must navigate over a full-scale representation of this monumental site, a daunting task.  

  • This method is based on the assumption that users need to be able to navigate exactly as they do in the “real world” (Ware 2000: 355).

  • Unless the user is quite familiar with the site, it’s easy to get lost.  


Figure 9. User interacting with a WIM of the site.
This model helps the user understand the site layout and helps
he/she choose locations to travel to at life-size scale.

We have integrated a WIM (world in miniature), figure 9, interface for navigation which allows the user to access a small version of the site to help make choices about areas to focus on at larger scales.  

  • This model  helps  acquaint the user with the overall site plan.  

  • Once the user has chosen an area to focus on, he/she is automatically transferred to the full-scale model for a more detailed exploration.

  • After the user is transported to an area to examine he/she can begin moving and interacting with excavation data via a mouse and pinch glove.  

  • The mouse is used to move, select and turn objects on and off.   The glove can be used to access a virtual widget to initiate queries of six different bulk finds (figure 6). 


Figure 10. User interacting with a WIM of the site.
This model helps the user understand the site layout and helps
he/she choose locations to travel to at life-size scale.

Queries and Analysis

Our main goal in developing the Archave system is to provide a simple format for displaying excavation data whereby remote users could come to many of the same conclusions archaeologists arrive at during excavation procedures.   This was to be accomplished by allowing users to investigate and manipulate artifact and site data at close range and perform a variety of queries for analysis. 

  • The system currently allows users to search for six types of bulk finds and a full range of special artifacts in seventeen trenches.  

  • As the user navigates in the model at full-scale, queries can be performed to show each of the six types of bulk finds as clusters in defined trenches (see figure 10).

  • Users can navigate through the model to examine it with variable concentrations of artifacts (see figure 11).

  • They can also ask to see special finds in the same context to try and establish relationships between the two artifact types.  

Our initial tests with the system have shown that it is fairly easy for the user to identify key areas with simple query commands.   By doing a variety of queries with the six types of bulk find data, it’s possible to see where excavation areas relate with the architectural finds and where important loci in each trench are located.


Figure 11.

Issues:

Currently, the user cannot access enough realistic data about special finds to use them for dating areas and relating them to bulk finds.   We posit that providing the user with a special find model hyper linked to a database with additional data about the object will provide the user with enough information to make educated conclusions.

  • Also, in performing flexible queries with the site data represented in a cluster format we encountered several problems.

  • The initial site model with trenches fairly stresses the processing speeds for the cave hardware since it is essentially polygon and texture intensive.  

  • Merging the additional polygons from the bulk finds increases overall polygon counts even more, making processing time longer and affecting the frame rates users experience. 

  • With the model running at low frame rates (2-3 frames per second compared to normal rates of 30+), users will notice jerky movement during navigation, which will affect both their performance during analysis tasks, and their level of comfort in the virtual environment.

Conclusion:

As stated earlier, in developing the Archave system, we are attempting to provide archaeologists with an alternative way of doing analysis with site data and to compare methods used in a VR environment with traditional analysis methods.  We have concluded that there are several key areas in need of additional development to provide users with fluid interaction and navigation in the system and access to all essential finds in those areas being investigated.

The immediate goal is to provide users with a natural way to investigate the site, architecture, trenches and artifacts, much like they might experience during excavation and analysis of the objects found.  To accomplish this in a VR environment such as the cave, we need to improve existing tools for fluid navigation and comfortable interaction with the data.   We must also provide access to additional, more detailed information (such as special find data) needed to make conclusions in the system.

Although we generally feel that the Archave system is still a working model it is an early effort to push VR applications away from strict visualizations and into research driven vehicles for advanced analysis.   The standard archaeological method provides a rich record for high-level analysis to occur and VR can provide a significant test-bed for advanced forms of analysis not heretofore available.  Current tendencies to implement VR for reconstruction and visualization need not be the only use for this technology.

References:

Cruz, Neira, C., D.J. Sandin, and T.A. DeFanti. 1993. "Surround-screen projection-based virtual reality: The design and implementation of the cave". Proceedings of SIGGRAPH 93, pages 135-142.

Gillings, Mark.  2000. “Plans, Elevations and Virtual Worlds: The development of Techniques for the Routine Construction of Hyperreal Simulations,” In J. Barceló, M. Forte, D.H. Sanders (eds.), Virtual Reality in Archaeology – Computer Applications and Quantitative Methods in Archaeology (CAA). Oxford: British Archaeology Reports International Series 843. pp. 59-69.

Reilly, P. 1990. “Towards a virtual archaeology.” In K. Lockyear and S. Rahtz (eds.), Computer Applications in Archaeology (CAA). Oxford: British Archaeological reports (Int. Series 565). p. 136.

Sanders, Donald H.  2000. “Archaeological Publications Using Virtual Reality: Case Studies and Caveats,” In J. Barceló, M. Forte, D.H. Sanders (eds.), Virtual Reality in Archaeology – Computer Applications and Quantitative Methods in Archaeology (CAA), Oxford: British Archaeology Reports International Series 843. pp. 37-46.

Stoakley, R., Conway, M. J., and Pausch, R. 1995.   Virtual Reality on a WIM: Interactive Worlds in Miniature, In Proceedings of Human Factors and Computing Systems, CHI95, pp. 265-272.

Van Dam, A. A. Forsberg, D. H. Laidlaw, J. L. LaViola, Jr., and R. M. Simpson.   2000.  “Immersive VR for Scientific Visualization: A Progress Report,”  In IEEE Computer Graphics and Applications November/December 2000. p. 37.

Ware, Colin.  2000.   Information Visualization: Perception for Design, Academic Press: San Diego, California. p. 355.

Wolfe, J.M. 1996. 'Visual Search' by Jeremy M. Wolfe. Edited by H. Parsier, University
College London Press, London, UK.

[back]

(links updated Feb. 2001)
Page Built and Maintained by Eileen Vote