Evaluating Different Spatial Anti Aliasing Techniques

EXAMENSARBETE INOM TEKNIK, GRUNDNIVÅ, 15 HP STOCKHOLM, SVERIGE 2017

VICTOR KESTEN

KTH SKOLAN FÖR DATAVETENSKAP OCH KOMMUNIKATION Evaluating Different Spatial Anti Alias- ing Techniques

VICTOR KESTEN

Bachelor in Computer Science Date: June 5, 2017 Supervisor: Dilian Gurov Examiner: Örjan Ekeberg Swedish title: Utvärdering av olika Spatial Anti Aliasing tekniker School of Computer Science and Communication i

Abstract

Aliasing is an effect that causes different signals to become indistinguishable when sampled. In computer graphics, it makes objects that are rendered on the screen appear jagged. This thesis aims to ﬁnd a compromise between performance and quality when applying different anti aliasing techniques within real time 3D environments. To achieve this several different anti aliasing techniques were tested on different 3D environments and a detailed survey querying people their anti aliasing preferences when presented different options was used to determine a quality compromise. In conclusion when analyzing all external factors the thesis ﬁnds that MSAAx4 or FXAA is the best option when using a system with limited resources. ii

Sammanfattning

Aliasing är en bieffekt som förekommer när man mäter olika signaler. Inom datorgraﬁk förekommer det när objekt blir renderade på skärmen och man kan då upptäcka tydli- ga ojämna och hackiga kanter. Denna uppsats siktar på att hitta en kompromiss mellan prestanda och kvalitet när man använder olika anti aliasing tekniker inom en realtids 3D miljö. För att uppnå detta har ﬂera olika anti aliasing tekniker testats på en mängd olika 3D miljöer samt har en undersökning gjorts angående människors preferenser inom bild kvalitet när dom är blint presenterade olika val. Uppsatsen lyckades och efter en grund- lig analys av dom insamlade resultaten kan dra slutsatsen att MSAAx4 eller FXAA är det bästa valet när man använder en dator med begränsade resurer. Contents

Contents iii

1 Introduction 1 1.1 Problem Deﬁnition ...... 2 1.2 Scope and Constraints ...... 2 1.3 Thesis Overview ...... 2

2 Background 3 2.1 Aliasing ...... 3 2.2 Signal Processing ...... 4 2.3 Rasterization ...... 4 2.3.1 Occlusion and Coverage ...... 5 2.4 Techniques ...... 7 2.4.1 An Introduction to Sampling ...... 8 2.4.2 Super Sampling ...... 10 2.4.3 Adaptive Super Sampling ...... 11 2.4.4 Resolve and Downsampling ...... 13 2.4.5 Post Processing - Pixel Based Anti Aliasing ...... 14 2.5 Other Forms of Anti Aliasing ...... 16

3 Method 17 3.1 Pre-existing Real-Time Environments ...... 17 3.2 3D OpenGL Real-Time Engine ...... 18 3.2.1 Programming Languages ...... 19

4 Results 20 4.1 Statistical Analysis ...... 20 4.1.1 Pre-Existing Real-Time Environment ...... 20 4.1.2 Custom Engine ...... 22 4.2 Survey ...... 23

5 Evaluation 25 5.1 Summary and discussion ...... 25 5.2 Future Work ...... 25

Bibliography 27

iii iv CONTENTS

A Unnecessary Appended Material 29 A.1 Abbreviations ...... 29 A.2 Survey ...... 30 Chapter 1

Introduction

Aliasing, a commonly found phenomenon in sound engineering, is an effect that causes different signals to become indistinguishable when sampled. In computer graphics, it occurs when a picture is processed through the rendering pipeline and ﬁnally reconstructed. The reconstruction, performed by a display for example - will differ from the originally intended image as aliasing artifacts can be seen. ‘Jagged’ is an informal name for the artifacts in raster images that appear from aliasing. Aliasing is not to be confused with compression artifacts as these occur due to lossy compression. Spatial anti aliasing, the primary focus of this thesis, is a collection of techniques used to minimizing the alias distortion artifacts when representing a high-resolution image on a lower resolution screen. In computer graphics, anti aliasing is generally used to improve the appearance of polygon edges so that they do not appear jagged and instead are smoothed out on the screen.

Figure 1.1: Image Source: [1]

This project is interesting because the topic is of utmost importance when simulating real life scenarios. Us as programmers can by balancing the limitations of hardware technology with software solutions aim to achieve what might seem to be a fair representation of a life like scenario with smooth edges and crisp colors, also recognized as a simulation. Anti aliasing consists of two key areas – blurring techniques and edge detection. These two components can be modiﬁed and tested for different results depending on the users needs and the technology available. The process can also be implemented and distinguished between post

1 2 CHAPTER 1. INTRODUCTION

or pre processing implementation techniques. Results can be measured in terms of performance and frame render time. The algorithms associated with anti aliasing implementations can be theoretically calculated and then compared to real time implementations.

1.1 Problem Deﬁnition

Finding a proper analysis of anti aliasing techniques in terms of quantifiable data is difficult. The question to be investigated in this thesis is find out which style of anti aliasing in a real- time 3D environment is the most efficient in terms of performance and produces the "best" result in terms of visual appeal. The aim is to find a compromise between best result and visual appeal that’s suitable for common personal computers. This involves testing different styles of anti aliasing as well as different techniques within the specific anti aliasing styles. For this to be a proper question, we have to define what “best result” means. Since we are dealing with an interactive 3D environment that should work in real time, i.e not a ray tracer - a rendering technique that generates an image by tracing light rays and simulates it’s interactions with objects, we define best result as being that result which produces good anti aliasing that performs the intended effect while also not degrading the performance of our application. What looks ’good’ and is visually appealing to humans will also be investigated through a perceptual study. Anti aliasing is notorious for being a costly setting within 3D engines and our goal is for it to find the one which runs as smoothly as possible in real time.

1.2 Scope and Constraints

The thesis will limit itself by only testing three main anti aliasing styles and base the results only on those. However it is important for the reader to know that this area is one of much research and thus we limit ourselves to the most commonly applied techniques. We also deﬁne "best looking" through the results of a perceptual study survey. This survey has the intention to test a range of users to see which style of anti aliasing they prefer, if they can tell the difference between speciﬁc styles and what their experience with computer graphics is like.

1.3 Thesis Overview

The thesis first thoroughly goes through the aliasing problem both in terms of signal processing and image generation. Then it goes through the rasterization process, specifically cov- ering occlusion and coverage as these are critical components in the alias creation process. Following this section, the thesis finally introduces anti aliasing and the most commonly used techniques that are used in modern computer graphics. The thesis then describes the process and the methods used to test different techniques on different real-time virtual environments. The results and evaluation section go through the gathered data, discusses the significance as well as discussing possible improvements to the project and future advancements that are being made within the area. Chapter 2

