Virtual RADelaide

Team Name: 

With virtual reality technologies on the cusp on mainstream adoption, 3D environments that replicate real-world locations are going to become one of many "killer apps" of this new technological frontier. We present what we believe is an early prototype of one of these killer apps, Virtual RADelaide. If you'd like to get a real sense of what we've created, we encourage you to check out our video on youtube, as below we outline some of the technical details behind what we've created.

Digital elevation model

We held (and still hold) lofty ambitions to faithfully recreate Adelaide in a game engine (Unreal Engine 4), using a large variety of data sets from and the various data repositories of national organisations. We began the process by replicating the terrain of a 30km x 30km area centred around the city of Adelaide. The terrain (the landscape's "heightmap" in UE4 parlance) was created using Digital Terrain Elevation Data Level 2 data (DTEDL2), also known as 1 second SRTM DEM, made available by Geoscience Australia (note - this data is derived from NASA's Shuttle Radar Topography Mission, hence STRM). The process to do this was quite involved (we are still unsatisfied with the results) requiring the use of multiple software packages to massage the data to a format appropriate for importing into the game engine. Broadly:

  1. We begin by downloading a raster (.tiff) containing elevation data  of the region of interest from Geoscience Australia. We note that the 1 second SRTM/DTED L2 data is sampled at ~30m points, such that the difference between each pixel translates to about 30m.
  2. We load the elevation data raster into 3DEM, which is terrain visualisation software.
  3. We change the projection to UTM WGS84.
  4. Adhering to technical limitations of UE4, we want to create a landscape of 4033 x 4033 vertices. In noting that 4033 vertices of 30m would give 120km, we only opt to only focus on an area of 1009 x 1009 (1009 x 30m = 30km). Using this knowledge we extract a smaller area centred on Adelaide (of size 1009 x 1009). The coordinates of this extraction in the UTM WGS84 Zone 54S coordinate system are crucial for all additional aspects of this work, as they define the geographical area we use for the extraction of all other data.
  5. We output the data as Binary Signed Integer.
  6. We use GNU Octave and a script to both rescale the heights and the number of data points (from 1009 x 1009 to 4033 x 4033). To scale the number of data points we use interpolation. To rescale the heights we need to consider the valid height ranges of UE4, which is effectively determine by the number of bits of various data types.
  7. The result of this process is a heightmap that is now in a format suitable for importing into UE4 (find the output of this process here).

Land use

The landscape provides the base upon which everthing else can developed, and in itself is bland and homogeneous from a texturing perspective. We decided to texture the landscape using layers derived from land use / land categorisation (SA data here). The original dataset contains 19 land use categories, with an additional category implied for unclassified areas. Although it would have ideal to maintain all 19 categories, technical limiations of UE4, lead us to make the decision to reduce this number to 8 (via combination of complementary categories). The 8 final categories and their constituent original categories are as follows:

  1. Farming - Argiculture, Horticulture, Farming
  2. Residential - Residential, Rural Residential, Non-Private Residential
  3. Vacant - Vacant, Vacant Residential
  4. Industry & Commercial - Food Industry, Commercial, Public Institution, Retail & Commercial, Utility Industry, Mining
  5. Reserves - Reserve, Forestry
  6. Recreation - Recreation, Golf (yes, golf courses apparently qualify for their own category)
  7. Education - Education
  8. Unclassified

We used QGIS to achieve this, with the inbuilt scripting functionality providing a very easy means to create the combined categories. With the categories combined, and because the vector to rasterise functions within QGIS are broken for what we need to do, we had to use the gdal tools from the command line. The commands we used can be found here (note - because we wanted to create the most faithful representation of the underlying vector data, we created massive size intermediate rasters that exceeded 2.5GB).

When we had the .tiff file with the geo-tag information stripped from it, we loaded it into GIMP for further manipulation. Using layers, thresholding, and rescaling, we created 8 8bit .png files corresponding to each land use category (see below). Although these images are 8bit .png files (required by UE4), they effectively contain binary data (i.e. 1 existence or 0 absence of particular land use category at any given pixel).

  1. Farming
  2. Residential
  3. Vacant
  4. Industry & Commercial
  5. Reserves
  6. Recreation
  7. Education
  8. Unclassified


The process for the creating road weightmaps was essentially the same as for the land use categories described above. One minor change to the process is the extra manipulation that was required in GIMP; to make the roads more visible in the 3D environment we had to play around with morphological operators such as dilation.


The land use and road data could easily be rasterised from shapefile as the geographic information is represented as polygons with some spatial extent. However, the hospital data (SA Health Hospital Locations) only contains point locations, so rasterising would not have yielded a suitable raster for a weightmap. We decided to extract the location of each hospital within the 30km x 30km region of interest and perform some coordinate transform magic to determine the location of each of these hospitals within the coordinate system within the game engine. It should be emphasised that this was non-trivial, as UE4 has no concept of the coordinate systems/projections we are all familiar with (such as long lat etc). Once we had the locations of the hospitals in UE4, we instantiated simple 3D objects at these locations.

To demonstate the capabilities of what is possible if our idea were to be taken further, we created a material in UE4 that responds to external input (keyboard key press), and toggles between a default colour and a highlight colour upon key press. We applied this material to the simple 3D objects used as placeholders for hospitals, such that when the user is navigating the landscape, they can press the specified key ("h") and each of the hospitals changes colour and lights up. Although the time constraints of GovHack restricted our of this implement to a single dataset, this idea and technique is incredibly powerful and could find widespread application.

Oculus Rift integration

We were lucky enough to have a team member that owned an Oculus Rift DK2, so we had an Oculus Rift at our disposal. One bonus of using UE4 was the relative ease with which the Oculus Rift could be integrated into our work, with UE4 effectively providing everything we needed to be get the Oculus Rift working with Virtual RADelaide.

Some images

We invite you to check out some screen shots of the creation process at our github project page.

What we didn't get around to..

In one word, "heaps". We did start to document everything we were planning to do, including the specific datasets, but we ran out of time to include that here...

Software tools

The various software tools used throughout our project are listed below. Note that apart from UE4 & the Oculus Rift, we have only used open source software (note - UE4 is a commercial tool that is freely available for non-commercial uses, full source code can be obtained from github by registering!!). Because of this, we hope that others can follow the process, use what we have created, and build upon our ideas further.

Datasets Used: 
South Australian data: 'Generalised Land Use' data (shapefile) - 'All SA Hospitals 2015' data (shapefile) - 'Roads' data (shapefile) - '3D model of the city of Adelaide' data (.3ds models) - National data: '1 second SRTM Digital Elevation Model of Australia (.tiff) -

Local Event Location: