General-Purpose Real-Time VR Landscape Visualization with Free Software and Open Data

Abstract

Within the last years, there have been major developments in the fields of virtual reality, open source software, and open geospatial data. This offers new opportunities for landscape visualization which have not yet been explored. This thesis gives an overview of the data, the theory, and the technology required for developing a modern landscape visualization tool with free software and open data. Through real-time rendering, this visualization can be viewed with virtual reality devices such as the Oculus Rift. As a proof-of-concept, a prototypical landscape visualization tool is developed using the open source game engine Godot. The issue of utilizing common geospatial data within a game engine is solved with a custom native plugin, which uses the GDAL library for loading data and converting it to resources usable by the engine. Techniques for shaping and texturing the terrain, as well as populating it with vegetation and other assets such as streets and buildings, are implemented. Via screenshots and a performance evaluation, real-time rendering of freely traversable large-scale landscapes in VR with minimal preprocessing is shown to be viable using free software and open data.

Full text

BACHELOR PAPER
Term paper submitted in partial fulfillment of the requirements
for the degree of Bachelor of Science in Engineering at the
University of Applied Sciences Technikum Wien - Degree
Program Computer Science
General-Purpose Real-Time VR Landscape
Visualization with Free Software and Open
Data
By: Karl Bittner
Student Number: 1710257005
Supervisor: FH-Prof. DI Alexander Nimmervoll
Wien, May 20, 2020

Declaration
“As author and creator of this work to hand, I confirm with my signature knowledge of the rele-
vant copyright regulations governed by higher education acts (see Urheberrechtsgesetz /Aus-
trian copyright law as amended as well as the Statute on Studies Act Provisions / Examination
Regulations of the UAS Technikum Wien as amended).
I hereby declare that I completed the present work independently and that any ideas, whether
written by others or by myself, have been fully sourced and referenced. I am aware of any con-
sequences I may face on the part of the degree program director if there should be evidence of
missing autonomy and independence or evidence of any intent to fraudulently achieve a pass
mark for this work (see Statute on Studies Act Provisions / Examination Regulations of the UAS
Technikum Wien as amended).
I further declare that up to this date I have not published the work to hand nor have I presented
it to another examination board in the same or similar form. I affirm that the version submitted
matches the version in the upload tool.“
Wien, May 20, 2020 Signature

Kurzfassung
Dank großer Fortschritte in den Bereichen Virtual Reality, Open Source Software und
Open Data innerhalb der letzten Jahre öffnen sich neue Möglichkeiten für Landschaftsvi-
sualisierung. Diese Arbeit vermittelt einen Überblick über die Daten, die Theorie und die
Technologie, welche benötigt wird, um anhand freier Software und offenen Daten ein mod-
ernes Landschaftsvisualisierungs-Tool zu entwickeln. Diese Landschaft kann durch Echtzeit-
Rendering mit Virtual Reality-Geräten wie der Oculus Rift betrachtet werden.
Als Proof of Concept wird eine prototypische Landschaftsvisualisierungs-Software mit der
Open Source Game-Engine Godot entwickelt. Die Engine wird durch ein eigenes Plugin
ergänzt, welches die GDAL-Bibliothek nutzt, um gängige Geodaten in die Game-Engine zu
importieren und in native Datentypen umzuwandeln. Techniken für das Formen und Texturi-
eren der Landschaft, sowie für die Darstellung von Vegetation, Häusern und Straßen, wer-
den implementiert. Anhand von Screenshots und einer Performance-Evaluierung wird gezeigt,
dass Echtzeit-Rendering einer frei begehbaren, großflächigen Landschaft in VR mit minimaler
Vorverarbeitung, unter der Verwendung freier Software und offenen Daten, möglich ist.
Schlagworte: Computergrafik, Landschaftsvisualisierung, Geoinformatik, Virtual Reality

Abstract
Within the last years, there have been major developments in the fields of virtual reality, open
source software, and open geospatial data. This offers new opportunities for landscape vi-
sualization which have not yet been explored. This thesis gives an overview of the data, the
theory, and the technology required for developing a modern landscape visualization tool with
free software and open data. Through real-time rendering, this visualization can be viewed with
virtual reality devices such as the Oculus Rift. As a proof-of-concept, a prototypical landscape
visualization tool is developed using the open source game engine Godot. The issue of utilizing
common geospatial data within a game engine is solved with a custom native plugin, which
uses the GDAL library for loading data and converting it to resources usable by the engine.
Techniques for shaping and texturing the terrain, as well as populating it with vegetation and
other assets such as streets and buildings, are implemented. Via screenshots and a perfor-
mance evaluation, real-time rendering of freely traversable large-scale landscapes in VR with
minimal preprocessing is shown to be viable using free software and open data.
Keywords: computer graphics, landscape visualization, geoinformatics, virtual reality

Acknowledgements
First and foremost, I want to thank all my colleagues who worked with me on this project which
landscape visualization was a part of: Mathias Baumgartinger, who implemented and examined
potential VR functionality; Barbara Latosi´
nska, who provided a different perspective focused on
machine learning; Christoph Graf, the technical project lead and responsible for geodata; and
Thomas Schauppenlehner, the scientific project lead. I always found our collaboration very
productive, supportive, and comfortable.
In addition to project supervision, Christoph Graf and Thomas Schauppenlehner also pro-
vided valuable feedback for scientific writing, which I am very thankful for. Furthermore, they
trusted us with a lot of freedom to research and implement what we found interesting and
promising, which proved to be beneficial for everyone involved.
Thanks to my supervisor Alexander Nimmervoll for the regular constructive feedback and
efficient communication, despite the uncertain and unusual times.
Since the performance evaluation and VR testing could not be carried out as expected due
to the COVID-19 situation, Mathias Baumgartinger kindly carried out some benchmarks on his
laptop and Oculus Rift.
Lastly, thanks to Lilia Schmalzl and Christian Mikovits for letting me use their landscape
photographs for the screenshot evaluation.

Contents
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Definition of the requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Expert interview 4
2.1 State of the art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Free software and open data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Geodata 5
3.1 Coordinate system and projection . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Digital elevation models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Orthophoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Land cover and land use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6 Buildings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.7 Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Theoretical basics 11
4.1 Game Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 GPU Shaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 Vertex shaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2 Fragment shaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3 Shader programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Level of detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Virtual reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Technology stack 18
5.1 Game engine (Client) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.1 Godot Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.2 Alternative options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 Geodata processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6 Implementation 22
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2 Specifications of the evaluation system . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3 Geodata loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.4 Tile-based terrain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4.1 Tile system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4.2 Relief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4.3 Texturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4.4 Collision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.5 Vegetation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.5.1 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.5.2 Rendering system overview . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.5.3 On-the-fly data preparation . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.5.4 GPU shaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.6 Buildings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.7 Roads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.8 Other assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.9 World offsetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7 Evaluation 40
7.1 Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2 Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.3 Pre-processing requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8 Limitations 46
9 Possible future work 47
10 Discussion 48
11 Conclusion 49
Bibliography 50
List of Figures 56
List of Tables 58
List of Code 59
List of Abbreviations 60
A Expert interview transcription 61

1 Introduction
1.1 Motivation
Landscape changes have an increasingly high impact on a large number of people. A tower
building or a wind turbine significantly alters the landscape which a large number of people
see and interact with daily. Because of this, such changes should be discussed and finalized
democratically, together with all stakeholders. Landscape visualization is a valuable technol-
ogy for this: Participants can view the landscape changes realistically and neutrally, providing
an objective basis for democratic decisions. With virtual reality headsets, this ability to assess
a landscape is amplified even further thanks to the realistic proportions and immersive explo-
ration. However, this way of decision-making is not yet widespread due to the lack of modern,
publicly available and usable landscape visualization technology:
Today’s landscape visualization technology is fragmented. General-purpose landscape visu-
alization is largely not up-to-date with modern computer graphics and virtual reality systems.
On the other hand, realistically rendered and VR-compatible case studies tend to model a very
specific area with no way to fully reuse it for other projects. This has two reasons: Firstly, the
process of importing geographical data into game engines is lacking and often an ill-defined
manual process. Secondly, the closed-source technology and data which is used rules out the
continued development and re-use of the tool by the general public.
The availability of open data has drastically improved within the last years. Simultaneously,
open source computer graphics technology and game engines have gained momentum, with
software like the Godot Engine having features which are comparable to commercial solutions.
These developments allow novel approaches to a landscape visualization which fully utilizes
modern technology. Through the use of the open source approach, development of such a tool
could be continued by the community, who could also re-use and extend the general-purpose
base for any other project.
The implementation shown in this thesis started as a prototypical landscape visualization
tool for participatory planning workshops. The first technical prototype was roughly described
in an early publication of this research project [1]. The tool was used to assess the impact of
renewable energy sources – wind turbines and solar panels – on the landscape. As part of an
internship, this software was developed further, with the goal of generalizing and automatizing
it into an easily usable and flexible general-purpose VR landscape visualization tool.
1

1.2 Problem statement
This thesis seeks to answer the following questions:
1. Can a technology stack for state-of-the-art VR landscape visualization with large amounts
of geospatial data be built entirely with free software?
2. What is the process from raw geodata to a rendered frame using these technologies?
3. Is it possible to realistically render landscapes purely based on open GIS data without
custom location-specific data, reference photos or manual additions?
4. What types of GIS data are required and freely available for this purpose?
It should be noted that this thesis focuses solely on the visualization. For specific real-world
applications, additional features such as UI, input methods, or landscape manipulation are likely
required. However, such features are out of scope in this paper. They are explored by Mathias
Baumgartinger in his thesis Concepts of Virtual Reality in GIS: A consideration of potential
benefits by using Virtual Reality in the field of Geoscience. Barbara Latosi´
nska also uses the
visualization tool and the data generated by using it with VR in her thesis Machine learning-
based object detection and user behavior classification using virtual reality landscape images
and head motion data.
Due to the focus on visualization, audio is also not discussed in this thesis. [2] suggests
that ambient sounds can further enhance realism of landscape visualizations. Some literature
suggests this could be even more important in VR, although [3] questions that that is the case.
1.3 Methods
As a qualitative method, an expert interview is conducted to capture an expert’s impression
of state-of-the-art landscape visualization, as well as potential opportunities when using open-
source game engines and open data. As noted in [4], the semi-structured format is ideal to
learn about the motivations, attitudes and beliefs of the interviewee, which is why this format
is chosen. The themes to cover in the interview are outlined, but the structure is not rigid
– it resembles a conversation. This interview justifies the requirements and implementation
approaches shown in this thesis.
Research is conducted on geospatial data with a potential use in landscape visualization,
as well as the theoretical background required for the development of such a VR landscape
visualization tool. Furthermore, modern software which can be used in a technology stack
for the entire pipeline from raw geodata to a VR visualization is researched. This research
is done mostly with keyword search on Google Scholar and BASE – first broadly, then on
specific issues and algorithms. Some literature is also taken from the references of other similar
implementations and literature collections.
2

Finally, using the research from the previous chapters, a prototype of a VR landscape visu-
alization is implemented. Well-established algorithms explained in the previous sections, as
well as more novel concepts, are used to realize a prototypical implementation in an attempt to
fulfill all requirements described in the following. To test this implementation, its performance is
evaluated, and screenshots are shown along with real photos to assess the visual fidelity.
The full source code of all parts of the implementation can be found at https://github.com/
boku-ilen/. The projects LandscapeLab and Geodot-Plugin are primarily relevant.
1.4 Definition of the requirements
The title of this thesis gives a rough outline for the requirements of the tool to be developed.
However, to further narrow down the potential research, data, and technology, as well as the
goal of the implementation, more precise requirements are specified:
1. Only technology which is available under a license approved by the Open Source Initiative
must be used. A list of approved licenses can be found in [5].
2. All data must be open, according to The Open Definition. A list of conforming licenses is
given in [6]. Self-created data, if necessary and feasible, is an exception.
3. The performance must be good enough to offer an immersive VR experience. Thanks
to Asynchronous Timewarp [7] and Asynchronous Spacewarp [8] on Oculus devices, as
well as SteamVR Motion Smoothing [9] in OpenVR-compatible devices, 45 FPS is used
as a minimum target.
4. Preprocessing requirements should be kept minimal – geodata which comes in common,
pre-defined formats (see chapter 3) should be usable with no time-consuming importing
process.
5. Given the required data, any geographic location should be displayable. Austrian data is
used for evaluating the available data and the implementation in this thesis, but this should
not be a static commitment; it is only done for practical reasons.
6. The landscape should be freely traversable as long as data is available. Data should be
loaded and unloaded dynamically based on the location.
7. The visuals should be good enough to be recognizable as a realistic landscape with real-
istic proportions in VR. In this thesis, this is assessed via screenshots, but as noted in the
conclusion, user studies should be done to investigate this in more detail.
3

1.5 Related work
A comprehensive collection of literature on various aspects of 3D landscape visualization by the
Virtual Terrain Project can be found at [10]. This project had a similar goal as this thesis: Pro-
viding a general-purpose open source toolset for global real-time terrain rendering. However,
this project is no longer maintained and thus out-of-date with new technology such as VR.
The technology behind the large-scale real-time landscape visualization tool Biosphere3D
is described in detail in [11]. Since the dissertation was published in 2011, it is technologi-
cally outdated at parts and lacks VR integration. However, the general approach to landscape
visualization described in the publication is still relevant.
A general-purpose vegetation rendering system for real-time landscape visualization is de-
scribed in [12]. While the implementation presented in that publication is also not at the tech-
nical state-of-the-art, the core concepts are used to a large extent in the implementation pre-
sented in this thesis. An overview of state-of-the-art global-scale terrain rendering is given by
[13]. An older but still relevant overview of massive terrain rendering can be read in [14]. Though
it focuses on zoomed-out top-down rendering, some techniques and data sources presented in
[15] are applicable to true-scale VR visualization as well.
Within the last years, game engines have increasingly been used instead of the classical,
largely outdated tools described above. [16] and [17] explore the usage of game engines and
modern consumer VR technology for landscape visualization and landscape planning. Further-
more, projects built in the ESRI CityEngine, a 3D urban planning tool integrated with ArcGIS,
can be imported into the Unreal Engine for an immersive VR visualization [18]. This pipeline is
especially interesting for visualizing urban areas. Unfortunately, details of the implementation
are not available to the public and the source code is not published.
2 Expert interview
An expert interview was conducted in order to better understand the current situation of land-
scape visualization technology and open data. The interviewee is Dr. Thomas Schauppen-
lehner, senior scientist at the Institute of Landscape Development, Recreation and Conserva-
tion Planning of the University of Natural Resources and Life Sciences, Vienna. His focus lies
on GIS and landscape visualization, both with classical and modern 3D VR technologies, es-
pecially in the context of civic participation in renewable energy projects. He is also the local
project leader of the original project where a prototype of this tool was developed and used, as
described in [1].
The full transcription of the interview (in German language) can be read in appendix A.
4

2.1 State of the art
The landscape visualization application of choice depends on the scale of the landscape to be
visualized. At a smaller scale, especially in urban scenarios, 3D modelling in applications such
as SketchUp is common. This is an entirely manual process. At larger scales, different tools
need to be used due to the large amounts of geodata. At the University of Natural Resources
and Life Sciences, Vienna, Visual Nature Studio is used for this purpose. It is relatively easy to
get good visual results with little manual or preprocessing work. However, in addition to being
closed-source, it is outdated and no longer receives updates.
Lately, many publications in the field of landscape visualization have used game engines for
rendering. However, these are typically tailored to very specific case studies, with no way to
generalize the tool and use it for different purposes. There is no clear pipeline for geodata, and
a lot of preprocessing and loading is done manually.
2.2 Free software and open data
The availability of open data has drastically improved within the last 10 years. Thanks to initia-
tives like the EU Public Sector Initiative PSI and the EU Directive for Infrastructure for Spatial
Information INSPIRE, geodata with quality high enough for landscape visualization is largely
available for free. However, two problems persist: Firstly, datasets come in a variety of co-
ordinate systems and projections, which necessitates a preprocessing step to unify this data.
Secondly, the search engines used for this data are not well optimized. These limitations were
researched in detail in [19]. Nonetheless, the ability to develop a large-scale landscape visu-
alization purely with geodata (aside from some manual data entry) is novel thanks to these
developments.
Free software has several benefits, especially in a public university setting: Software licenses
are usually not included in the budget for research projects, so a cost-free product is attractive.
This is especially problematic with subscription-based licenses: After that specific research
project is over, the developed tool cannot be reused due to the lack of continued funding for
these licenses. In addition, there is an ethical aspect: When open source software is used
in research projects, it is possible for anyone to reproduce and verify the results. While for-
profit corporate entities may benefit from the guaranteed and actionable support of commercial
software, this is usually not the case in experimental research projects which are not safety-
critical.
5

