A WEB-BASED INTERACTIVE TOOL FOR MULTI-RESOLUTION 3D A WEB-BASED INTERACTIVE TOOL FOR MULTI-RESOLUTION 3D MODELS OF A MAYA ARCHAEOLOGICAL SITE MODELS OF A MAYA ARCHAEOLOGICAL SITE

Continuous technological advances in surveying, computing and digital-content delivery are strongly contributing to a change in the way Cultural Heritage is “perceived”: new tools and methodologies for documentation, reconstruction and research are being created to assist not only scholars, but also to reach more potential users (e.g. students and tourists) willing to access more detailed information about art history and archaeology. 3D computer-simulated models, sometimes set in virtual landscapes, offer for example the chance to explore possible hypothetical reconstructions, while on-line GIS resources can help interactive analyses of relationships and change over space and time. While for some research purposes a traditional 2D approach may suffice, this is not the case for more complex analyses concerning spatial and temporal features of architecture, like for example the relationship of architecture and landscape, visibility studies etc. The project aims therefore at creating a tool, called “QueryArch3D” tool, which enables the web-based visualisation and queries of an interactive, multi-resolution 3D model in the framework of Cultural Heritage. More specifically, a complete Maya archaeological site, located in Copan (Honduras), has been chosen as case study to test and demonstrate the platform’s capabilities. Much of the site has been surveyed and modelled at different levels of detail (LoD) and the geometric model has been semantically segmented and integrated with attribute data gathered from several external data sources. The paper describes the characteristics of the research work, along with its implementation issues and the initial results of the developed prototype


INTRODUCTION
The continuous development and improvement of new sensors, data capture methodologies, multi-resolution 3D representations can contribute significantly to the documentation, conservation, presentation and fruition of archaeological information and to the growth of research in the Cultural Heritage field.This is met by increasing requests and needs for digital documentation of archaeological sites at different scales and resolutions.Nowadays the generation of 3D models of large and complex sites is performed using methodologies based on image data (e.g.photogrammetry) (Remondino and El-Hakim, 2006), range data (e.g.laser scanners) (Blais, 2004;Vosselmann and Maas, 2010), classical surveying (e.g. total stations or GPS), maps (Yin et al. 2009) or graphical and procedural modelling.The choice depends on several factors like for example the required accuracy, object dimensions and location, the surface characteristics, the working team experience, the project's budget, the final goal, etc.More and more often the different methodologies are also combined and integrated to exploit the intrinsic potentials and advantages of each technique and to derive multi-resolution data and different levels of detail (LoDs), both in geometry and texture, useful, for example, for interactive visualisation (El-Hakim et al., 2004;Grün et al., 2005;Guidi et al., 2009;Remondino et al., 2009;Takase et al., 2009).Multi-resolution data are nowadays the base of different geospatial databases, visualisation repositories and virtual reality (VR) platforms.Probably the best and most known examples are given by Google Earth or Microsoft Bing Maps (previously known as Microsoft Virtual Earth).Data span from 10 m resolution (or more) -both in geometry and texture -down to some decimetres -in texture only.The user can browse through the low-resolution geospatial data and get, when necessary, high-resolution and detailed imagery, often linked to other 2D/3D information (text, images, city models, etc.).It is therefore clear that the 3D digital world is providing opportunities to change the way we can access and exchange knowledge and information.Moreover, a faithful 3D modelling approach of Cultural Heritages helps to simulate reality in a more objective (and thus more reliable) way and provides the opportunity to use digital 3D models for different purposes.One of the most interesting opportunities offered by realitybased 3D models is to use them either as visualisation containers or as highly intuitive interfaces between different kinds of information.Given their usual geometric complexity and the possibility to link them to a wide range of data, 3D models can be analysed, split in their sub-components and organised following proper rules in order to ease data retrieval.In the case of (modern) buildings, for instance, the BIM (Building Information Models) concept aims at describing building components with respect to their geometry, topology and semantic information.In 2009 an international and interdisciplinary research project was founded to develop an online, searchable, virtual-reality environment and database that brings together GIS maps, highly detailed 3D models and collections of archaeological data so that researchers may compare and analyse buildings, sculpture, and artefacts in a 3D landscape context.Directed by von Schwerin, an architectural historian at the University of New Mexico (UNM), this project is a collaboration with archaeologists at UNM and site managers from the Honduran Institute of Anthropology and History (IHAH), along with experts in computer imaging, remote sensing, photogrammetry, 3D modelling, GIS and Virtual Reality from the ETH Zurich (Switzerland), the University of California, Merced (USA) and the Bruno Kessler Foundation (FBK) in Trento (Italy) (Remondino et al., 2009;von Schwerin, 2010).FBK is leading the technical development of the tool -called QueryArch3D.In the following paragraphs, a brief introduction will be given about the Maya site at Copan and the related surveying and 3D modelling campaigns to date, followed by a quick overview and open issues concerning the web-based interactive access to 3D geodata.Successively, the characteristics of the QueryArch3D prototype, its underlying design concepts and the initial implementation will be presented.The concluding remarks will evaluate the initial results as well as some open issues and future plans for the next development steps.