Background

In this section the thesis will give the reader a thorough insight as to what aliasing is and the techniques used to prevent it. It explains the concept in general terms and ultimately concludes by listing the modern options most commonly used.

2.1 Aliasing

The term display resolution is simply defined as the number of rows and columns of pixels that create the display we see in front of us when using a monitor. Historically, display resolution along with aspect ratio has varied quiet a bit and even to this day we still see high increments of pixel density when newly released monitors and TV displays appear on the market. The first graphics card ever created was introduced by IBM in 1981 and was called Color Graphics Adapter (CGA). It was equipped with 16 kilobytes of video memory (VRAM) and the highest resolution possible of any mode was 640x200 with 2 bit colors, or alternatively 320x200 with 4 bit colors[2]. Today in 2017, one of the most prestigious and well defined graphics card available is the Nvidia GeForce GTX 1080 which supports a maximum display resolution of 7680x4320 pixels and has 8GB of VRAM – a true testament as to how advancements have been made within this field[3]. This equates to approximately 235 times more pixels on a single screen. The card also offers a color depth of 8 bits - a more ’life-like’ range of colors. A problem that the two cards have in common when generating images on the display however, is aliasing. Aliasing is an effect that causes different signals to become indistinguishable when sampled. In computer graphics, it occurs when a picture is reconstructed on a computer display, having the reconstructed image differ from the original by having alias artifacts appear in certain spots[4]. An alias artifact is visually displayed as a jagged edge or an incomplete detail in an image, thus the informal name “jaggies”. It is common to find the anti aliasing topic brought up when discussing digital imagery, movie animation rendering or video games. Digital imagery however deals with static images and generally the time it takes to process a full-fledged anti aliasing scheme on an image is irrelevant as the person observing the image will be observing a finalized saved result that’s been pre-processed and already edited. In movie animation, anti aliasing techniques are in fact extremely common and Disney for example have an entire dedicated research time working full time on rendering techniques such as this. They are known to release scientific papers and can be highly recommended to the interested reader. However, animated movies generally use a form of ray tracing when being rendered and thus are not expected (or even

3 4 CHAPTER 2. BACKGROUND

capable) to be rendered in real time with many objects. Movie animations, similarly to digital imagery, is only made to be viewed once in one speciﬁc way – the way the artist intended it to be. Therefore, the movies are pre-rendered and processing time to a certain extent is irrelevant and more resources can be put on providing the literal best picture possible. [5] What this thesis will focus on is real-time rendering, or in other words – using a rasterizer to render the images we see on the screen and how implementing anti aliasing affects performance in real time scenarios. This is extremely common within the video games industry and thus analyzing some of the techniques they implement can be very informative in achieving our end goal.

2.2 Signal Processing

Before explaining how aliasing occurs within computer graphics, it is important to have a full understanding of where said phenomenon originates. An image can be interpreted as a signal. The image that is displayed on the users screen is taken as samples at each x and y point of a ﬁltered version of the signal. In the earlier days of computer graphics, people used Fourier transformations to transform the pixels into a signal, similarly how a musical chord can be displayed as frequencies. [6] The goal of a signal anti aliasing process it to reduce the frequencies above the Nyquist Limit so that the signal is accurately represented by it’s samples. The Nyquist Limit essentially states that the wave’s frequency must not be above half the sampling frequency and thus the process of adapting this to computer graphics becomes fairly trivial. [6]

2.3 Rasterization

As we’ve discussed before, aliasing occurs when the input signal is undersampled and thus there are two logical possible solutions: raising the sampling rate of which we sample the pixels or to put a limit on how many pixels that are allowed in the input[4]. To begin, it is important to discuss the rasterization pipeline and what features a 3D11 (Or future DirectX 12 or Vulkan) capable GPU provides to the programmer as this is crucial when we design our subsequent algorithms. The main reason why jagged edges appear is due to how the rasterizer transforms the vertex data into actual fragments behind the scene[7]. Rasteriza- tion, the technique used by most real-time rendering applications, is the process of taking an image described in vector notation and transforming said pixels into a raster image which in itself is outputted on a display. In principle, the rasterizer supports the rendering of points, lines and triangle primitives and as a collective, these shapes can create the mesh-like objects we see on the screen. [8] The vertices that are rendered are generally collected as tuple vertex coordinates which are stored in a dedicated buffer datastructure called Vertex Buffer Object who’s sole purpose is to transport the data to the graphics card. As compared to most normal applications that do not use advanced graphics features or the OpenGL/DirectX languages, all executable graphics code is run on the dedicated graphics card which is optimized for doing vertex and texture calculations very fast in parallel. The vertex points are placed in the homogenous clip space and produce a projection matrix along with some form of a transformation. The ﬁnal positions calculated by the rasterizer are then used to determine what pixels we see on the screen. [8] CHAPTER 2. BACKGROUND 5

The vertex data submitted to the rasterizer tend to be 3D points that form triangles. The rasterizer interpolates between these points to form solid surfaces and then provides support for proper texture mapping and shading among other graphics techniques. Triangles are used because of their simplicity (having only 3 points) and for their linear properties making calculations very easy[9]. From a set of basic triangles you can form incredible 3D shapes such as the famous Stanford Bunny[10], the Cornell Box[11] or the commonly used marbles that show off ambient, specular and diffuse lighting as well as test refraction and reﬂection[12]. Because interpolation is used between single vertex points it’s almost guaran- teed ﬂoating point values will appear along the grid space and thus it is also the rasterizer’s job to determine which discrete pixel to shade or not to shade.[7]

Figure 2.1: A pixel grid with three vertices in orange and interpolated lines.

2.3.1 Occlusion and Coverage The ﬁnal picture we see on the screen is determined by two key components: coverage and occlusion[8]. Coverage is the process of determining whether or not triangles provided by the vertex buffer overlap a single given discrete pixel. However, in most modern GPUs, coverage is calculated by testing if the primitive overlaps a single sample point located in the center of each pixel – a big difference which will later be discussed in more detail. Common tests for this include sampling the distance of the primitive to the sample point, how much of a percentage the triangle covers a pixel or if the sample lies is within the primitive[13]. These tests are crucial to the success of our subsequent anti aliasing algorithms and techniques. Occlusion is the process of determining whether or not a pixel covered by a triangle is also covered by any other triangles. In almost all modern applications this is handled by using a z-buffer, also known as a depth buffer. A z-buffer is no more than a 2 dimensional array constructed with the same size as the image being displayed, containing a list of ﬂoating 6 CHAPTER 2. BACKGROUND