3 Geodata
Geospatial data provides the foundation of the visualization. Since this thesis seeks to avoid
manual data entry and specialization on specific locations, as much information as possible
should come from general geodata.
As discussed in the previous chapters, the access to open spatial data has improved dramat-
ically. Naturally, only a subset of this data has a use in landscape visualization. This chapter
gives an overview of the most important data sources which play a large role in defining the
visual properties of a landscape. These datasets will subsequently be used in the implementa-
tion.
Geodata has some unique properties, such as varying coordinate systems and projections.
An introduction to these factors and their relevance for landscape visualization provides the
theoretical background required for understanding and using such data properly.
3.1 Coordinate system and projection
All data which is expressed in or relative to geographical coordinates has to choose a geodetic
system which defines the precise meaning of these coordinates. The World Geodetic Sys-
tem 1984 (WGS 84) is a global standard reference frame in which geospatial data is often
expressed, largely due to its use in GPS. OpenStreetMap, for example, uses this geographic
datum [20]. WGS 84 assumes the Earth to be an oblate spheroid and defines its radius and
flattening. Coordinates are expressed in degrees of longitude and latitude.
WGS 84 is widespread, but while its precision of 1-3 meters is enough for GPS navigation,
more accurate coordinates could be desired for some small-scale geodata. More exact systems
are available for specific areas. For example, ETRS 89 is a European standard with an accuracy
of 5 millimeters. National systems also exist: The MGI system is used for national survey within
Austria [21].
In addition to a geodetic system, raster data also has to define a projection which maps a
curved surface on Earth to a 2-dimensional image. A large number of different projections
exists; it is chosen based on the particular use-case of the raster image or map [22]. Because
reprojection is a computationally expensive process, on-the-fly reprojection is too slow for real-
time applications. A single projection should be chosen for all data.
Different projections focus on optimizing certain properties. In [22], these properties include:
1. Area: When using an equal-area projection, a given area on the projected map covers the
same area on Earth, regardless of where the area is located. On such a map, the relative
size of countries and continents is correct, but as a trade-off, their outlines are distorted.
2. Shape: Conformal projections retain local angles. For example, two streets intersecting
at an angle of 90°are shown at the same angle of 90°on the projected map.
6

3. Scale: With an equidistant projection, all distances to one or two certain, established
points or along every meridian remain correct.
4. Direction: Azimuthal projections preserve directions from the center point outwards.
Another important factor is the complexity of the algorithm which applies the projection. While
the WGS 84 coordinate system assumes Earth to be ellipsoid, projections such as Web Merca-
tor use a spheroid for the projection (although Web Mercator coordinates are still expressed in
WGS 84). Because of its efficiency, this projection is used in many online map services such as
Google Maps, Microsoft Bing Maps and OpenStreetMap [23]. The prevalence of the projection
is also significant due to the large amount of time it takes to reproject large amounts of data.
Web Mercator was chosen for the geodata in this landscape visualization tool. While it is
inappropriate for precise mapping due to the discrepancy between the coordinate system, which
uses an ellipsoid, and the projection, which uses a sphere, multiple arguments can be found for
using it for landscape visualization:
1. It is the most common projection in online map services [23], meaning large amounts of
data can be used directly without further processing. This is important due to requirement
4.
2. It works globally, thus satisfying requirement 5.
3. Data which is projected differently can be reprojected to Web Mercator quickly due to the
efficient spherical Earth model.
4. Web Mercator is (nearly) conformal. Thus, on the scale which is viewed in landscape
visualization, there is minimal warping.
However, while these properties make the projection favorable, the properties which the Web
Mercator projection does not fulfill - equal-area and equidistant - do need to be compensated
for. This is discussed further in 6.4.2.
3.2 Digital elevation models
Digital elevation models (DEMs) provide height information as a 2-dimensional texture - usually
a GeoTIFF with 32-bit floating point values, representing the elevation in meters, at each pixel.
There is an important distinction to be made between digital surface models (DSMs) and
digital terrain models (DTMs). DSMs provide actual surface heights including buildings and
vegetation canopy. In contrast, DTMs depict the elevation of the bare ground. This means that,
when viewing a wooded area, the trees are recognizable on the DSM due to their canopy, while
there is no distinction between areas with high vegetation and bare plains in DTMs [24]. This
difference is shown in figure 1.
7

Figure 1: Comparison of a DSM (left) and a DTM (right) at the same location (Cobenzlgasse, Vienna).
Data from [25]
Both DSMs and DTMs are relevant for 3D landscape visualization. DSMs can be used in
conjunction with the orthophoto for a rough representation of the landscape with minimal per-
formance impact, while DTMs are valuable when detail such as building and trees is rendered
separately.
DEMs are available for all of Austria with a resolution of at least 10m, meaning one pixel
represents a 10x10m area [25]. Vienna offers the best data with 1m DTMs [26] and 50cm
DSMs [27].
3.3 Orthophoto
Orthophotos are aerial photographs which have been orthorectified, meaning that they follow a
given map projection and provide orthographic, top-down imagery at all positions. The process
of orthorectification uses parameters of the camera lens, the camera position, a DSM and
multiple overlapping photos to remove perspectivic tilt [28].
In conjunction with a DSM, orthophotos can provide a rough but recognizable representation
of a landscape, as shown in figure 2. This is especially valuable at larger distances, where no
additional building or vegetation meshes are loaded. However, the resolution of orthophotos is
not high enough for display close to the camera, since the finer structure of the terrain cannot
be discerned.
Another limitation is that less information is available for steeper areas due to their vertical,
orthographic nature. Furthermore, no information can be retrieved about straight walls. The
effect of this can be seen in figure 2, where the sides of trees and buildings are not textured
properly. Lateral aerial images could compensate for this, but are not generally freely available.
The basemap service offers orthophoto tiles for Austria with a resolution of 29cm [30]. Or-
thophotos for Vienna are available with 15cm resolution [29].
8

Figure 2: Example of a 3-dimensional terrain tile from an orthophoto and a DSM (Cobenzlgasse, Vi-
enna). Data from [27], [29]
3.4 Land cover and land use
Land cover data creates relationships between locations and land cover types, usually in the
form of a raster dataset. Such land covers typically include asphalt, water, some types of
vegetation, rocks, et cetera – the physical material on the surface of the Earth at that position
[31].
This relatively rough data can be refined with land use maps. These maps provide a socio-
economic interpretation of the surface. For example, where land cover maps might only make
a distinction between herbaceous vegetation and trees, land use maps also specify the specific
crops and trees grown on that land. As noted in [31], however, the exact distinction between
land cover and land use is not always clear, and some classifications are a combination of both.
On its own, such maps are of little direct use for realistic landscape visualizations. However,
given additional data definitions per classification, they can add detail which is not attainable
with orthophotos and heightmaps alone. For example, detailed ground textures can be applied
based on the land use / land cover ID, as shown in [15]. The vegetation system presented in
this thesis also heavily relies on land use data for placing accurate plant communities.
The Sentinel-2 land cover map for Austria provides a foundation with a resolution of 10x10m
and 14 land cover classes [32]. However, especially for vegetation, more specific knowledge of
the plants growing at a location is often required - landscapes with corn crops are noticeably
distinct from wheat fields. Therefore, the INVEKOS dataset, which contains polygons with
detailed information about the agricultural cultivation of the surface [33], is partially added to
the land cover map, resulting in a detailed dataset with 78 classifications as shown in figure 3.
9

Figure 3: Example of combined land use [33] and land cover [32] datasets (left), next to the Open-
StreetMap representation of the area (right) for reference (Tamsweg, Salzburg).
3.5 Infrastructure
Infrastructure such as streets and railways can have a large impact on the aesthetic of a land-
scape. While their rough shape is discernible in high-quality orthophotos, the texture of asphalt
and road markings are largely missing or noticeably pixelated. In addition, 3-dimensional fea-
tures such as elevated roads and bridges, as well as guardrails and other typical repeating
details, are missing.
For this reason, a vector dataset containing infrastructure data is used. It provides line seg-
ments corresponding to streets and railways, usually with additional detail such as type of street,
width, number of lanes, or the speed limit. The rough type of street (e.g. railway, rural road,
or highway) is mapped to a pre-defined street cross-section. This cross-section, as well as the
additional parameters, can be used to procedurally create detailed streets.
OpenStreetMap is a viable global source for such data [34].
3.6 Buildings
Buildings are typically provided as polygons describing their footprints, often with additional
information such as their type or height. OpenStreetMap offers global building polygons [34].
Since height information is not consistently available in this data, the average of the difference
between the DTM and DSM within the building polygon is used. This approach could also be
used for identifying buildings purely from DEMs and Orthophotos, as described in [35].
The type and shape of a building’s roof can be estimated based on the building type field.
Alternatively, applying machine learning to extract roof shapes from DSMs has been shown to
be viable, for example in [36].
10

3.7 Others
There are multiple additional datasets which can further increase the quality of the visualized
landscape, such as power lines, isolated trees, or fences. This can also vary depending on the
type of landscape which is visualized - for example, in regions with a focus on winter tourism, ca-
ble cars may be an important detail, while in urban areas, additional infrastructure and building
data could be required. Many of these datasets are available on OpenStreetMap. Thanks to its
well-defined API, it is easy to retrieve additional data from OSM depending on the requirements
[34].
In the case of missing data, artificial intelligence technology can be used to improve existing
data or gather new datasets. Image recognition technology has been shown to accurately
extract point or polygon features from orthophotos, DEMs, or both. These techniques are out of
scope for this thesis, also due to the available geodata for Austria being good enough, however
it should be mentioned as a promising alternative in areas with lacking datasets. For example,
object detection from aerial images is shown to be viable in [37].
4 Theoretical basics
The data which was presented needs to be turned into a 3-dimensional landscape, which is then
rendered as a finished image of that landscape to be displayed on the virtual reality device. For
realistic and efficient rendering, specialized computer graphics technology and algorithms are
required. This chapter gives an overview of the theoretical concepts which are vital for using a
game engine to implement such a rendering system.
4.1 Game Engines
In the early days of video games, the concept of a game engine did not exist – gameplay and
rendering was inseparable in games such as Pac-Man. However, the more general back-end
code progressively got more reusable. In the 1990s, games such as Quake and Unreal allowed
the creation of games in similar genres. Starting in the 2000s, commercial game engines such
as Unreal Engine, as well as open-source tools like OGRE 3D, became available as general-
purpose game engines. Typical features include 3D rendering, user interface creation tools, a
physics engine and a scripting language [38].
While a landscape visualization tool is not a game per se (although it is often used in the
context of serious games, as discussed in [39]), the efficient and realistic real-time rendering of
large 3-dimensional worlds is a requirement in both video games and landscape visualization
11

tools. Because of this overlap, game engines can reduce the amount of work required for a
custom landscape visualization tool and keep it up-to-date with new software and hardware
features [17].
As described in [38], game engines provide most of the low-level code which is required for
real-time 3D applications. This includes:
• Start-up and shut-down sequences where systems are constructed and dependencies
are resolved.
• Efficient memory management – garbage collection must be avoided in real-time applica-
tions as they may cause stutters.
• Optimized container types such as arrays and trees.
• Efficient file loading and saving, as well as serialization.
• Debugging tools such as logging, breakpoints and performance profiling.
• A game loop which is called multiple times per second to handle input, update the cur-
rently instanced objects, et cetera, after which the finished frame is rendered.
Furthermore, a basic rendering system with default implementations for common require-
ments such as camera projections, lighting, and reflections is provided by a game engine. This
includes common optimization algorithms such as culling (ignoring objects which are not within
the field of view or covered by other objects) and spatial hierarchy structures such as octrees,
which make operations such as finding nearby objects in a 3-dimensional space faster [38].
To summarize, game engines can drastically decrease the amount of work required for im-
plementing a 3D application like a landscape visualization, and they provide efficient rendering
tools with visually pleasing results. However, in some cases, these default implementations
for rendering need to be adapted to the specific task – this will be discussed in the following
section.
4.2 GPU Shaders
Before the 1990s, computer graphics code was generally written manually in a similar way as all
other code, and it was executed on the CPU. However, with the rise of 3D games in the 1990s,
graphics cards with special chips built specifically for computer graphics operations – graphics
processing units (GPUs) – entered the market. With them came the fixed function pipeline, a
standardized list of operations which is hard-wired and parallelized to a large degree on the
GPU [40].
The fixed function pipeline can be roughly divided into two stages: The vertex processor, and
the fragment processor. The vertex processor manipulates geometry via primitives and ver-
tices, with information such as vertex position, normal vector, and texture coordinates. Multiple
12

transformations are applied to this geometry to bring it from model space – vertex positions
relative to the origin of a single object – into screen space, which is a 2-dimensional represen-
tation of projected vertices with depth values. The fragment processor rasterizes the output of
the vertex processor by interpolating between vertices and their associated information. Colors
and textures are applied. After depth testing, blending and masking, the actual pixel color is
output [40].
This fixed function pipeline is valuable for efficient general-purpose computer graphics ap-
plications. It provides a standardized default model for common operations such as lighting
calculation and camera projection, which can run efficiently due to being hard-wired to a large
extent. However, it is inflexible: Programmers cannot intervene in stages of the pipeline for
non-standard lighting calculations, different vertex offsetting logic, or other changes that could
be desired based on the use-case [40].
Because of this, parts of the fixed function pipeline were gradually replaced by shaders in
the 2000s. Since then, graphics cards have become increasingly generalized. Today, even
non-graphical computations can be outsourced to the GPU with technology like OpenCL and
CUDA [40].
Vertex shaders and fragment shaders will be discussed in more detail, since they are avail-
able in Godot [41] and heavily used in the implementation later. However, it should also be noted
that modern graphics APIs support additional features such as tesselation shaders, which can
interpolate between existing vertices to create new vertices. These shaders offer new opportu-
nities in level-of-detail systems, as demonstrated in [42].
4.2.1 Vertex shaders
Vertex shaders replace large portions of the vertex processor of the fixed function pipeline
described above. The code in a vertex shader is called for each vertex of an object. Thus,
attributes of the vertex which is currently operated on, such as position, normals and color, can
be read and changed [40]. For example, in the implementation, a vertex shader will be used to
offset the vertices of a flat plane based on the height of a heightmap.
In OpenGL, it is necessary to convert the geometry from model space to clip space using
matrices such as the ModelViewMatrix which the shader can access [40]. In Godot’s shading
language, this transformation is done automatically after the custom shader. A hidden default
implementation for lighting is provided as well. Thus, a vertex shader in Godot must only de-
scribe where to deviate from the default OpenGL vertex function of the engine [41].
4.2.2 Fragment shaders
Fragment shaders are called for each fragment, the precursors to pixels. The values they have
access to, such as texture coordinates and color, are largely a result of interpolating between
the output vertices of the geometry stages based on the position of the current fragment. They
13

1shader_type spatial;
2
3uniform sampler2D tex;
4
5void vertex() {
6VERTEX += NORMAL *0.1;
7}
8
9void fragment() {
10 ALBEDO = texture(tex, UV).rgb;
11 }
Code 1: Example of a simple shader in Godot. The object is inflated by moving the vertices outwards
along the normal vectors, and textured.
replace parts of the fragment processor of the fixed function pipeline and are responsible for
outputting a final pixel color. Thus, they usually read from textures and calculate per-pixel
lighting [40].
4.2.3 Shader programming
Shaders are generally written in languages similar to C. However, the approach to programming
shaders is different from usual CPU programming due to the unique architecture of GPUs and
the large focus on performance.
According to [40, p. 93], the GPU features four levels of parallelization:
1. Device-level: Systems can have multiple GPUs.
2. Core-level: GPUs have multiple cores, typically far more than CPUs.
3. Thread-level: There can be multiple threads per core.
4. Data-level: Instructions can act on multiple data elements.
When programming a fragment or vertex shader, it is assumed that the code runs on each
fragment or vertex at once. Thus, the state of other fragments in not accessible.
Graphics cards focus heavily on matrices and vectors, and calculations such as matrix mul-
tiplications and dot products are generally the most efficient. If-conditions, on the other hand,
should be avoided: Data-level parallelization works best when instructions can act on all cur-
rently loaded data at once, which is interrupted by branching caused by if-conditions.
Godot’s shading language is a simpler abstraction of GLSL, the OpenGL shading language
[41]. Code 1 shows a simple example of a vertex and fragment shader written in this language.
The result of this shader is shown in figure 4. As is evident, even with no shader (the first image
of figure 4), the basic vertex and lighting transformations are handled by Godot.
14