THE MAYA SITE OF COPAN, HONDURAS
The ancient Maya civilisation of Mexico and Central America lasted for almost 2000 years (600 B.C. -A.D. 1521).One of their most thoroughly investigated Maya cities is the UNESCO World Heritage site of Copan, Honduras located on the southern periphery of the Maya world.Copan was an important centre for commercial and cultural exchange and excavations in the city's main civic-ceremonial complex (Principal Group) have uncovered layers of architecture with sculpture, imagery, and hieroglyphs showing that Copan had a dynasty of sixteen kings that ruled over five centuries (A.D. 427-820) (Bell, Canuto, and Sharer 2004).Copan's early kings built packed adobe architecture, while the city's later kings erected stone buildings with plaster sculpture (Sharer et. al., 1992;Andrews and Fash, 2004).Temple 22, commissioned by Copan's thirteenth ruler, King Waxaklajuun U'baah K'awiil (reign: A.D. 695-738), gives a sense of this kingdom's artistic accomplishments.Often referred to as the "Parthenon of the Maya world" because it has over 3500 pieces of sculpture housed in museum collections around the globe, Temple 22 was once three-storeys-high and covered with plaster, paint and sculpture (von Schwerin, 2011).However, only the first storey remains and its upper facades and sculptures are collapsed making it is difficult for visitors to imagine the glory of this and other ancient temples at Copan without the aid of 3D reconstructions.The first 3D surveys of Copan were hand-drawn maps with elevation information.The earliest examples are from the early 1800s when explorers such as Galindo (Graham, 1963) and Stephens and Catherwood (Stephens, 1841) drew schematic maps of the Principal Group.With the first scientific investigations, the maps became more detailed and Gordon (1896) and later Stromsvik (1947) published maps at scale of 1:1500.In the 1980s, architects (Hohmann and Vogrin, 1982) published maps and drawings of the Principal Group at scales of 1:100 and 1:200 and archaeologists on the Proyecto Arqueológico Copán (PAC I) published maps of the valley's residential sites at a scale of 1:2000 (Fash and Long, 1983).Until recently, there were very few GIS maps of Copan.Maca's (2002) GIS maps of Group 9J-5 and nearby sites were some of the first.In 2006-2007, Richards-Rissetto (2007, 2010), the GIS Director of the 3D Copan Project, digitised and geo-referenced the PAC I maps (covering 24 km 2 ) and integrated them with more recently available large-scale maps to create a GIS for the entire Copan Valley.Currently, the GIS contains (i) vector data of archaeological buildings and monuments, hydrology, contour lines and (ii) raster data of a Digital Elevation Model (DEM) of the valley (generated from contours ranging from 2-10 metres) and an Urban DEM of the valley's with more than 3000 buildings.In 2009 a field campaign acquired high-resolution 3D data using terrestrial photogrammetry, UAV and terrestrial laser scanning (Remondino et al., 2009).

