Beacon Virtua: A Virtual Reality Simulation Detailing the Recent and Shipwreck History of Beacon Island, Western Australia
Beacon Virtua is a project to document and virtually preserve a historically significant offshore island as a virtual reality experience. In 1629, survivors of the wreck of VOC ship Batavia took refuge on Beacon Island, Western Australia, followed by a mutiny and massacre. In the 1950s the island became the base of a successful fishing industry, and in 1963 human remains from Batavia were located. The fishing community has recently been moved off the island to protect and preserve the site and allow a thorough archaeological investigation of the island. Beacon Virtua exposes users to the history of both the shipwreck survivors and the fishing community. The project uses the virtual environment development software Unity to present a simulation of the island, with 3D models of buildings and jetties, photogrammetric 3D reconstructions of graves and other features, 360° photographic panoramas, and information on the history of the island. The experience has been made available on a wide range of different platforms including via a web-page, as part of an exhibition, and on head mounted displays (VR headsets). This chapter discusses the features included in Beacon Virtua, the storytelling techniques used in the simulation, the challenges encountered and solutions used during the project.
Keywords3D visualization Beacon Virtua Maritime landscape Storytelling Unity
On the morning of 4 June 1629, the VOC (Dutch East India Company) ship Batavia struck Morning Reef off Beacon Island—1 of about 100 islands in the Houtman Abrolhos Archipelago, off the coast of Western Australia. Of the 322 people on board Batavia when it grounded, only 122 would eventually reach the vessel’s intended destination of Batavia (modern-day Jakarta) (Roeper 2002, 220–221). Two-hundred people died at this remote location, either by drowning, due to illness or injury, or by murder or execution (Roeper 2002, 220–221). Survivors from the wreck initially mainly took refuge on Beacon Island. The senior merchant Francisco Pelsaert took a ship’s boat and yawl, with 48 people on-board to look for water and supplies, but soon decided to head to Batavia which they finally reached a month later (Roeper 2002, 69). Left in charge of the survivors was junior merchant Jeronimus Cornelisz who progressively oversaw the murder of 125 individuals, initially under the pretence of limited provisions, but later for no obvious reason (Drake-Brockman 2006, 130; Roeper 2002, 85). The story of the Batavia period of Beacon Island’s history is a real-world ‘Horrible History’ and has been written about widely (Dash 2003; Drake-Brockman 1956, 2006; Edwards 1966; FitzSimons 2011; Pelsaert 1647; Roeper 2002). Beacon Virtua is a virtual reality (VR) simulation of Beacon Island which explores ways of exposing visitors to five periods of Beacon Island’s history: (a) the wrecking of Batavia in 1629 and the subsequent experience of the crew and passengers on the island, (b) the fishing history of the island from the 1950s through to around 2010, (c) the discovery of shallow graves and the Batavia wreck site and subsequent excavation in the 1960s and 1970s (Green 1989) (d) the recent history with the removal of the fishing shacks in 2014 and an ongoing archaeology program, and (e) the future of the island as a location for heritage tourism.
Visualization and simulation are an important tool to enable the interpretation and representation of cultural heritage particularly maritime (Adams 2013). The goals of Beacon Virtua were to provide an accurate digital record of the island and also to provide a way for people to experience the island in an accessible manner. The simulation is based on actual data over an artist’s impression, and as far as possible the simulation is intended to be used by anyone regardless of familiarity with game like experiences or computers in general. Beacon Virtua has been targeted at multiple platforms to assess the practicality of using different types of computer systems for displaying virtual environments and also to make the simulation available to a larger audience.
Virtual reality has a long history of development, but it is in roughly the last 5 years that the evolution of a number of key technologies has reached an important stage to allow highly realistic experiences to be presented to users. Virtual reality experiences can be delivered to users via a range of different techniques including head-mounted displays, large-scale immersive displays and also more conventional displays; however, it is usually head-mounted displays that the public associates with VR. Virtual reality techniques offer an important ability to immerse a user in a fictitious or remote location. It has been shown that the use of immersive technologies to present cultural heritage experiences results in better understanding and improved retention (Jacobson 2013). This project aimed to explore the impact, experience and usability of VR technologies to communicate the story of Beacon Island.
The original development of Beacon Virtua is discussed in Bourke and Green (2016). This chapter will focus on development of Beacon Virtua as a storytelling tool—the adaption of the simulation to expose users to the rich history of the island and doing so across multiple platforms. We will also discuss its features and how the user interacts with them and the challenges encountered in creating the simulation. The methods used to capture the original assets for the simulation are discussed in Bourke and Green (2016).
The level of visual realism in a virtual reality simulation can vary considerably—options can include: more or less photo-realistic, impressionistic or even schematic (Denard 2009). The choice of level of photo-realism can be driven by a range of factors including audience type (e.g. expert or non-expert) and purpose of the simulation (e.g. archaeological interpretation or public education) (Frankland 2012). The level of photo-realism used for Beacon Virtua was chosen on a more pragmatic level. In this particular project there was a desire to make the simulation as photo-real as possible, however this had to be metered with the effort involved in gaining photo-realistic qualities for the various aspects of the simulation, and the load that this may place on the computer platform used to run the simulation.
The level of detail that can be implemented in a full 3D virtual environment is dependent on a range of factors including: the time/resource available to create the simulated environment, the tools and techniques used to document the location, and the computing power available to render the environment in real-time. The resultant realism and accuracy of the simulation will also depend upon the actual geometric complexity of the real-life environment—a very simple environment can be simulated very accurately with limited resources and effort, but a complex environment may be impossible to accurately depict even with unlimited resources.
3D modelling and virtual reality simulation have been used on a wide range of maritime archaeology related projects. Examples include the Pianosa Island wreck site in Italy which has used a wide range of emerging techniques to document, map, model and visualize the wreck site including traditional photogrammetry (for point-by-point measurements), 3D manual modelling, early experiments with photogrammetric 3D reconstruction, along with GIS and VRML for visualization (Drap et al. 2007, 2008; Haydar et al. 2008). Others, such as the Mazatos shipwreck in Cyprus, which started excavation in 2007 using manual 3D modelling and visualization in a large CAVE display (Katsouri et al. 2015) and the Vrouw Maria shipwreck in Finland which has used multibeam sonar, laser scanning of ship models, manual 3D modelling, and VR simulation using Unity (Reunanen et al. 2015). Also notable, the Le Boullongne virtual sailing ship simulation has been developed from the ship’s plans and unlike the others listed above, is not a wreck site simulation (Barreau et al. 2015).
Beacon Virtua is different from these examples in that the focus is on the island, and it uses the island as the platform to expose users to the story of the ship and her crew, and other aspects of the history of the island. All of the content in Beacon Virtua is presented on or in relation to the island. The user can access all of this content by exploring the island, similar to how one might walk around a museum to see exhibits. At the time of writing, and to our knowledge, this is the only VR simulation of an entire ‘maritime landscape’ used to educate the public about the cultural heritage of the location. Rather than just a series of individual wrecks in 3D, this project presents an entire environment and although it does not show the actual wreck of Batavia in the simulation now, there are plans to extend the simulation to include the offshore site in one seamless environment in the future.
13.2.1 Guided Tour
13.2.2 Technical Features
Beacon Virtua has been built in the ‘Unity’ virtual environment development platform. Unity is a versatile piece of software intended for making many different kinds of applications, including games and simulations (see also Benjamin et al., Chap. 14, this volume). It provides an editor capable of building standalone applications that can be distributed to multiple end users without them needing the Unity editor or the source project. In the editor, virtual environments can be constructed out of 3D models and other assets, and systems can be created to allow the user to navigate the environment and interact with features. Unity can build the same project to a wide range of different platforms (the target hardware and operating system software) which makes it very versatile. Beacon Virtua uses a mixture of techniques to achieve an advanced level of realism appropriate for the task of telling the story of Beacon Island within various technical constraints (Bourke and Green 2016).
18.104.22.168 Island and Ocean
The ground layer of Beacon Island is reproduced as an aerial image draped over a Digital Elevation Model (DEM) of the island. The surrounding ocean is simulated using a selection of different water simulation techniques and algorithms depending upon the compute capacity of each target platform—which in turn have different levels of realism. Several nearby islands that play an important part of the story of Batavia have also been experimentally implemented but have not been included in the first museum release of the simulation.
22.214.171.124 Buildings and Jetties
126.96.36.199 Graves and Coral Features
188.8.131.52 360° Photo Bubbles
Some details of the island were unable to be accurately reproduced as 3D models, such as vegetation, and hence a series of over one hundred 360° panorama photo bubbles were captured across the island. In the simulation, the user is able to navigate and essentially ‘pop their head inside a bubble’ to see a photographically accurate depiction of the island from that particular point. In order to prevent the large number of photo bubbles polluting the view of the landscape, the photo bubbles only fade into view when the user comes close to them. This is not the first time that photo bubbles have been used in a VR environment – other examples include ‘Eye of Nagaur’ from 2008 (Bourke 2009; Shaw 2010) and ‘Mawson’s Hut’ from 2010 (Morse 2010). Photo bubbles are a very economical way of increasing the realism of the simulation. The photo bubbles in Beacon Virtua are monoscopic (2D), although there are ways of capturing them as stereoscopic bubble pairs (Gurrieri and Dubois 2013).
184.108.40.206 Information Panels
As mentioned earlier, a series information panels have been inserted into the environment to provide instructions and tell the story of Beacon Island. The information panels are made to clearly stand out from the environment, so they are not mistaken for real features of the island. The panels are programmed to fade out when the user is far away so that they do not obscure the environment when they are not needed. Sherman and Craig (2002) discuss four types of VR interfaces: (i) in the world, (ii) in the hand, (iii) in front of the view (HUD), and (iv) on the panel. In Beacon Virtua, the information panels we used fit the last category, information and/or controls on a 3D panel in the world. This has proved to be an effective solution for the requirements of Beacon Virtua.
220.127.116.11 Text Menu
In addition to the information panels, a text menu is also used. This menu can be brought up by clicking a button or pressing a key and provides an overview of the controls as well as a set of options allowing the user to access more features such as jumping to a particular point of the island.
Ambient sounds around the island were recorded while on site—capturing sounds such as the birds, waves and wind. The different audio recordings have been located at their corresponding locations on the island, and as such provide a dynamic soundscape as the user moves around.
Beacon Island is home to a variety of birdlife, which have been incorporated into the simulation. The birds are represented in the simulation as white, winged objects which fly above the island in random patterns based on a home point. The birds will randomly pick a destination to fly to—the choice of destination is weighted so that the bird will favour destinations close to its home point. The algorithm provides both a pattern of birds gathering around a focal point as well as individuals that fly off on their own. The bird home points have been positioned over each of the wharves. The destinations are capped between certain altitudes so that the birds do not fly through buildings or other scenery but remain in view. Each bird has an audio source set to play recordings of the island’s birds at random intervals, allowing them to squawk as they fly overhead. As the birds are flying above the island they can only be seen from a distance, allowing them to create the impression of birds without using detailed models or animations. The implementation of the birds in the simulation contributes to the dynamic nature of the simulation.
18.104.22.168 Batavia Marker
13.3 Target Platforms
To date Beacon Virtua has been built for 14 different target platforms: Desktop Windows and Mac, WebGL/Web Browser, multiple Head Mounted Displays (Google VR Cardboard iPhone and Android, HTC Vive, Oculus Rift, Gear VR), four types of large-scale immersive displays such as those in the HIVE (high resolution tiled, Cylinder, Dome, and Wedge/CAVE), a touch-screen exhibition version, and videos (regular widescreen, and 360° 3D) for uploading to YouTube or other streaming service. The flexibility of Unity to export the same project to multiple platforms saves a considerable amount of development time and maximizes the potential target audience. Different platforms have different capabilities and different interaction modalities which will be discussed specifically in the following sections.
The original or development version of Beacon Virtua is targeted at desktop or laptop computers running the Windows or Mac operating systems. This version has all of the high-level features and content available. This version is deployed as a downloadable application about 1 GB in size. The only sacrifice in quality for the PC version is that the panoramic bubbles are 4K resolution rather than 8K, since the use of 8K textures triples the application file size to 3 GB.
The most accessible version of Beacon Virtua uses Unity’s WebGL player that allows the simulation to run within a desktop web browser—Firefox, Chrome, Internet Explorer and Edge were all tested. This version is built into a webpage, which is hosted normally as part of a website. When the user navigates to the web page, their browser begins running Beacon Virtua in a similar way to view any web based content. This system requires the entire application to be downloaded into the web browser when the user navigates to the page. As such, the total size of the application is limited by the amount of time the user will wait for it to download, and how much memory their browser can allocate to run it. In our testing we found that the application needed to be kept within around 25 MB in size.
Unity heavily compresses the assets when it makes the WebGL build of the application, but to meet this much smaller build size some assets either had to be removed entirely or use lower quality copies. The 3D models captured using P3DR contributed significantly to the file size and hence the 3D models of graves and cairns were removed and replaced with flat images. Additionally, textures were downsized, and all but a small sample of the panoramic photo bubbles were removed.
The massive drop in application size from 1 GB to around 20 MB is possible because the majority of the original application’s size is due to the texture resolution. Removing bubbles and downsizing other textures is relatively easy, though there is a noticeable decrease in the visual quality of the simulation.
22.214.171.124 Head Mounted Displays
Unity provides native support for several head mounted display VR systems. Unity can be configured to build applications that will run with minimal programming effort. However, the design of the simulation needs to be adjusted to account for the differences in user experience and supported user input devices on the various HMD platforms. The high-end HMD version is built off the PC version and employs an Xbox controller that operates relative to where the user is looking. This version has not been publicly released at this stage.
Google Cardboard is an entry level head mounted display which uses a smartphone to display stereoscopic content. The phone is mounted in a low-cost holder—often made from cardboard, hence the name—which when worn, uses lens to show each of the viewer’s eyes only half the screen. An image for the left eye is rendered on one half of the smartphone screen and an image for the right eye is rendered on the other half, allowing the user to see stereoscopic 3D depth.
Unity can build for Cardboard with a plugin provided by Google. The Cardboard version of Beacon Virtua is also constrained by its file size. Users must download it, and their phone must be able to fit the application in memory. The project team targeted less than 100 MB for the Cardboard version. To reach this size limit the textures were downsized and bubbles were reduced as was done with the WebGL version. Cardboard applications can be built for iPhone and Android phones. Separate builds must be made for iOS and Android, and there are different stores and approval processes for distributing the application to end users.
The Samsung Gear VR is another system for turning an Android smartphone into a head mounted display. Like the Oculus Rift, the Gear VR is directly supported by Unity and needs no plugins. As the Gear VR is quite similar to the Google Cardboard it could use effectively the same version of Beacon Virtua; however, the Gear VR version can assume a higher level of computer performance and hence can offer a higher graphics performance level than the Google Cardboard version.
126.96.36.199 Large-Scale Immersive Displays
The Curtin HIVE visualization facility at Curtin University features four immersive large-screen displays in one facility (Woods 2016b). Each of the displays has unique capabilities. The Tiled display is a 24 mega pixel media wall made up of 12 full-HD 55″ LCD panels. The Cylinder display is a 3 m high 180° wide screen with an 8 m diameter which can operated in stereoscopic 3D. The Wedge display has two rear-projected flat screens mounted at 90°, each with a 3.7 m diagonal which can also operate in stereoscopic 3D—similar to two panels of a CAVE display. The Dome display is a 4-m diameter half-dome oriented vertically which fills the user’s full primary and peripheral field of view. These displays are typical of the types of large-scale immersive displays available in visualization facilities around the world. Beacon Virtua has been customized to run on all four of the large screens in the HIVE.
The principal HIVE version of Beacon Virtua is for the HIVE Cylinder display. MiddleVR is used to run Unity applications in stereoscopic 3D on the Cylinder. To account for the curved surface of the Cylinder, MiddleVR is configured to use 12 stereoscopic cameras around the cylinder to render the environment, each one drawing to a small vertical strip section of the screen. When the application is run in stereoscopic 3D each camera needs to be duplicated so that there is one camera for each eye for a total of 24 cameras.
The Dome version of Beacon Virtua uses a special camera model that pre-distorts the fisheye image to account for the optical properties of the display. The pre-distortion ensures that the final image on the curved dome surface appears correct to the viewer. The HIVE systems can optionally use the SpaceMouse six degrees of freedom controller from 3Dconnexion for user navigation input. All HIVE display versions have unique executables but run the same content as the PC version of Beacon Virtua, except with 8K bubbles and adjusted information text to explain the different controls.
188.8.131.52 Exhibition Version
Towards the completion of this edition of Beacon Virtua there was an opportunity to showcase the simulation in a major exhibition; however, it was thought necessary to implement a special exhibition version. Although Beacon Virtua works well with a head mounted display, this configuration would require a full-time attendant which was not possible to resource for an exhibition which would run for almost 6 months—hence, it was decided to use a flat-screen display to present the simulation in this instance.
Some extra thought had to go into how the exhibition version would ideally operate – particularly the input method. There was concern that physical controllers such as a keyboard and mouse, a joystick, a SpaceMouse, or a gaming controller would be too confusing for a general audience across a wide range of ages. Touch-screen devices are very common these days so it was decided to adapt the simulation to run with a touch-screen interface. In the exhibition, Beacon Virtua was run on a gaming laptop and presented on a 55″ LCD touch screen mounted on a wall. Controls were adapted to work with the touch screen, so that look direction could be changed by swiping the screen and the player could move to a new location by tapping the screen in the direction in which they wish to move.
A number of additional features were added to this version to make it more suitable for the exhibition environment. Firstly it was important that the screen did not remain static between users, perhaps stuck looking at a blank wall, hence an automatic path follow mode was added which would commence after a predetermined period of no user input. Once the timeout is reached, the simulation navigates to the closest point on the guided pathway, and then proceeds along the pathway whilst pausing at all of the information panels and items of interest. When a new user approaches the display, they would see an interesting and enticing simulation. Users could just continue to watch the simulation as it auto-navigates around the island or touch the screen and take control. In order to encourage users to take control, a photo-realistic hand is animated to rise from the bottom of the screen and make a touch action at regular intervals. Once taking control, the user can choose to continue from their current location or start at the beginning. As this version did not need to be downloaded, the 8K bubble textures were used.
Two special plug-ins were used to export video sequences of the user auto-navigating through the entire Beacon Virtua experience—one in standard widescreen aspect in 4 resolution, and another in 360° stereoscopic 3D producing an over-under equirectangular video file. Both of these video sequences have been uploaded to YouTube to provide potential users with a quick way to preview the content of Beacon Virtua.
13.4 Multiple Target Platforms
A significant set of challenges were posed by Beacon Virtua’s deployment to multiple platforms. Different platforms have their own technical and design considerations. Different display types require different cameras to render them—for example, the Google Cardboard setup requires a camera for each eye configured to render to the phone screen properly, while the HIVE Cylinder requires a special VR manager object. Different display systems support different user interface devices and/or modalities. Different systems also have different graphics compute capacity and some content may limit the frame rate of the simulation more than is acceptable. File size is an important consideration for versions that will be downloaded, possibly restricting how much content can be included in the simulation.
In Unity, content is arranged in files called scenes. A scene is like a room where things can be placed. At first multiple scenes were created for different versions of Beacon; this made sense when there were just two versions (WebGL and desktop) but it became difficult to manage as the number of versions increased and as testing refined which content was used in which version. A system was needed that could share content between versions that had similar capability and requirements, while also allowing customized content to be used for platforms that have different requirements. This was achieved using Unity’s Additive Load feature. Normally when a scene is loaded the previous scene is deleted. When an Additive Load is used, the new scene is added to the current one. Content was split between scenes, for example the island and buildings went in one scene while the panoramic bubbles went in another. A version is made by creating an entry scene, this scene includes the control method needed for that version, a UI that works for that display type, and a camera suitable for rendering to that display type. The entry scene also includes a list of all the content scenes needed by that version. When the application is run, the content scenes are loaded additively, adding the island, bubbles, information panels and so on to the entry scene.
This allows two different versions to share content scenes when they have content in common. When the content is updated, changes are inherited by both versions because they are loading the same content. Where content needs to be different, an alternate content scene can be made with the different content and the two versions can load two different scenes for that section of content.
An ongoing challenge of Beacon Virtua’s development was how to allow the user to explore the island. The navigation system is intended to invoke the sense of walking. This required moving over the ground, following the level of the ground, and not letting the user walk through walls, as that is both impossible in real life and visually jarring.
Unity includes its own character controller as a generic solution for letting the user navigate an environment, however this was found to not work well on Beacon’s uneven surfaces and small building interiors. A new player controller was developed which used collision detection to move over the ground and bounce off walls, allowing the user to move around the island like they were walking.
During the early development of Beacon Virtua it was observed that users often struggled with this particular navigation system. In particular, moving around the small, narrow interiors of buildings proved challenging. The problem was that the system would take the user’s input as a direction to move, and then if the collision detection encountered any objects it would either stop or bounce off. This meant that the user would have to select the exact direction that was clear of obstacles to avoid them. Another issue was that this navigation method required a control scheme capable of entering any direction the user wanted to move. This meant that the simulation could not be deployed to the exhibition touch screen or Cardboard without an overhaul of the navigation system, as these versions had limited input methods.
A new system was therefore devised which would take the user’s input and treat it as a destination to reach, moving around any obstacles if needed. The new system makes use of Unity’s pathfinding capability. Pathfinding (in games) is typically a system used by computer control characters to navigate the environment. It works by creating a map of all the areas in the environment a character could reach, and at runtime, characters use an algorithm to find the optimal path to their destination according to that map. Unity has its own system for implementing pathfinding, providing tools for building this map, and telling agents (the user in our case) where to move to. A navigation map was built for the scenes of Beacon Island, and a system was created to pass the user’s input to their player as a destination to reach. The pathfinding then moves the player to the destination automatically, stepping around obstacles as it moves.
13.6 Dynamic Text
The information panels around the island present a lot of text to the user. Each information panel is an object floating in a Unity scene. Text on the panels could be updated in the editor. This text needed to be written, proof-read, sent around the team members for approval, and updated over the development of the project. The text also needed to change across the different versions, as it would refer to the control scheme used and content that may or may not be present.
At first the information panels were treated like the other content and used the additive scene load to load in different sets of panels depending on which version was used. This approach was problematic as panels often only had minor differences, such as an added sentence, between versions. A lot of scenes were added with very similar panels, which exaggerated another problem. Every time a change was made, the text had to be copied from the master text document to each of the information panels. The master document also had to include notes about how panels changed across versions. This was found to be a very labour intensive and potentially error prone technique to update the panels.
The solution was to create a system which read the text from a master file at runtime, and used commands embedded in the file text to filter what content was shown depending on what version was being played. This system uses a third-party plugin for Unity called Ink (2016). Ink is a mark-up language made by the game company Inkle for use in computer game versions of ‘Choose your own Adventure’ books. Text is written in an ink file, and at runtime Unity can read through this file and display text according to the command logic included in the text file. Text can be wrapped in an ‘if’ statement, so it will only display if that condition is true. In the entry scene, we then have a list of variables we set to true or false to determine what version of the text is displayed.
Integrating Ink also provided access to a system for offering choices to the user which was used for Beacon Virtua’s main menu system. Options are displayed asking the user if they would like to go back to the start or jump to a particular part of the island. When a response is selected the simulation receives an instruction to move the user or similar.
13.7 3D User Interface
A minor challenge, though a common one in VR development, is that the user interface (UI) must be viewable in 3D. In 2D game like experiences, the UI can be drawn on top of everything the user sees, because the user sees everything on a flat surface. With a 3D experience, the user can see depth so an interface has to appear at a certain depth. This in turn means the UI elements should be drawn at a distance the user can comfortably see them, but at the same time appear in a way that they do not interfere with objects in the world, such as appearing behind or through walls.
The UI was built to appear as a 3D object in the world, and a script was written to position and orient the UI in relation to the user’s location and facing direction. To avoid clipping through other objects, when the menu is opened all the other objects in the world are made invisible. With the menu displayed the user is unable to move, so there is no need for them to be able to see the environment.
The museum version of Beacon Virtua was launched to the public on 11 October 2016. Beacon Virtua is made available via the WA Museum’s website via www.museum.wa.gov.au/BeaconVirtua. The web page provides an explanation of Beacon Virtua followed by four ways to experience the simulation: (1) A video preview available via YouTube, (2) The WebGL version which provides a simplified version of the simulation, (3) a Google Cardboard (Google VR) version which will run on iPhone and Android smartphones, and (4) the full desktop version which can run on Mac and Windows computers. Allied pages provide information about Beacon Island, the Batavia and the ARC Linkage Roaring 40s project.
While Beacon Virtua has not undergone formal user experience testing, the team has generally observed positive reactions from people who have been shown the simulation. The simulation’s development has mostly concentrated on getting content into the simulation, presenting it in a way that gives a clear sense of the island’s layout and allowing users to explore it easily. The best way to use this kind of simulation to inform users about the subject is another consideration. Unity Analytics has been used to collect limited user activity information about the use of Beacon Virtua. Unity Analytics was in beta during the development of Beacon Virtua and its results have not been validated as yet so the analytics results will not be commented on here. As of June 2018, there was a reported 335 installs of Beacon Virtua across the Android and iOS App Stores.
13.9 Future Work and Conclusions
Formal user testing is something that the team would like to progress and some work is being conducted in that direction currently. One of the most often requested additions to Beacon Virtua is a simulation of the wreck site, which is not currently included except for a floating marker which indicates the location of the wreck site. At the Travellers and Traders exhibition visitors could be seen touching the wreck marker indicating their desire to visit that location. It is worth noting that in parallel with the development work on Beacon Virtua there has been another project supported by the ARC Linkage Roaring 40s project focussing on developing digital 3D models of the Batavia wreck timbers as they existed on the seafloor before excavation. A selection of digital 3D models have been developed from approximately 3500 underwater photographs taken during the 1970s and processed using P3DR. Plans are currently in progress to include the Batavia wreck site in a future upgrade of Beacon Virtua.
The Batavia wreck site today is characterized by a large patch of sand, from where the wreck timbers were removed, surrounded by reef. A PhD student also supported by the Roaring 40s project has created a digital 3D model of the current site using P3DR techniques (McAllister 2018). This 3D model could also be integrated into Beacon Virtua to provide a representation of the wreck site as it is today. Further work could also include the inclusion of a CAD model of the Batavia into the simulation based on knowledge of the timbers and general design of the ship itself (Van Duivenvoorde 2015, 2005).
Virtual reality technologies are currently undergoing rapid development and improvements—both in terms of display and computer hardware, but also in terms of software support and capability. These advancements in turn are spurring significant growth in the development of applications which exploit these technologies. The development of Beacon Virtua has served as an exploration of the use of virtual reality technologies to act as both a digital record of the place and as a way for people to virtually experience the site.
Beacon Virtua uses a rich mix of asset types to implement the simulation of Beacon Island. The challenge and conflict is the ability, or otherwise, to preserve high quality assets while at the same time providing an interactive experience. The level of detail required in a simulation so it can act as a digital record will depend upon the expectations of the individual user and the purpose for which the simulation is created. In some user’s eyes the current level of detail will be insufficient for their requirements—but to add more detail could sacrifice the ability to run the simulation in real-time and hence to provide a realistic interactive visualization. In our view there needs to be much better support for automated level of detail allowing progressively more detailed mesh and textures. In its current form Beacon Virtua has provided a good example of how a remote and significant cultural heritage site can be delivered as an interactive experience to a general audience. The techniques used to provide structure to the guided tour is fairly simplistic but seems to work well. We look forward to conducting formal user experience testing on the simulation to further optimise its operation.
This project has been funded by the ARC Linkage project ‘Shipwrecks of the roaring forties: a maritime archaeological reassessment of some of Australia’s earliest shipwrecks’ (project LP130100137). Initial project work was supported by a Your Community Heritage Grant awarded in 2012 to the Department of Maritime Archaeology at the WA Museum in conjunction with the Department of Fisheries, The University of Western Australia and Flinders University. We wish to thank the Curtin HIVE team including Joshua Hollick and Jesse Helliwell for their contributions to the project. Further project funding for the onward development of Beacon Virtua has recently been received from the Australian Government Department of Environment and Energy, Protecting National Historic Sites scheme.
- Adams JR (2013) Experiencing shipwrecks and the primacy of vision. In: Adams JR, Ronnby J (eds) Interpreting shipwrecks: maritime archaeological approaches. The Highfield Press, Southampton, pp 85–96Google Scholar
- Ariese C (2012) Databases of the people aboard the VOC ships Batavia (1629) & Zeewijk (1727) - An analysis of the potential for finding the Dutch castaways’ human remains in Australia. Special Publication No. 16, Australian National Centre of Excellence for Maritime Archaeology Report—Department of Maritime Archaeology, Western Australian Museum, No. 298. Online: http://museum.wa.gov.au/maritime-archaeology-db/maritime-reports/databasespeople-aboard-voc-ships-batavia-1629-zeewijk-1727. Date Accessed 5 Sept 2018
- Barreau J-B, Nouviale F, Gaugne R, Bernard Y, Linares S, Gouranton V (2015) An immersive virtual sailing on the 18th-century ship Le Boullongne. Presence 24(3):24Google Scholar
- Bourke P (2009) EON—Eye of Nagaur. http://paulbourke.net/exhibitions/EON/. Accessed 15 July 2018
- Cox G (2017) Working on the invincible: the deal with photogrammetry. Artasmedia blog. https://artasmedia.com/2017/03/26/working-with-the-invincible-photogrammetry/. Accessed 14 Sept 2017
- Dash M (2003) Batavia’s graveyard: the true story of the mad heretic who led history’s bloodiest mutiny, 2nd edn. Phoenix, LondonGoogle Scholar
- Denard H (2009) The London charter for the computer-based visualisation of cultural heritage (version 2.1). http://www.londoncharter.org/. Accessed 4 Sept 2018
- Department of Fisheries (2014) Restoration under way at Abrolhos Batavia site. http://www.fish.wa.gov.au/About-Us/Media-releases/Pages/_archive/Restoration-under-way-at-Abrolhos-Batavia-site.aspx. Accessed 15 July 2018
- Drake-Brockman H (1956) The reports of Francisco Pelsaert. West Aust Hist Soc 5(2):1–18Google Scholar
- Drake-Brockman H (2006) Voyage to disaster: the life of Francisco Pelsaert (translated by ED Drok). University of Western Australia Press, NedlandsGoogle Scholar
- Drap P, Seinturier J, Scaradozzi D, Gambogi P, Long L, Gauch F (2007) Photogrammetry for virtual exploration of underwater archaeological sites. Proceedings of the 21st international symposium of CIPA, Athens, Greece, 1–6 October 2007. 6 ppGoogle Scholar
- Drap P, Seinturier J, Conte G, Caiti A, Scaradozzi D, Zanoli SM, Gambogi P (2008) Underwater cartography for archaeology in the VENUS project. Geomatica 62(4):419–427Google Scholar
- Edwards H (1966) Islands of angry ghosts. Hodder & Stoughton, LondonGoogle Scholar
- FitzSimons P (2011) Batavia: betrayal, shipwreck, murder, sexual slavery, courage: a spine-chilling chapter in Australian history. William Heinemann, SydneyGoogle Scholar
- Frankland T (2012) A CG artist’s impression: depicting virtual reconstructions using non-photorealistic rendering techniques. In: Chrysanthi A, Murrieta Flores P, Papadopoulos C (eds) Thinking beyond the tool: archaeological computing and the interpretive process, BAR International Series 2344. Archaeopress, Oxford, pp 24–39Google Scholar
- Green J (1989) The loss of the Verenigde Oostindische Compagnie retourschip BATAVIA, Western Australia 1629. In: Hands AR, Walker DR (eds) BAR International Series 489. B.A.R, OxfordGoogle Scholar
- Haydar M, Maidi M, Roussel D, Drap P, Bale K, Chapman P (2008) Virtual exploration of underwater archaeological sites: visualization and interaction in mixed reality environments. In: Ashley M, Hermon S, Proenca A, Rodriguez-Echavarria K (eds) Proceedings of VAST: international symposium on virtual reality, archaeology and intelligent cultural heritage. The Eurographics Association, pp 141–148. https://doi.org/10.2312/VAST/VAST08/141-148
- Ink (2016) https://www.inklestudios.com/ink/. Accessed 4 Sept 2018
- McAllister M (2018) ‘Seeing is Believing’: investigating the influence of photogrammetric digital 3D modelling of underwater shipwreck sites on archaeological interpretation. Unpublished PhD dissertation, University of Western AustraliaGoogle Scholar
- Morse P (2010) Heritage visualisation on iPhone. http://www.petermorse.com.au/2010/04/heritage-visualisation-on-iphone/. Accessed 15 July 2018
- Pelsaert EF (1647) Ongeluckige voyagie, van’t schip Batavia, nae de Oost-Indien: gebleven op de Abrolhos van Frederick Houtman, op de hooghte van 28 1/3-graet, by zuyden de linie Aequinoctiael. Uytgevaren onder den E. Francoys Pelsert. Jan Jansz, AmsterdamGoogle Scholar
- Roeper V (2002) De schipbreuk van de Batavia, 1629. Walburg Pers, ZutphenGoogle Scholar
- Shaw G (2010) Eye of Nagaur. https://www.jeffreyshawcompendium.com/portfolio/eye-of-nagaur/. Accessed 15 July 2018
- Sherman WR, Craig AB (2002) Understanding virtual reality: interface, application, and design. Elsevier, New YorkGoogle Scholar
- Van Duivenvoorde W (2005) Capturing curves and timber with a laser scanner: digital imaging of Batavia. INA Q 32(3):3–6Google Scholar
- Van Duivenvoorde W (2015) Dutch East India Company shipbuilding: the archaeological study of Batavia and other seventeenth-century VOC ships. Texas A&M University Press, College StationGoogle Scholar
- Woods AJ (2016a) An underwater odyssey: the mission to image the wrecks. In: McCarthy M (ed) From great depths: the wrecks of HMAS Sydney II and HSK Kormoran. UWA Publishing and WA Museum, Perth, pp 255–277Google Scholar
- Woods AJ (2016b) Curtin HIVE—hub for immersive visualisation and eResearch. Presentation at stereoscopic displays and applications conference, electronic imaging symposium, San Francisco, California, USA, 15–17 January 2016. https://youtu.be/iSLESjFZuXg. Accessed 5 Sept 2018
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.