Figure 2.2: Highlighted in green are covered pixels. point numbers. When an object is rendered, the z coordinate provided by the primitive is normalized and stored in the buffer if and only if the object is closer to the observing lens. When all objects have been processed, the z-buffer will perform z-culling, essentially meaning that we ensure that when we render two primitives, the one closer to the observer will cover the one that’s further away. For optimizations sake, almost all modern hardware performs some form of a depth test before the shading occurs and thus only the primitives seen by the observer will actually be rendered. [7] [8] In figure 2.2 we see a triangle with three vertices being drawn across a pixel space. By using simple point sampling the pixels covered by our intended triangle are clearly highlighted in green and all other non-covered pixels are grey. We can see that the pixels highlighted are only those in which the interpolated line fully covers even though it may be within the ’pixel area’ - a term we will return to shortly. For our occlusion test the triangle only tests it’s z-index against the clear color background and will always be drawn as the closest object if nothing else is present. If two triangles were to be drawn, the vertex with the highest z-index would be drawn on top of the other triangle’s vertex. Together, coverage and occlusion determine the visibility of a triangle and the subsequent coordinates can be easily defined in a 2D vector. It can therefore also be treated as a signal as we described earlier and we can define this signals behavior in terms of signal processing. The way we handle the jagged aliasing is through specific anti aliasing techniques. The goal of anti aliasing is to minimize the jagged edges and spots on the digital image when representing a higher resolution image on a lower resolution screen in such a way not to destroy the finer details[13]. Figure 2.4 shows the final output raster image without the imaginary lines that guided our coverage stage. CHAPTER 2. BACKGROUND 7

Figure 2.3: Our interpolated triangle and what is actually seen on screen.

2.4 Techniques

The aliasing problem usually occurs in three speciﬁc situations when rendering an image [13].

1. Along edges on the rendered primitive or a crease in a surface

2. In very small objects

3. In areas of complicated detail.

There are then also essentially three techniques for improving the rendition of detail. First and perhaps the most obvious is to increase the resolution of our display. What this would do is cause single sample points to occur more frequently and thus the effects of the transi- tion from one resolution to another would be negligible. If you have a theoretical screen with unlimited pixels, aliasing would not be a problem – similarly to how we experience real life from our own human visual perspective. The costs of calculating a single image on a screen that big would however be infinitely high and thus this is highly impractical. The second technique is to process the rasterized image by blurring or applying contour smoothing algorithms to the places affected by aliasing. While this may create a more visually pleasing image without aliased areas, it may potentially blur small details and thus information that may be essential to the image can be lost in the process. The third technique is to make each sample point in our unrasterized image represent a finite area in the scene rather than a single infinitesimal discrete point. As a triangle is drawn, one can grasp the average coverage of said triangle within the finite pixel area and produce a weighted average of the colors of the triangle and any other mesh overlaps or the local background. What’s ultimately discussed and researched within this thesis is a compromise between all three techniques. [13] 8 CHAPTER 2. BACKGROUND

Figure 2.4: Final output raster image

The anti aliasing topic has been researched since the early 70’s and thus a lot of techniques have been theorized, developed and implemented[13]. However, it is only in recent times where this topic has sparked a lot of attention and become of great interest as the need for good anti aliasing in real time environment for entertainment simulations, better known as video games, has become essential when wanting to create a full life like simulation. [7]

2.4.1 An Introduction to Sampling To simply increase the display resolution, while in theory may be a viable strategy to elimi- nate our problem, eventually ends up being way too costly. To force the signal, or pixels in our case, to conform to a low sampling rate by attenuating and using a low pass filter on the high frequency components, that give rise to aliasing artifacts, is highly impractical and in itself would cause a severe loss of primitive detail. Thus when implementing anti aliasing techniques a compromise between increasing screen resolution and using a low pass filter. [4] To begin we will look at a fairly naïve approach when generating an output raster image. This technique is called point sampling, something that’s only been mentioned and not fully explained prior to this. What this term means is that each output pixel is a single sample of the input image, never considering the neighboring pixels[13]. We also define this point to be just that – a point, when realistically it represents an area. By using a single point as a sample will most likely cause information to be lost in the conversion as the detail of the samples tend to not be of the same resolution and thus aliasing artifacts may surface. This indicates that the sampling density is not sufficiently high to characterize the input. Immediate intervals between samples, which should have some influence on the output, are completely ignored[4]. In reference to the first technique when tackling the aliasing problem, we can clearly CHAPTER 2. BACKGROUND 9

see that if we increase the resolution causing sample points to occur more frequently, will allow for finer details to be displayed and thus diminishing the obtrusion of jagged edges. However in most scenarios this is impractical as it’s not so simple to just increase screen resolution of a fixed machine and thus we must explore different options in order to include the sought after details in our final picture. When we look at point sampling we can determine one big flaw in it’s logic. A pixel that is sampled in this scenario is considered to be a discrete point when it actually represent an area. A better way to look at a pixel is that each output pixel should be considered a tiny area representing a color which then looks onto the input image [4]. Instead of sampling one single point one should use a low pass filter upon the projected area in order to properly reflect the information being mapped onto the output pixels[13]. A low pass filter attenuates signals with higher frequencies and sets a determined cutoff point. In computer graphics terms, this means attaining surrounding information about the pixels around itself and then blurring the pixel in which we only have partial coverage by the primitive shape.[4]

Figure 2.5: Pixel point to area

It’s clear that the final rasterized image produced by area sampling is superior to that which is produced by point sampling as it effectively reduces the aliasing artifacts and uses sound mathematics to do so. The area sampling in computer generated imaging is usually implemented using a box filter, averaging surrounding pixels and producing a fixed, diluted output color. The box filter acts as a convolution filter, meaning it provides a method of multiplying two arrays with each other in order to provide a third array – these two being the image sample and a filter kernel in order to get our final filtering result array[14]. The filter kernel array defines how the filtering will happen. The power of a box filter is extremely vast and it allows you to do things such as sharpen, emboss, edge-detect, smooth and motion blur. This is also known as post-processing and later on we will see ways this strategy can be used to create extraordinary anti aliasing in a very short amount of time. [15] As explained by Vorlesung however, area sampling is akin to direct convolution except for one notable exception: independently projecting each output pixel onto the input image limits the extent of the filter kernel to the projected area[4]. Of course, this constraint can be overcome if we consider the bounding area, which ultimately becomes the smallest region that completely bounds the pixel’s convolution kernel. It’s nevertheless far superior to point sampling. We now look at the way we sample pixels in an image. In signal processing, a finite impulse filter (FIR) must be used to form an average of the aggregated samples. If the filter kernel remains constant, meaning the aggregated samples all have the same values, as it progresses through the image, the rasterized image is referred as space invariant. Most 3D applications have the need for space variant filters – the opposite of this and we see the kernel varies depending on where it is positioned. Space variant filters are needed for things 10 CHAPTER 2. BACKGROUND