Figure 4: Comparison of the same object in Godot with an empty shader (left), and with the shader in
code 1 and a texture passed into the tex parameter (right).
4.3 Level of detail
When rendering large scenes, it is infeasible to render all available data at once due to con-
straints in memory and processing power. Thus, systems have to be developed to decide what
has to be rendered with what degree of detail. In rendering, this is called level-of-detail or LOD.
LOD systems are typically employed when rendering meshes. Figure 5shows two LODs of
the same mesh. The highest LOD version with 507 vertices is rendered close to the camera.
Further away, much of the detail becomes indiscernible. Thus, a simplified version with only
161 vertices (31.8% of the original) can be rendered, increasing performance. In figure 5, the
vertex count was reduced using the Decimate / Collapse modifier in Blender [43].
When it comes to large-scale landscapes, additional methods are required. Firstly, it is not
trivial how to handle different LODs in a seamless landscape; secondly, not only the vertices
and draw calls need to be reduced further away from the camera, but also the amount of data
which is loaded.
The quad-tree is a popular data structure to approach this issue. Essentially, it is a tree
where each node has either four or zero children [44]. Quad-trees can be thought of as a two-
dimensional generalization of binary trees. The 3-dimensional equivalent would be octrees.
Quad-trees are relevant at multiple stages of terrain generation and rendering: For triangu-
lating individual terrain tiles, and for organizing all terrain tiles. The application for triangulation
is shown in [45]. For LOD, the latter application is more directly relevant. It has also been called
chunked LOD in [14].
In this context, quad-trees can be viewed as a pyramid of tiles. At the top is the base-level
square tile. This tile can split into four new tiles which, together, cover the same area as the
base-level tile. Each of these tiles can split into four again, producing a total of 16 tiles at level 3,
and so on. This is visualized in figure 6. In first-person landscape visualization, a tile generally
splits when it is close to or underneath the camera. A specific implementation is described in
15

Figure 5: Example showing the reasoning behind LOD systems: Close to the model (top), the details
in the high LOD mesh (left) are significant, while further away (bottom), the lower LOD mesh
(right) is almost indiscernible from the more detailed one.
16

Figure 6: A quad-tree of tiles with three levels.
6.4.1.
Such an LOD tree is not only well-suited for terrain in landscape visualizations due to its
recursive and thus easily generalizable nature: The same quad-tree tiling is present in many
raster datasets, and web-based maps and GIS services such as OSM and Google Maps load
their data in such tiles as well. In this case, the base tile (LOD 0) represents a full Web Mercator
map; at a resolution of 256x256 pixels, a pixel located at the equator is 157 kilometers wide at
this LOD. At LOD 20, a pixel at the same location, at the same resolution is just 15 centimeters
in size [46]. Therefore, applying the same principle to the 3D terrain reduces (pre-)processing
cost: The pre-tiled raster images can be used directly, and no unused data is loaded per LOD.
A typical problem of quad-tree-based terrain are cracks between tiles of different LODs. When
a tile has more detail than the tile next to it, it might display rises and recesses which are not
visible at the resolution of the tile next to it; in this case, the meshes cannot perfectly align, and
a hole will be visible between them.
Multiple solutions exist for solving this issue, as described in [14]. Additional meshes could be
generated to precisely fill these gaps. However, this is a complex operation; a simpler solution
is preferable for real-time dynamic terrain. An alternative approach is to add vertices at the
edge of the tile and move them downwards, thus creating a wall below the tile at its edge which
fills any gaps that might occur.
17

4.4 Virtual reality
Virtual reality devices essentially attempt to make users feel presence and immersion. Pres-
ence, or place illusion, means that the illusion of being in a different place should be conveyed.
Immersion implies that real actions cause the expected response: For example, turning ones
head or leaning forward should produce the expected visual result and feel natural [47].
In head-mounted displays (HMDs) such as the Oculus Rift, presence is realized using two
high-resolution screens which are situated closely (20-70mm) in front of each eye. Convex
lenses are placed between the display and the eye to allow the eye to focus comfortably and
receive a clear image [48]. Thus, each eye receives a separate image which must be generated
using stereoscopic rendering. This has two implications for rendering: Firstly, the workload is
increased, since some parts of the rendering pipeline must be traversed twice. Secondly, the
camera projection is more complex in order to render images which are correctly interpreted
as stereoscopic [49], and distortion caused by the lens needs to be compensated [50]. This is
usually handled by the back-end provided by the HMD manufacturer.
To facilitate immersion, the VR device not only displays the 3-dimensional world, but also
tracks the position and rotation of the user’s head. The Oculus Rift does this via outside-in
tracking: Stationary cameras (outside) record infrared LEDs on the HMD (in). From this, the
position and orientation of the HMD can be triangulated [51].
The stereoscopic view needs to react quickly to changes in the user’s position and orienta-
tion – the motion-to-photon-delay should be below 20 milliseconds [50]. Valve’s and Oculus’
VR drivers directly do optimizations in order to compensate for the increase workload and still
allow immediate reactions. These techniques are called Asynchronous Timewarp [7] and Asyn-
chronous Spacewarp [8] on Oculus devices, and SteamVR Motion Smoothing [9] in OpenVR-
compatible devices such as the Valve Index. Both are implementations of the same concept:
The previously rendered image (along with the pixels’ depth values) is warped in order to look
as if viewed from the new position and orientation, even though no real new image was ren-
dered. While this is inherently limited by the amount of data available from the previous frame, it
works well when used every second frame, thus making 45 FPS seem like 90 FPS to the user.
Some commonly used computer graphics techniques do not work as well in VR as they do
on a flat monitor. Essentially, every illusion of depth perception such as normal mapping (3-
dimensional shadow effects on 2-dimensional surfaces) and billboards (flat meshes with an
image of a 3-dimensional object rendered onto them) are more noticeable, since stereoscopic
rendering facilitates true depth perception. Techniques such as parallax mapping and fur shad-
ing, which produce different visuals for each eye, are preferable [49].
18

5 Technology stack
Now that the relevant theory has been established, a concrete technology stack must be built
which enables the use of the described algorithms and data. This stack is split into two parts:
The game engine which is used for turning the data into a 3-dimensional landscape and ren-
dering it, and the geodata processing tools which import the raw geodata to the engine in an
appropriate format.
5.1 Game engine (Client)
As described in 4.1, game engines can be valuable for getting state-of-the-art graphics and well-
tested implementations of common algorithms required for large-scale 3D rendering. Through
providing design principles, scripting languages and GUI editors, they can speed up develop-
ment and make the result easier to maintain. However, a large number of 3D game engines
and frameworks exist with different features and design philosophies. Thus, in addition to the
open source requirement, additional demands are defined:
1. 3D rendering with modern lighting and post-processing effects must be possible and pro-
vided for general purposes out-of-the-box.
2. Support for OpenVR and Oculus virtual reality devices must given.
3. Custom GPU shaders, at least fragment and vertex shaders, must be supported to allow
the implementation of modern landscape rendering algorithms.
4. The engine must be in active development, so that the addition of upcoming software and
hardware advancements can be expected.
5. An active community of users should surround the engine, so that solutions to common
questions and problems can be found quickly.
6. If tools for handling geospatial data are not provided by the engine, the possibility of
adding such features without large changes in the engine itself should be given.
5.1.1 Godot Engine
The open source Godot engine [52] fulfills all listed requirements, as documented in [41]:
1. Godot supports modern physically based materials, including more advanced features
such as depth maps (adding the illusion of depth to textures), subsurface scattering and
refraction. Different types of light, such as directional lights, point lights, and spot lights
19

are supported. Both baked lightmaps and real-time global illumination are available. Post-
processing effects such as HDR, screen space reflection, depth of field and glow are
supported.
2. Classes for VR functionality are provided in the engine. An implementation for a specific
VR SDK must be added as a plugin. Amongst others, such an implementation is available
for the Oculus SDK and for OpenVR (SteamVR).
3. Custom fragment shaders and vertex shaders can be used instead of the default
physically-based material. They are programmed with Godot’s own shading language,
which is a simplified version of GLSL.
4. Godot is in active development: As of April 25th, 2020, 1114 contributors have added code
to the repository on GitHub [52]. In the month between March 25, 2020 and April 25, 2020,
267 pull requests have been merged and 340 issues closed. The next major upcoming
release will be Godot 4.0, which will include full support for the graphics framework Vulkan
[53].
5. At the Global Game Jam 2020, 358 out of 9601 games were made with Godot. This
makes it the third most popular engine at the jam, with 667 games made with Unreal
Engine, while Unity was clearly the most popular with 6247 games. For contrast, just
three games were developed with the comparable open source 3D engine Xenko [54].
6. No support for geographical data is offered by the engine. However, through GDNative,
compiled libraries written in languages such as C++ can be added to a project without
any changes in or recompilation of the engine itself. These custom libraries, in turn, can
load other libraries for geodata processing, like the ones described in section 5.2.
Godot uses its own scripting language GDScript with a simple syntax which is similar to
Python. However, other languages such as C++ and C# can also be used with the afore-
mentioned GDNative [41]. A GUI editor is provided for programming in GDScript and visually
managing 3D as well as UI scenes.
Godot’s design philosophy
Most game engines use the concept of a scene graph to some extent [55]. In Godot, it is
inherent to the design philosophy and exposed to the developer to a large degree [41].
Scene graphs organize nodes in parent-children-relationships. Scene trees are a special-
ization where each node can have multiple children, but only one parent. Godot uses such a
scene tree. A typical scene tree of the world in a 3D game is shown in figure 7.
When combined with object-oriented design, as is the case in Godot, each node is an object
of a certain class. Godot provides a Node class, which all other types of nodes inherit from.
An example for the chain of inheritance of more specialized nodes is given in figure 8.
The RigidBody, an object participating in the 3D physics simulation, inherits from the abstract
20

Figure 7: Simplified example of a scene tree in a typical 3D world.
• Root
–Sky
–Terrain
–Assets
*Wind turbine
*Car
–Player
*Camera
*Collision object
Figure 8: Inheritance chain of the RigidBody class in Godot according to [41].
RigidBody > PhysicsBody > CollisionObject > Spatial > Node > Object
PhysicsBody, which provides shared functionality for collision detection. Next in the chain,
the CollisionObject handles functionality of colliding using Shapes.Spatial is the basic 3-
dimensional node in Godot, holding a transformation matrix and providing 3D position and
rotation information in different formats. As described previously, Node is the base class of
all nodes in the scene tree, responsible for functionality such as accessing the parent node or
children nodes. Object is the base class for all non built-in types [41].
Godot encourages the use of loose coupling: Self-contained, independent classes with little
to no knowledge about their environment. One common method to achieve this in Godot is
the Signal-system. Signals are essentially Godot’s implementation of the classic Observer
design pattern introduced in [56]. Instead of a node directly calling functions in other nodes
when a certain condition is met, it only emits a signal. Other nodes which are connected to
this signal consequently call a specified function. Thus, instead of a node requiring knowledge
about all other nodes which react to its behavior, it can act as a self-contained system. Signal
connections should ideally be set up by a shared parent node. That way, the single responsibility
principle [57, p. 115-120] is met: The parent node is responsible for organizing its children in the
desired way; the child nodes each implement their own behavior without any tight references
to other outside behaviors. The same type of parent-child relationship is used for dependency
injection: Like signal connections, self-contained child nodes should indirectly receive required
information about other classes from their parent. In other words, nodes should only depend
on their child nodes, not on siblings or parents [41].
21

5.1.2 Alternative options
While the popular and highly capable Unreal Engine does make the source code available to
developers with an account on their Epic Games service, it is not licensed under a true free
software license and thus not an option [58].
Torque3D [59] and Xenko (recently renamed to Stride) [60] can be investigated as possible
alternatives. However, these projects are far less active: Torque3D has merged only two pull
requests within the month from March 25, 2020 to April 25, 2020 [59], while Xenko/Stride has
merged 19 [60]. Three games have been made with Xenko at the Global Game Jam 2020 (as
opposed to 358 with Godot, as noted above); Torque3D does not show up in the statistics at all
[54]. Thus, Godot is chosen for this implementation due to excelling in requirements 4 and 5.
5.2 Geodata processing
As described in chapter 3, various different formats exist for geospatial data. Since these are
not supported by Godot by default, additional tools are required for processing this data and
converting it to a format which Godot can handle, such as textures or Godot’s internal vector
types.
Geographic information systems (GIS) can be looked towards for efficient geoodata visu-
alization and processing. ArcGIS is a popular and capable GIS tool which, as noted in the
introduction, is also used and taught at the University of Natural Resources and Life Sciences,
Vienna. However, it is a closed-source, proprietary product. The leading open source GIS
software and a natural alternative to ArcGIS is QGIS [61].
QGIS makes heavy use of GDAL/OGR: The Geospatial Data Abstraction Library (GDAL)
for raster processing and the OGR Simple Features Library (OGR) for vector processing [62].
As shown in [63], GDAL supports a very large number of raster formats (over 140) and is
scalable and performant enough for handling and processing large amounts of spatial data.
GDAL also offers a complete and well-supported API for C++, making it usable with GDNative.
In its documentation, it is described as presenting “a single raster abstract data model and
single vector abstract data model to the calling application for all supported formats [64]”. Thus,
GDAL is well-suited for the purpose of reading and converting various types of geospatial data.
Its place in the implementation is described in detail in 6.3.
6 Implementation
Using the technology and the theory from the previous chapters, a complete, self-contained
landscape visualization tool is developed as a proof-of-concept. While prototypical, all important
22

aspects for a realistic landscape rendering are described. The specific implementation using
Godot and the GDAL plugin is shown with the aid of code and figures.
6.1 Overview
As discussed in chapter 5, the Godot game engine is chosen for visualizing the landscape in
VR. For loading geospatial data efficiently, a custom plugin for Godot using C++ and GDAL is
accessed.
Many aspects of the visualization use a central quad-tree system for level-of-detail (LOD). It
allows areas of over 100x100km to be displayed with increasingly more detail towards the cam-
era. A shader uses digital elevation models and orthophotos for displaying the basic landscape.
For more detail, land cover data is accessed as well to render fitting detailed ground textures.
The same land cover texture is used by the vegetation system. IDs on this texture are
mapped to definitions of plant communities, each of which consists of multiple plant species
represented by photographs and parameters such as their height and their frequency of occur-
rence. In Godot, a shader processes this data to render the images in the appropriate size at
the appropriate positions.
Additional detail such as buildings, roads and power poles are loaded from vector geodata.
In the case of assets like power poles, static meshes are used. The building meshes are
generated from their footprints and height in a pre-processing step. 3D roads are generated
on-the-fly. A world offsetting system ensures that the large-scale terrain is not prone to floating-
point errors.
6.2 Specifications of the evaluation system
While development of this implementation was carried out on multiple different PCs, even ac-
cross operating systems, one device served as the benchmark to verify the performance re-
quirements. The hardware specifications of this PC are listed in table 1.
The VR benchmarks were carried out with an Oculus Rift CV1, which has a resolution of
1080×1200 per eye, and a refresh rate of 90 Hz.
Table 1: Hardware specifications of the performance evaluation PC.
Operating system Windows 10 Pro 64-bit (10.0, Build 18363)
Processor Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (12 CPUs), 2.2GHz
Memory 16384MB RAM
GPU NVIDIA GeForce RTX 2080 with Max-Q Design
Display Memory 16126 MB
23

Figure 9: Architecture of Geodot, the custom GDNative plugin for loading geodata.
Godot
Geodot (GDNative Module)
Raster Processor Vector Processor
GDAL/OGR
Dataset 1 Dataset 2 Dataset 3
6.3 Geodata loading
As discussed in 5.1.1, Godot itself does not support geodata loading. However, it does provide
a way for developers to write plugins in languages such as C++ without recompiling the engine.
This system is called GDNative. It is used for developing a plugin which loads georeferenced
datasets such as GeoTIFFs and shapefiles, extracts the desired data from them, and passes it
to Godot in a native Godot class. That plugin was named Geodot and is available as a separate
open-source project at https://github.com/boku-ilen/geodot-plugin.
For the reasons described in 5.2, GDAL is chosen as a library for loading geodata from disk.
An additional layer is added to improve maintainability: So-called processing libraries depend
on GDAL and wrap its data to custom classes. The actual GDNative module depends on these
processing libraries and converts their output to Godot classes. Thus, the code which depends
on GDAL does not need to be recompiled for new Godot versions, and the API provided by
the custom processing libraries keeps changes in GDAL from directly affecting the GDNative
module. This architecture is visualized in figure 9. As is evident in that diagram, other process-
ing libraries could easily be added; they could even access a different back-end than GDAL, if
necessary.
For example: In GDScript, a subset of a raster dataset is requested via Geodot. Geodot
queries the Raster Processor, which loads the dataset with GDAL and wraps it in the GeoRaster
class. This class is returned back to the GDNative module, where it is wrapped in the Godot-
compatible class GeoImage with functions such as GeoImage.get_image_texture which returns
the data as an ImageTexture, a Godot resource type.
24

Figure 10: Wireframe rendering of the tile terrain, viewed top-down, with 4 LODs. The camera is posi-
tioned at the red point.
6.4 Tile-based terrain
A large portion of the loaded geodata is used in a tile-based terrain system. The general
structure and purpose of this is described, followed by descriptions of the individual modules
used in that system.
6.4.1 Tile system
As described in 4.3, the use of an LOD system is crucial to large-scale terrain rendering. The
quad-tree approach is used in this implementation for the reasons described previously. The
effect of the typical quad-tree subdivision on terrain detail can be seen in figure 10: The smaller
tiles close to the camera produce a higher density of vertices, and thus more detail.
A node named WorldTile was added; it represents a tile at a certain LOD. Depending on the
distance to the camera, it can split or converge. Splitting means that the tile instances four new
WorldTiles as children. When they are done loading, these children become active and visible,
while their parent tile turns invisible. Conversely, when a WorldTile converges, it deletes its
children and becomes visible again.
In addition to splitting and converging, a WorldTile is responsible for instancing its modules.
A module implements a certain functionality or visual element, such as the colliders or a basic
25