WEB-BASED 3D-GEODATA INTERACTION
Besides the usual visualisation per se, 3D models can be used also as "containers" for several kinds of heterogeneous information that is usually organised and collected in (not necessarily spatially enabled) databases.This is also one of the most interesting needs and requirements of an ideal 3D data visualisation and query tool in which the visualisation capabilities should be associated to query functionalities for data retrieval, possibly web-based.The latter are actually typical functions of current GIS packages, which, on the other hand, very often fall short when dealing with detailed and complex 3D data.Different authors have presented possible solutions for 3D data management and visualisation, possibly on-line (Shi et al., 2003;Calori et al., 2005;Khuan et al., 2007;Kibria et al., 2009;Conti et al., 2009;Apollonio et al., 2010;Manferdini and Remondino, 2010).Despite the great research work, nowadays almost no unique, reliable and flexible package is available, while, on the other hand, several approaches have been presented dealing with some specific and partial aspects of the topic.In the following, only some related work will be mentioned, which has served as inspiration for the prototype tool presented here.When it comes to data modelling and storage, several examples exist.CityGML, for example, is a common information model for the representation of 3D urban objects.It defines the classes and relations for the most relevant topographic objects in cities and regional models with respect to their geometrical, topological, semantic and appearance properties.It also deals with generalisation hierarchies between thematic classes, aggregations, relations between objects, and spatial properties (Kolbe, 2009).Unfortunately, even in CityGML's LoD4, currently the highest available level of detail, architectural models are defined up to the interiors by means of their constructive elements and with a maximal point accuracy of 0.2 m.These specifications are of course enough for modern buildings, but -understandingly -are not (yet) straight compatible for a reality-based archaeological model, which generally differ in terms of scale and scope.It must be noted, however, that CityGML provides two ways to support the exchange of data not yet already explicitly defined: by generic objects and attributes, or by Application Domain Extensions (ADE), which provide a means to handle for example bridges, tunnels, etc. Regarding visualisation, in the videogames domain some packages and development tools exist and can be adaptedwithin certain limits -to support 3D geodata (e.g.Unity3D, OSG, OGRE3D, OpenSG, 3DVIA Virtools, etc.) but with limited capabilities when it comes to loading and displaying large and complex reality-based 3D models.In the framework of on-line 3D contents retrieval, Google Earth has been used as web-based solution for architectural 3D models in Apollonio et al. (2010), while Conti et al. (2009) have used the NASA World Wind to deliver a web-based 3D and OGC compliant solution capable to provide interoperable access to geographical information and geospatial processing services.In these cases, however, a trade-out between model complexity and network/client resources had to be found.When it comes to (3D) web services, some initial experiences like in the Geodata Infrastructure 3D project (Shilling et al., 2009) exist (i.e. the OpenStreetMap-3D and Heidelberg-3D projects).A web 3D service (W3DS) is a portrayal service for 3D geodata such as landscape models, city models, textured building models, etc.It can handle datasets consisting of multiple LoDs and geodata are delivered as scenes that are comprised of display elements, optimized for efficient real time rendering.However, the definition of such W3DS is still at level of OGC discussion papers (version 0.4 as of February 2011).

THE QUERYARCH3D TOOL
Ideally, an adequate 3D analysis tool in the framework of architectural and archaeological Cultural Heritage should be able to perform (at least) the following tasks: • handle standard spatial features (e.g.2.5D landscapes) as well as geometrically and topologically more complex 3D models; • support multi-resolution data, at varying levels of detail; • support not only "passive", predefined content retrieval, but also an interactive one, e.g. by means of user-defined queries; • allow access to contents stored locally but also web-based • rely (possibly) on free and open-source tools.
Given that such a tool still does not exist, the present research work has focussed first on identifying how the aforementioned prerequisites could be fulfilled and then on defining a workflow/pipeline to implement a prototype.The resulting tool, called QueryArch3D, was created keeping in mind the needs of researchers working at the Copan archaeological site, although the basic concepts can be extended and generalised to other applications.Its capabilities, which fulfil the points listed before, and the underlying structure will be presented in the following paragraphs.Regarding the complexity of the models, QueryArch3D supports multiple LoDs, which are required to reflect independent data collection processes.LoDs also facilitate efficient visualisation and data analysis.For the Copan site, four levels of detail have been defined for the structures: • LoD1, in which a structure is presented as a simplified 2.5D prismatic buildings with flat roofs (or an aggregation of such features), mostly obtained by extrusion of 2D footprints.Accuracy tied to this LoD is thought in terms of model accuracy and is for us accepted to be within 2 m. • LoD2, in which the exterior of a structure is modelled in detail and allowing 3D geometries.The composing structures (e.g.walls, roofs or external stairs) can be identified, and the characterising accuracy is within 0.5 m. • LoD3, in which the interior elements are added (rooms, corridors, etc.) to the structures.Some simplified, realitybased models can be added, both to the interior and to the exterior of the structures.The accuracy is within 15 cm.• LoD4, in which structures (or parts of them) are presented as high-resolution (e.g.laser-scanner-acquired) models.
High-resolution models can be further segmented into subparts.The accuracy is within 3 cm.
Similarly to CityGML, particular care in the design principles has been given to achieve a coherent modelling of semantics and geometry.At the semantic level, entities are represented by features (stairs, rooms etc.) and they are described by attributes, relations and aggregation hierarchies (part-of-relations) between features.The part-of-relationship between features can be derived at the semantic level, without considering geometry.However, at spatial level, geometry objects are assigned to features representing their spatial location and extent.So the model consists of two hierarchies: the semantic and the geometric ones in which the corresponding objects are linked by relationships (Stadler and Kolbe, 2007).If both hierarchies exist for a specific object, they must be coherent: if a temple consists of three storeys and an axial stair at the semantic level, then the geometry representing the temple must include also the geometry parts for the storeys and the axial stair.
Once the conceptual schema for the LoDs and the hierarchies (i.e. the part-of-relations) are defined, the successive steps are organised as follows: 1) Existing and available data (spatial and non-spatial) are gathered and evaluated: a checked is performed for potential incompatibilities (different formats, different modelling paradigms, etc.), geometric and/or semantic inconsistencies, especially with regards to the next step.2) Data integration and homogenisation: from many sources to (ideally) one.Furthermore, spatial data is aligned and geo-referenced.Features are aggregated or disaggregated according to the LoDs and the hierarchy relationships.3) Data publication and interactive access.On-line publishing possibilities, drawbacks and limitations.