such as texture or perspective mapping when using the shader functionality of for example OpenGL. Since this is a lot of work, the ﬁltering requires a lot of pre-image samples in order to compute the ﬁnal pixels on the rasterized image. We shall only be discussing regular sampling although the reader should note that both regular and irregular exists. Regular sampling is the process of using a normal sampling grid in order to uniformly collect pixel samples. [4]

2.4.2 Super Sampling Super sampling anti aliasing, more commonly recognized as SSAA or FSAA (full screen sampling) when discussing computer generated graphics was one of the first techniques to reduce the appearance of aliasing artifacts. The technique involves internally using a much higher resolution to render the scene and when outputted, the resolution is down sampled back to the normal resolution of the output display[8]. This would solve the problem of having to upgrade your screen to a higher resolution. Despite the idea being ingeniously simple it obviously also has its downfalls. The extra resolution is used to prevent the aliasing artifacts by having more fine details to work with. However this comes at a great cost as it means the GPU has to draw a lot more fragments and thus one will definitely experience performance drawbacks in high fidelity graphical applications [7].

Figure 2.6: Pixel converted into subpixels.

Implementing SSAA in a 3D rasterizer is trivial as we only render to a higher resolution and then downsample it using a reconstruction ﬁlter. The problem however is performance[7]. Of course when the resolution of the render target is increased, we receive a higher sampling rate of visible pixels which in itself is favorable when considering the problem we’re dealing with. This also means that the pixel shading rate increases as well, as the execution pixel shader is tied to the resolution of the screen. This increase is in fact exponential and thus any work done inside the pixel shader would be performed at a much higher rate and consume more resources than what is perhaps available[8]. An example of this would be if our initial display resolution is 1920x1080p and we use x4 SSAA, the shader has to process four times the amount of pixels compared to before. This will put a hefty amount of pressure on the bandwidth when writing the result of the pixel shader to the render target as well as increase memory consumption since the render target and corresponding z-buffer respectively must also increase in size[7]. Thus SSAA is only commonly used for GPUs that are extraordinary, real time environments that leave the GPU not working 100% or when frame rate can be sacriﬁced for nicer looking real-time images. CHAPTER 2. BACKGROUND 11

Figure 2.7: Coverage after using multisampling. Some pixels are only partially covered.

2.4.3 Adaptive Super Sampling While our super sampling strategy works it’s also proved to be a very expensive operation and a technique that surely can be improved. When analyzing super sampling it is easy to identify one major issue: we’re using the strategy on every pixel on the screen when this may not be necessary at all. When observing aliasing, as previously described, we only encounter it along the edges of primitives, in very small objects or in complicated details[13]. In order to keep the desired outcome of SSAA but also reduce the cost of running it we can produce a new technique in which attempts to identify said scenarios and ignores the rest of the image. Historically in the early 2000s within the game industry, pixel shading mostly consisted of texture fetches and therefore did not suffer from proper aliasing[7]. A mipmap image is a pre-calculated and optimized sequence of images each of which appear in different resolu- tions. The aim of these images is to provide optimization when implementing level of detail (LOD) in game engines and is in some form still used to this day. A high resolution mipmap is used for high density samples, for example when the displayed game object is close to the users screen and thus reduces aliasing while low resolution textures are used when the game object is further away[8]. Researchers eventually came up with the technique that now days is commonly referred to as adaptive super sampling or Multi-Sample Anti Aliasing (MSAA). Implementation wise, MSAA is implemented in the rasterizer similarly to how super sampling is implemented. Our initial coverage and occlusion test are done at a higher resolution and we ﬁnally downsample the image to the render target. Super sampling and multi-sampling both consider each pixel as if though they represent 12 CHAPTER 2. BACKGROUND

Figure 2.8: Final output image compared to intended triangle. an area. This area is divided up to have N sample points, conveniently named sub-pixels, where N represents the multi sampling rate. Generally when picking the level of ﬁnesse in anti aliasing the sample rate is either 2, 4, 8 or in very rare cases 16. Essentially what this means is that each pixel from the original screen resolution is now represented as an area with 2, 4, 8 or 16 sub pixels. This is of an exponential order of increase and the results you get from 16 sub pixels versus 8 when considering the time and processing power it takes to perform said task is not very good[8]. The new samples taken from these sub pixels are called sub samples. The triangle is tested for coverage at each sub sample point, essentially building a bitwise coverage mask representing the portion of the original pixel which is covered by the rendered triangle or primitive[7]. Occlusion testing is also performed as initially described - analyzing the triangle’s z po- sition at each covered sample point and tests this information against the already existing value in the z buffer. However, there is now a need for a much bigger z-buffer as we have more points sampled. The size of this z-buffer must be changed to store the additional subpixel depth values and is automatically set to be N times the size of the original buffer. Where our two techniques begin to differ is when we execute our pixel shader. Note that when we execute the pixel shader for super sampling, as explained above, we execute it for each pixel and sub pixel in the image. As originally explained, our intention was to now only use the sub samples of in which aliasing can occur[8][7]. In our new adaptive super sampling we only execute the pixel shader once for each pixel where the coverage mask is non-zero. At this point, pixel shading occurs in the same manner as non-adaptive super sampling. When sampling many points, the vertices and their attributes are interpolated to the center of the pixel and used by the pixel shader to do lighting calculations as well as CHAPTER 2. BACKGROUND 13

Figure 2.9: Final raster image as seen on the screen. texture fetching if necessary. Ultimately what this means is that the ﬁnal pixel shader costs do not increase exponentially as they do for when SSAA is enabled. As we progress through the different anti aliasing concepts we need to consider one more thing within the adaptive super sampling topic that affects the performance of a graphical application. It is never sufﬁcient to only store one output value per pixel in the render target as we may have triangles that overlap certain areas. We need to support the ability to store multiple samples per rendering target in order to store the results from multiple triangles that all may only partially cover said triangle. Therefore the rasterizer, when MSAA is enabled, increases the memory to store N subsamples for each pixels. Conceptually this is identical to how the z-buffer is also increased when dealing with the occlusion test[7]. When the pixel shader outputs it’s value, it’s only ever done so after the sub samples have passed the coverage and occlusion test. So if a triangle covers half the same points in a 4x pattern, only half of the sub samples in the render target receive that pixel shader output value. Generally this will create some form of a color gradient when the triangle is matched with a non-color background. This is an explanation as to why having a higher VRAM is favorable when using advanced settings.

2.4.4 Resolve and Downsampling The last and key step which has only been brieﬂy mentioned is the downsampling of our high or semi-high resolution render. This process involves resampling down to the output resolution before displaying the signal or raster image. In the very early days of GPUs this function was performed by hardware on the GPU and as a programmer one had little to no 14 CHAPTER 2. BACKGROUND