1{
2"distances": [
37000,
42000,
5500
6],
7"modules": [
8["BasicTerrainModule"],
9[],
10 ["TerrainColliderModule"],
11 ["-BasicTerrainModule", "DetailedTerrainModule"]
12 ]
13 }
Code 2: Simplified example for the definition of tile split distances and modules per LOD in JSON format.
terrain from orthophotos and DSMs. Modules are implemented generically. In most cases,
they do not need to know the LOD at which they are currently operating; they only access
parameters such as their tile’s size and position, which is injected by this tile. They are also
self-contained – they load their own data and handle how it should be used, regardless of what
potential other modules are doing.
More specificially, within Godot’s design philosophy, this means that the WorldTile node is
responsible for splitting and converging appropriately. It has two child nodes, a ChildrenHan-
dler which instances four new WorldTiles as a reaction to the WorldTile’s split signal, and a
ModuleHandler which instances the appropriate module scenes for its LOD.
The modules which the ModuleHandler of a WorldTile should load are defined per LOD. Thus,
the quad-tree is not only responsible for adding vertices, but also for adding new functionality,
which might use new data sources. For example, at a high LOD, the DetailedTerrainModule is
loaded instead of the BasicTerrainModule. Colliders are not loaded at all at low LODs.
Code 2 shows how the distances at which a tile splits, and the modules that tiles load, are
defined. The first layer of tiles (LOD 0) is loaded with just a BasicTerrainModule. At a distance of
7000m or closer, the tile splits, producing four new tiles which each have a BasicTerrainModule.
Since each of these new modules loads data at the same resolution as their previous low-
LOD counterpart, the resolution of the overall terrain at this position effectively doubles. At
2000m, the TerrainColliderModule is added in addition to doubling the terrain resolution again.
Lastly, at 500m (LOD 3), the DetailedTerrainModule is loaded by the new tile instead of the
BasicTerrainModule, which loads additional data sources and a different shader to provide more
detailed visuals (this is described more closely in 6.4.3).
Thanks to this modifiable definition, it is easy to adapt the LOD system based on the capa-
bilities of the PC and VR headset which are currently used: With a more performant PC and
a higher-resolution VR display, the splitting distances might decrease and modules might be
added and replaced sooner. Because they are self-contained, entirely new modules could be
26

1float get_curve_offset(float distance_squared) {
2return RADIUS - sqrt(RADIUS *RADIUS - distance_squared);
3}
Code 3: Calculation of the offset which needs to be subtracted from VERTEX.y to compensate for the
Earth’s curvature based on its radius. The squared distance is used in order to prevent an
additional, unnecessary square root.
added or removed as well, depending on the current use case.
6.4.2 Relief
In most cases, a module which displays 3-dimensional terrain will always be loaded by a tile.
Although the texture might differ (see 6.4.3), the generation of the relief – the 3-dimensional
terrain itself – is always similar.
A plane with a set number of subdivisions forming a uniform grid of vertices is used. As
mentioned in 4.3 and described in [45], more complex approaches are available for triangulating
a mesh for a heightmap. The vertex count can be decreased with such methods. However,
without tessellation shaders (which are not available in Godot), this mesh would have to be
generated on the CPU, which is time- and resource-consuming.
A shader then transforms the vertices of this plane mesh based on a heightmap: The pixel
value at the current UV position is read and assigned to VERTEX.y. In the case of Web Mercator
data, this height may be multiplied by a factor in order to compensate for the discrepancy
between x- and z-meters (which are warped by the projection and thus do not necessarily
correspond to real lengths), and y-meters – values of the heightmap, which are not affected by
the projection. In turn, to preserve proper scale perception in VR, all terrain must be downscaled
by this factor. Alternatively, the world scale of Godot’s ARVROrigin node can be modified so
that one Godot unit is perceived to be longer or shorter than one meter.
For accurate large-scale visualization, the Earth’s curvature needs to be compensated for
since projected data is being rendered onto flat planes. This is done in the shader: A vertical
offset is added to vertices based on their distance to the camera on the x-z-plane. The function
used for this is shown in code 3. The formula is derived from the Pythagorean theorem.
As mentioned in 4.3, a problem arises when tiles of different LOD are next to each other: Due
to the added detail, the higher-LOD terrain can render rises and recesses which are not visible
in the lower-LOD neighbor tile. Thus, gaps form between the tiles. As a workaround, the skirt
method proposed in [14] is used: The mesh has an additional outer row of vertices which are
positioned far below the vertices controlled by the heightmap. This causes the area below a tile
to be enclosed by walls, which fill potential gaps. This is shown in figure 11.
27

Figure 11: Wireframe rendering of a border between tiles of different LODs. The skirt extending down
at the edge can be seen. Some locations where the necessity of the skirt is visible are
highlighted in green.
6.4.3 Texturing
Albedo
Low- to medium-LOD tiles are textures only by an orthophoto. At high LODs, however, these
orthophotos are not sufficient: The finer structure of the ground, such as a detailed forest floor
or the characteristic texture of asphalt, should be visible. For this, the land-use map is used. A
detailed ground texture is assigned to each possible pixel value in this map in a manual tabular
definition. The terrain shader then reads the land-use value at the current UV position and uses
it to select one of the detailed ground textures.
While this gives the terrain a realistic, detailed texture, some detail is actually lost by replacing
the orthophoto with these textures: The true shade of the ground at that position is replaced by
the generic color in the detail texture. Not only does this make the ground less accurate, it also
causes it to look unnaturally homogeneous.
To solve this, the orthophoto is also read in addition to the land-use map and the detail texture.
The color value from the orthophoto is converted from RGB (red, green, and blue) to HCY (hue,
chroma, and luminance). The algorithm for this color space conversion is adapted from [65]. It
is efficient and well-suited for a fragment shader: RGB to HCY involves three dot products, an
arctangent, and a square root. The opposite direction can be done with three dot products, a
sine and a cosine. The same conversion is done with the value from the detail texture.
The hue of the detail texture value is then replaced by the hue value from the orthophoto. The
chroma value is also shifted towards the orthophoto’s chroma. The result is converted back to
RGB and applied to the fragment. As a result, the ground texture is less repetitive and emulates
28

Figure 12: Comparison between terrain textures with only an orthophoto (left), only the detail textures
according to the land-use map (center), and the detail textures hue-shifted to the orthophoto
color (right).
the shade of the orthophoto – for example, different shades of green and brown on a field of
grass are again visible. The effect of the individual stages of this process can be seen in figure
12. It should be noted that this figure serves only to illustrate the difference between textures
and the effect of adapting the hue – normally, only the orthophoto would likely be used at this
distance, since the fine texture of the ground is not relevant.
A downside of this technique is that floors of dense forests are colored according to the
canopy color visible in the orthophoto, not the color of the ground, which is not available. Ex-
cluding certain land-use IDs from the hue shifting process may be worth investigating, although
this would increase the complexity of the vegetation definition, which is why it was avoided in
this implementation.
Normal
As described in [66], small changes in surface height primarily present themselves with the
shadowing they produce, not through the actual geometry. This resulted in the proposal of nor-
mal maps: Textures whose RGB values represent 3-dimensional normal vectors of the surface.
Thus, a fragment shader uses not only the normal which was interpolated from the vertices for
light calculation, but an additional value from this normal texture. This method is used in the
terrain to achieve more detailed shadowing, making the height information appear to be more
detailed than the actual vertex geometry.
A heightmap such as the DEM used by the terrain can be converted into a normal map. [66]
shows an algorithm for this using the cross product of the partial derivatives of the surface at the
desired position. This algorithm is used in Godot’s Image.bumpmap_to_normalmap function
[52]. However, other algorithms are available for better results: In [67, p. 24, 25], use of the
Sobel filter is described for smoother and less noisy normal maps.
Another downside of Godot’s implementation is that it only supports clamp to edge behav-
ior during the calculation of normal vectors. At the edge of the image, one additional height
29

1// Prevent the edges from having flat normals by using the closest valid normal
2x = std::clamp(x, 1, heightmap->get_width() - 2);
3y = std::clamp(y, 1, heightmap->get_height() - 2);
4
5// Sobel filter for getting the normal at this position
6float bottom_left = heightmap->get_pixel(x + 1, y + 1).r;
7float bottom_center = heightmap->get_pixel(x, y + 1).r;
8float bottom_right = heightmap->get_pixel(x - 1, y + 1).r;
9
10 float center_left = heightmap->get_pixel(x + 1, y).r;
11 float center_center = heightmap->get_pixel(x, y).r;
12 float center_right = heightmap->get_pixel(x - 1, y).r;
13
14 float top_left = heightmap->get_pixel(x + 1, y - 1).r;
15 float top_center = heightmap->get_pixel(x, y - 1).r;
16 float top_right = heightmap->get_pixel(x - 1, y - 1).r;
17
18 Vector3 normal;
19
20 normal.x = (top_right + 2.0 *center_right + bottom_right) - (top_left + 2.0 *
center_left + bottom_left);
21 normal.y = (bottom_left + 2.0 *bottom_center + bottom_right) - (top_left + 2.0
*top_center + top_right);
22 normal.z = 1.0 / scale;
23
24 normal.normalize();
Code 4: Calculation of the normal vector corresponding to a pixel at position x, y in a heightmap using
the Sobel operator as described in [67, p. 24, 25]. C++ code used in the GDNative plugin.
pixel outside of the image would be requried in order to calculate the normal vector. Godot’s
implementation assumes the height value outside of the image to be the same as the closest
available value, resulting in flat (upright) normal vectors. However, this is not usually the case
with terrain: It makes more sense to assume that the incline of the terrain stays constant at the
edge, not the height.
For these reasons, a custom implementation was written. It is shown in code 4, and a com-
parison between this method and Godot’s default is given in figure 13. This calculation happens
on the CPU, and the resulting image is passed to the shader. It is possible to calculate the
normal values from the heightmap directly in the shader, but due to the complexity of the cal-
culation (primarily caused by the large number of texture reads), the slightly increased loading
time is deemed less problematic than a consistently lower framerate.
When a detailed ground texture is used as described in the Albedo section above, a normal
map of this ground texture is also accessed. Normals are sampled from it and rotated to be
relative to the normal map of the terrain itself, obtained with the previously described method.
30

Figure 13: Comparison between Godot’s Image.bumpmap_to_normalmap function (left) and the result
of the custom implementation shown in code 4 using a Sobel filter (right): The tile borders are
far less noticeable, and the noise is slightly reduced.
6.4.4 Collision
As described in 6.4.2, the visual relief is created on-the-fly on the GPU using a shader. As
a result, the geometry of the terrain is not known outside of the rendering pipeline. Thus, a
different, additional module is required for collision detection with the terrain and, generally,
obtaining the height of the terrain at a given position.
Collision detection is required to varying accuracy in multiple scenarios:
• Placing the VR origin on the virtual ground
• Allowing raycasts for applications such as teleportation or distance measuring in VR
• Placing assets such as power poles and buildings on the ground
Godot provides the CollisionShape node, which PhysicsBodies can use for colliding with
other PhysicsBodies that have a CollisionShape. Such shapes can either be a simple geometric
shape, such as a sphere, or arbitrarily complex meshes. However, complex meshes cause two
performance hits: Once when building it, and subsequently when it is used by the physics
engine.
For this reason, a hybrid approach is used. First, a rough collision mesh is built: Heightmap
samples are taken in a grid and used to build a mesh. This process is similar to the relief
shader. The discrepancy between this collision mesh and the more detailed terrain is evident
in figure 14.
If a precise position is required, a pixel can be sampled directly from the heightmap image by
converting the global position to pixel coordinates on the heightmap image. Code 5 shows how
this can be implemented in Godot.
For raycasts, the two techniques are combined: First, the rough position is obtained via a ray-
mesh-intersection. Then, the height of this intersection point is replaced by the more precise
height sampled from the heightmap.
31

Figure 14: Comparison between the visible terrain mesh (white wireframe) and the less detailed collision
mesh (red wireframe).
1var tile_origin = tile.global_transform.origin
2var tile_size = tile.size
3
4var normalized_position = (Vector2(global_point.x, global_point.z) -
Vector2(tile_origin.x, tile_origin.z) + Vector2(tile_size / 2, tile_size /
2)) / tile_size
5
6var pixel_position = normalized_position *heightmap_size
Code 5: Conversion of a global position to a pixel position on the heightmap texture of a tile.
32

6.5 Vegetation
6.5.1 Data
The vegetation system uses four data sources: The heightmap for positioning plants at the cor-
rect height, the land-use map for assessing which plant community (also called phytocoenosis)
to place, a custom tabular definition of plants within such a plant community, and a set of pho-
tographs of individual plants or tufts with a transparent background. This approach is similar to
the vegetation system presented in [12]. The aim is to render these photographs onto quads
(rectangular meshes with four vertices) based on the plant community at that location. The end
result can be seen in figure 15.
Values in the land-use map correspond to IDs of plant communities in a CSV file. Each
plant community is comprised of a number of individual plants, each of which is defined with
an average height, the standard deviation from this height, its density (frequency of occurence)
within the plant community and the filename of their photograph.
The definition of plants and the acquisition of their photographs is a significant amount of
manual preparatory work. Most of the required data and images can be found online, but writing
the tabular definition is still laborious. However, no such datasets exist for openly available land-
use data, so this pre-processing step is deemed necessary.
6.5.2 Rendering system overview
Plant rendering heavily relies on the camera position for optimizing performance: Dense grass
is only rendered very close to the camera, while larger trees are rendered at larger distances as
well. Because the tile system does not allow such fine control (the desired radius within which
the densest grass is rendered may be less than 10 meters), the vegetation system is not part
of the LOD-based modules.
Because of the large amount of quads which must be rendered for convincing vegetation
coverage, a system which can efficiently draw the same mesh many times is required. Godot
offers the MultiMeshInstance and the Particles nodes for this. Both can render the same mesh
at multiple locations with only one draw call to the GPU. The MultiMeshInstance focuses on
static instances which can be positioned on the CPU, whereas the Particles node allows the
developer to define a custom shader for the particle placement. Because vegetation should be
loaded, placed and rendered on-the-fly for the current camera location, the Particles node is
chosen. A shader of type particles is written for the quad placement. Another shader of type
spatial specifies the texturing each of these quads.
6.5.3 On-the-fly data preparation
The vegetation data is prepared on the CPU before being passed to the shaders for render-
ing. First, when starting the application, the vegetation definition tables are parsed to custom
33

Figure 15: The same scene with (top) and without (bottom) vegetation on top of an orthophoto, with
heights from a DTM. Grass is rendered within a radius of 20m around the camera, trees are
visible within 1km.
34

GDScript classes. A dictionary maps IDs to Phytocoenosis; each of these Phytocoenosis has
an array of Plants with the previously described parameters.
When loading a given area, the DTM and land-use maps are first extracted from the raster
dataset. A histogram of the land-use image is created to obtain the most common phytocoeno-
sis in this area, which are then retrieved from the previously created ID-to-Phytocoenosis map.
The plants of these Phytocoenosis objects are filtered to only contain plants of a specific height,
because multiple renderers are used for different vegetation layers.
Photograph spritesheet
A spritesheet (multiple plant images within one texture) is created for all plants in the filtered
Phytocoenosis objects. Each row in the spritesheet corresponds to a phytocoenosis, with the
photographs of their plants aligned horizontally in the columns. The plant images are scaled
to at most 1024x1024 pixels and downscaled further based on the difference between their
average height and the maximum height in this renderer, which is also the height of the quad it
is rendered on. Since Godot can handle images with a resolution of up to 16384×16384 pixels
[41], this allows for a total of 16 phytocoenosis per renderer, each with a total of 16 plants.
ID-to-row texture
The row in the photograph spritesheet is selected based on the land-use ID. However, a total of
256 land-use classes exist, while the spritesheet can only hold up to 16 phytocoenosis. Thus,
an additional mapping of land-use ID to spritesheet row is required.
Because Godot’s shaders do not support arrays as uniform arguments, an image is generated
for this purpose. It has a resolution of 256x1 pixels, where the x-coordinate corresponds to a
land-use ID, with the pixel color being the spritesheet row.
Distribution textures
Using the previously described textures, the plant shader can select the spritesheet row to use
at a given position. However, information about which column to use is missing. Selecting
a random plant directly in the shader is not an option, because this random value would be
different each frame. Thus, another texture called the distribution texture is generated for this
purpose.
This texture is a 16x16 pixels image with pixel values representing the IDs of plants within
one phytocoenosis, and thus the columns in the spritesheet. It is created by iterating over all
plants, generating a random number weighed by the plant’s density value, and choosing the
plant with the highest result, at each pixel.
The distribution textures of all phytocoenosis displayed by a given renderer are condensed
into one image. Since up to 16 phytocoenosis are possible per renderer, this texture can be up
to 16x256 pixels large. Again, the row corresponds to the land-use ID via the ID-to-row texture.
35