Data description, data collection and integration
For the Copan archaeological site, consisting of over 3700 single structures (temples, palaces, stelae, altars, etc.), several datasets exist that have been created during the course of time, as mentioned in section 2. The following datasets were chosen for generating the structures at the different LoDs.For LoD1, 2D vector data digitised by Richard-Rissetto in 2007 has been adopted as the source for the prismatic geometric objects.The nearly 20000 polygons representing over 3700 structures have been checked for topology errors (overlaps and gaps); polygons belonging to the same structure and having the same attributes have been merged to reduce the number of geometric features down to circa 5000.At this point, the 2D footprints have been extruded according to the height field provided with the shapefile.Every single structure, from LoD1 down to LoD4, is classified according to a unique code.Upwards, all structures are thematically aggregated into groups (containing several structures) and clusters (i.e."groups of groups"), according to the existing hierarchy used by the archaeologists.Additional GIS data from the Richard-Rissetto dataset has been used to generate a digital terrain model for landscape contextualisation.
Regarding LoD2, a model of an unfinished reconstruction of Temple 22 (i.e.Structure 10L-22), created in Autodesk 3ds Max, has been disaggregated into its architectonical elements such as basement, storeys, stairs, walls, mouldings, roofs etc.Every segment has been coded and organised according to the proper part-of-relationship hierarchy.
Analogously, for LoD3, some of the interior elements of the temple have been added.Some architectonic details, like the corner masks or the interior sculpted doorframe of the Temple 22 have been added, simplifying the geometric models obtained from laser scanning acquisitions (Figure 2).The geometric simplification (in the order of 30% of the original models) is mainly due to reduce the number of polygons displayed at the same time and keep a fluent on-line visualisation.In a similar way, simplified 3D models of two stelae (stela A and stela B) have been created and added to LoD3.This kind of data integration has allowed the digital "restoration" objects that are no longer at the archaeological site: Stela A, some of Temple 22's corner masks and its carved interior doorframe are in fact now preserved at the Museo de la Escultura Maya in Copán Ruinas (Figure 3).For the LoD4 models, currently only the laser-scanner acquired models of the aforementioned objects (two stelae, the corner mask and the interior doorframe) have been imported (at the original geometric resolution) and segmented into their subparts.Many more elements are to be added in future.An example is shown in Figure 4. Once the geometric models have been manually segmented and given a hierarchy order, they were aligned and geo-referenced in order to share a unique coordinate system.Finally, all objects were given an elevation value, taken from the DTM.At the same time, non-spatial tabular data (mainly coming from MS Access databases, text files, FileMaker Pro) have been checked, homogenised and integrated.Since the goal is to reduce heterogeneity of data formats, PostgreSQL has been chosen at the target DBMS where all data should progressively and eventually converge.Moreover, thanks to its PostGIS extension, spatial data also can be stored in the same database.So far, standard GIS formats can be imported and exported from/to PostgreSQL (e.g. using ArcGIS and its Data Interoperability extension or, alternatively, by means of the open-source OGR utilities via QGIS), while the .objfile format has been chosen to import triangulated 3D geometries.