Figure 2.10: Pixels colored that only need single samples. control over how it happened[8]. The graphics cards available tended to use a 1-pixel wide box filter, meaning they aggregate and average all subsamples within a given pixel. This type of box filter produced results that were arguably good and bad at the same time. It was arguably good because you would never unintentionally reduce the details through luring and also arguably bad because it will definitely produce post-aliasing – that is, aliasing that occurs after you anti alias. [8] A key note to mention and for the reader to take with them is that for any form of super sampling does not work when using a deferred renderer. A standard forward renderer expects you to supply the vertices array and it will project it, break down the values into vertices and transform said vertices to fragments or pixels that are treated with post-rendering functions (if necessary) before being displayed[16]. This process is linear as each geometric shape is independently passed down the pipeline to produce the raster image. In a deferred renderer the rendering is delayed until all of the geometric shapes are passed through the pipe. The final raster image is not created shaded until the very end of the cycle. This means that lighting decisions are not made until the very end of the shading and by this time the information needed by our anti aliasing process is gone[17]. However – all hope is not lost yet. A way to implement anti aliasing in a deferred renderer using a different technique will be discussed in the next section.

2.4.5 Post Processing - Pixel Based Anti Aliasing Super sampling and it’s subsidiaries are not the only ways to perform good and effective anti aliasing. In the early part of 2011 a rendering expert at Nvidia by the name of Timothy CHAPTER 2. BACKGROUND 15

Figure 2.11: Pixels that need multisampling.

Lottes published a paper along with supporting sample code demonstrating a new technique to anti alias in an extremely fast fashion while still achieving good results. This technique is known as Fast Approximate Anti Aliasing (FXAA) and utilizes techniques that are in no way similar to how SSAA and MSAA do things. It’s a fantastic example of how heuristics and the use of simple hacks, things that are commonly used to great effect in video game development, can solve a problem. [18] FXAA reduces visible aliasing while maintaining sharpness, all at a cost that reduces the frame rate and game performance by a very small margin. Lottes clearly states that the intentions of this aliasing is to target aliasing both on triangle edges and in shader results, to have logic to reduce single-pixel and sub-pixel aliasing, for it to be easily integrated into a single pixel shader, that it should run as a single-pass filter on a single-sample color image, that it should provide a memory advantage over the fairly-expensive MSAA and that it can provide a performance advantage for deferred rendering over using MSAA[15]. These are some ambitious goals and if we reminisce to how MSAA was developed we can see it’s fairly difficult if not impossible to use the same strategy if we want to attain all these improvements using the old techniques.[8] The filter is applied as a full screen post processing pass after the entire scene has been rendered, performing edge detection and subsequent blurring of said edges. Since it’s applied as a post processing filter it means that in theory it’s possible to mix both a form of SSAA and our post-processing FXAA and potentially annihilate post-aliasing that can appear when using lower sampling rates. It is also therefore also recommended that this filter is used before rendering eventual HUD or UI elements of the screen as this might cause things such as text to show up blurry.[15] 16 CHAPTER 2. BACKGROUND

If we do a deep dive into the algorithm we see that it takes the screen array of non-linear RGB color data as input which it then internally converts into a scalar estimate of luminance. This luminance value is used to check local contrasts as to avoid processing non-edges within the image display. Pixels that pass the local contrast test are classified and divided up in horizontal and vertical classes which are then, given the edge orientation, selected based on the highest contrast pixel pair that match up within 90 degrees. The algorithm searches for the end of the edge and furthermore checks for significant changes in the average luminance of the high contrast pixel pair along the edge. The input texture is then resampled given the subpixel offset and finally a low pass filter, like before in previous techniques, is blended in depending on the amount of detected sub pixel aliasing. [15] The two main parts of this algorithm that can be subject to tweaking is edge detection and blurring (low pass filtering). Depending on what edge detection techniques one can either over estimate what might be considered an edge or underestimate – a common trait amongst heuristic algorithms. What this essentially ensures is that there will be no near perfection as there may be with the super sampling technique. However, this operation of using said heuristic algorithm ensures much better performance while still generating substantial results as will be seen later on in the report. The low pass filtering techniques can also be altered, as we’ve previously discussed, and we are free to use a variety of sampling techniques to ensure proper blurring of the surrounding pixels.

2.5 Other Forms of Anti Aliasing

The following two anti aliasing techniques are modern day adaptions and experimental ver- sions that aim to outperform the more traditional implementaitons that have been described so far. The first technique is called Adaptive Edge Anti Aliasing Filter and is very similar to the implementation made by Timothy Lottes. Instead of focusing on the hardware and the graphics pipeline, improved quality is achieved by using information from neighboring pixel samples to compute both an approximation of the gradient of primitive edges and the final pixel color. It uses an intelligent reconstruction filter built within a shader to edge detect and blur. This technique was explore in 2009 and was therefore before Lotte’s FXAA. [19] The second technique goes by the name of Enhanced Subpixel Morphological Anti Alias- ing (SMAA). The technique uses local contrast analysis for a more reliable edge detection essentially meaning a more sophisticated object and silhouette reconstruction while maintaining extremely fast execution time. [20] Chapter 3

Method

The question to be investigated in this thesis is find out which style of anti aliasing in a real- time 3D environment is the most efficient in terms of performance and produces the "best" result in terms of visual appeal. Occlusion and coverage techniques are scrutinized as well as experiencing the techniques previously discussed in specific settings. There are two stages to the undertaking of this study.

1. An analysis of pre-existing anti aliasing techniques in several different real time environments.

2. An implementation of anti aliasing into our own virtual real-time environment.

The key variables we are testing are VRAM consumption, clockcycles per frame rendered, frames per second and GPU Load. We can analyze and compare theoretical limits and determine whether or not these values match our implementations. With these statistics we can start answering at least the first part of our problem - which anti aliasing technique is the most efficient in terms of visual output. Another key factor that will be measured is the users visual appeal to each technique and how ’good’ it looks. Due to current knowledge in human visual perception have not reached sufficient levels we must generally decide this to be “what looks best”. This is difficult to measure in numbers as us as humans have no way of determining what looks ’good’ in pure mathematics as it’s also thought to be subjective. Therefore a survey with supporting images explaining what to look for has been used and the results are reflected on. This survey can be found in the appendix. This survey will help us answer the second part of the problem - what us as humans believe to look "good" and if we can actually see a noticeable difference between the techniques. By combining the two measurements we can come up with a conclusion and determine a suitable candidate for "best" anti aliasing technique. The anti aliasing techniques tested will be the ones discussed in the pre-study: SSAA, MSAA and FXAA.

3.1 Pre-existing Real-Time Environments

A crucial part in doing testing is investigating already available options and see how they impact our observed variables. As anti aliasing is something used in many different forms of applications we have a clear sample space available to us with plenty of options. The two existing real time environments this study has decided to use are the following:

