13.1 Introduction

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.

Beacon Virtua also allows an exploration of how a virtual environment simulation can be used as a digital preservation tool. Beacon Virtua shows the island as it was in 2013 when it housed a small fishing community, with the island dotted with small buildings (colloquially referred to as ‘shacks’), jetties and other structures (see Fig. 13.1). In 2014 all the shacks and jetties were removed which allowed a more detailed examination of the archaeology of the island to take place (Department of Fisheries 2014). The fishing history of the island is an important phase in the life of the island so there was a desire to document the physical embodiment of that activity before it was removed.

Fig. 13.1
figure 1

Aerial view of Beacon Island from the Beacon Virtua simulation showing the jetties and shacks

Full size image

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).

13.2 Simulation

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

One of the challenges in Beacon Virtua was how to turn a fully explorable island simulation into a guided tour to tell the story of Beacon Island’s history. The reason for guiding users was that there are many uninteresting or insignificant locations on the island and hence a user might not find the key locations of the island and discover important aspects of the story without assistance. Any guidance mechanism that was implemented had to be compatible with all of the different platforms on which the simulation would be deployed. There were also limitations of file-size and modes of interaction on the various platforms. Different deployments might also have different requirements - such as the exhibition version that is discussed later. The mechanism that was implemented to guide the user was a series of footprints which indicate a preferred path around the island. The path was chosen to guide the user to important locations on the island that in turn could be used to expose the user to the various aspects of the island’s history. Along the path are a series of floating information panels containing text information about the history of Beacon Island or some aspect about the particular location they are seeing. The user is also able to freely explore the island if they wish. The simulation starts at the end of the main jetty looking towards the island – giving the user the impression of having just arrived at the island by boat (Fig. 13.2). The walk along the jetty provides time for the user to become accustomed to the controls and receive some guidance about the simulation. The guided path continues around the island through some of the shacks, past some of the shallow graves and ends at the southern tip of the island which is the closest point of the island to the Batavia wreck site, which is a nice point to complete the guided tour aspect of the visit.

Fig. 13.2
figure 2

The Beacon Virtua simulation commences at the end of the main jetty

Full size image

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).

13.2.2.1 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.

13.2.2.2 Buildings and Jetties

The buildings and jetties have been recreated as 3D models made by an artist from measurements and photographs taken of the originals on the island. The interiors of the buildings have only been recreated in shape, with blank grey walls (Fig. 13.3). However, the interiors of each room of each shack were captured photographically with series of 360° panorama photo bubbles. These bubbles record the inside of each structure in a level of detail that it is not feasible to recreate geometrically.

Fig. 13.3
figure 3

One of the shacks on the island illustrating the internal photo bubble

Full size image

13.2.2.3 Graves and Coral Features

Three sets of graves, a coral cairn and a coral shelter have been captured as digital 3D models using photogrammetric 3D reconstruction (P3DR) techniques and specifically using the software Agisoft Photoscan/Metashape. P3DR combines the use of traditional photogrammetric methods with advanced image processing techniques to generate detailed digital 3D models of real-world objects from a series of photographs of that object. P3DR is good at generating digital 3D models of complex objects that would be difficult to do any other way, however in this project it has been done sparingly because the models can often be extremely detailed and can place a high computational demand on the simulation (Cox 2017). Generating models that have a ‘low poly count’ but remain visually realistic can be very difficult. The use of P3DR to create 3D models of maritime archaeology related items has exploded in recent years and is particularly suitable for underwater items due to limited visibility and an inability to capture a single image of a large object using other techniques (Woods 2016a). The detailed digital 3D models are inserted into the Unity scene amongst the other project assets (Fig. 13.4).

Fig. 13.4
figure 4

The coral cairn as is it reproduced as a digital 3D model in Beacon Virtua

Full size image

13.2.2.4 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).

13.2.2.5 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.

13.2.2.6 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.

13.2.2.7 Audio

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.

13.2.2.8 Birds

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.

13.2.2.9 Batavia Marker

The Batavia was wrecked on Morning Reef about 1.6 km from the shores of Beacon Island. To indicate the presence of the shipwreck in the simulation a marker was placed floating above the shipwreck location (Fig. 13.5). Clicking on the marker brings up a text menu providing a brief explanation of the marker. At this stage the user cannot explore or navigate to the wreck site but it is something that we are working towards. In another part of the project, digital 3D models of the Batavia wreck site have been developed from roughly 3500 underwater photographs taken of the wreck in the 1970s using the P3DR technique described earlier (Woods 2016b). The team is working towards including these 3D models of the wreck site in the simulation in a future revision of the simulation.

Fig. 13.5
figure 5

Looking towards the Batavia wreck site from Beacon Island in Beacon Virtua

Full size image

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.

13.3.1 Desktop

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.

13.3.2 WebGL

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.

13.3.2.1 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.

13.3.2.2 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.

13.3.2.3 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.

13.3.2.4 Videos

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.

13.5 Navigation

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.

13.8 Discussion

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.

The exhibition version of Beacon Virtua was displayed at the Travellers and Traders in the Indian Ocean World exhibition at the WA Maritime Museum in Fremantle and officially launched by the King and Queen of The Netherlands. The exhibition ran over the period 31 October 2016–23 April 2017 (Figs. 13.6 and 13.7). The simulation was run on a laptop plugged into a large 55-in. touch screen LCD. This configuration provided an effective way for visitors to experience Beacon Virtua, with visitors able to walk up and explore for as long as it held their interest. Promotional postcards located beside the display provided visitors with information about the downloadable versions of Beacon Virtua (Fig. 13.8). One idea was that visitors could experience the HMD version of Beacon Virtua by using their smartphone in combination with a cheap Google Cardboard viewer. The simulation proved to be highly reliable over the length of the exhibition with only two restarts necessary—both due to power failures.

Fig. 13.6
figure 6

Beacon Virtua in situ at the Travellers and Traders exhibition during a curator tour. (Natali Pearson, University of Sydney)

Full size image
Fig. 13.7
figure 7

Beacon Virtua being interacted with by a user at the Travellers and Traders exhibition

Full size image
Fig. 13.8
figure 8

Beacon Virtua promotional postcard

Full size image

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.