3D visualisation and interaction environment
After some initial tests using Quest 3D, the Unreal Engine SDK and Shiva, the implementation of the interactive 3D visualisation for the archaeological site of Copan has been carried out using the game engine Unity 3D, due to the quick development time offered by its scripting capabilities, which have been used to perform most of the tasks needed.Unity is an integrated authoring tool for creation of 3D videogames or other interactive content such as architectural visualisations or realtime 3D animations.Applications can be developed for all major platforms (Windows, Mac, Wii, iOS, Android, Xbox 360, PlayStation 3) as well as for a web site.On-line applications can thus be accessed through a freely downloadable browser plugin.Unity permits scripting through JavaScript and C#, thus allowing access to numerous .NET libraries.Furthermore it has its own library to communicate with the internet, specifically the WWW class, which has been used to access the Copan database.Once the geometry has been generated and loaded in Unity, it contains the data properly structured, i.e. one "layer" for each object, and every layer name is the reference key for the corresponding attributes in PostgreSQL.
A frontend interface in PHP has been developed to access the database: Unity performs a request to PHP which loads and sends the data forth from PostgreSQL (Figure 5).Different approaches have been tested to load attribute data into Unity.In the first one the database is queried every time a building is selected with the mouse in Unity, with the PHP servlet acting between PostgreSQL and Unity.This method has been discarded due to the delay in the queries.
A faster approach consists in treating each geometric object like a class with attributes and functions.To achieve this, a script is added to each object and, as soon as the application is run, Unity controls whether an Internet connection exists.If this condition is fulfilled, all the remotely stored information like structure type, structure name, year of construction etc. is retrieved and assigned the respective class.For example, when all stelae need to be selected, a Broadcast Message is sent to all the GameObjects in the Scene, a function in the class is called which performs the query and finally highlights the geometry if it fulfils the criterion ("is this a stela?").The advantage of this approach lies in the possibility to work also offline (once the attributes have been initially loaded), thus significantly reducing the time the user has to wait whenever an attribute query is performed.
As of today, only some initial interactions and functions have been defined and implemented: • The first interaction step allows the user to move freely around in the virtual environment.To this extent, both an aerial view (Figure 6) and a ground-based view, where the user can reach and enter the structures "on foot", have been implemented; • Multiple LoDs of the same models are visualised using an observer-object distance function: the closer the observer, the higher the LoD of the surrounding objects.For the aerial view, only LoD1 objects are displayed, while subsequent LoDs are visualised in the ground-based view.At LoD4, for the laser-scanner-acquired architectonical details, a separated view is loaded which contains the selected object and its subparts only (Figure 7 to Figure 11); • The user can perform queries over the whole dataset according to some attributes (e.g."show all structures built by a certain ruler"; "show all altars"; "show only stelae belonging to group X and built in year Y") (Figure 12 and Figure 13); • The user can click any selectable object and receive the related amount of information according to its LoD (e.g.: only the name of the whole temple at LoD1, the name of the structural exterior parts at LoD2, and so on till LoD4) (Figure 14 to Figure 16); • The user can measure distances between two objects in the 3D world; • The user can perform line-of-sight tests between two selectable objects.More function and capabilities will be tested and added in the future, as the project continues and evolves.