17 18 CHAPTER 3. METHOD

• Grand Theft Auto V

• World of Warcraft - Legion

Grand Theft Auto V was a commercial success when released back in 2013. It was praised for it’s graphical fidelity and innovations made within the video game development industry. In 2015 the game was released for PC and became a testament to what the power of a strong GPU can produce in terms of graphical fidelity. This game uses the custom made RAGE engine - an engine developed by rockstar themselves using DirectX 11 and supports stereoscopic 3D rendering. The game simulates a fictive version of the city Los Angeles and follows the protagonists Michael, Franklyn and Trevor in an open world experience. The engine allows amazing customization and visual guidelines on how much processing power is necessary when changing options. This video game will be abbreviated as "GTA V" from now on. Compared to GTA V, World of Warcraft (WoW) was a major project started back in 1999 and finally released to the public in 2004. This ultimately means the engine used in the game is much older. The difference in what was possible 15-20 years ago compared to today is very vast, especially when taking Moore’s law into consideration. The engine is however still scalable and does a fine job to this day with great options for customization and testing. In 2015 along with patch 6.1 Blizzard added anti aliasing support to their game engine along with other graphical updates[21]. Blizzard are also known for their wide range of system compatibility - that their games work on a range of different machines and operating systems without much issues[22]. A classic saying is that "A Blizzard game will run on almost any machine but even the most high-end computers struggle running them at max settings." This is something that will be discussed more in the results section. A general trend among video games is for their option menus to be extremely limited and seclusive in terms of what they allow you to customize as a user. They also rarely show any interesting statistics in terms of performance. We shall therefore use the program GPU Z as our terms of measurement when recording statistics. GPU Z is a program that monitors GPU variables and allows users to log these statistics to files. We shall also use in-game FPS counters as to see how anti aliasing effects performance. FPS is a good indication of how taxing a specific setting is and can be measured to be proportional to available resources and resources in use. The reader should be aware that there is however not a linear relation- ship between fps and rendering of a frame[23]. The reason for using frames per second as a measurement and not the more preferred time-to-render a single frame is due to measurement constraints. Within the two games there is no such feature and to keep things uniform the custom engine is consistent with the previously chosen variables. The two video games selected were picked with caution.

3.2 3D OpenGL Real-Time Engine

By using a self-created 3D OpenGL engine it allows us to thoroughly customize and track information that may not be possible in any other way. It also allows us to implement custom algorithms for the anti aliasing that we want to investigate - i.e describe and investigate different implementation techniques and algorithms. The engine uses forward rendering as we want to test multiple implementations of different anti aliasing techniques. CHAPTER 3. METHOD 19

3.2.1 Programming Languages This engine is implemented in Java using Slick and LWJGL. We use OpenGL’s own GLSL shading language as to shade and render our primitives and OBJ files as mesh data. LWGJL provides an easy-to-use interface with the Open Graphics Library and grants us abilities to create windows, register inputs and to design an engine from the ground up. The justification of using Java instead of a more conventional language such as C++ - generally considered the industry standard, is purely due to convenience and time constraints. A creation in C++ would improve some performance aspects of the end-product and would be suitable for a release product. However, ultimately what we’re looking at and research- ing is relative performance when comparing two anti aliasing techniques and thus overall performance is irrelevant. Another key factor to take into mind is that the implementation of these algorithms will differ from system to system and programming language to programming language as this is the nature of how computer technology works. The equipment used for testing the algorithms is a Nvidia GTX970. This is a fairly powerful dedicated GPU card - something not all computers have and since anti aliasing as clearly described before increases VRAM memory consumption, one will experience performance delays if the VRAM is insufficient as paging will occur and thus further delays as we will later see in the results. We are also using the OpenGL packet and there are other options such as DirectX 3D which may produce different results. However - the algorithms themselves when described in theory should be unadulterated. Chapter 4

Results

This chapter aims to display and discuss the results collected by the studies described in chapter 3. It ﬁrst does an analysis of the numbers collected and discusses the reason for achieving said results in the pre-existing real-time environments. The chapter then explores the custom engine and does a similar analysis. The survey is interviewed last and conclusions are drawn. The testing was for the most part successful. This section will be divided up into the statistical analysis where all gathered data for each technique is calculated and then the survey - an analysis of what people generally think looks better and their reasoning behind it.

4.1 Statistical Analysis

4.1.1 Pre-Existing Real-Time Environment

Figure 4.1: Left: No Anti Aliasing. Right: MSAAx2

20 CHAPTER 4. RESULTS 21

Figure 4.2: Left: No Anti Aliasing. Right: SSAAx2

Setting GPU Core GPU Mem- Memory GPU Load Power Consump- FPS Clock ory Clock Used tion No AA 1303.6MHz 1752.8MHz 2896MB 61% 51% 60 MSAAx2 1312.6MHz 1752.8MHz 3437MB 65% 57% 60 MSAAx4 1335.4MHz 1752.8MHz 3518MB 70% 65% 55 MSAAx8 1332.1MHz 1752.8MHz 3903MB 86% 73% 28 FXAA 1353.2MHz 1752.8MHz 2993MB 64% 51% 60 GTA 5

Setting GPU Core GPU Mem- Memory GPU Load Power Consump- FPS Clock ory Clock Used tion No AA 1303.6MHz 1752.8MHz 971MB 71% 32% 97 MSAAx2 1312.6MHz 1752.8MHz 1036MB? 50% 57.8% 96 MSAAx4 1335.4MHz 1752.8MHz 1065MB? 95% 93% 85 MSAAx8 1332.1MHz 1752.8MHz 1256MB 100% 90% 35 SSAAx2 1290.9MHz 1752.8MHz 1642MB 100% 96% 40 FXAA 1353.2MHz 1752.8MHz 1003MB 65% 75% 94 WoW

The results gathered from the pre existing engines show what we theoretically could expect with only some variance. If we start by looking at the GTA 5 statistics we see that the core clock is fairly constant with no significant increases amongst the trials. A GPU specializes in using SIMD parallelization to great effect when doing calculations and will use longer vector parallelization instructions. This means the core clock will only slightly increase as there are only a few more extra calculations to be done - thus the minimal gradual increase. Another key thing to note is that the GPU also does other calculations simultaneously to the anti aliasing calculations. We can see in the figure 4.1 that the two scenes are in fact different. This is because everything in the game is moving and time passes - changing the shadow rendering and reflections around the target object. This distortion will add errors to the data and therefore the results, although showing the wanted result, should be taken with a grain of salt and used as proving a general trend. An argument for creating the custom engine is to diminish these external factors and gather raw reliable data. 22 CHAPTER 4. RESULTS

