Department of Science and Technology Institutionen för teknik och naturvetenskap
Linköping University Linköpings universitet
g n i p ö k r r o N 4 7 1 0 6 n e d e w S , g n i p ö k r r o N 4 7 1 0 6 -E S
LiU-ITN-TEK-A--18/033--SE
Automatic Clustering of 3D
Objects for Hierarchical
Level-of-Detail
Benjamin Wiberg
2018-06-14
LiU-ITN-TEK-A--18/033--SE
Automatic Clustering of 3D
Objects for Hierarchical
Level-of-Detail
Examensarbete utfört i Medieteknik
vid Tekniska högskolan vid
Linköpings universitet
Benjamin Wiberg
Handledare Patric Ljung
Examinator Jonas Unger
Norrköping 2018-06-14
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –
under en längre tid från publiceringsdatum under förutsättning att inga
extra-ordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida
http://www.ep.liu.se/Copyright
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page:
http://www.ep.liu.se/Linköping University | Department of Science and Technology Master Thesis | Media Technology and Engineering Spring 2018 | LiU-ITN-TEK-A--00/000--SE
Automatic Clustering of 3D Objects
for Hierarchical Level-of-Detail
Benjamin Wiberg
Supervisor: Patric Ljung
Examiner: Jonas Unger
Linköping University SE-581 83 Linköping 013–28 10 00, www.liu.se
Abstract
This report describes an algorithm for computing 3D object hierarchies fit for Hierarchical Level-of-Detail (HLOD) optimization. The algorithm is used as a pre-processing stage in an HLOD pipeline that automatically optimizes 3D models containing multiple meshes.
The algorithm for generating hierarchies groups together meshes in a hierarchical tree using opera-tions on bounding spheres of the meshes. The algorithm prioritizes grouping close objects together in the early stages, and relaxes its constraints toward the end, resulting in a tree structure with a sin-gle root node. The hierarchical tree is then used by computing proxy meshes, i.e. simplified stand-in meshes, for the inner nodes of the hierarchy. Finally, the resulting proxy meshes, together with the generated hierarchy and the original meshes, are used to render the model using a tree-traversing HLOD switching algorithm that renders deeper parts of the tree containing more detailed meshes when more detail is needed.
In addition, a minor change to the clustering algorithm is proposed. By swapping the bounding spheres to AABBs (Axis-Aligned Bounding Boxes) in the clustering stage, hierarchies with different proper-ties are generated. This change is shown to generate hierarchies with similar rendering performance as the hierarchies made with bounding spheres, while at the same time resulting in lower space re-quirements for all proxy meshes.
Overall, the proposed automatic HLOD pipeline is shown to increase rendering performance for all evaluated scenes in most frames, while never yielding noticeably worse performance than the original model as well.
Keywords: hierarchical level-of-detail, mesh simplification, hierarchical clustering, 3D optimization
Acknowledgements
First off, I would like to thank everyone at Microsoft, Simplygon Studios in Linköping, where the majority of the work was carried out. My supervisor at the office, Sebastian Wiberg, who has guided me through our many technical discussions, thank you for giving me valuable advice! Anders Östlund for giving me permission to do the thesis at Microsoft. Samuel Ranta-Eskola for helping me refine the extent of the work, keeping a narrow but sharp focus to the thesis. Jukka Tahtinen for helping my find 3D models to use in my work. And to everyone at the office, thanks for the thoughtful discussions, your curiosity toward my work, and the endless joy of pingpong during coffee breaks. It has been a pleasure!
Furthermore, I want to thank my advisor at Linköping University, Patric Ljung, for offering key advice on the report and supporting me from the beginning. I also want to thank my examiner Jonas Unger at Linköping University.
Finally, I want to thank my wonderful partner Linda who has supported me through the entire work in all ways imaginable, as well as my caring friends and family, some who even read the report and gave critical feedback.
June 19th, Linköping Benjamin Wiberg
Contents
Abbreviations v
Nomenclature v
List of Figures vi
List of Tables viii
1 Introduction 1 1.1 Purpose . . . 1 1.2 Problem formulation . . . 2 1.3 Delimitations . . . 2 2 Background 3 2.1 Mesh Simplification . . . 3 2.1.1 Reduction . . . 3 2.1.2 Remeshing . . . 4 2.2 Level-of-Detail . . . 6 2.2.1 Discrete Level-of-Detail . . . 6 2.2.2 Continuous Level-of-Detail . . . 6 2.2.3 Hierarchical Level-of-Detail . . . 7 2.2.4 Simplygon . . . 8
3 The Importance of Hierarchies for Hierarchical Level-of-Detail 9 3.1 Effective Object Hierarchies for Hierarchical Level-of-Detail . . . 9
3.2 Generating Hierarchies Fit for Hierarchical Level-of-Detail . . . 9
3.2.1 Uniform Grid . . . 10
3.2.2 Octree . . . 10
3.2.3 Bottom-up Hierarchical Clustering of 3D Objects . . . 11
4 Improved Hierarchical Clustering for Hierarchical Level-of-Detail 14 4.1 Bounding Boxes . . . 14
CONTENTS iv
4.2 Bounding Box Proportion Constraint . . . 15
5 System Overview 17 5.1 Hierarchical Clusterer . . . 17
5.2 Hierarchy Exporter . . . 18
5.3 Hierarchical Proxy Mesh Processor . . . 18
5.4 Hierarchy Importer . . . 19
5.5 Runtime HLOD Viewer . . . 19
6 Results 21 6.1 Geometric Complexity and Space Requirements . . . 22
6.2 Performance Comparisons . . . 24
6.3 Visual Comparisons . . . 27
7 Analysis and Discussion 30 7.1 Method . . . 30
7.2 Results . . . 30
7.2.1 Performance Comparisons . . . 30
7.2.2 Visual Comparisons . . . 30
7.2.3 Comparing Clustering with Bounding Sphere and AABB . . . 31
7.3 Source criticism . . . 31
7.4 The work in a wider context . . . 31
8 Conclusion 32 8.1 Future Work . . . 32
Abbreviations
AABB Axis-Aligned Bounding Box. 2, 13–16, 21, 26–28, 30, 31 AR Augmented Reality. i
CAD Computer-aided Design. 3, 8 CLOD Continuous Level-of-Detail. 6 CPU Central Processing Unit. 17
DLOD Discrete Level-of-Detail. 5, 6, 14, 18, 21 GPU Graphics Processing Unit. 3
HLOD Hierarchical Level-of-Detail. i, 1, 2, 6–10, 13, 14, 16, 18, 20, 21, 29–32 LOD Level-of-Detail. 1, 5–7
MR Mixed Reality. i
MST Minimum Spanning Tree. 12 SPL Simplygon Processing Language. 18 SSF Simplygon Scene Format. 17, 18 UE4 Unreal Engine 4. 1, 10, 30 VR Virtual Reality. i
List of Figures
2.1 A triangle mesh (left) is simplified using a reduction process, resulting in a new mesh with fewer triangles (right). . . 4 2.2 A mesh with a wide distribution of surface areas per triangle (left) is turned into a
mesh with uniform triangle area and a consistent edge count for each vertex (right) using a uniform remeshing algorithm. Image taken from [2]. . . 5 2.3 Three versions of the same mesh. Left: the original mesh, center) remeshed using a
uniform density function, right) remeshed using a curvature-based density function. Notice that the rightmost mesh uses a few large triangles to represent the any flat surfaces in the model. Image taken from [1]. . . 5 2.4 An example Discrete Level-of-Detail (DLOD) chain. From left to right: 1) 92 832
triangles, 2) 9 283 triangles, 3) 928 triangles, 4) 232 triangles. . . 6 2.5 A HLOD. Level 0 is a single mesh representing the entire model. Lower levels contain
consecutively smaller parts of the model with progressively higher triangle counts. The lower levels of the hierarchy are rendered when viewed from a close distance. . . 7 3.1 Example of a hierarchy that does not work well for Hierarchical Level-of-Detail
(HLOD). The subtrees containing the break discs and the tires are both terrible, since they are very spread out. When viewing either of the wheels from a close distance, the algorithm will switch all four wheels to the more detailed version, wasting detail for the other three wheels we don’t see close. . . 10 3.2 Example of a better hierarchy for HLOD. The break discs and wheels have been
grouped together based on position instead of part type. When viewing a particular wheel from a close distance only that wheel will be switched out for its more detailed tire mesh and brake disc, while the other three wheels can still render their aggregated version from level 1. . . 11 3.3 An example hierarchy generated by the bounding sphere clustering algorithm. The left figure
shows a geometric representation of the hierarchy, while the right figure shows the underlying tree data structure that encodes the hierarchy. . . 12 4.1 Comparison of bounding box clustering and Axis-Aligned Bounding Box (AABB)
clustering for two similar scenarios. In the first scenario (1 and 2 from the left) the two objects A and B have the same size and are laid out along x-axis. This results in a big bounding sphere but a smaller AABB (albeit longer in that dimension). In the second scenario (3 and 4 from the left) A and B are separated in both x and y. The bounding sphere cluster is similar in shape as the first scenario, while the AABB cluster is larger in y than the first scenario but same in x. . . 14
LIST OF FIGURES vii
4.2 A hierarchy generated by AABB clustering. The camera, illustrated by the frustum on the left, is too close to ABCD, so it must instead render its more detailed children A, B, C and D separately, even though C and D in particular are quite far away from the camera. This results in four draw calls, where C and D are needlessly complex
for this viewing point. . . 15
4.3 A hierarchy generated by AABB clustering using a box proportions constraint. The camera, illustrated by the frustum on the left, is too close to AB, so it must instead render its more detailed children A B separately. However, the camera is sufficiently far away from CD, so it can render the less detailed proxy mesh instead of the children C and D. This results in three draw calls, i.e. one less than in 4.2, and potentially a lot less triangles by rendering CD instead of C and D. . . 15
5.1 Overview of the HLOD pipeline. . . 17
5.2 Hierarchical scene graph with meshes attached to all nodes (a) is converted to only having meshes at leaf nodes (b). . . 18
6.1 The five models used in the tests. . . 22
6.2 Performance of the Powerplant scene for the six configurations. . . 24
6.3 Performance of the Powerplant scene for the six configurations. The graph has been scaled vertically to show the entire range of the data. . . 24
6.4 Performance of the Car scene for the six configurations. . . 25
6.5 Performance of the Diesel Engine scene for the six configurations. . . 25
6.6 Performance of the Kitchen scene for the six configurations. . . 26
6.7 Performance of the Locomotive scene for the six configurations. . . 26
6.8 Comparison of the Power Plant model, rendered at t = 3s in the animation, using six different methods. The images have been magnified with a factor of 2 to better show the details. . . . 27
6.9 Comparison of the Power Plant model, rendered at t = 30s in the animation, using six differ-ent methods. . . 28
6.10 Comparison of the Power Plant model, rendered at t = 6.1s in the animation, using six different methods.. . . 28
6.11 Comparison of the Car model, rendered at t = 0s in the animation, using six different meth-ods. The images have been magnified with a factor of 3 to better show the details. . . 29
6.12 Comparison of the Car model, rendered at t = 22.7s in the animation, using six different methods. . . 29
A.1 A custom UI developed to cluster GameObject hierarchies within Unity. . . 36
A.2 A custom UI developed to cluster GameObject hierarchies within Unity. . . 37
A.3 A custom UI window giving easy access to helper functions and statistics of selected GameObjects. . . 38
List of Tables
6.1 Statistics for 3D models used in measurements . . . 21
6.2 Statistics for the Power Plant scene. . . 22
6.3 Statistics for the Car scene. . . 22
6.4 Statistics for the Diesel Engine scene. . . 23
6.5 Statistics for the Kitchen scene. . . 23
6.6 Statistics for the Locomotive scene. . . 23
Chapter 1
Introduction
Interactive computer graphics is becoming common in many industries. The spectrum of available 3D data is very wide, ranging from hand-crafted simple meshes for mobile games to massively detailed environments created from scans of the real world. A big challenge is bringing a 3D experience to a wide array of devices while preserving the perceived visual quality. A tool to solve these problems is Level-of-Detail (LOD), a class of algorithms aimed at achieving great performance and decent visual complexity by reducing the rendering complexity where the impact is the least noticeable.
The archetypical LOD technique, explained in greater detail in section 2.2.1, involves precomputing a chain of proxy meshes with progressively lower detail from a source mesh, and intelligently deciding which version of the mesh to render at any given time. This type of technique has been used in the games industry for many years. While this technique is great for increasing performance, 3D worlds that have thousands of individual objects might still be out of reach for realtime rendering. Hierar-chical Level-of-Detail (HLOD) techniques solve the problem of having many objects by aggregating suitable objects together recursively, allowing for not just single-object LOD but scene-wide LOD. While HLOD has been an active area of research since the early 2000’s, it is only recently that the technique has started being used in the gaming industry. A prominent example of HLOD can be seen in Grand Theft Auto 5 [3], released in 2013. Additionally, the popular game engine Unreal Engine 4 (UE4) added support for HLOD in its 4.11 update, enabling HLOD techniques to be used by any UE4 games developer [4].
1.1
Purpose
The purpose of this master’s thesis report is to evaluate existing algorithms for automatic HLOD generation. The current implementation in Unreal Engine 4 is targeted towards-, and has mainly been used for, environment-like scenes that are relatively flat. In such scenes, objects are generally evenly spread out on an approximate plane, e.g. houses and objects on the street in a city exterior level. On the other hand, Non-environment scenes are essentially all scenes and models that don’t represent such environments, e.g. a complex engine model with many intersecting models located close to one another but spread out in all three dimensions. Therefore the main purpose of this thesis is to evaluate HLOD methods for environment scenes as well as for non-environment models. In addition, this report will evaluate the performance benefits of HLOD and if it is worth the extra overhead to use HLOD in a given situation.
CHAPTER 1. INTRODUCTION 2
1.2
Problem formulation
• How can the generation of HLOD be automated by applying algorithms for automatic hierarchy generation?
• Can hierarchical clustering be applied to complex 3D scenes that describe non-environments, for usage in a HLOD rendering pipeline?
• Can bounding spheres be substituted for Axis-Aligned Bounding Box (AABB)s in a hierar-chical clustering algorithm to improve the performance of the clustering algorithm and/or the rendering of the produced data?
1.3
Delimitations
The implementation of the algorithms described in the report uses the Simplygon software for creating simplified proxy meshes. Simplygon is a software for automatic optimization of 3D content1.While
Simplygon has many important parameters to tune, its configuration has been kept relatively default, given the limited time available for the project2. Also, while Simplygon supports high-quality material
baking, the decision was made to disable material baking and only process the geometry.
1Simplygon is covered in greater detail in 2.2.4.
Chapter 2
Background
This chapter will describe the concept of mesh simplification and a few different techniques that are classified as such. Traditional LOD techniques are also described briefly, to give a solid foundation for the HLOD techniques covered in this report.
2.1
Mesh Simplification
Mesh simplification has been an active area of research since the early days of 3D computer graphics. Motivated by weak rendering performance, methods of simplifying polygon meshes while retaining as much detail as possible were necessary to allow for fast, interactive rendering. Nowadays, even with modern Graphics Processing Unit (GPU)s having great performance, mesh simplification still has its uses. Many ways of authoring 3D meshes can result in a lot more polygons than what is necessary, e.g. when reconstructing geometry from images or 3D point clouds. Such reconstruction methods often output very dense meshes with large triangle counts, even in areas where fewer triangles would be needed to describe the geometry. In addition, 3D models exported from Computer-aided Design (CAD) software are in general very detailed and often require some kind of simplification before they can be used in realtime rendering applications.
There are, broadly speaking, two major classes of mesh simplification techniques. They are called reduction1and remeshing.
2.1.1
Reduction
Mesh reduction algorithms operate directly on the source mesh, creating simplified versions of it by iteratively removing redundant vertices and triangles with the least influence on the shape of the mesh. An example reduction is shown in figure 2.1.
1Also known as decimation
CHAPTER 2. BACKGROUND 4
Figure 2.1: A triangle mesh (left) is simplified using a reduction process, resulting in a new mesh with fewer triangles (right).
Quadric Simplification
Surface Simplification Using Quadric Error Metrics is one of the most common mesh reduction algorithms, introduced by Garland et al. [5] in 1997. The algorithm simplifies a triangle mesh by collapsing pairs of vertices into a single vertex and updating the surrounding faces accordingly. The order of collapses is determined by computing a quadric-error metric that is low for vertices with flat surroundings and grows as the local curvature around the vertex grows. The error metric will not be described in detail here, but the result of using the metric is that the algorithm keeps vertices and triangles with high-frequency variations and discards those that are in more planar areas.
2.1.2
Remeshing
Remeshing algorithms differ from reduction algorithms in that they use the original mesh as a guide to generating an entirely new mesh. By making the assumption that the original mesh accurately describes the details of the underlying geometric surface, remeshing algorithms generate entirely new meshes that describe the same surface but with different properties of the mesh itself. As such, remeshing algorithms can not only be used for mesh simplification but have many other applications as well. A common usage is to resample a triangle mesh with many redundant vertices and varying triangle areas to a uniform mesh where the triangles are equally sized and laid out in more structured patterns, an example is shown in figure 2.2.
CHAPTER 2. BACKGROUND 5
Figure 2.2: A mesh with a wide distribution of surface areas per triangle (left) is turned into a mesh with uniform triangle area and a consistent edge count for each vertex (right) using a uniform remeshing algorithm. Image taken from [2].
Voronoi Remeshing
Alliez et al. [1] proposed Centroidal Voronoi diagrams for isotropic surface remeshing in 2005. The algorithm allows the remeshing process to be controlled precisely by specifying a surface density function that controls the triangle and vertex density of the output mesh. A common density function is to use the curvature of the original mesh, yielding a mesh with few large triangles for flat parts of the surface and many small triangles for fast varying parts of the surface. A comparison of different density functions applied to the same model is shown in figure 2.3.
Figure 2.3: Three versions of the same mesh. Left: the original mesh, center) remeshed using a uniform density function, right) remeshed using a curvature-based density function. Notice that the rightmost mesh uses a few large triangles to represent the any flat surfaces in the model. Image taken from [1].
CHAPTER 2. BACKGROUND 6
2.2
Level-of-Detail
LOD is a class of algorithms that adjust the rendering complexity of 3D data based on some run-time condition. The primary purpose of using LOD methods is to improve performance by reducing rendering complexity where the perceived visual difference is minimal. The need for LOD is highly dependent on the 3D data and the properties of the rendering platform - if the rendering environment can render the original data with a decent framerate, the usage of LOD algorithms will only serve to introduce unneccesary overhead. However, if the 3D dataset to be rendered is complex enough it might be impossible to render it fast enough to fulfill the requirements, in which case LOD is a tool that can improve performance.
2.2.1
Discrete Level-of-Detail
Discrete Level-of-Detail (DLOD) is considered to be the archetypical LOD method. In a pre-processing step, the polygon mesh is simplified recursively, yielding a chain of progressively simpler meshes as seen in figure 2.4. During rendering, one of the meshes is chosen to be rendered for a given frame, depending on how detailed the mesh needs to be for that frame. It is common to have a switching dis-tanceor, equivalently, a maximum screen size (in pixels) associated with each of the proxy meshes. This number represent at what distance, or at what occupied screen size, the mesh starts to diverge from the original mesh in its rendered appearance.
By always making sure to obey this distance metric, one can, in theory, make sure that the appearance of the mesh is as if it was the original mesh that was rendered. If a mesh is rendered closer than its specified render distance, the loss in quality will be apparent. When the switch to a more detailed version happens a so called popping effect might occur, where details of the mesh suddenly appear. Applying a transition duration where both meshes are rendered and faded in some way can mitigate the unwanted popping effect to a degree.
Figure 2.4: An example DLOD chain. From left to right: 1) 92 832 triangles, 2) 9 283 triangles, 3) 928 triangles, 4) 232 triangles.
2.2.2
Continuous Level-of-Detail
Continuous Level-of-Detail (CLOD) is, as the name implies, a class of methods where the geometry of an object can be evaluated for any given viewpoint position. It is continuous since the level-of-detail evaluation happens continuously and, usually, on a polygon-basis, as opposed to discrete methods described in section 2.2.1.
Hoppe [6] introduced the Progressive Meshes method that uses progressive refinement and simpli-fication of an original mesh through local operations. Lindstrom et al. [8] proposed a similar tech-nique for the specific purpose of rendering height field geometry with the main contribution being per-polygon level-of-detail evaluations. Other notable examples of CLOD are raymarching of signed distance fields (thoroughly explained in [7]) or mesh generation from scalar fields using the marching cubes algorithm [9].
CHAPTER 2. BACKGROUND 7
2.2.3
Hierarchical Level-of-Detail
HLOD reduces the number of draw calls for a dataset by grouping objects together and replacing them with a single, aggregated proxy object. This can yield massive performance benefits, especially for large models and environments, since the object count is generally large and regular single-object LOD methods result in too many draw calls to be performant. An example HLOD version of a 3D model is shown in figure 2.5.
Figure 2.5: A HLOD. Level 0 is a single mesh representing the entire model. Lower levels contain consecutively smaller parts of the model with progressively higher tri-angle counts. The lower levels of the hierarchy are rendered when viewed from a close distance.
Given a hierarchy represented by a tree structure, the algorithm to render the hierarchy is shown in algorithm 1.
Algorithm 1Rendering of a HLOD hierarchy 1: procedureRENDERNODE(Node, Camera)
2: ifDistance(Node, Camera)<=MaximumRenderDistance(Node) then 3: Render(Node)
4: else
5: for all Childin Node do
6: RENDERNODE(Child, Camera) 7: end for
8: end if 9: end procedure
CHAPTER 2. BACKGROUND 8
2.2.4
Simplygon
Simplygon is a commercial software for automatic optimization of 3D content, developed by Simply-gon Studios which is a part of Microsoft. Its primary feature is creating discrete LOD chains for 3D meshes, using a wide array of different methods. Simplygon provides, among other things, a high-quality reduction processor, an aggregation processor that combines multiple meshes into a single one, and a very high-quality remeshing processor. The remeshing processor generates high-quality meshes from one or more input meshes, and also discards geometry hidden inside of other geometry, essentially creating a "plastic wrapped" version of the original geometry. In addition, Simplygon can also create a new material for any output mesh by taking the materials of the input meshes and fitting them together into a new single texture. This approach of combining multiple textures into a single texture is known as baking.
Chapter 3
The Importance of Hierarchies for
Hierarchical Level-of-Detail
Section 2.2.3 introduced the basic idea of HLOD. This chapter will discuss the importance of the hierarchy of the scene when generating proxy meshes for the HLOD.
3.1
Effective Object Hierarchies for Hierarchical Level-of-Detail
Since HLOD algorithms use the object hierarchy to generate aggregated proxy geometry, the hierar-chy of the input scene has a massive impact on the outcome. Ideally, the subtrees of any node would be evenly distributed in the scene. However, many 3D models are created with other purposes than realtime rendering in mind, and the hierarchy of the model can be a terrible fit for direct usage in a HLOD pipeline.
An example of a 3D model hierarchy unfit for HLOD would be a car model, where the hierarchy in many cases encodes semantic information. A common practice with car models made in CAD programs is to group meshes together in subtrees based on their material, e.g. all four rubber tire mesh parts might belong to the same subtree, while the four metallic brake discs belong to another subtree. Such a hierarchy is shown in figure 3.1. This causes the hierarchy to be fragmented spatially, and one can see that it is particularly unfit for HLOD.
A better hierarchy would, in the case with the car model, be a hierarchy where each entire wheel is a subtree in the hierarchy, where each subtree contains the inner metallic rim mesh and rubber tire rim as direct children. This is shown in figure 3.2. Arranging the model hierarchy in this manner ensures spatial locality.
Another common hierarchy for 3D scenes is that all of the scenes meshes are direct descendants of the root node, effectively making the hierarchy an unordered list of meshes and their world transfor-mations.
3.2
Generating Hierarchies Fit for Hierarchical Level-of-Detail
As explained previously, using the original hierarchy of a 3D model or scene for HLOD optimizations can not be guaranteed to produce high-quality results. Therefore, an algorithm that generates a 3D object hierarchy that suits HLOD as much as possible is required.
Using HLOD for height field rendering is a great fit, since the source data is available in structured 2D 9
CHAPTER 3. THE IMPORTANCE OF HIERARCHIES FOR HIERARCHICAL LEVEL-OF-DETAIL10
Level 0
Level 1
Level 2
Figure 3.1: Example of a hierarchy that does not work well for HLOD. The subtrees containing the break discs and the tires are both terrible, since they are very spread out. When viewing either of the wheels from a close distance, the algorithm will switch all fourwheels to the more detailed version, wasting detail for the other three wheels we don’t see close.
arrays meaning that one can create perfectly square subdivisions, optimal for performance and detail. On the other hand, applying HLOD to generic 3D models composed of a large number of different sized meshes means that such structured subdivisions cannot be easily made. To achieve this, one would have to merge all meshes into one huge mesh and then slice it up into evenly sized chunks. This approach is very unpractical for various reasons, so an algorithm that operates on the original meshes is required.
There are two fundamental groups of methods for generating hierarchies of 3D objects. Top-down approaches break down the entire problem into subsequently smaller parts, until some partitioning criteria has been met. Bottom-up approaches start by considering the individual parts of the whole and piecing them together until all parts are grouped together. Some of the most well-known algorithms of both kinds are described briefly below.
3.2.1
Uniform Grid
A simple top-down approach to spatial partitioning is to divide the domain into a uniform grid where each cell has the same sidelengths. This technique is great for some application such as point-cloud partitioning for fast nearest-neighbour queries. However, the technique is unfit for producing 3D ob-ject hierarchies since the resulting tree structure has a fixed depth of two. In addition, since the dimen-sions of each cell are fixed there is a large chance that any given mesh either is too large to fit inside a single cell or lies on the boundary of two or more cells. This problem can’t be fixed by increasing the size of the cells either, since the relative size of meshes can be huge, so the cell size can’t possibly be large enough to fit all meshes while at the same time be fine-grained enough to partition small meshes in different cells. Furthermore, while the problem can be solved by splitting the mesh perfectly along the boundary, mesh splitting can cause many problems, particularly that it can introduces many new triangles and vertices in the process.
3.2.2
Octree
Octrees are an improvement over uniform grids that introduces a kind of dynamic cell sizes. The algorithm starts by constructing a single cell with equal sidelengths that encapsulates all objects. The
CHAPTER 3. THE IMPORTANCE OF HIERARCHIES FOR HIERARCHICAL LEVEL-OF-DETAIL11
Level 0
Level 1
Level 2
Figure 3.2: Example of a better hierarchy for HLOD. The break discs and wheels have been grouped together based on position instead of part type. When viewing a particular wheel from a close distance only that wheel will be switched out for its more detailed tire mesh and brake disc, while the other three wheels can still render their aggregated version from level 1.
next step is to subdivide any cell that contains more than a specified number of objects. The cell is subdivided into eight cells of equal size, and all object of the original cell that fit into any of the child cells are moved into that cell. The subdivision step is then performed recursively for all the new cells, and this continues until either all cells contain fewer children than the threshold, or no objects fit into any of the newly created subcells.
Octrees are, like uniform grids, well suited for partitioning point clouds. In fact, they are even better for this purpose than uniform grids since the octree allows for finer detail in the data structure where there is a lot of point cloud data. In addition, since points in a point cloud dataset are volume-less, the octree can theoretically be subdivided forever until a desired condition is met.
However, using octrees for polygon meshes has the same drawback as uniform grids in that if a mesh lies on the boundary of two or more cells, it is impossible to move it down to a subcell. Therefore the quality of the octree algorithm is highly dependent on the size of the meshes as well as their positions in the scene. A partial solution to fix the boundary problem is to allow cells to grow a little to encapsulate a mesh, but this does not solve the problem fully either.
3.2.3
Bottom-up Hierarchical Clustering of 3D Objects
The hierarchical clustering algorithm introduced by Sappa et al. [10] in 2004 is a bottom-up ap-proach. The algorithm was designed for efficient computation of minimum distance queries, but is also proven to work great for HLOD applications. UE4 introduced an automatic HLOD feature in its 4.11 update [4], where this hierarchical clustering algorithm is used to generate the hierarchy. The general idea of the algorithm is to represent all meshes by their bounding spheres and hierarchically group them together based on an effective cost function. An example hierarchy is shown in figure 3.3. The first step of the algorithm is to compute the minimum bounding spheres for all meshes in the scene. By considering the bounding sphere associated with a mesh, instead of the mesh geometry itself, any geometric operations during the execution of the algorithm are greatly simplified.
CHAPTER 3. THE IMPORTANCE OF HIERARCHIES FOR HIERARCHICAL LEVEL-OF-DETAIL12 A C G D E B B {AC}, {GDE}, B, F, H F F H AC GDE H
Figure 3.3:An example hierarchy generated by the bounding sphere clustering algorithm. The left figure shows a geometric representation of the hierarchy, while the right figure shows the underlying tree data structure that encodes the hierarchy.
The Clustering Operation
The fundamental operation performed in the algorithm is to cluster two bounding spheres together, i.e. grouping two bounding spheres together. The viability of a clustering operation is determined by its clustering cost, computed as in algorithm 2, line 3, where A and B are bounding spheres, r is the radius and F is the fill factor of the new bounding sphere.
Algorithm 2Pseudo-code for computing the clustering cost of two bounding spheres. 1: procedureCOMPUTECLUSTERCOST(A, B)
2: AB ←EncapsulateSpheres(A, B) 3: CAB ← rAB3 FAB 4: return CAB 5: end procedure
The above mentioned fill factor represents what fraction of a bounding sphere’s volume is occupied by geometry. When computing the initial bounding spheres for every mesh, the fill factor is set to 1. Any new bounding spheres created by a clustering operation are assigned a fill factor computed as in equation 3.1, where V is the volume of a bounding sphere and F is the fill factor of a bounding sphere.
FAB = FAVA+ FBVB−Voverlap
VAB (3.1)
Iterative Clustering
After the initial bounding spheres have been computed, the iterative clustering part of the algorithm starts. It is broken up into three discrete steps that are performed repeatedly until the end condition has been met. The end condition is to have a single bounding sphere left.
CHAPTER 3. THE IMPORTANCE OF HIERARCHIES FOR HIERARCHICAL LEVEL-OF-DETAIL13
The first step in the iterative part is to consider all possible pairs of bounding spheres. The clustering cost for every pair is computed and stored in an adjacency graph as shown in algorithm 3.
Algorithm 3Pseudo-code for building the adjacency graph of clustering costs. 1: procedureBUILDADJACENCYGRAPH(S)
2: N ← Count(S)
3: for i← 0, i < N, i ← i + 1 do 4: for j ← 0, j < i, j ← j + 1 do
5: Ci,j ← COMPUTECLUSTERCOST(Si, Sj)
6: end for 7: end for 8: return C 9: end procedure
Next, we want to perform a series of clustering operations, starting with the pairs with the lowest clustering cost. To find the cluster pair to start with, the Minimum Spanning Tree (MST) of the adjacency graph is computed. The edge with the lowest associated cost in the MST is selected and a clustering operation is performed, yielding a new bounding sphere that contains the previous two bounding spheres as direct children. The new bounding sphere is assigned a new fill factor, computed as in equation 3.1. The new bounding sphere is added to the MST, and any potential clusters in theMST that overlap1are updated with new cluster costs, according to algorithm 2.
Algorithm 4 Pseudo-code for the hierarchical clustering using bounding spheres al-gorithm.
1: procedureCLUSTER(Meshes)
2: Spheres← ComputeBoundingSpheres(M eshes) 3: Hierarchy ← empty list
4: while Count(Spheres) > 1 do
5: Costs← BUILDADJACENCYGRAPH(S) 6: M ST ← BUILDMST(Costs)
7: Spheres← MERGESPHERES(MST ) 8: ADDLEVEL(Hierarchy, Spheres) 9: end whilereturn Hierarchy
10: end procedure
Chapter 4
Improved Hierarchical Clustering for
Hierarchical Level-of-Detail
The iterative algorithm proposed by [10] and summarized in section 3.2.3 is a great starting point for designing an algorithm for HLOD applications.
4.1
Bounding Boxes
While the original algorithm proposes the use bounding spheres for all of its clustering calculations, the original authors acknowledged that further work would be needed in evaluating possible other bounding volumes used in the algorithm. They listed ellipsoids as a candidate, but I will argue that AABBs might be a good choice. While bounding spheres have the inherent quality that their shape is perceived in the same way from the same viewpoint no matter what orientation the bounding sphere has, they are also limited by only being allowed to grow in all three dimensions simultaneously. In contrast, AABBs can grow in any dimension without also growing in the other two dimensions. This property allows encapsulation of additional objects while keeping the volume of the AABB small. This is demonstrated in figure 4.1.
A AB B A AB B A B AB A B AB
Figure 4.1: Comparison of bounding box clustering and AABB clustering for two similar scenarios. In the first scenario (1 and 2 from the left) the two objects A and B have the same size and are laid out along x-axis. This results in a big bounding sphere but a smaller AABB (albeit longer in that dimension). In the second scenario (3 and 4 from the left) A and B are separated in both x and y. The bounding sphere cluster is similar in shape as the first scenario, while the AABB cluster is larger in y than the first scenario but same in x.
CHAPTER 4. IMPROVED HIERARCHICAL CLUSTERING FOR HIERARCHICAL LEVEL-OF-DETAIL15
4.2
Bounding Box Proportion Constraint
While AABBs in most cases will generate a tighter fit when considering the merge of two clusters in terms of the occupied volume, the proportions of the resulting boxes might be very stretched. This type of cluster is very undesirable since proxy mesh generated for the cluster will be large in one dimension and thin in the others. When viewed from one of the ends of the proxy, the switching to the deeper, more detailed original meshes will lead to high resolution being wasted for the meshes located on the other end of the proxy. An example of this can be seen in figure 4.2.
A
B
C
D
ABCD
Figure 4.2: A hierarchy generated by AABB clustering. The camera, illustrated by the frustum on the left, is too close to ABCD, so it must instead render its more detailed children A, B, C and D separately, even though C and D in particular are quite far away from the camera. This results in four draw calls, where C and D are needlessly complex for this viewing point.
A solution to this problem is to modify the cost function when determining which clusters to merge first. The proposed modification is to multiply the original cost with the ratio between the AABBs largest dimension and its smallest. This will cause the clustering step to prefer clusters whose AABB is shaped more as a cube over disproportionate ones. This can be seen in figure 4.3.
A
B
C
D
AB
CD
Figure 4.3: A hierarchy generated by AABB clustering using a box proportions con-straint. The camera, illustrated by the frustum on the left, is too close to AB, so it must instead render its more detailed children A B separately. However, the camera is sufficiently far away from CD, so it can render the less detailed proxy mesh instead of the children C and D. This results in three draw calls, i.e. one less than in 4.2, and potentially a lot less triangles by rendering CD instead of C and D.
CHAPTER 4. IMPROVED HIERARCHICAL CLUSTERING FOR HIERARCHICAL LEVEL-OF-DETAIL16
to the parameter. This will scale the influence of the proportions constraint in such a way that a value of zero will remove the constraint entirely, while larger values will drive the algorithm even stronger towards cube-like clusters. Putting all of this together leads to the cluster cost being computed as in equation 4.1, where k is the previously mentioned exponent. Furthermore, the original cluster cost, in algorithm 2, line 3, has r3
in the denominator, i.e. a value linearly proportional to the volume of the bounding sphere. Therefore, the r3
factor has been substituted for the exact volume of the AABB in equation 4.1.
C ← VAABB FAABB
max(AABBx, AABBy, AABBz)
min(AABBx, AABBy, AABBz) k
Chapter 5
System Overview
The implemented HLOD pipeline is divided into steps, shown in the systems overview in figure 5.1. The Unity game engine1 has been used as a base for the implementation, since it is easy to develop
for and supports almost all asset formats that exist. The following sections describe the steps of the pipeline in greater detail.
Hierarchical Clusterer Hierarchy Exporter Hierarchical Proxy Mesh Processor Hierarchy Importer Runtime HLOD Viewer GameObject Hierarchy GameObject Hierarchy
Unity
GameObject Hierarchy Folder Hierarchy w/ Meshes in Leaf Folders Folder Hierarchy w/ Meshes in All Folders2+ Meshes 1 Proxy Mesh
SIMPLYGON
Figure 5.1: Overview of the HLOD pipeline.
5.1
Hierarchical Clusterer
The hierarchical clustering algorithms, using both bounding spheres and AABBs, have been imple-mented in Unity. In addition, an Original Hierarchy Clusterer and an Octree Clusterer have been implemented, mainly for debugging purposes. The different implementations share a common ab-stract base class so they expose a common public API for clustering a scene in Unity. Each clusterer takes a GameObject2 hierarchy where any of the internal nodes have MeshRenderer and MeshFilter
1https://unity3d.com, version 2018.1
2All things in a game level are GameObjects in Unity.
CHAPTER 5. SYSTEM OVERVIEW 18
components attached. The output of the clustering step is a new hierarchy. In the new hierarchy, only leaf nodes have meshes attached, exemplified in figure 5.2.
A
B C D
E F G
H I J
(a) Hierarchical scene graph where all nodes, including internal nodes, have meshes attached. E F H I J D A B C G
(b) Hierarchical scene graph where only leaf nodes have meshes attached.
Figure 5.2: Hierarchical scene graph with meshes attached to all nodes (a) is converted to only having meshes at leaf nodes (b).
5.2
Hierarchy Exporter
The next step in the pipeline is to export a hierarchy tree from Unity to an external format, in prepara-tion for the next step. The exporter writes a folder structure that matches the hierarchy of GameObjects selected inside Unity, and exports each node’s local transformation matrix as well as every leaf node’s mesh. The meshes are exported to Simplygon’s proprietary format Simplygon Scene Format (SSF) and placed in the correct folder.
5.3
Hierarchical Proxy Mesh Processor
A standalone program that processes an exported folder hierarchy to generate proxy meshes has been implemented in C#. It traverses the folder hierarchy in a top-down postfix manner, invoking the public Simplygon API as a new process for each node. In this manner, each node in the tree awaits the execution of its child nodes, and only after they have completed starts the aggregation and generation of the node’s proxy mesh. The benefit of having separate processes for each subnode in the tree is that multiple Simplygon processes can be started at the same time, since the Simplygon API can process jobs separately and distribute the work across Central Processing Unit (CPU) cores as well as across multiple connected computers3.
The Simplygon process was configured to use the remesher processor, which takes as input the node’s children and creates a new watertight mesh with no redundant triangles - i.e. triangles hidden beneath
3I developed the pipeline on a laptop with 4 physical CPU cores. When processing jobs, I scheduled up to 2 concurrent
CHAPTER 5. SYSTEM OVERVIEW 19
the surface of the mesh. The Simplygon API is passed processing arguments using Simplygon Pro-cessing Language (SPL) files that contain a multitude of parameters. I used the default values for most of the arguments, but set the maximum screen size in pixels, explained in section 2.2.1, to a fixed value of 300. I experimented a bit with using the size of the currently processed geometry as ba-sis for the maximum pixel value, but finally settled on a constant value for lack of time. Additionally, as explained in section 1.3, I skipped processing materials and textures for simplicity, since it also made the processing a bit faster. The output mesh was stored in the current folder, and the process then completed its execution, signaling to the parent process that it was completed. When a folder’s subprocesses have completed it can start its own process to aggregate and remesh the results of the subfolders’ processes.
When the program finishes execution every folder in the folder hierarchy contains a proxy mesh representing the entire subtree below itself.
5.4
Hierarchy Importer
The last step before rendering is to import the folder hierarchy from the previous step back into Unity. I implemented an importer of SSF files and processed the entire folder hierarchy, creating a new GameObject hierarchy as output. The imported hierarchy is then exported using Unity’s native binary FBX exporter. The resulting file size is measured and used later in the results section 6.1.
5.5
Runtime HLOD Viewer
The runtime HLOD viewer was implemented in Unity. A major part of HLOD performance comes from intelligently deciding what levels of the tree to render for a given viewpoint and frame, as explained in section 2.2.3. The runtime parts of were implemented as two Unity Components, the HLODRenderer and the HLODGroup4. The HLODRenderer is attached to the root GameObject, while every node in the hierarchy has a HLODGroup component. Each frame, before rendering, the HLODRenderer of the root GameObject calls an update member function, explained in algorithm 5, on its own HLODGroup component that is tasked with evaluating what meshes to draw this frame. A major optimization is to check if a node in the tree lies outside the camera frustum, seen on line 10. If an internal node, with a lot of children deeper in its subtrees, lies outside the frustum, we can safely skip evaluating its children since they will lie outside the frustum as well. If the entire hierarchy lies outside the frustum, the check to see if it is inside is only performed once, compared to once for every object if all objects are rendered separately.
CHAPTER 5. SYSTEM OVERVIEW 20
Algorithm 5Evaluating what hierarchy nodes to render. 1: procedureRENDERSUBTREE(Node, Camera) 2: Children= GETCHILDREN(Node)
3: if!InsideFrustum(Node, Camera) then
4: return 5: end if 6: ifCount(Children)== 0 then 7: Render(Node, Camera) 8: return 9: end if
10: if!InsideFrustum(Node, Camera) then
11: return
12: end if
13: ifDistance(Node, Camera)<=MaximumRenderDistance(Node) then 14: Render(Node)
15: else
16: for all Childin Children do
17: RENDERSUBTREE(Child, Camera) 18: end for
19: end if 20: end procedure
Chapter 6
Results
All the following measurements were performed on a Dell XPS 15 laptop with an Intel Core i7 6700HQ 2.6 GHz with 4 cores. The laptop had 16 GB RAM, an Nvidia GeForce GTX 960M GPU with 2 GB of GDDR5 VRAM, and a 512 GB SSD drive.
The implemented HLOD pipeline has been tested on five different 3D models. Statistics for every model is shown in table 6.1, and renders of the original models can be seen in figure 6.1. The Car, Locomotiveand Diesel Engine models are considered non-environments, as explained in section 1.1.
Model Triangles Vertices Meshes Space (MB)
Power plant 12.75M 10.97M 4103 356
Car 9.82M 5.40M 2333 435
Diesel engine 1.25M 847K 1317 65
Kitchen 1.07M 899K 753 30
Locomotive 532K 509K 360 17
Table 6.1: Statistics for 3D models used in measurements
All tests were carried out for six different configurations for every asset. The configurations were the following.
(a) Original model
(b) DLOD chain on a per-mesh basis. The chain for each mesh consists of the original mesh and four consecutive reduced versions of the original mesh. The Simplygon Reduction processor with a reduction ratio of 40%, e.g. keeping 40% of the vertices, was used for generating the reduced versions.
(c) HLOD with the bounding sphere clustering algorithm.
(d) HLOD with the AABB clustering algorithm, with the box proportions constraint parameter k with a value of 0.
(e) HLOD with the AABB clustering algorithm, with the box proportions constraint parameter k with a value of 1.
(f) HLOD with the AABB clustering algorithm, with the box proportions constraint parameter k with a value of 2.
CHAPTER 6. RESULTS 22
(a) Power Plant (b) Car
(c) Diesel Engine (d) Kitchen (e) Locomotive
Figure 6.1: The five models used in the tests.
6.1
Geometric Complexity and Space Requirements
After performing the associated pre-processing and pre-computation steps, the geometric statistics, such as vertices, triangles and meshes, were gathered, as well as the space occupied on the hard drive. This was done for all five models for every configuration, and the results are shown in figures 6.2, 6.3, 6.4, 6.5 and 6.6.
Version Triangles Vertices Meshes Space (MB)
Original 12.75M 10.97M 4103 356 DLOD chain 20.66M 20.65M 11427 753 HLOD, sphere 15.44M 14.13M 5950 825 HLOD, AABB k=0 14.54M 13.05M 5703 740 HLOD, AABB k=1 14.33M 12.77M 5330 713 HLOD, AABB k=2 14.02M 12.45M 4968 681
Table 6.2: Statistics for the Power Plant scene.
Version Triangles Vertices Meshes Space (MB)
Original 9.82M 5.40M 2333 435 DLOD chain 16.20M 9.75M 11662 875 HLOD, sphere 13.40M 8.85M 4074 875 HLOD, AABB k=0 11.78M 7.34M 3075 767 HLOD, AABB k=1 12.29M 7.90M 3409 815 HLOD, AABB k=2 11.96M 7.51M 3182 783
CHAPTER 6. RESULTS 23
Version Triangles Vertices Meshes Space (MB)
Original 1.25M 847K 1317 65 DLOD chain 1.96M 1.57M 3975 192 HLOD, sphere 2.37M 1.86M 1960 216 HLOD, AABB k=0 2.02M 1.54M 1769 186 HLOD, AABB k=1 2.02M 1.54M 1762 185 HLOD, AABB k=2 1.96M 1.49M 1712 179
Table 6.4: Statistics for the Diesel Engine scene.
Version Triangles Vertices Meshes Space (MB)
Original 1.07M 899K 753 30 DLOD chain 1.51M 1.48M 2897 104 HLOD, sphere 1.30M 1.12M 1010 92 HLOD, AABB k=0 1.26M 1.08M 981 88 HLOD, AABB k=1 1.26M 1.08M 953 88 HLOD, AABB k=2 1.24M 1.06M 909 86
Table 6.5: Statistics for the Kitchen scene.
Version Triangles Vertices Meshes Space (MB)
Original 532K 509K 360 17 DLOD chain 772K 780K 1377 37 HLOD, sphere 851K 811K 536 56 HLOD, AABB k=0 764K 724K 470 48 HLOD, AABB k=1 743K 698K 456 46 HLOD, AABB k=2 724K 680K 448 44
CHAPTER 6. RESULTS 24
6.2
Performance Comparisons
Measuring performance was done by animating the camera along a path for a duration of 30 seconds, showcasing every model’s key features both from a close distance and also far away. The total duration for each frame to be produced was recorded and stored for the duration of the camera path. The time series was recorded four times for each asset and each configuration and averaged together, to get better stability and reliability of the results. The averaged frame durations were then inverted to be displayed as Frames Per Second (FPS) values instead, since it is more common to show FPS than actual durations in graphics research. The results are shown in figures 6.2, 6.3, 6.4, 6.5, 6.6 and 6.7.
0 10 20 30 0 30 60 90 120 150 Time (s) Frames/second Original DLOD chain HLOD, sphere HLOD, AABB k = 0 HLOD, AABB k = 1 HLOD, AABB k = 2
Figure 6.2: Performance of the Powerplant scene for the six configurations.
0 10 20 30 0 150 300 450 600 750 Time (s) Frames/second Original DLOD chain HLOD, sphere HLOD, AABB k = 0 HLOD, AABB k = 1 HLOD, AABB k = 2
Figure 6.3: Performance of the Powerplant scene for the six configurations. The graph has been scaled vertically to show the entire range of the data.
CHAPTER 6. RESULTS 25 0 10 20 30 0 30 60 90 120 Time (s) Frames/second Original DLOD chain HLOD, sphere HLOD, AABB k = 0 HLOD, AABB k = 1 HLOD, AABB k = 2
Figure 6.4: Performance of the Car scene for the six configurations.
0 10 20 30 0 20 40 60 80 100 Time (s) Frames/second Original DLOD chain HLOD, sphere HLOD, AABB k = 0 HLOD, AABB k = 1 HLOD, AABB k = 2
CHAPTER 6. RESULTS 26 0 10 20 30 0 50 100 200 300 400 500 600 Time (s) Frames/second Original DLOD chain HLOD, sphere HLOD, AABB k = 0 HLOD, AABB k = 1 HLOD, AABB k = 2
Figure 6.6: Performance of the Kitchen scene for the six configurations.
0 10 20 30 0 20 40 60 80 100 Time (s) Frames/second Original DLOD chain HLOD, sphere HLOD, AABB k = 0 HLOD, AABB k = 1 HLOD, AABB k = 2
CHAPTER 6. RESULTS 27
6.3
Visual Comparisons
A few points in time are compared visually for the Power Plant model in figures 6.8, 6.9, 6.10, and for the Car model in figures 6.11 and 6.12.
(a) Original model 2812 active meshes 133 milliseconds
(b) DLOD chain 2812 active meshes 139 milliseconds
(c) HLOD, bounding sphere 271 active meshes
14 milliseconds
(d) HLOD, AABB (k=0) 410 active meshes 20 milliseconds
(e) HLOD, AABB (k=1) 539 active meshes 26 milliseconds
(f) HLOD, AABB (k=2) 1041 active meshes 17 milliseconds
Figure 6.8: Comparison of the Power Plant model, rendered at t = 3s in the animation, using six different methods. The images have been magnified with a factor of 2 to better show the details.
CHAPTER 6. RESULTS 28
(a) Original model 2812 active meshes 130 milliseconds
(b) DLOD chain 2812 active meshes 140 milliseconds
(c) HLOD, bounding sphere 1011 active meshes
46 milliseconds
(d) HLOD, AABB (k=0) 1146 active meshes 53 milliseconds
(e) HLOD, AABB (k=1) 1484 active meshes 67 milliseconds
(f) HLOD, AABB (k=2) 1913 active meshes 88 milliseconds
Figure 6.9:Comparison of the Power Plant model, rendered at t = 30s in the animation, using six different methods.
(a) Original model 2812 active meshes 99 milliseconds
(b) DLOD chain 2812 active meshes 89 milliseconds
(c) HLOD, bounding sphere 1058 active meshes
50 milliseconds
(d) HLOD, AABB (k=0) 1266 active meshes 61 milliseconds
(e) HLOD, AABB (k=1) 1566 active meshes 61 milliseconds
(f) HLOD, AABB (k=2) 1951 active meshes 72 milliseconds
Figure 6.10:Comparison of the Power Plant model, rendered at t = 6.1s in the animation, using six different methods.
CHAPTER 6. RESULTS 29
(a) Original model 2333 active meshes 109 milliseconds
(b) DLOD chain 2333 active meshes 105 milliseconds
(c) HLOD, bounding sphere 106 active meshes
17 milliseconds
(d) HLOD, AABB (k=0) 32 active meshes
14 milliseconds
(e) HLOD, AABB (k=1) 49 active meshes
13 milliseconds
(f) HLOD, AABB (k=2) 35 active meshes 15 milliseconds
Figure 6.11:Comparison of the Car model, rendered at t = 0s in the animation, using six different methods. The images have been magnified with a factor of 3 to better show the details.
(a) Original model 2333 active meshes 78 milliseconds
(b) DLOD chain 2333 active meshes 75 milliseconds
(c) HLOD, bounding sphere 347 active meshes
39 milliseconds
(d) HLOD, AABB (k=0) 320 active meshes 40 milliseconds
(e) HLOD, AABB (k=1) 380 active meshes 43 milliseconds
(f) HLOD, AABB (k=2) 240 active meshes 40 milliseconds
Chapter 7
Analysis and Discussion
7.1
Method
The choice of using Unity for the base of the project has had its benefits and drawbacks. First off, since Unity handles importing of all kinds of assets automatically, even reloading scripts and updates to already imported models, the pace of development could be kept high. Never needing to quit Unity and recompile the entire project certainly had its benefits. In addition, the C# language is very expressive and enabled me to write efficient extensions to Unity.
Unfortunately, I realized late in the project that I had not recorded either the time spent clustering the models or the time spent invoking Simplygon to generate proxy meshes for the resulting hierarchies. This means that while the results for the performance comparisons of the pipeline are interesting, I do not have any accurate measurements of those other metrics. I do, however, have a general feel for the duration spent generating proxy meshes for an entire hierarchy, it was never lower than an hour for any model and never higher than 24 hours.
7.2
Results
7.2.1
Performance Comparisons
The performance comparisons clearly show that the HLOD pipeline gives great performance gains across all five of the 3D models tested. One of the main takeaways from e.g. figure 6.2 and figure 6.4 is that the framerate for any of the given HLOD configurations is very stable over the entire sequence. In comparison, the framrate for the original model rendering as well as the reduction chain configu-ration is unstable and varies with up to a factor of 3. Moreover, the HLOD configuconfigu-rations are never significantly worse than the original model rendering or the reduction chain configuration.
7.2.2
Visual Comparisons
Inspecting the still frames taken from the animations, shown in 6.11, 6.12, 6.8, 6.9 and 6.10, it is hard to distinguish any apparent visual artifacts for any of the configurations compared to the original models. In addition, watching the entire animation path in realtime yields similar results for all con-figurations. However, the less-detailed proxy meshes for the HLOD configurations are noticeable in a few cases, mainly when moving the camera fast from far away to a close distance, or vice versa.
CHAPTER 7. ANALYSIS AND DISCUSSION 31
7.2.3
Comparing Clustering with Bounding Sphere and AABB
Looking at the performance results for all HLOD configurations, one can see that the bounding sphere configuration is slightly better overall in figures 6.2 and 6.7. However, the four different configura-tions are remarkably similar in performance across all five models, with the AABB configuraconfigura-tions performing slightly better than the bounding sphere configuration for the Kitchen asset, in figure 6.6. However, when it comes to the number of nodes, effectively the number of meshes, in the generated hierarchy tree, the AABB configurations generated fewer nodes in all cases. As a result of this the space requirements are also lower in all cases.
7.3
Source criticism
The main papers that this thesis references the most are well-cited papers published no earlier than 1996, and so it is reasonable to assume that they are accurate. In addition, the techniques presented have been heavily inspired by the work in UE4 and are available in that software for anyone to use, lending further credibility to the effectiveness of the sources it was built on.
7.4
The work in a wider context
I would argue that there are few ethical concerns related to this work, if any at all. The work done as part of the thesis will not be released as a product in its current state, but the theory presented might become part of some software in the future. If anything, the framework for HLOD discussed here will serve to broaden the reach of this feature to many more users, thanks to it being automatic in its implementation.
Chapter 8
Conclusion
I consider the thesis to be successful, in general. The individual steps of the HLOD pipeline have been implemented and perform well. However, the entire pipeline is not automated as there are a few steps that need to be done manually, e.g. exporting/importing the hierarchical data from/to Unity. The performance of the HLOD renderer is good, and effectively highlights the benefits of the technique. In section 1.2 I proposed three research questions to be answered. I will try to answer these using the findings of the report.
How can the generation of HLOD be automated by applying algorithms for automatic hierarchy generation?
By using a hierarchical clustering algorithm to generate efficient hierarchies for HLOD, one can automate the HLOD pipeline. For all five test scenes HLOD does show improvements in performance, and the introduced overhead by HLOD tree evaluation and proxy mesh switching never makes the HLOD versions of the assets to perform noticeably worse than the original model.
Can hierarchical clustering be applied to complex 3D scenes that describe non-environments, for usage in a HLOD rendering pipeline?
The results presented clearly shows a that the HLOD configurations improved performance for all scenes, even for the non-environments scenes. This confirms that the hierarchical clustering is able to produce good results for non-environment scenes, not just for environments.
Can bounding spheres be substituted for AABBs in a hierarchical clustering algorithm to im-prove the performance of the clustering algorithm and/or the rendering of the produced data? As discussed in section 7.2.3, using AABBs over bounding spheres give a slightly more compact hier-archy representation, resulting in a little less hard drive space being taken up to store the proxy mesh files. Moreover, the performance of them both is very similar, and there is no discernible difference in visual quality between them.
8.1
Future Work
While the conclusions drawn in this report are promising for automatic HLOD pipelines, there is still more research to be done in the field.
CHAPTER 8. CONCLUSION 33
The implementation of material handling into the pipeline is a must if this pipeline should ever be released as a product. This opens up a lot of questions, such as additional space requirements of textures for baked materials. A possible modification to reduce the number of baked materials could be to introduce a factor into the clustering cost function that favors clustering meshes with the same material together, meaning that the proxy mesh can reuse the same material.
While the current mesh switcher for the HLOD renderer fulfills its function there is room for im-provement. If even larger models with hundreds of thousands of nodes are to be rendered, the tree evaluation must be efficient. One improvement could be to keep the currently rendered node front in a cache, so that the next frame’s tree evaluation can start from that node front, since continuous camera movements means that the node front is the most likely nodes to be rendered the coming frames as well.
Bibliography
[1] Pierre Alliez, Éric Colin De Verdière, Olivier Devillers, and Martin Isenburg. Centroidal voronoi diagrams for isotropic surface remeshing. Graphical models, 67(3):204–231, 2005.
[2] Mario Botsch and Leif Kobbelt. A remeshing approach to multiresolution modeling. In Proceed-ings of the 2004 Eurographics/ACM SIGGRAPH symposium on Geometry processing, pages 185–192. ACM, 2004.
[3] Adrian Courrèges. GTA V - Graphics Study - Part 2. https : / / web . archive . org / web / 20180404105420 / http : / / www . adriancourreges . com / blog / 2015 / 11 / 02 / gta-v-graphics-study-part-2/, 11 2015. (Accessed on 04/06/2018).
[4] Hierarchical Level of Detail. https://docs.unrealengine.com/en-us/Engine/HLOD. (Accessed on 04/06/2018).
[5] Michael Garland and Paul S Heckbert. Surface simplification using quadric error metrics. In Proceedings of the 24th annual conference on Computer graphics and interactive techniques, pages 209–216. ACM Press/Addison-Wesley Publishing Co., 1997.
[6] Hugues Hoppe. Progressive meshes. In Proceedings of the 23rd annual conference on Computer graphics and interactive techniques, pages 99–108. ACM, 1996.
[7] Mark W Jones, J Andreas Baerentzen, and Milos Sramek. 3d distance fields: A survey of techniques and applications. IEEE Transactions on visualization and Computer Graphics, 12(4):581–599, 2006.
[8] Peter Lindstrom, David Koller, William Ribarsky, Larry F Hodges, Nick Faust, and Gregory A Turner. Real-time, continuous level of detail rendering of height fields. In Proceedings of the 23rd annual conference on Computer graphics and interactive techniques, pages 109–118. ACM, 1996.
[9] Timothy S Newman and Hong Yi. A survey of the marching cubes algorithm. Computers & Graphics, 30(5):854–879, 2006.
[10] Angel Domingo Sappa and Miguel Angel Garcia. Hierarchical clustering of 3d objects and its application to minimum distance computation. In Robotics and Automation, 2004. Proceedings. ICRA’04. 2004 IEEE International Conference on, volume 5, pages 5287–5292. IEEE, 2004.
APPENDIX A. UNITY UI 36
Appendix A
Unity UI
APPENDIX A. UNITY UI 37
APPENDIX A. UNITY UI 38
Figure A.3: A custom UI window giving easy access to helper functions and statistics of selected GameObjects.