CONCLUSIONS AND OUTLOOK
This paper presents the initial results of the prototype tool QueryArch3D.The goal is to create a web-based tool that allows for interactive visualisation and queries of multiresolution 3D models in the framework of Cultural Heritage.More specifically, the Maya archaeological site of Copan in Honduras has chosen as a test field, due to its extent (ca.24 km 2 ), its considerable number of mapped structures (over 3700) and the availability of several heterogeneous datasets.In particular, distinct surveying campaigns have created different models at different scales and at different levels of detail, such that an integration of these (spatial and non-spatial data) is highly desirable, both for further research investigation but also for data query and analysis purposes.
Currently, the visualisation front-end allows the user to navigate interactively in a virtual environment, where existing structures can be visualised and queried at different levels of detail.
According to the observer's distance from the object, models vary from low-resolution prismatic geometries to laser scanner high-resolution meshes.Some spatial functions (like distance measurements and visibility analysis) have been implemented and additional functions will be created in the future.Within the user interface, the data have been integrated and structured according to a multi-resolution modelling paradigm, coupled with geometric and semantic hierarchy criteria.Heterogeneous non-spatial information has been collected from various sources and linked to the geometric features.Because QueryArch3D is in a prototype phase, many issues remain to be solved and several new functions remain to be added.Further performance tests need to be carried out while the model is extended and enriched.Some of the initial planned improvements need to handle the following issues: • Most of the structures are neither textured nor chromatically characterised.The very first improvement of the buildings from LoD2 upwards will take this into account, an operation to do in close collaboration with the archaeologists, who can assist especially with those structures for which a hypothetical reconstruction is given; • It should be possible to distinguish (e.g."switch" on and off) real structures from virtually reconstructed ones; • Regarding the database storage system, some import/export routines to/from PostgreSQL should be added and/or improved.Just to name an example, converting a GIS polygon (with holes in it) into a triangulated mesh isn't yet a straightforward process with the existing tools.PostGIS itself, in its present version (1.5.2) offers support to store 3D features, but all GIS functions are still substantially 2D, i.e. three-dimensional "out-of-the-box" spatial analysis tools are still to come.On the other hand, the coming 2.0 version, due in spring 2011, should offer substantial improvements in raster data management and storage for TINs and meshes.• Besides the building structures, the modelling paradigm has still to be applied to other entities, like for example the DTM.So far, only a coarse TIN is used and objects are simply placed on top of it leading to some geometric inconsistencies in some places.A better integration of highresolution models into a coarser DTM should be therefore taken into account.To this extent, Agugiaro (2009) has discussed possible approaches and presented a solution which could be also adapted to the Copan dataset.• Integrating high-resolution models into an on-line virtual environment requires high performance hardware (and good internet connections).Currently, the complete Copan model consists of little more than 1 million triangles.As the number of included architectural models grows, proper strategies will have to be adopted to test and to keep the user experience acceptable (e.g. in terms of frame rate during navigation).The advantage of using a game engine environment, on the other hand, offers a certain level of confidence, since these are all well-known constraints in the videogame industry.• Finally, much effort has been put into data integration, interaction and visualisation.Accessing the data for updates and maintenance purposes is, however, also fundamental: at this stage, a user-friendly interface which guarantees access to privileged users (i.e.archaeologists, architectural historians, or Cultural Heritage managers) is yet to be implemented.

Figure 2 :
Figure 2: Examples of segmentation of the Temple 22 model for LoD2 (exterior architectural elements, above) and LoD3 (interior spaces and architectonic details, below).For a better visualisation, some segments are identified with different colours.

Figure 3 :
Figure 3: The two stelae at LoD3 in the virtual Main Plaza of Copan.Stela A, in background, which is actually held at the Museo de la Escultura Maya in Copán Ruinas (Honduras).The LoD3 Stela B can be seen in the foreground.

Figure 4 :
Figure 4: Example of manual segmentation of a LoD4 architectural element: a corner mask of Temple 22 in Copan.For a better visualisation, some segments are identified with different colours.

Figure 5 :
Figure 5: Schematic representation of the data exchange between Unity and PostgreSQL, using PHP as interface.

Figure 6 :
Figure 6: Aerial view of the Copan site visualised through Unity: the main group with the principal temples can be seen in the middle of the image, while the remaining structures spread all over the valley are visible.Structures are visualised as LoD1.

Figure 7 :
Figure 7: View of the southern side of Copan Temple 22 (and the surrounding acropolis) as LoD1 model: the geometry is generated by extrusion of 2D planar geometries.

Figure 8 :
Figure 8: View of Copan Temple 22 as LoD2: (only) the temple model has a higher level of detail, the outer shell of the temple contains 3D elements.No interior rooms are loaded.The surrounding acropolis remains at LoD1.

Figure 9 :
Figure 9: View of the Copan Temple 22 as LoD3: (only) the temple model has a higher level of detail, the outer shell of the temple contains 3D elements and the corner masks, which are simplified models derived from laser scanner acquisitions.Interior rooms are loaded and can be seen in the following images.The surrounding acropolis remains at LoD1.

Figure 10 :
Figure 10: Detail view of the Temple 22 at LoD3: interior rooms (top) and reality-based architectural elements (the interior doorframe, bottom) are loaded and visualised, and can be reached by the observer walking inside the 3D virtual environment.

Figure 11 :
Figure 11: Detail view of the interior doorframe at LoD4: due to the large number of triangles used in the model, visualisation of LoD4 elements takes place separately.

Figure 12 :
Figure 12: Example of an attribute query over the whole dataset: the results are highlighted in red.

Figure 13 :
Figure 13: Example of an attribute query over the whole dataset ("Select all stelae in Copan"): results are highlighted in red.

Figure 14 :
Figure 14: Example of a query on a single building at LoD1: information regarding the whole of Temple 22 is shown.

Figure 15 :
Figure 15: Example of a query on a single building at LoD2: information regarding the architectural element of the interior doorframe (as a whole) is shown.

Figure 16 :
Figure 16: Example of a query on a single segmented object at LoD4: information regarding the segmented architectural elements of the interior doorframe is shown.