The memory consumption shows a more proper increase. It is also clear that the memory consumption is proportional to the frames per second. This increase is to be expected as we know that each frame now has up to twice the number of pixels as previously when we run MSAAx2. The video card used has a 3.5GB VRAM threshold with 500MB being of a lower tier quality[24]. Once we reach this 3.5GB threshold we clearly see a significant decrease in FPS. The reason for the decrease in frame rendering time is due to the need for paging. With the GPU load not being used to it’s full potential it’s clear that the significant short coming is the lack of available VRAM when using a higher grade of MSAA. If we look at the WoW results we also see similar results. As the MSAA sampling rate is increased we see an increase in VRAM consumption. What’s interesting in this scenario is the significant increase in GPU load when the setting is increased. As stated earlier, WoW is a game that’s not only very old but also runs well on a lot of different computers and operating systems. What this means within the code is a more generic approach to GPU programming and the support for a wider range of cards. This could also mean the lack of using advanced features such as vector parallelization or specific parts of the dedicated hardware that the advanced GTX 970 supplies the user. The legacy code may not be accustomed to the modern day optimization methods provided in later generation APIs and thus we see the GPU being at max load and the VRAM not be limiting factor. Ultimately what this leads us to is the discussion of what you want your application to achieve. GTA 5 is dedicated to the Windows environment and uses the latest DX11 technology when rendering. It also has dedicated optimizations from NVIDIA and is designed for high end systems. WoW on the other hand is an extremely old game that supports Windows, OS X and Linux systems with support for a huge range of hardware - including high and low end. Creating specific code that optimizes performance for each hardware available is not feasible and thus this sacrifice is made. It is also perhaps due to the legacy code within the engine - code that does not utilize the modern day GPU dedicated functions and specific hardware implementations. If we now look at FXAA compared to no MSAA for both games we also see highly antic- ipated results. As Timothy Lottes states in his report on the subject - FXAA should ideally only cost under 1ms extra time in rendering the scene[15]. Considering we have just about 16ms to render a scene in order to create a 60fps experience, this cost is comparable to nothing. Both games show an increase in core clock time but no significant increase in VRAM used. The slight increase in VRAM is most likely loading the post-processing shader file and doing the local calculations - something that clearly is not as costly as doing MSAA.

4.1.2 Custom Engine

Setting GPU Core GPU Mem- Memory GPU Load Power Consump- FPS Clock ory Clock Used tion No AA 135.0MHz 162.8MHz 486MB 15% 8.5% 60 MSAAx2 135.6MHz 162.8MHz 507MB 15% 8.5% 60 MSAAx4 135.4MHz 162.8MHz 515MB 17% 8.3% 60 MSAAx8 135.1MHz 162.8MHz 530MB 20% 8.7% 60 MSAAx16 162.2MHz 162.8MHz 559MB 26% 9.7% 60 FXAA 145.3MHz 162.8MHz 486MB 16% 8.7% 60 Custom CHAPTER 4. RESULTS 23

The custom engine proves our initial hypothesis. It should be noted that there have been no optimization used in the implementation of this solution (such as explicit parallelization) and we solely rely on the optimization LWJGL provide internally. If we start by observing the GPU Core Clock we see a general ﬂat lined progression in terms of clock speed until we hit 16 samples. Once again - the reason for this could be due to the vectorization the GPU does internally. We are using the latest version of LWJGL and thus we can expect a lot of optimization to be implemented for us, especially since we’re using the MSAA provided by OpenGL. Once we hit 16 samples however, the vectorization math is not enough as the length of the vectors are limited and thus more calculations are needed and we see an increase in the instructions per second calculated. As can be seen in the plot below the memory used is in fact almost perfectly proportional to the number of samples we take. The engine, on purpose, does not create a vibrant world as this would cause distortion and errors in the data. Everything is perfectly still when we render the scene and we therefore get a constant memory reading. This clearly shows the proportional increase in memory consumption when increasing the sampling rate - something we absolutely expected when discussing the concept in the pre-study. FXAA shows a different picture. We see that similarly to the results in the other two engines we have an increase in core clock rate. This is, as previously described, expected as there are more calculations done per frame rendered. The GPU does edge detection and blurring - two techniques that can be costly. In our case however, the number of objects on screen are limited and the lack of other effects such as shadows are missing. If we have more objects with more edges the clock rate may increase but memory should stay the same. Memory dependence of Sample Rate in the custom engine 600 Memory Increase 580

560

540

520 Memory [MB] 500

480

460 0 1 2 4 8 16 Sample Rate

4.2 Survey

The survey gave varying results. The target audience were both friends and family with gaming and non gaming backgrounds. Generally a person with a video games background would have heard of the term as it is a common option available to the user. Most people 24 CHAPTER 4. RESULTS

Figure 4.3: Left: No Anti Aliasing. Right: MSAAx4

Figure 4.4: Left: No Anti Aliasing. Right: MSAAx8. who had heard of anti aliasing however were unsure of what it does - an acceptable response as it generally tends to be the unsung hero of realism in visual simulations. It’s there - people see it and don’t expect something else. When it’s not there they will notice that it is not there. This was also clearly proved in the survey by questions 2 and 3, two comparison questions asking whether or not the user could see a difference in two identical images, one with MSAA and one without. The majority of people were successfully able to identify the correct anti aliased image. The last question of the survey asked the user to point out which image looked the "best" to them. Provided were 5 images showcasing no MSAA, 4x MSAA, 8xMSAA, 16xMSAA and FXAA. No one responded that they though no anti aliasing looked the best. However there were disputes between 16x, 4x and FXAA. 57.1% believed that the 16xMSAA looked the best while a split 21.4% though 4xMSAA and FXAA looked the best. Chapter 5

Evaluation

In this chapter we discuss the conclusions drawn in the results section and suggest what could be done in terms of future work for similar projects as well as this research area.

5.1 Summary and discussion

The results gathered from our testing drew plenty of conclusions but also rose many questions. Using the already existing game engines was both good and bad. It was good as they have clear options for the techniques we were investigating and we were able to test it and measure the results in a real time environment. It was bad because the data received was distorted due to interference from objects and things appearing and disappearing from the screen. Of course in a real time environment - the ones we are investigating, this is common and will happen but since this thesis’ focus was on gathering data in regards to one specific implementation of a technique it gave varying results. The conclusion we can draw from the raw data is two things and can be stated fairly simply. When the user has extra VRAM and the developer has optimized parallelization and utilization of resources, MSAA is not too bad. It creates a beautiful scene with less jagged edges and does not necessarily increase the cycles per seconds in the GPU. The survey suggests that having the highest setting MSAA is infact not necessary as there was an influx of people picking between x16 and x4. Therefor if you truly want to provide an effective anti aliased scene, MSAAx4 could be sufficient. The second part has to do with FXAA. When the user has fully utilized their VRAM capabilities - i.e there occurs paging from the secondary memory to the VRAM but we still have clock cycles available to us FXAA becomes a fantastic alternative. The user based study says that they do not mind the FXAA blur and that it is a good alternative as they compared it to MSAAx4.