Figure 16: Data loaded and generated by the vegetation system. The images have been edited for better
visibility.
Vegetation definition
Geodot
Figure 16 visualizes all data loaded and generated by the vegetation system: Using Geodot,
the DTM (left) and land-use (right) sections are extracted. From the land-use map, the ID-to-
row texture (bottom) is created. Using the vegetation definition of the most common plants, the
distribution (right) and photograph (bottom) spritesheets are created.
6.5.4 GPU shaders
Vegetation layer shader
This shader is responsible for positioning the vegetation meshes. As a shader of type particles,
the vertex function is not called for every vertex, but for every particle instance, and no fragment
function is available.
The rows and spacing parameters are used along with the INDEX – an incrementing unique
identifier of the particle which is currently iterated on – to calculate its position and apply it to
the TRANSFORM variable, along with the height at that position sampled from the DTM.
Without further changes, the vegetation looks unnatural: Each plant is identical and they per-
fectly align in a grid. For this reason, an additional noisemap is sampled and used to randomly
offset the particle position, as well as rotate it. As shown in [68], more complex placement
functions exist which can produce good visual grass density with fewer particles; however, that
implementation assumed static placement during pre-processing. It is subject to further re-
search whether this gain would outweigh the cost of additional complexity in the placement
shader when used for dynamic placement.
36

1splat_id = texture(splatmap, pos).r *255.0;
2ivec2 dist_pos = ivec2(int(pos.x *dist_scale) % 16, int(pos.y *dist_scale) %
16);
3
4row = texelFetch(id_to_row, ivec2(int(round(splat_id)), 0), 0).r *255.0;
5col = texelFetch(distribution_map, ivec2(0, int(row) *16) + dist_pos, 0).r *
255.0;
Code 6: Transformation of a global position (pos) to row and column on the plant spritesheet in a vertex
shader using the land-use texture (splatmap) and the distribution texture (distribution_map).
This shader was adapted from Bastiaan Olijs grass particle system implementation [69].
Plant shader
The plant shader is the material of each quad placed by the previously described vegetation
layer shader. Thus, it is responsible for texturing the mesh.
In the vertex function, the world position of the vertex is calculated by multiplying the vertex
position with the WORLD_MATRIX. This position is converted to a position on the splatmap
texture. The splatmap ID is read and converted to a spritesheet row using the ID-to-row texture.
The value from the distribution map (the spritesheet column) is read using the world position of
the vertex and a scale factor for the distribution. The shader code of this can be seen in code
6.
These row and column values are varying variables, which can be set in the vertex function
and read in the fragment function. An interpolation type can be chosen for such variables.
Here, flat interpolation is required because one quad should not interpolate between rows and
columns and draw a combination of multiple plants.
In the fragment shader, a color is obtained from the plant photograph spritesheet using the
row and column variables. Alpha scissoring is also applied: Pixels with an alpha value below a
certain threshold are drawn, while those below are discarded. This circumvents potential issues
with depth sorting of truly transparent materials.
To prevent a harsh transition from vegetation rendering to no vegetation, plants are faded out
from 3/4of the radius of the renderer towards the maximum radius. In order to prevent issues
with depth sorting, which can be problematic with particles as they render within one draw
call, screen-door transparency is used. The principle is the same as dithering: Instead of a true
smooth transition, pixels alternate between full transparency and full opacity in various patterns.
A matrix with threshold values is used to achieve different patterns based on the alpha value
(in this case, the distance). This matrix can be constructed with the Floyd-Steinberg method,
as shown in [70]. A 4-dimensional matrix is used in this implementation, allowing 16 different
dither patterns.
37

Figure 17: Buildings placed on top of a basic terrain (orthophoto + DTM).
6.6 Buildings
Buildings are generated with a Python script for Blender in a pre-processing step. The Open-
StreetMap building footprint dataset is used and extruded along the height, which was retreived
as described in 3.6. Roofs are generated on top of this extruded footprint. Another extrusion
is done downwards in case the building stands on uneven terrain – without this extrusion, parts
of the building may be above the ground. Simple textures are added to the walls and roofs.
Buildings generated this way can be seen in figure 17.
Godot’s importing process limits the possibilities of dynamically loading assets: For perfor-
mance reasons, only meshes which have previously been imported by the engine can be loaded
at runtime. As a workaround, the DSCN Importer [71] is used. It allows pre-importing meshes
and saving them as DSCN files, which can be loaded at runtime using the plugin. However,
a downside is that each file is self-contained, meaning the textures are duplicated in each file.
This leads to an average file size of 9 MB.
Generating buildings is a time-consuming pre-processing step. It was used in this implemen-
tation due to the lack of libraries for building meshes at runtime in Godot with typical features
such as extruding polygons. However, in the future, this may be worth revisiting to assess
whether the impact on runtime performance is small enough for dynamic building generation to
be viable.
The available open data for buildings is relatively undetailed: Many OpenStreetMap buildings
have no attributes other than the footprint polygon. For this reason, relatively generic textures
38

and roofs are used. If more data becomes available in the future, multiple more complex algo-
rithms could be defined for different types of buildings.
6.7 Roads
Detailed, 3-dimensional roads are generated by a tile module at high LODs. Using Geodot,
LineStrings from an infrastructure dataset are extracted according to that tile’s position and
size, and converted to Godot’s Curve3D type.
The points of this curve are given the appropriate height by accessing the DTM. It is important
to use a heightmap with the same resolution as the relief module at that LOD to prevent roads
from floating above the terrain or intersecting with the terrain. In addition to setting their position,
the tilt parameter of each point is set using the normal vector of the terrain at that position. Thus,
the superelevation of the street is preserved.
It is possible to define a polygon which is procedurally extruded along such a Curve3D using
the CSGPolygon node. For rendering streets, a simple CSGPolygon representing the cross-
section of a street is defined. Different cross-sections could be defined for different types of
roads. Textures are added to the meshes which result from this extrusion. In addition to extrud-
ing this polygon to shape the basic street, typical repeating objects such as guardrails or street
lamps could also be added periodically along the curve.
Cross-sections and other more complex features of a street network usually cause minor
visual inaccuracies with this approach, as can be seen in figure 18. Also, typical features such
as traffic lights and appropriate road markings are missing. This was not investigated further
in this implementation since infrastructure is not the focus; however, for some applications,
additional methods could be required, such as the algorithms shown in [72].
This procedural extrusion along a 3-dimensional curve is costly, which is why these detailed
roads are only loaded at high LODs. Depending on the application, generating static models
for the streets in a pre-processing step may be preferrable.
6.8 Other assets
A custom node was written which can load assets based on a georeferenced point dataset.
Possible values of an attribute in that dataset can be mapped to different meshes within the
Godot editor. A radius around the camera in which these assets should be loaded must also
be defined. Thus, static objects such as radio masts, park benches and power poles can be
added depending on the available data and its format.
39

Figure 18: A more complex street network with a roundabout, showing the limitations of the road visu-
alization: While the street alignment is principally correct, some intersections cause visual
glitches, and road markings are inaccurate.
6.9 World offsetting
As defined in requirement 6, it should be possible to traverse all available data without restarting
the application or choosing a different starting location. Therefore, the user might move far away
from the original starting point and coordinate origin. At some point, floating point errors are
inevitable.
To solve this, a global script continuously monitors the camera position. If its x- or z-
coordinate becomes too large, all visual nodes – including the camera itself – are shifted so
that the camera is closer to the in-engine world origin again. Because this is done via a signal,
which can immediately trigger all connected functions in Godot, this shifting is not noticeable
to the user. For loading data, the distance which has been shifted must be saved, and it must
be possible to translate in-engine coordinates to world coordinates (projected Web Mercator
meters).
40

7 Evaluation
Different aspects of the implemented landscape visualization tool are verified in this chapter:
Screenshots are used to demonstrate the visual fidelity, compared to photographs of the same
landscape. Objective benchmarks serve to verify the 45 FPS requirement. Lastly, the pre-
processing requirements are summarized.
7.1 Screenshots
To demonstrate the visual fidelity of the implementation, as well as the closeness of the visual-
ization to reality, screenshots are compared to real photographs of the same location in figures
19,20,21, and 22. The positions were matched using GPS data; the angle of the photo was
roughly recorded and aligned manually. The field-of-view was also adapted to approximately
resemble the focal distance of the camera.
7.2 Benchmarks
The screenshots demonstrate the visual fidelity of the implementation, but for comfortable view-
ing in VR, high framerates are vital. For this reason, the performance of typical, fully loaded
scenes, similar to the previously presented screenshots, is evaluated. The system described in
6.2 is used for these evaluations. It should be noted that an unoptimized debug build is used in
order to have access to Godot’s profiling tools.
Table 2shows the result of the performance evaluation in three different locations. The fram-
erate is captured via Godot’s profiling tools, which calculate an FPS value every second. Each
area was tested for 15 seconds, with the HMD rotating to view every direction. As is evident,
the performance requirement of 45 FPS can be met on average. However, two out of three
tests included a stutter which temporarily dropped the framerate below that.
Table 2: Framerate measurements in three different areas. An FPS value was calculated each second,
meaning that the FPS minimum value represents the second where the smallest amount of new
frames was rendered, and vice versa for the FPS maximum. The FPS average is the average
of all 15 measured seconds. Kindly provided by Mathias Baumgartinger.
Location FPS minimum FPS average FPS maximum
Nockberge 13 46 55
Joglland 45 55 63
Kamptal 17 54 64
The largest bottleneck is the vegetation due to the high amount of individual plants being
41

Figure 19: Comparison between a real photograph (top) and a screenshot of the same location in the
landscape visualization tool (bottom). Location: Kamptal, Austria.
42

Figure 20: Comparison between a real photograph (top) and a screenshot of the same location in the
landscape visualization tool (bottom). Location: Nockberge, Austria.
43

Figure 21: Comparison between a real photograph (top) and a screenshot of the same location in the
landscape visualization tool (bottom). Location: Nockberge, Austria.
44

Figure 22: Comparison between a real photograph (top) and a screenshot of the same location in the
landscape visualization tool (bottom). Location: Joglland, Austria.
45

rendered: Without vegetation, between 70 and 90 FPS are encountered in the same areas.
The framerate fluctuations during testing also largely depend on the amount of plants being
rendered currently.
The performance evaluation in table 2tests fully loaded environments. When the location
changes, or during initial loading (when the LOD gradually increases), stutters can be encoun-
tered occasionally. The largest observed spike while loading three areas was a frame taking
478ms (almost half a second). This occurred while loading an unusually complex street – as
noted in 6.7, they are extruded on-the-fly.
7.3 Pre-processing requirements
Due to most data being loaded into the required format on-the-fly, the requirements for pre-
processing could be kept low. The most time-consuming manual step is the acquisition of
vegetation data, and organizing it with the custom tabular format. As discussed in the expert
interview, this step is similarly laborious in current general-purpose tools. The other major
pre-processing step is the generation of building meshes for the area. Efficient algorithms for
generating these buildings on-the-fly could be investigated as an alternative in the future.
Aside from these steps, the amount of pre-processing depends on the available geodata
for the area to be visualized: If everything is available in the desired projection, no further
processing is required. If the data is incoherent, however, pre-processing such as reprojection
is necessary, as these operations would be too expensive to do on-the-fly. The amount of
work required to acquire the desired geodata – finding open data sources, downloading, and
validating – should not be underestimated as well. For a more easily deployable application
which does not require the user to manually obtain data, the use of online raster tile APIs could
be investigated.
8 Limitations
The vegetation system presented in this implementation relies purely on flat meshes with plant
photographs. The use of 2-dimensional plants has two reasons: Firstly, it allowed the imple-
mentation of an efficient general-purpose renderer for any plant within a certain height range,
thus making the implementation independent of the data it may be used with. Secondly, plant
images are more available and easier to produce manually than 3D models. This is acceptable
in screenshots and on a flat monitor, but the illusion breaks easily with virtual reality displays.
Possible alternatives are discussed in chapter 9.
Naturally, the fidelity of the available data is a hard limitation. The effect of this can be seen
46

well in figure 21: The style and color of the visualized building is noticeably different from the
real one due to lacking building information, and the tree is wrongly placed due to the imprecise
land-use data (resolution of 10m). This results in a noticeably different view at that location.
Because of the lacking features in Godot for procedural mesh generation and mesh importing
at runtime, the implementation presented for buildings is very prototypical and prone to errors,
as well as unwieldy due to the large file size. A different approach would be preferable. Similarly
to the Geodot plugin for geodata loading, a GDNative plugin could be written for efficient on-
the-fly mesh generation.
The quad-tree based terrain system presented in the implementation is flat in the sense
that terrain is rendered onto a plane, not a sphere. While the terrain shader gives vertices
a vertical offset based on the distance to the camera, creating the illusion of curvature, the
limitations inherent to the projection used with the geodata remain. Flight simulators are a
possible application of large-scale landscape visualization where this would be problematic:
Because no projection can maintain realistic distances, areas and angles at once, flight paths
and distances cannot generally be accurate.
There is always a trade-off to be made between pre-processing and on-the-fly generation. As
specified in the requirements, this implementation leans more towards on-the-fly processing.
Thanks to modern hardware and heavy use of multi-threading, this target could largely be
reached – buildings are the only major exception where pre-processing is necessary. However,
the visual fidelity of the landscape visualization is hindered by this focus in two ways: Firstly,
some algorithms which produce better-optimized or better-looking graphics are not fast enough.
Secondly, continuously loading and processing geodata means that the amount of resources
available for rendering is reduced. It is dependent on the specific use-case which approach
is preferable. A general-purpose landscape visualization should allow the user to control the
balance between pre-processing and on-the-fly-computation.
9 Possible future work
The visual fidelity of VR software cannot be conveyed accurately with screenshots. In addition,
it is subject to further research which factors are most vital for immersive landscape recog-
nition. For truly evaluating the graphics and the impact of different parts of the visualization
on the impression of the viewer, user studies are required. These will be conducted with the
implementation shown in this thesis in a later study.
Similarly, the degree of accuracy required for a landscape to be immediately recognizable in
VR should be evaluated in future studies. As discussed in the previous chapter, the wrongly
placed tree and incorrectly estimated building style in 21 cause the visualization to differ no-
ticeably when viewed as a screenshot, side-by-side with a photograph. However, the degree
47

to which this hinders recognition in VR without a reference photo, and whether this would be
improved significantly with more accuracy, is unknown.
Overall, the procedural 3-dimensional buildings shown in this thesis are very approximate and
heavy on pre-processing. Efficient algorithms for generating them on-the-fly could be examined
in future studies, as well as methods for generating more accurate buildings based on the limited
available data. Machine learning techniques could be viable for approximating the roof shape
and inferring the type of building based on size, location and other parameters.
Vegetation is a very broad subject in landscape visualization with many opportunities for fu-
ture research. Firstly, methods for creating a flexible and general database of plant communities
for land-cover and land-use IDs should be investigated. Providing and openly maintaining such
a database could alleviate much of the manual work currently required for defining vegetation
types. On top of that, procedurally generating 3-dimensional vegetation based on the data in
this database might be possible. Furthermore, performance optimizations and visual improve-
ments from state-of-the-art video games could be incorporated.
The open data typically required for landscape visualization has been shown in this thesis,
but various additional data is available, both locally and through global services such as Open-
StreetMap. Possible applications of more unconventional datasets could be researched. Again,
machine learning may provide novel opportunities to use such data.
Because of the focus on visualization, audio was not considered in this implementation. How-
ever, the effect of spatial audio and accurate ambient noises on the convincingness of virtual
landscapes in VR is an interesting area for future studies. The importance of realistic audio, as
opposed to realistic graphics, should be evaluated and taken into account when optimizing the
performance of a landscape visualization tool.
10 Discussion
A technology stack consisting of only free software was presented and used in the implementa-
tion. The open source requirement was not a limitation – even large commercial game engines
like the Unreal Engine do not have native geodata support [17], and with Godot’s GDNative
system, a plugin which accesses GDAL for geodata loading could be built.
The process from raw geodata to a rendered frame was described in detail in the implemen-
tation. To summarize: Data is loaded with GDAL and converted to a Godot resource class using
the GDNative plugin. Depending on the type of data, it is manipulated and put into context by
a Godot script, until it is rendered – often by a custom shader. This design is easily extendable
and allows the usage of various different types and formats of data.
Rendering a landscape based on open GIS data without custom location-specific data and
reference photos was shown to be feasible. As shown by the screenshots given in 7.1, the
48