5.2 Future Work

An interesting performance study that could be done to improve the current project is to dwell into the GPU memory management code. We clearly saw when testing GTA that the limiting factor was indeed VRAM. When the GPU does the calculation it only needs pixel data once (or a few more times depending on when ﬁnding primitives but this can possibly be sorted through good spatial locality and a custom cache coherency protocol) per frame and can discard the pixel more

25 26 CHAPTER 5. EVALUATION

often than not immediately afterwards. Us as programmers know that when we do these calculations we can discard the data immediately afterwards and we can use this to our advantage. One of the most ideal paging algorithm is one that can accurately predict which data will not be used in the near future and replace that data for data that will be used next. There should be a dedicated thread or dedicated hardware in the GPU that deals with anti aliasing paging data. This hardware would in parallel discard and page in future data, replacing old non-usable data once the VRAM memory is ﬁlled up. Realistically the data that the GPU is done with is still contained in the VRAM after it’s been done and a normal paging algorithm would not know when to discard it. With the predictability of which data needs to be used when doing anti aliasing calculations it should be possible to implement a dedicated thread that preemptively pages in and out memory frames in parallel to the GPU doing the MSAA calculations. This would reduce the overhead of having to page in only once there is a miss and would ultimately reduce the penalty. This way the GPU can continuously work and the VRAM would no longer be the limiting factor. This would however be an entire project on it’s own and not feasible for the average programmer as it requires manipulating hardware and hardware close code - something that’s restricted by the GPU manufactorer. The second limiting factor we discovered was that there was an overuse of GPU resources being used when performing anti aliasing. The solution to this, if one actually wants a solution as it clearly has beneﬁts too as discussed earlier, would be to more properly optimize the code you use. The programmer should take advantage of the SIMD scheme and multi- core support in modern day GPUs and also rely on the optimizations DirectX and OpenGL provide. Having 16xMSAA is realistically overkill and this could be seen with the survey. People were unsure whether they thought MSAAx16 or MSAAx4 looked the best when presented a range of options. There was also opinions that FXAA was the best looking anti aliasing option - a pleasant surprise as this is generally a much cheaper option than any form of MSAA. Bibliography

[1] Role of anti-aliasing (aa) in gaming, 2017. URL https://ageeky.com/role-of-anti-aliasing-aa-in-gaming/.

[2] Frank Durda IV. Ibm pc-compatible cga video reference, 2001. URL http://nemesis.lonestar.org/reference/video/cga.html.

[3] Geforce gtx 1080 ti, 2017. URL https://www.nvidia.com/en-us/geforce/products /10series/geforce-gtx-1080-ti/.

[4] George Wolberg. Digital image warping. IEEE Computer Society Press, 1994.

[5] Hayley Iben. Artistic simulation of curly hair. Disney Pixar, 2012.

[6] Allan V. Oppenheim. Discrete-Time Signal Processing. Prentice Hall, 2 edition, 1990. ISBN 0137549202.

[7] Joey De Vries. Learn opengl, extensive tutorial resource for learning modern open gl, July 2015.

[8] Matt Pettineo. A quick overview of msaa, October 2012. URL https://mynameismjp.wordpress.com/2012/10/24/msaa-overview/.

[9] Herbert Freeman. Computer processing of line-drawing images. volume 6. Computing Surveys, March 1974.

[10] Stanford bunny, 2004. URL http://graphics.stanford.edu/data/3Dscanrep/.

[11] Modeling the interaction of light between diffuse surfaces. volume 18. Computer Graphics (SIGGRAPH), July 1984.

[12] Rendering marbles. URL https://www.scratchapixel.com/lessons/3d-basic -rendering/introduction-to-ray-tracing/adding-reflection-and-refraction.

[13] Franklin C. Crow. The aliasing problem in computer generated shaded images. volume 20. Communications of the ACM, November 1977.

[14] Digitales Video. Anit aliasing.

[15] Timothy Lottes. Fxaa. Technical report, 2701 San Tomas Expressway Santa Clara, CA 95050, January 2011. URL www.nvidia.com.

[16] Brent Owens. Forward rendering vs. deferred rendering, October 2013. URL https://gamedevelopment.tutsplus.com/articles/forward-rendering-vs- deferred-rendering-gamedev-12342.

27 28 BIBLIOGRAPHY

[17] The Benny Box. URL http://www.youtube.com/thebennybox.

[18] Jeff Atwood. Fast approximate anti-aliasing (fxaa), December 2011. URL https://blog.codinghorror.com/fast-approximate-anti-aliasing-fxaa/.

[19] Andrew Pomianowski Konstantine Iourcha, Jason C. Yangy. A directionally adaptive edge anti-aliasing ﬁlter. Advanced Micro Devices, Inc., August 2009.

[20] Yeongkyu Lim Jinhong Park Jae-Ho Nah, Sunho Ki and Chulho Shin. Axaa: Adaptive approximate anti-aliasing. July 2016. doi: http://dx.doi.org/10.1145/2945078.2945129.

[21] Blizzard. Patch 6.1, February 2015. URL https://worldofwarcraft.com/en-us/news/17989015.

[22] Thomas Morgan. How does overwatch run on budget pcs?, June 2016. URL http://www.eurogamer.net/articles/digitalfoundry-2016-how-does- overwatch-run-on-budget-pcs.

[23] Robert Dunlop, 2005. URL https://www.mvps.org/directx/articles/fpsversusf rametime.htm.

[24] Why nvidias gtx 970 slows down when using more than 3.5gb vram, January 2015. URL http://www.pcgamer.com/why-nvidias-gtx-970-slows-down-using-more- than-35gb-vram/. Appendix A

Unnecessary Appended Material

A.1 Abbreviations

Here a list of all abbreviations and deﬁnitions mentioned in the report will be contained.

Abbreviation Proper Word AA Anti Aliasing FXAA Fast Approximate Anti Aliasing MSAA Multi Sampling Anti Aliasing SSAA Super Sampling Anti Aliasing FSAA Fullscreen Sampling Anti Aliasing GPU Graphics Processing Unit VRAM Video Random Access Memory VBO Vertex Buffer Object OpenGL Open Graphics Library LWJGL Light Weight Java Graphics Library 3D11 3D Direct X 11 GLSL Graphics Library Shading Language HUD Heads Up Display UI User Interface RGB Red Green Blue GTA V Grand Theft Auto 5 WOW World of Warcraft

29 30 APPENDIX A. UNNECESSARY APPENDED MATERIAL

A.2 Survey

The survey used when querying people. www.kth.se