available data is accurate enough for a recognizable and relatively realistic representation of
the landscape. It should be noted that not all feasible data sources were used in this proof-of-
concept – using additional data sources, even more detail can likely be displayed. However,
this could not be achieved entirely without manual additions: The vegetation data requires a
custom definition, and their photographs must be taken or collected manually.
Overall, the pre-processing requirements are comparable to existing general-purpose GIS-
based tools such as Visual Nature Studio. This is an improvement compared to most existing
game engine-based landscape visualizations, which do not have a clear and efficient geodata
importing process.
The performance requirement of 45 FPS can largely be met. Vegetation is a major bottleneck,
so optimizations should target this system first. In addition, because of the avoidance of pre-
processing, loading and rendering new geodata can cause stutters, which may be problematic
for some applications. For the tool to be as universal and general-purpose as desired, improve-
ments and configurability of this trade-off between pre-processing and run-time performance
may be necessary.
11 Conclusion
Thanks to developments in the fields of open data and free software, a general-purpose land-
scape visualization tool using open data with minimal manual input and pre-processing was
shown to be viable. The data required for a rough representation of a landscape – primar-
ily orthophotos and DSMs – are freely available and can be used with no further processing.
Depending on the desired degree of detail, some manual work is required: Vegetation and ad-
ditional detailed assets and textures require some manual data entry and creation, although
this too could be minimized.
The implementation is prototypical with room for improvement in most aspects. By pursu-
ing the general-purpose approach and collaborative development, such a tool could hopefully
become a valuable starting point in various circumstances, for various groups, and in various
places. As noted in the introduction, the full source code of all parts of the implementations can
be found at https://github.com/boku-ilen/.
Engines like Godot are improving rapidly, as is the availability of high-fidelity open data. In
addition, much is still unknown about the potentials of modern VR technology in the fields of
landscape visualization and landscape planning. Thus, this area is full of opportunities for
further studies which the research and implementation presented here can, hopefully, serve as
a basis for.
49

Bibliography
[1] T. Schauppenlehner, K. Lux, and C. Graf, “Effiziente großflächige interaktive Land-
schaftsvisualisierungen im Kontext des Ausbaus erneuerbarer Energie – das Poten-
zial freier Geodaten für die Entwicklung interaktiver 3D-Visualisierungen,” AGIT Jour-
nal für Angewandte Geoinformatik, vol. 5, pp. 172–182, 2019. [Online]. Available:
https : / / gispoint . de / gisopen - paper / 5904 - effiziente - grossflaechige - interaktive -
landschaftsvisualisierungenim - kontext - des - ausbaus - erneuerbarer - energie - das -
potenzial - freier- geodaten - fuer - die- entwicklung - interaktiver - 3d - visualisierungen. html
(visited on 10/21/2019).
[2] M. Lindquist, E. Lange, and J. Kang, “From 3D landscape visualization to environmental
simulation: The contribution of sound to the perception of virtual environments,” Land-
scape and Urban Planning, vol. 148, pp. 216–231, Apr. 1, 2016, ISS N: 0169-2046. DOI:
10.1016/j.landurbplan.2015.12.017. [Online]. Available: http://www.sciencedirect.com/
science/article/pii/S0169204615002595 (visited on 04/25/2020).
[3] K. Rogers, G. Ribeiro, R. R. Wehbe, M. Weber, and L. E. Nacke, “Vanishing Importance:
Studying Immersive Effects of Game Audio Perception on Player Experiences in Virtual
Reality,” in Proceedings of the 2018 CHI Conference on Human Factors in Computing
Systems, ser. CHI ’18, Montreal QC, Canada: Association for Computing Machinery,
Apr. 21, 2018, pp. 1–13, ISBN: 978-1-4503-5620-6. DOI:10 . 1145 / 3173574 . 3173902.
[Online]. Available: https://doi.org/10.1145/3173574.3173902 (visited on 04/25/2020).
[4] K. Raworth, C. Sweetman, S. Narayan, J. Rowlands, and A. Hopkins, Conducting Semi-
Structured Interviews. Oxfam GB, 2012, 6 pp., ISBN: 978-1-78077-218-9.
[5] Open Source Initiative. (). Licenses by Name, [Online]. Available: https://opensource.org/
licenses/alphabetical (visited on 04/22/2020).
[6] Open Knowledge Foundation. (2020). Conformant Licenses - Open Definition - Defining
Open in Open Data, Open Content and Open Knowledge, [Online]. Available: http : / /
opendefinition.org/licenses/ (visited on 04/22/2020).
[7] M. Antonov. (2015). Asynchronous Timewarp Examined | Oculus, [Online]. Available:
https : / / developer. oculus . com / blog / asynchronous - timewarp - examined/ (visited on
04/22/2020).
[8] D. Beeler, E. Hutchins, and P. Pedriana. (2016). Asynchronous Spacewarp | Oculus, [On-
line]. Available: https://developer.oculus.com/blog/asynchronous-spacewarp/ (visited on
04/22/2020).
50

[9] (Nov. 27, 2018). Steam :: SteamVR :: Introducing SteamVR Motion Smoothing, [On-
line]. Available: https :/ / steamcommunity.com /games /250820 /announcements /detail/
1705071932992003492 (visited on 04/22/2020).
[10] B. Discoe. (2015). Virtual Terrain Project, [Online]. Available: http://vterrain.org/ (visited
on 05/12/2020).
[11] M. Clasen, “Towards Interactive Landscape Visualization,” Nov. 3, 2011. DOI:http://dx.
doi.org/10.14279/depositonce-3005. [Online]. Available: https://depositonce.tu-berlin.de/
handle/11303/3302 (visited on 04/26/2020).
[12] L. Jiang, “The intelligent placement of vegetation objects in 3D worlds,” Masters Research
thesis, The University of Melbourne, 2009. [Online]. Available: https://minerva- access.
unimelb.edu.au/handle/11343/35191 (visited on 04/30/2020).
[13] B. Deng, F. Qin, and T. Deng, “GPU Based Rendering of Global Scale Terrain Data,”
DEStech Transactions on Computer Science and Engineering, vol. 0, no. iceiti, iceiti 2017,
ISSN: 2475-8841. DOI:10.12783/dtcse/iceiti2017/18834. [Online]. Available: http://www.
dpi-proceedings.com/index.php/dtcse/article/view/18834 (visited on 04/26/2020).
[14] T. Ulrich, “Rendering massive terrains using chunked level of detail control,” in SIG-
GRAPH Course Notes, ser. SIGGRAPH Course Notes, vol. 3, 2002.
[15] D. Dinkov and R. Vatseva, “3D MODELLING AND VISUALIZATION FOR LANDSCAPE
SIMULATION,” in ResearchGate, Albena, Bulgaria, 2016. [Online]. Available: https://www.
researchgate. net /publication/ 332543286_ 3D_MODELLING _AND _VISUALIZATION _
FOR_LANDSCAPE_SIMULATION (visited on 04/20/2020).
[16] M. Smith, N. S. Walford, and C. Jimenez-Bescos, “Using 3D modelling and game engine
technologies for interactive exploration of cultural heritage: An evaluation of four game
engines in relation to roman archaeological heritage,” Digital Applications in Archaeology
and Cultural Heritage, vol. 14, e00113, Sep. 1, 2019, ISSN: 2212-0548. DOI:10.1016/j.
daach.2019.e00113. [Online]. Available: http://www.sciencedirect.com/science/article/pii/
S221205481830050X (visited on 01/26/2020).
[17] D. Edler, J. Keil, T. Wiedenlübbert, M. Sossna, O. Kühne, and F. Dickmann, “Immersive
VR Experience of Redeveloped Post-industrial Sites: The Example of “Zeche Holland”
in Bochum-Wattenscheid,” KN - Journal of Cartography and Geographic Information,
vol. 69, no. 4, pp. 267–284, Dec. 1, 2019, ISSN: 2524-4965. DOI:10.1007/s42489-019-
00030-2. [Online]. Available: https://doi.org/10.1007/s42489- 019-00030- 2 (visited on
01/25/2020).
[18] imitropoulou-esristaff. (2020). From CityEngine to Unreal Engine: The journey f... |
GeoNet, The Esri Community | GIS and Geospatial Professional Community, [Online].
Available: https : // community. esri .com / docs/ DOC - 13480- from - cityengine- to - unreal -
engine - the- journey - from- first - design- steps - to - high- quality - real- time - visualization
(visited on 04/26/2020).
51

[19] T. Schauppenlehner and A. Muhar, “Theoretical Availability versus Practical Accessibility:
The Critical Role of Metadata Management in Open Data Portals,” Sustainability, vol. 10,
no. 2, p. 545, 2 Feb. 2018. DOI:10.3390/su10020545. [Online]. Available: https://www.
mdpi.com/2071-1050/10/2/545 (visited on 05/05/2020).
[20] O. Kounadi, “Assessing the quality of OpenStreetMap data,” University College of London,
2009.
[21] J. Otter, 3-D Referenzsysteme in Österreich, 2015.
[22] J. P. Snyder, Map Projections–a Working Manual. Washington, D.C.: U.S. Government
Printing Office, 1987, 410 pp. Google Books: nPdOAAAAMAAJ.
[23] S. Battersby, M. Finn, E. Usery, and K. Yamamoto, “Implications of Web Mercator and Its
Use in Online Mapping,” Cartographica: The International Journal for Geographic Infor-
mation and Geovisualization, vol. 49, pp. 85–101, Jun. 1, 2014. D OI:10.3138/carto.49.2.
2313.
[24] M. Rexer and C. Hirt, “Comparison of free high-resolution digital elevation data sets
(ASTER GDEM2, SRTM v2.1/v4.1) and validation against accurate heights from the Aus-
tralian National Gravity Database,” Australian Journal of Earth Sciences, pp. 1–15, 2014.
[Online]. Available: https://web.archive.org/web/20160607102637/http://geodesy.curtin.
edu.au/local/docs/Rexer_Hirt_2014_DEM_AJES_av.pdf (visited on 04/11/2020).
[25] Stadt Wien und Österreichische Länder bzw. Ämter der Landesregierung. (2016).
Basemap.at – Verwaltungsgrundkarte Österreichs, [Online]. Available: https : / / www.
basemap.at/ (visited on 05/05/2020).
[26] Stadt Wien. (2020). Geländemodell Raster Wien - data.gv.at, [Online]. Available: https:
//www.data.gv.at/katalog/dataset/1eda4b16-05e3-43c3-b5b0-ef8276df0701 (visited on
04/26/2020).
[27] ——, (2020). Oberflächenmodell Raster Wien - data.gv.at, [Online]. Available: https: //
www.data.gv.at/katalog/dataset/47b36dc6- 4555-49bf-900e-8cd67b19dece (visited on
04/26/2020).
[28] G. Konecny, “Methods and Possibilities for Digital Differential Rectification,” in Photogram-
metric Engineering and Remote Sensing, vol. 45, 1979, pp. 727–734.
[29] Stadt Wien. (2019). Orthofoto 2019 Wien - data.gv.at, [Online]. Available: https://www.
data . gv. at / katalog / dataset / 8c3158c9 - be30 - 43a8 - 8db7 - 41aa1a310ac7 (visited on
04/26/2020).
[30] geoland.at. (2019). Orthofoto Österreich - data.gv.at, [Online]. Available: https: //www.
data . gv. at / katalog / dataset / 254757be - 69ef - 4a6c - a4c1 - 1432815d7522 (visited on
04/26/2020).
[31] P. Fisher, A. Comber, and R. Wadsworth, “Land use and land cover: Contradiction or
complement,” in Re-Presenting GIS, John Wiley and Sons Ltd, Jan. 1, 2005, pp. 85–98.
52

[32] Umweltbundesamt. (2019). Sentinel-2 Bodenbedeckung Österreich 2016 - data.gv.at,
[Online]. Available: https : / / www . data . gv. at / katalog / dataset / 97327f91 - 93b7 - 4dbb -
94a4-008a09f45d77 (visited on 04/26/2020).
[33] Agrarmarkt Austria. (2016). INVEKOS Feldstücke Österreich 2016 - data.gv.at, [Online].
Available: https : / / www . data . gv. at / katalog / dataset / fdba4da7 - 259e - 401e - a0ec -
b959e5cdf893 (visited on 04/26/2020).
[34] O. Foundation. (2020). OpenStreetMap, [Online]. Available: https://www.openstreetmap.
org/ (visited on 04/26/2020).
[35] F. Rottensteiner, J. Trinder, S. Clode, and K. Kubik, “Building Detection Using LIDAR Data
and Multi-spectral Images,” p. 10, 2003.
[36] J. Castagno and E. Atkins, “Roof Shape Classification from LiDAR and Satellite Image
Data Fusion Using Supervised Learning,” Sensors, vol. 18, no. 11, p. 3960, Nov. 2018.
DOI:10.3390/s18113960. [Online]. Available: https://www.mdpi.com/1424- 8220/18/11/
3960 (visited on 03/27/2020).
[37] G.-S. Xia, X. Bai, J. Ding, Z. Zhu, S. Belongie, J. Luo, M. Datcu, M. Pelillo, and L. Zhang,
“DOTA: A Large-scale Dataset for Object Detection in Aerial Images,” May 19, 2019.
arXiv: 1711.10398 [cs]. [Online]. Available: http://arxiv.org/abs/1711.10398 (visited on
03/27/2020).
[38] J. Gregory, Game Engine Architecture, 1st ed. A K Peters/CRC Press, 2009, ISBN: 978-
1-56881-413-1.
[39] I. D. Bishop, “Landscape planning is not a game: Should it be?” Landscape and Ur-
ban Planning, Landscape and Urban Planning at 100, vol. 100, no. 4, pp. 390–392,
Apr. 30, 2011, ISSN: 0169-2046. DO I:10 .1016 /j .landurbplan .2011 . 01. 003. [Online].
Available: http://www.sciencedirect.com/science/article/pii/S0169204611000302 (visited
on 02/22/2020).
[40] M. Bailey and S. Cunningham, Graphics Shaders, 2nd ed. Taylor & Francis Inc, 2012,
ISBN: 978-1-56881-434-6.
[41] J. Linietsky, A. Manzur, and Godot Community. (2020). Godot Docs – 3.2 branch —
Godot Engine 3.2 documentation, [Online]. Available: https://docs.godotengine.org/en/3.
2/ (visited on 04/25/2020).
[42] M. Ö. Özek and E. Demir, “Pixel-based level of detail on hardware tessellated terrain ren-
dering,” in ACM SIGGRAPH 2017 Posters, ser. SIGGRAPH ’17, Los Angeles, California:
Association for Computing Machinery, Jul. 30, 2017, pp. 1–2, ISBN: 978-1-4503-5015-0.
DOI:10.1145/3102163.3102218. [Online]. Available: https://doi.org/10.1145/3102163.
3102218 (visited on 04/26/2020).
[43] Blender Foundation. (2020). Blender.org - Home of the Blender project - Free and
Open 3D Creation Software, [Online]. Available: https :// www. blender. org/ (visited on
05/05/2020).
53

[44] R. Finkel and J. Bentley, “Quad Trees: A Data Structure for Retrieval on Composite Keys.,”
Acta Inf., vol. 4, pp. 1–9, Mar. 1, 1974. DO I:10.1007/BF00288933.
[45] R. Pajarola, “Overview of Quadtree-based Terrain Triangulation and Visualization,” Uni-
versity of California, Irvine, Technical Report 02-01, 2002.
[46] V. Wendlik, I. Karut, and F.-J. Behr, “Tiling Concepts and Tile Indexing in Internet Mapping
APIs,” in Applied Geoinformatics for Society and Environment, vol. 1, AGSE Publishing,
2011, ISBN: 978-3-943321-00-5.
[47] M. Slater, “Place Illusion and Plausibility Can Lead to Realistic Behaviour in Immersive
Virtual Environments,” Philosophical transactions of the Royal Society of London. Series
B, Biological sciences, vol. 364, pp. 3549–57, Dec. 1, 2009. DOI:10.1098/rstb.2009.0138.
[48] J.-T. Kim, “Corrective lens for viewing target located at extremely short distance,” U.S.
Patent 20170336599A1, Nov. 23, 2017. [Online]. Available: https://patents.google.com/
patent/US20170336599A1/en (visited on 05/11/2020).
[49] H. Grasberger, “Introduction to Stereo Rendering,” TU Wien, Vienna, 2008.
[50] J. M. P. van Waveren, “The asynchronous time warp for virtual reality on consumer hard-
ware,” in Proceedings of the 22nd ACM Conference on Virtual Reality Software and Tech-
nology, ser. VRST ’16, Munich, Germany: Association for Computing Machinery, Nov. 2,
2016, pp. 37–46, ISBN: 978-1-4503-4491-3. DOI:10.1145/2993369.2993375. [Online].
Available: https://doi.org/10.1145/2993369.2993375 (visited on 05/11/2020).
[51] “Tracking constellation assembly for use in a virtual reality system,” pat., Jan. 8, 2016.
[Online]. Available: https : / / patents . google . com / patent / US9977494B2 / en (visited on
05/11/2020).
[52] J. Linietsky, A. Manzur, and Godot Community, Godotengine/godot, Godot Engine,
Apr. 25, 2020. [Online]. Available: https : / / github . com / godotengine / godot / tree /
4d2c8ba922085a94ab7e963d23289fb8ed9c1f08 (visited on 04/25/2020).
[53] J. Linietsky. (2019). Godot Engine - Vulkan progress report #1, [Online]. Available: https:
//godotengine.org/article/vulkan-progress-report-1 (visited on 04/25/2020).
[54] Global Game Jam, Inc. (2020). Global Game Jam, [Online]. Available: https : / /
globalgamejam.org/ (visited on 04/25/2020).
[55] A. M. L. Karim, M. S. Karim, E. Ahmed, and D. M. Rokonuzzaman, “Scene Graph Man-
agement for OpenGL based 3D Graphics Engine,” p. 6,
[56] E. Gamma, R. F. Helm, R. E. Johnson, and J. M. Vlissides, Design Patterns: Elements of
Reuseable Object-Oriented Software. Addison-Wesley, 1994, I SBN: 0-201-63361-2.
[57] R. C. Martin and M. Martin, Agile Principles, Patterns, and Practices in C#, 1 edition.
Upper Saddle River, NJ: Prentice Hall, Jul. 30, 2006, 768 pp., ISBN: 978-0-13-185725-4.
[58] (2020). Unreal Engine 4 on Github, [Online]. Available: https://www.unrealengine.com/en-
US/ue4-on-github (visited on 04/25/2020).
54

[59] GarageGames/Torque3D, GarageGames, Apr. 23, 2020. [Online]. Available: https : / /
github.com/GarageGames/Torque3D (visited on 04/26/2020).
[60] Stride3d/stride, Stride (Xenko), Apr. 26, 2020. [Online]. Available: https : // github .com /
stride3d/stride (visited on 04/26/2020).
[61] J. M. Flenniken, S. Stuglik, and B. V. Iannone, “Quantum GIS (QGIS): An introduction to a
free alternative to more costly GIS platforms,” EDIS, vol. 2020, no. 2, pp. 7–7, 2 Mar. 31,
2020, ISSN: 2576-0009. [Online]. Available: https :/ /journals.flvc. org/ edis/article/ view /
108810 (visited on 05/05/2020).
[62] QGIS project. (2020). Documentation for QGIS 3.10 — QGIS Documentation documen-
tation, [Online]. Available: https://docs.qgis.org/3.10/en/docs/ (visited on 04/25/2020).
[63] M. Appel, F. Lahn, W. Buytaert, and E. Pebesma, “Open and scalable analytics of large
Earth observation datasets: From scenes to multidimensional arrays using SciDB and
GDAL,” ISPRS Journal of Photogrammetry and Remote Sensing, vol. 138, pp. 47–56,
Apr. 1, 2018, ISSN: 0924-2716. DOI:10. 1016 /j .isprsjprs. 2018 .01 .014. [Online]. Avail-
able: http://www.sciencedirect.com/science/article/pii/S0924271617300898 (visited on
04/23/2020).
[64] F. Warmerdam, E. Rouault, and Contributors. (2020). GDAL documentation, [Online].
Available: https://gdal.org/ (visited on 04/23/2020).
[65] K. Shapran. (2013). Colour-space-viewer, [Online]. Available: https://code.google.com/
archive/p/colour-space-viewer/ (visited on 05/05/2020).
[66] J. Blinn, “Simulation of Wrinkled Surfaces,” Jan. 1, 1978. [Online]. Available: https://www.
microsoft.com/en- us/research/publication/simulation- of-wrinkled- surfaces/ (visited on
05/05/2020).
[67] M. Mikkelsen, “Simulation of Wrinkled Surfaces Revisited,” Department of Computer Sci-
ence at the University of Copenhagen, 2008.
[68] C. Muratori. (2014). The Nebraska Problem, [Online]. Available: https: //caseymuratori.
com/blog_0011 (visited on 04/30/2020).
[69] B. Olij. (2018). Godot-grass-tutorial, [Online]. Available: https://github.com/BastiaanOlij/
godot-grass-tutorial (visited on 05/05/2020).
[70] S. W. Thomas and R. Bogart, “Color dithering,” in Graphics Gems II, J. Arvo, Ed., Aca-
demic Press, 1991, pp. 72–77.
[71] TwistedTwigleg. (2019). DSCN_Plugin, [Online]. Available: https : / / github . com /
TwistedTwigleg/DSCN_Plugin (visited on 05/05/2020).
[72] E. Bruneton and F. Neyret, “Real-Time Rendering and Editing of Vector-based Terrains,”
Computer Graphics Forum, vol. 27, no. 2, pp. 311–320, 2008, ISSN: 1467-8659. DOI:
10.1111/j.1467-8659.2008.01128.x. [Online]. Available: https://onlinelibrary.wiley.com/
doi/abs/10.1111/j.1467-8659.2008.01128.x (visited on 02/14/2020).
55

List of Figures
Figure 1Comparison of a DSM (left) and a DTM (right) at the same location (Cobenzl-
gasse, Vienna). Data from [25] . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 2Example of a 3-dimensional terrain tile from an orthophoto and a DSM (Coben-
zlgasse, Vienna). Data from [27], [29] . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 3Example of combined land use [33] and land cover [32] datasets (left), next to
the OpenStreetMap representation of the area (right) for reference (Tamsweg,
Salzburg). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 4Comparison of the same object in Godot with an empty shader (left), and with
the shader in code 1 and a texture passed into the tex parameter (right). . . . . 15
Figure 5Example showing the reasoning behind LOD systems: Close to the model
(top), the details in the high LOD mesh (left) are significant, while further away
(bottom), the lower LOD mesh (right) is almost indiscernible from the more
detailed one. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 6A quad-tree of tiles with three levels. . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 7Simplified example of a scene tree in a typical 3D world. . . . . . . . . . . . . . 21
Figure 8Inheritance chain of the RigidBody class in Godot according to [41]. . . . . . . 21
Figure 9Architecture of Geodot, the custom GDNative plugin for loading geodata. . . . 24
Figure 10 Wireframe rendering of the tile terrain, viewed top-down, with 4 LODs. The
camera is positioned at the red point. . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 11 Wireframe rendering of a border between tiles of different LODs. The skirt
extending down at the edge can be seen. Some locations where the necessity
of the skirt is visible are highlighted in green. . . . . . . . . . . . . . . . . . . . 28
Figure 12 Comparison between terrain textures with only an orthophoto (left), only the
detail textures according to the land-use map (center), and the detail textures
hue-shifted to the orthophoto color (right). . . . . . . . . . . . . . . . . . . . . . 29
Figure 13 Comparison between Godot’s Image.bumpmap_to_normalmap function (left)
and the result of the custom implementation shown in code 4 using a Sobel
filter (right): The tile borders are far less noticeable, and the noise is slightly
reduced. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 14 Comparison between the visible terrain mesh (white wireframe) and the less
detailed collision mesh (red wireframe). . . . . . . . . . . . . . . . . . . . . . . 32
Figure 15 The same scene with (top) and without (bottom) vegetation on top of an or-
thophoto, with heights from a DTM. Grass is rendered within a radius of 20m
around the camera, trees are visible within 1km. . . . . . . . . . . . . . . . . . 34
56

Figure 16 Data loaded and generated by the vegetation system. The images have been
edited for better visibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 17 Buildings placed on top of a basic terrain (orthophoto + DTM). . . . . . . . . . 38
Figure 18 A more complex street network with a roundabout, showing the limitations of
the road visualization: While the street alignment is principally correct, some
intersections cause visual glitches, and road markings are inaccurate. . . . . . 40
Figure 19 Comparison between a real photograph (top) and a screenshot of the same
location in the landscape visualization tool (bottom). Location: Kamptal, Austria. 42
Figure 20 Comparison between a real photograph (top) and a screenshot of the same
location in the landscape visualization tool (bottom). Location: Nockberge,
Austria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 21 Comparison between a real photograph (top) and a screenshot of the same
location in the landscape visualization tool (bottom). Location: Nockberge,
Austria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 22 Comparison between a real photograph (top) and a screenshot of the same
location in the landscape visualization tool (bottom). Location: Joglland, Austria. 45
57

List of Tables
Table 1Hardware specifications of the performance evaluation PC. . . . . . . . . . . . . 23
Table 2Framerate measurements in three different areas. An FPS value was calculated
each second, meaning that the FPS minimum value represents the second where
the smallest amount of new frames was rendered, and vice versa for the FPS
maximum. The FPS average is the average of all 15 measured seconds. Kindly
provided by Mathias Baumgartinger. . . . . . . . . . . . . . . . . . . . . . . . . . 41
58

List of Code
Code 1 Example of a simple shader in Godot. The object is inflated by moving the ver-
tices outwards along the normal vectors, and textured. . . . . . . . . . . . . . . . 14
Code 2 Simplified example for the definition of tile split distances and modules per LOD
in JSON format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Code 3 Calculation of the offset which needs to be subtracted from VERTEX.y to com-
pensate for the Earth’s curvature based on its radius. The squared distance is
used in order to prevent an additional, unnecessary square root. . . . . . . . . . 27
Code 4 Calculation of the normal vector corresponding to a pixel at position x, y in a
heightmap using the Sobel operator as described in [67, p. 24, 25]. C++ code
used in the GDNative plugin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Code 5 Conversion of a global position to a pixel position on the heightmap texture of a tile. 32
Code 6 Transformation of a global position (pos) to row and column on the plant
spritesheet in a vertex shader using the land-use texture (splatmap) and the dis-
tribution texture (distribution_map). . . . . . . . . . . . . . . . . . . . . . . . . . . 37
59

List of Abbreviations
VR Virtual Reality, usually in the context of headmounted displays with positional tracking
and stereoscopic rendering.
LOD Level of detail: Rendering in a varying degree of detail depending on the distance to
the camera.
GDAL/OGR Geospatial Data Abstraction Library / Simple Features Library. Libraries used for
reading and processing geospatial data.
UV 2-dimensional vector describing the position on a texture, usually in a shader.
WGS 84 World Geodetic System 1984, a global geodetic reference system.
ETRS 89 European Terrestrial Reference System 1989, geodetic reference system for within
Europe.
MGI A geodetic reference system for Austria.
DEM Digital elevation model, either a DSM or a DTM.
DSM Digital surface model, a heightmap which includes the height of buildings and
vegetation canopy.
DTM Digital terrain model, a heightmap of the bare ground, regardless of vegetation or
buildings.
OSM OpenStreetMap, a collaborative map and geodata API.
GPU Graphics processing unit, a processor designed for efficient graphical rendering.
GIS Geographic information system, an application with various tools for working with
geographic data.
HMD Head-mounted display: A virtual reality device which is worn on the head, placing
screens closely in front of the eyes.
FPS Frames per second: The number of new images rendered and displayed each
second.
60

A Expert interview transcription
Karl Bittner (Interviewer): Ich schreibe meine Bachelorarbeit über das Landschaftsvisual-
isierungstool, das wir entwickeln, und die freie Software und die freien Daten, die hier ver-
wendet werden, sind ein Alleinstellungsmerkmal davon. Es gibt relativ wenig Forschung in die
Richtung und gerade in Verbindung mit VR ist das etwas neues. Deshalb möchte ich kurz reden
über die Tools, die derzeit für Landschaftsvisualisierung verwendet werden, um einen Vergleich
zu haben, und dann darüber, warum freie Software und open data konkret für dich interessant
wären.
Karl Bittner: Zuerst einmal zu dem derzeitigen state-of-the-art: Welche Programme verwen-
det ihr für Landschaftsvisualisierung in der Lehre und in der Forschung?
Thomas Schauppenlehner (Experte): Es ist ein bisschen ein Gradient. Wir haben in der
Landschaftsplanung immer den Raumbezug und je nachdem, wie groß das Gebiet ist, das
wir planen wollen, danach richtet sich die Entscheidung, welche Software man verwendet.
Für kleine Räume, das nennt man bei uns Objektplanung, das heißt man hat einen kleinen
Freiraum, üblicherweise urban oder urban-nahe - ein kleiner Park, ein Straßenfreiraum, et
cetera - verwendet man häufig klassische 3D-Modellierungsprogramme. In der Branche ist
Sketchup extrem weit verbreitet, weil es sehr günstig ist. Früher hat man sehr viel mit 3DS Max
gemacht, manche auch mit Blender, aber das ist der klassische Hand-Zugang, also Handarbeit:
Ich habe eine CAD-Planungsgrundlage, welche händisch texturiert wird. Da gibt es ganz wenig
Automatismen. Sobald man irgendwie in die Landschaft geht, kommen entweder an Stelle
der CAD-Daten (in der Objektplanung hat man üblicherwiese CAD-Daten als Grundlage) oder
ergänzend GIS-Daten. Das ist im einfachsten Fall ein Höhenmodell, und wenn es darüber hin-
aus geht natürlich auch noch andere Dinge wie Landnutzungsdaten, Gewässernetz, Straßen-
netz, und so weiter. Da gibt es mit den vorher genannten Softwareprogrammen das Prob-
lem, dass einerseits die wenigsten einen sinnvollen Workflow für die Integration von GIS-Daten
haben, und dass die meisten Programme meistens schon mit dem Import des Höhenmodells
eines größeren Gebiets überfordert sind. Die Algorithmen dort sind einfach nicht so gewählt,
dass sie großflächig mit Level-of-detail in der Ferne arbeiten sondern immer alles berechnen
und die Dinge dann einfach "in die Knie gehen". Es gibt ein paar klassische Landschaftsvi-
sualisierungsprogramme, die aber in den letzten Jahren ziemlich zurückgegangen sind. Echte
Produkte gibt es noch, aber die sind alle ein bisschen vernachlässigt worden und teilweise rel-
ativ outdated. Das, womit wir in den letzten Jahren viel gearbeitet haben und womit ich noch
immer arbeite – was aber wirklich outdated ist, was VR-Support und solche Dinge anbelangt
– ist das Visual Nature Studio. Das ist Mitte der 90er-Jahre entwickelt worden als "World Con-
struction Set", und dann in den 2000ern bis in die 10er Jahre hinein als Visual Nature Studio
61

verbreitet worden. Es ist ein amerikanisches Produkt, das noch immer verkauft wird, aber es
wird eigentlich nicht mehr weiterentwickelt.
Thomas Schauppenlehner: Um kurz zu kategorisieren, was das Visual Nature Studio kann:
Es kann super mit GIS-Daten umgehen, egal ob Rasterdaten oder Vektordaten, man kann auch
Attribute importieren, das heißt man kann auch im Programm selbst zum Beispiel basierend auf
Attributen Landnutzungen verteilen, und so weiter. Es gibt sogenannte Ecosystems mit fractal
noises usw., wo man quasi mit wenigen Klicks und ein paar Menüeinträgen relativ schnell sehr
natürlich wirkende Ökosysteme (Pflanzengesellschaften) zusammenbringt.
Thomas Schauppenlehner: In letzter Zeit sind diese Programme wie gesagt relativ zurückge-
fahren worden, was der genaue Grund ist weiß ich ehrlich gesagt gar nicht. Einerseits, was man
in den letzten Jahren massiv bemerkt hat, ist die Zunahme von Game Engines im Bereich der
Landschaftsvisualisierung. Das erste mal ist das meines Wissens Anfang 2000 gekommen,
da ist die Doom Engine für Architekturvisualisierung verwendet worden. Später, wie Unreal
und Unity gekommen ist, oder auch die CryEngine und ein Haufen anderer, das findet man
immer wieder, aber in den Publikationen wird selten ein generelles Konzept präsentiert, son-
dern nur die Softwarenutzung. Wenn du also liest über eine Game Engine Case Study, siehst
du zwar, dass das super funktioniert, was die 3D-Sache anbelangt – also eine Evaluierung,
wie das unter Nutzern lief – aber du hast wenig über die technische Einbaubarkeit in eigene
Projekte. Im Prinzip fangst du wieder von Vorne an, es gibt keinen gescheitnen Importer für
die 3D-Daten, meistens wird das in Graustufen-Maps umgewandelt, und mit den Editoren weit-
gehend händisch angepasst. Es gibt relativ wenig, was man generisch für andere Projekte
einsetzen kann. Das ist auch eine Erfahrung, die wir selbst gemacht haben: Dass man sehr oft
etwas eigenes entwickelt für ein Projekt, wo sehr viel Zeit und sehr viel Geld hineinfließt, um
für eine Region schöne Bilder zu erzeugen. Wenn aber das nächste Projekt kommt, fängt man
im Prinzip wieder von vorne an. Was bei der Verwendung dieser Game Engines – und hier
komme ich schon ein bisschen zum open-source-Gedanken – ist, dass sehr oft diese Engines
zwar grundsätzlich frei sind, dass man sie also testen kann, aber sobald man das publiziert
oder sie in einem breiteren Rahmen einsetzt, befindet man sich in einem rechtlichen Graubere-
ich oder muss Lizenzkosten klären. Ich glaube zwar, dass sich da in den letzten Jahren bei
irgendeiner Engine einiges getan hat, aber selbst da ist nicht ganz klar, ob das jetzt wirklich
offen ist oder nicht...
Karl Bittner: Ich glaube Unreal ist das – die sind so halb offen, wenn man ein Mitglied ist
bekommt man den Source Code, aber man darf wenig damit machen.
Thomas Schauppenlehner: Irgendwie so. Das ist aus zweierlei Gründen ein Problem: Ein-
erseits hat man so gut wie nie im Projektbudget Lizenzkosten für Software drinnen. Zweitens,
und das sehe ich als größeres Problem: Eine Software kann ich mir anschaffen, da gibt es
Uni-Budgets, wenn ich das gut argumentieren kann. Das Hauptproblem sind eher die Abo-
Gebühren, dass man also Software nicht kauft und dann für die Verwendung besitzt, sondern
man muss es jährlich lizensieren. Projekte dauern dann oft länger als ein Jahr, und man will
es nachher auch noch verwenden, das heißt es fallen fast unkalkulierbar Lizenzkosten an, wo
62

man auch nicht weiß, ob man das in dem Ausmaß braucht und wie lange. Das ist im Prinzip
einer der wesentlichen Beweggründe gewesen, in diesem Projekt sich anzuschauen, welche
offenen Lösungen gibt es überhaupt, und können die mit dem mithalten, was wir an Anforderun-
gen haben. Am Beginn haben wir sehr viel mit Unity und Unreal probiert, dann gab es noch
die Unigine, da hatten wir einen Kontakt, der das unbedingt verkaufen wollte, das wäre aber
von den lizenzkosten einfach viel zu hoch gewesen, und dann gab es noch eine weitere open
source Geschichte, die wir uns angeschaut haben, das ist das Biosphere3D, aber für die Kom-
plexität und den Detailgrad, den wir brauchen, war das einfach nicht so weit bzw. ist nicht so
weit. Das war auch der Grund, warum wir uns für die Godot Engine entschieden haben.
Karl Bittner: Was bei kommerzieller Software gerade von Firmen oft als Vorteil genannt wird,
ist dass von einem großen Unternehmen garantiert Support angeboten wird, solange man die
Lizenz hat. Glaubst du, könnte das bei freier Software ein Problem sein, dass man an Grenzen
stößt und niemanden hat, der dafür zuständig ist?
Thomas Schauppenlehner: Schwer zu sagen: Ich glaube, bei freier Software – wenn die Soft-
ware nicht wirklich ein Randgruppenprodukt ist – habe ich meistens eine sehr gute Community,
die meistens sehr bereitwillig Information und Support liefert, aber natürlich ohne Garantie:
Wenn es nicht hinhaut, haut es nicht hin. Wenn es also einen Bug gibt, kann es sein, dass
er behoben wird oder nicht, aber es muss nicht sein, es ist niemand verpflichtet. Bei kom-
merzieller Software habe ich das vielleicht – ich würde gar nicht sagen sicher, es gibt genug
Bugs in kommerzieller Software, die nicht behoben werden, ich ärgere mich zum Beispiel seit
vielen Versionen mit ArcGIS von ESRI, und sie schaffen es seit 4 Versionen nicht, den ein
oder anderen Bug zu beheben, obwohl man dafür bezahlt. Also ich glaube, vielleicht habe ich
rechtlich ein anderes Gewicht und kann bestimmte Dinge einklagen, wenn ich einen Schaden
erleide aufgrund eines Fehlers. Ich glaube, das spielt sicher eine Rolle in Bereichen wo es
um Sicherheitsaspekte geht, da kann ich mir das durchaus vorstellen. Nachdem wir aber im
Unibereich eher immer auf der experimentellen Ebene sind und in den meisten Fällen nicht für
die breite Masse entwickeln, sondern das meiste prototypisch ist, halte ich diese Einschätzung,
dass ich bei kommerzieller Software mehr Sicherheit und mehr Support habe, eigentlich für
nicht entscheidungsgebend. Wenn ich aber wirklich ein Business habe, das darauf läuft, und
ich muss mich auf bestimmte Dinge verlassen können, kann ich mir durchaus vorstellen, warum
manche Leute dann zu einer kommerziellen Lösung greifen.
Karl Bittner: Ist für dich der ethische Aspekt von open-source Software auch entscheidend?
Thomas Schauppenlehner: Aus Sicht des Einsatzes von Software auf der Universität auf
jeden Fall. Nachdem ich der Meinung bin, dass Forschung grundsätzlich frei sein soll oder frei
sein muss und auch die Ergebnisse frei zugänglich sein müssen, ist nur logisch, dass man
auch mit Werkzeugen arbeitet, die auch von jedem verwendbar und reproduzierbar sind, was
man bei geschlossenen, kommerziellen Lösungen de facto nicht oder so gut wie nicht hat.
Karl Bittner: Dann noch zur open data: Wie hat sich da aus deiner Sicht die Landschaft in
den letzten 5-10 Jahren verändert? Also wie war der Stand vor 5-10 Jahren, und wie schaut
die Lage im Vergleich jetzt aus?
63

Thomas Schauppenlehner: Vor 10 Jahren war es katastrophal. Es gab so gut wie keine offe-
nen Daten, die über die Grenzen der Gemeinden oder Bundesländer hinaus gingen. Das heißt,
man musste sich die Daten, die man gebraucht hat, irgendwie entweder über Projektpartner
oder durch "Beknien" von Behörden organisieren. Budget ist auch damals kaum gewesen für
Datenanschaffung, das heißt man hat oft strategisch Projektpartner ausgewählt, um an Daten
zu kommen. Also man hat bewusst das Land Oberösterreich oder Niederösterreich als Pro-
jektpartner ins Boot geholt, um nachher die Daten zu bekommen. Was damals auch der Fall
war: Dadurch, dass das alles mehr oder weniger Daten waren, die auf irgendeiner Festplatte
in irgendeiner Behörde lagen, sind sie in sehr unterschiedlichen Formaten und Standards und
mit sehr unterschiedlichen Koordinatensystemen und Beschreibungen gekommen. Also selbst
wenn man die Daten hatte, war es ein langwieriges Unterfangen, die Daten zu verstehen und
übereinander zu bringen. Vor allem, wenn man unterschiedliche Quellen genutzt hat: Da war
das Koordinatensystem falsch, dann wusste man nicht, welches das ist, und tausende andere
Probleme.
Thomas Schauppenlehner: Vor 10 Jahren war es also wie gesagt katastrophal, aber ab dem
Zeitpunkt hat sich die Entwicklung massiv beschleunigt in Richtung open government data.
Das ist natürlich nicht alles ganz freiwillig passiert, sondern das war einfach auch Vorgabe
der EU. Da gibts die Public Sector Initiative (PSI), die Richtlinie über die Informationspflicht
der öffentlichen Behörden und Körperschaften. Das Zweite war die INSPIRE-Richtlinie. Die
hat im Prinzip den technischen Part - welche technischen Aspekte sind zu beachten beim
Aufbau einer frei zugänglicher Geodaten-Infrastruktur - und die PSI-Richtlinie im Prinzip die
Informationspflicht mit Daten für die Bürger, geregelt. Da ist in den letzten Jahren in Österreich
sehr viel passiert, in Europa extrem viel passiert. Es gibt zwei große Portale: Das eine in
Österreich ist data.gv.at, und in Europa ist es das European Data Portal, die hier Daten zur
Verfügung stellen. Man hat auch in diesem Projekt gemerkt, dass jetzt manche Daten da sind,
die wir vor 2 Jahren noch nicht hatten.
Thomas Schauppenlehner: In manchen Bereichen, oder je nach Behörde, ist es immer
noch sehr unterschiedlich organisiert. Manche veröffentlichen nur das notwendigste - zum
Beispiel Niederösterreich - also nur das, was unbedingt sein muss nach Vorgabe, und an-
dere sind sehr freizügig, wie zum Beispiel das Land Oberösterreich oder das Land Salzburg.
Wir haben hier in Österreich natürlich das Problem mit dieser föderalen Organisation, sodass
man bei länderübergreifenden Projekten in jedem Land andere Bedingungen vorfindet, andere
Datenqualitäten und Datentypen, was es schwierig macht, das zusammenzuführen. Wenn
man für Österreich einen Datensatz braucht, stellt man fest, dass man das aus 9 Bundeslän-
dern zusammenfinden muss, die einen verwenden Rasterdaten, die anderen Vektordaten, oder
beim Höhenmodell: Niederösterreich gibt 10m her, Oberösterreich 50cm. Manche stellen es
zum Download bereit, bei anderen muss man irgendein Formular ausfüllen, bei anderen re-
icht es anzurufen. Es ist also vieles gut geworden, aber ich denke, es gibt noch vieles, was
viel besser werden könnte. Es ist nach wie vor ein ziemlicher "Sauhaufen": Die Beschlagwor-
tung und Suchmaschine funktioniert weder im europäischen Datenportal noch in Österreich
64

besonders gut. Darüber habe ich vor 2 Jahren auch einen Artikel geschrieben, da geht es
hauptsächlich um Metadaten und wie man Daten findet. Es ist lustig: Obwohl ich das Gefühl
habe, ich habe einen sehr großen Überblick darüber, finde ich manche Daten noch immer eher
per Zufall. Das ist natürlich ein Problem, aber andererseits nicht grundsätzlich ein Problem der
offenen Daten sondern generell ein Problem, wenn man zunehmend komplexe und eine große
Anzahl an Daten, Datentypen, Dateninhalten hat, dass man die so aufbereitet, dass sie auch
in irgendeiner Art und Weise strukturiert browse-bar oder findbar sind.
Karl Bittner: Um kurz nochmal zur Verarbeitung dieser Daten zu kommen: Wie ist das zum
Beispiel im Visual Nature Studio, das du erwähnt hast - wie viele Personenstunden würdest
du ganz grob schätzen, braucht es von rohen Daten bis zu einer brauchbaren Visualisierung,
inklusive Vorverarbeitung und was sonst dabei nötig ist?
Thomas Schauppenlehner: Das ist insofern schwer zu sagen, weil es beim Visual Nature Stu-
dio oder auch bei allen anderen Programmen davon abhängt, welche Libraries man verwendet.
Damit meine ich zum Beispiel Darstellungen von Bäumen und Pflanzen. Das ist etwas, das
einerseits natürlich sehr regionsabhängig ist - es gibt manche Regionen, wo man ganz spez-
ifische Arten braucht, die in anderen gar nicht vorkommen, und umgekehrt - das ist natürlich
ein Stück weit Erfahrungswissen und was man sich so zusammengesammelt hat. Im Visual
Nature Studio an sich ist der Prozess so, dass man in einem GIS-Projekt alle Daten, die man
braucht, sauber aufbereitet, also auf das Gebiet zuschneidet, auf das man es braucht, dass
man alle ins gleiche Koordinatnesystem bringt, dass man die Daten entsprechend kovertiert
oder merged - je nachdem, zum Beispiel Landnutzungsdaten und Gewässerdaten, dass man
sie mit passenden Attributen versieht, und so weiter. Es ist zum Beispiel so: Bleiben wir beim
Beispiel Gewässer. Manche Gewässerdatensätze haben sehr detaillierte Unterscheidungen,
die haben Gewässerbreiten oft im Zentimeterbereich. Je weniger ich das klassifiziere oder
gruppiere, desto schwieriger ist es, nachher damit zu arbeiten. Bei der Visualisierung geht es
ja üblicherweise nicht um den einen Zentimeter, sondern: Ist das ein Bach, oder ein größerer
Fluss, oder ein riesengroßer Tieflandfluss wie die Donau. Das heißt, diese teils detailierten
Daten, wie auch immer die aufgenommen wurden, zu strukturieren und klassifizieren, sodass
sie sinnvoll mit Attributkategorien ausgestattet in die Visualisierung reinkönnen, ist der große
Arbeitsaufwand. Unsere Vegetationsdaten zum Beispiel: Die Invekos-Daten haben 220 ver-
schiedene Kulturen. Das klingt super, aber heißt auch, dass ich 220 verschiedene Vegetations-
definitionen brauche. Das ist relativ schwierig. Wenn ich aber die einzelnen Landnutzungen
anschaue für die Visualisierung: Ich erkenne auf der Visualisierung nicht, ob das Getreide
Weizen oder Roggen oder sonst etwas ist. Es gibt 10 Getreidearten, die schauen de facto
gleich aus. Natürlich erkenne ich es, wenn ich hingehe und sie mir genau anschaue, aber es
ist nicht das Ziel der Landschaftsvisualisierung, Pflanzenbestimmung zu machen, sondern die
Landschaft wahrzunehmen. Da ist natürlich sehr viel Arbeit drin zu schauen: Von den über
200 Kategorien, welche können wir zusammenfassen und welche Vegetationsrepresationen
geben wir ihnen dann? Wenn ich das hab, geht es relativ schnell: Ich hab 20 Arten und 20
Ökosysteme, dann lade ich das Höhenmodell, das Landnutzungslayer und teile über einfache
65

Attributabfragen wie im Sinne einer Datenbank Pflanzen auf Vektoren der Landnutzung zu. Das
Problem ist aber natürlich, dass es eine statische Sache ist: Wenn ich ein weiteres Projekt hab,
fang ich mehr oder weniger von vorne an. Unser Ziel bei diesem Projekt war auch, zu schauen:
Können wir eine österreichweite Basis schaffen, die man auch erweitern kann, um relativ rasch
zu sagen: Wir haben ein Projekt irgendwo im Murtal, ein anderes irgendwo in Salzburg. Wir
greifen einfach auf unsere Daten zu und haben mehr oder weniger das Grundsetup der Land-
schaft - wir haben ein Höhenmodell, wir haben eine saubere Landnutzung, eine Verteilung der
Gebäude und vielleicht der übergeordneten sichtbaren Infrastruktur wie Strommasten und Win-
dräder. Wenn man dann noch weiteres braucht, weil es das Projekt erfodert, muss man das
natürlich dazuladen. Entweder man holt es sich aus den OSM-Daten oder es sind eigene Er-
hebungen, jedes Projekt hat eigene Anforderungen, was dargestellt werden muss. Aber man
hat eine gute solide Basis.
Karl Bittner: Um auf diesen Ausblick in die Zukunft zurückzukommen: In ca. 5 Jahren, durch
weitere Entwicklungen in Open Data und VR-Technologie - was wäre für dich das, was man
hoffentlich bis dahin erreichen kann? Hast du da grobe Vorstellungen, was durch neue Daten
und hinsichtlich der Visualisierung möglich sein könnte, was heute noch nicht geht?
Thomas Schauppenlehner: Ich kann mir vorstellen, dass wir in 5-10 Jahren vor allem
auch durch die zunehmende Erhebung von Daten über Radar- und Laser-gestützte Verfahren
große Landschaftsausschnitte mit einer extrem feinen Auflösung haben, auch was Vegeta-
tionsverteilung anbelangt, und wir auch durch schnellere Maschinen in der Lage sind, Land-
schaften wirklich realitätsnahe zu visualisieren, auch in der VR-Brille. Auch dahingehend, jetzt
ist es so: Man sieht Pixel. Ich vergleiche das ein bisschen mit meinem Monitor: Ich habe einen
alten Computer, der ist 10 Jahre alt, mit dem habe ich viele Jahre gearbeitet und es war immer
super. Jetzt habe ich hier meinen Retina-Display und sehe keine Pixel mehr. Wenn ich den
alten anschmeiße, sieht man die Pixel. Es hat mich damals nie gestört, aber man sieht natür-
lich, man hat die Fortschritte der Technik einfach gesehen. Es ist jetzt bei den VR-Brillen so
ähnlich. Man spürt sie vielleicht noch zu viel, sie sind noch relativ schwer, man hat trotz der
relativ hohen Auflösung durch die knappe Nähe zum Auge sichtbare Pixel. Das ist schlichtweg
das technische Limit, mit dem man derzeit leben muss. Ich gehe aber davon aus, dass sich
hier in den nächsten Jahren viel tun wird. Es ist natürlich auch immer die Frage: Wie schnell
rechnen die Prozessoren? Eine Verfeinerung von etwas bedeutet natürlich auch eine größere
Datenmenge, die zu transportieren, darstellen und berechnen ist. Trotzdem wird man damit
hoffentlich visuell sehr realistisch darstellen können.
Thomas Schauppenlehner: Bei allem weiteren bin ich ein bisschen skeptisch. Was auch
geht, sind akustische Modelle, da gibt es auch Forschung dazu. Alles weitere - wie die Land-
schaft riecht, wie man Wind spürt, da bin ich ein bisschen skeptisch, dass das in der Zeit geht,
beziehungsweise ist auch die Frage, ob das notwendig ist. Man muss immer überlegen, wo hat
man technische Limits und wo sind Limits sinnvoll, weil es sonst zu aufwendig ist und keinen
Benefit bringt. Wobei, wie gesagt: Realitätsnah zu visualisieren ist eine bestimmte Kür, die
man beherrschen sollte, aber nicht immer ist es sinnvoll, wirklich realitätsnah zu visualisieren.
66

Simulationen sind einfach unscharf, und weil man natürlich mit jeder Darstellung der Realität
auch suggeriert, dass es tatsächlich so ist, ist das ein Stück weit auch eine Täuschung des
Betrachters, die sich vielleicht hintergangen fühlen. Es ist also teilweise auch ein bewusster
Schritt, das nicht realitätsnah zu machen.
Karl Bittner: Gut, das war es von meiner Seite - möchtest du noch etwas anmerken, oder
passt es auch von dir aus?
Thomas Schauppenlehner: Nein, ich glaube, wenn du sonst keine Fragen hast, nein.
Karl Bittner: Dann vielen Dank!
Thomas Schauppenlehner: Gerne!
67