Creating an Appealing 3D-visualization Tool for Baseboards in the Web Browser

Full text

(1)LiU-ITN-TEK-A--20/028--SE. Creating an Appealing 3D-visualization Tool for Baseboards in the Web Browser Lars Bergman 2020-06-12. Department of Science and Technology Linköping University SE-601 74 Norrköping , Sw eden. Institutionen för teknik och naturvetenskap Linköpings universitet 601 74 Norrköping.

(2) LiU-ITN-TEK-A--20/028--SE. Creating an Appealing 3D-visualization Tool for Baseboards in the Web Browser Examensarbete utfört i Medieteknik vid Tekniska högskolan vid Linköpings universitet. Lars Bergman Handledare Henry Fröcklin Examinator Niklas Rönnberg Norrköping 2020-06-12.

(3) 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 extraordinä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/. © Lars Bergman.

(4) Linköping University | Department of Science and Technology Master’s thesis, 30 ECTS | Medieteknik 202020 | LIU-ITN/LITH-EX-A--2020/001--SE. Creating an appealing 3Dvisualization tool for baseboards in the web browser Skapande av ett tilldragande 3D-visualiserings verktyg för lister i webbläsaren Lars Bergman Supervisor : Henry Fröcklin Examiner : Niklas Rönnberg. Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se.

(5) Upphovsrätt Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publiceringsdatum under förutsättning att inga extraordinä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 ﬁnns 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 period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon 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/.. © Lars Bergman.

(6) Abstract Today a lot of libraries, tools and techniques exist to create visual appealing renders for the web. In this thesis, a prototype for visualizing baseboards in the web browser was developed. The prototype demonstrates how certain libraries and techniques were used in order to achieve a generalized, appealing and realistic visualization of the baseboards in a 3D-visualization. This paper also covers why certain libraries and techniques were used for this prototype. The resulting prototype, use Three.js and takes advantage of PBR, different mapping methods and lighting sources that can be changed during runtime through a GUI. To get results on different aspects, such as the visual appeal, how realistic, and what lighting sources worked best for the prototype, a web-survey was sent out and the results evaluated. The evaluation showed that the usage of PBR, a roughness-metalness workflow, environment mapping, physical correct lighting and a point light solution in Three.js all made a good job in creating an appealing, generalized and realistic visualization tool for the web..

(7) Acknowledgments I would like to thank Valbo Trä for suggesting and making this master thesis possible. A big thank you goes to my supervisors at Valbo Trä Nisse Eriksson and Mikael Helmersson for discussions, feedback and ideas, as well as more project related advice and encouragement. I would like to thank Patrick Andersson at 100 Procent media as well for more technical details regarding the project. Also I want to thank my thesis examiner Niklas Rönnberg and assistant Henry Fröcklin at Linköping University, for guiding me in the right direction for this master thesis and report. Lastly a thank you to Camilla Forsell at Linköping University for helping me with the structure of the web survey.. iv.

(8) Contents Abstract. iii. Acknowledgments. iv. Contents. v. List of Figures. vii. List of Tables. viii. 1. 2. 3. 4. Introduction 1.1 Visualization tool for browser 1.2 Research questions . . . . . . 1.3 Limitations . . . . . . . . . . . 1.4 Structure of report . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. Related Work 2.1 An optimal solution for implementing a specific 3D web application . . . . . . 2.2 Ambient Occlusion for Dynamic Objects and Procedural Environments . . . . . 2.3 Photorealistic Texturing for Modern Video Games . . . . . . . . . . . . . . . . . 2.4 IKEA - Home planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Three.js - Physically accurate incandescent bulb . . . . . . . . . . . . . . . . . . 2.6 Babylon.js - Physical based rendering . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Xeogl.js - Importing and loading a more complex model and using different materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Background 3.1 HTML . . . . . . . . . . . . . . . . 3.2 Javascript and Libraries . . . . . . 3.3 WebGL . . . . . . . . . . . . . . . . 3.4 Lightings . . . . . . . . . . . . . . . 3.5 Ray-tracing . . . . . . . . . . . . . . 3.6 PBR - Physically Based Rendering 3.7 3D-models, maps and textures . .. 1 1 2 2 2 3 3 3 4 4 4 4 4. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 5 5 5 6 8 9 9 10. Method 4.1 PBR . . . . . . . . . . . . . . . . . . . 4.2 Libraries . . . . . . . . . . . . . . . . 4.3 Lighting . . . . . . . . . . . . . . . . 4.4 Mapping and textures . . . . . . . . 4.5 Web-survey . . . . . . . . . . . . . . 4.6 Camera and movement in the scene. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 13 13 13 14 15 15 15. v.

(9) 5. 6. 7. Implementation 5.1 Localhost server - Node.js 5.2 Creating the scene . . . . . 5.3 Lighting . . . . . . . . . . 5.4 Baseboards . . . . . . . . . 5.5 PBR . . . . . . . . . . . . . 5.6 Mapping and textures . . 5.7 GUI . . . . . . . . . . . . . 5.8 Shadows . . . . . . . . . .. . . . . . . . .. 16 16 16 17 17 18 18 19 19. . . . .. 21 21 25 27 28. Conclusions and future work 7.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30 30 31. Result and discussion 6.1 Prototype . . . . . . 6.2 Web-survey results 6.3 Survey evaluation . 6.4 Discussion . . . . .. . . . .. . . . .. . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. Bibliography. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. 32. vi.

(10) List of Figures 3.1 3.2 3.3 3.4 3.5 3.6 3.7 5.1. 6.1 6.2 6.3 6.4. 6.5. 6.6 6.7 6.8. Scene node map for Three.js, showing the render flow . . . . . . . . . . . . . . . . . Shows browser support of WebGL 1.0. . . . . . . . . . . . . . . . . . . . . . . . . . . Shows browser support of WebGL 2.0. . . . . . . . . . . . . . . . . . . . . . . . . . . Difference between a perspective and an orthographic camera. . . . . . . . . . . . . Shows how roughness and metalness affects a material. . . . . . . . . . . . . . . . . Image showing the two most common PBR workflows Metalness/Roughness and Specular/Glossiness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Image showing a cube map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 11 12. Artefacts can be seen on the side of the baseboard when using a normal map, inside the red rectangle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 19. Resulting prototype, showing the base model, a baseboard, the skybox and the two windows containing the GUI and performance. . . . . . . . . . . . . . . . . . . Resulting prototype, showing a white baseboard in close-up. . . . . . . . . . . . . . GUI components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Image showing off the shadows. Note that there are two light sources in the scene. One spotlight and one point light. The spotlight is casting the sharpest shadow and the point light the lesser shadow. The model floating in the middle of the room was added to show the shadows more clearly. . . . . . . . . . . . . . . . . . . Shows four images of different roughness and metalness values. The only parameters changing in the images are the metalness and roughness values. Note that both the scene and baseboard have the same roughness and metalness values here, but they can be different. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Shows the AO effect implemented on the baseboards with different intensity. . . . Shows the environment maps effect implemented on the baseboards with different intensity. The lighting in the scene is minimal to easier see the difference. . . . . . . Shows the light map effect implemented on the baseboards with different intensity. In image d, the color of the baseboard is set to blue, this can be useful to easier see the effect on some of the methods used. . . . . . . . . . . . . . . . . . . . . . . .. vii. 6 7 7 8 10. 22 22 23. 23. 24 24 25. 25.

(11) List of Tables 6.1. 6.2. Results from the users grading certain aspects of the prototype. The testing aspects can be seen in the first column, each testing aspect correlates to one question in the survey. Furthermore the first row represent the grading 1-5 and the median and mean value can be shown for the different areas. The numbers below the grading numbers in row 2-6 are how many users picked the grading for each testing aspect. 26 Results from the users picking the best looking image. Column one describes the testing areas and each testing area corresponds to a question in the survey. Column two to six at row one are the different images the user choose from in each testing area and the rows below are the users picking each alternative. Finally column seven shows the percentage of the most picked alternative for each testing area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26. viii.

(12) 1. 1.1. Introduction. Visualization tool for browser. As the web continues to grow, new techniques and tools to visualize arises. A good visualization is vital in most areas such as the game industry, video industry, web-shopping, architectural and medical industry. This is often needed to promote and market the product to a wider audience or present important data. In order to create a good and realistic visualization a number of fields have to be explored: Lightings, Textures, Maps, Materials, Models, Shadows, Renderer, Camera. It can be hard to get a good understanding of a product from a web-shop using only images. Furthermore a time-consuming task to take good looking images for multiple products for a web-shop. A visualization tool can be used to visualize a product in 3D and to quickly get photos on the product using a single 3D-model. Many benefits comes with a 3Dvisualization tool, such as seeing how it looks in the scene, being able to rotate it and get a sense of scale on the product. As well as being able to modify the product in real time, this could for example be changing the material of the model or the lighting in the scene using different controls. When developing a visualization tool for the browser it is important to both think about the user and the implementation process. The tool needs to be user-friendly and the implementation can be simplified by choosing appropriate tools and libraries that fits the desired requirements of the visualization. To simplify the coding experience a lot of JavaScript libraries are built upon WebGL to make it more intuitive for developers. This Master Thesis was proposed by Valbo Trä in Gävle. The goal of this Master Thesis is to develop a prototype for an interactive visualization tool for baseboards in the web browser, to help the user see how the baseboard can look in a scene and get a better sense of the product. Also the tool will be more effective in that it only needs one 3D-model per baseboard instead of using multiple images. Another aim of the thesis is to answer the research questions in the next section. The tool is supposed to be able to visualize different baseboards in an appealing way for the user to view in 3D. The focus will be on making the visualization look good and try to resemble the real world as close as possible. This will be achieved by looking at different lighting sources, mapping methods, and comparing libraries and tools to be used. Furthermore the prototype is supposed to work for different baseboards so a more generalized solution is needed.. 1.

(13) 1.2. Research questions. 1.2. Research questions. The master thesis aim to answer the following questions: 1. What libraries and techniques should be used to create the tool and how can the tool be generalized to work with different baseboards? 2. Which features are necessary for the tool with respect to visual appeal? 3. What lightings, material and maps are needed?. 1.3. Limitations. Several limitations have been made during this project, in order to keep the focus on the research questions. One limitation is that the tool will visualize the baseboards models that are already created. The visualization tool is only compatible with the most common browsers that can use WebGL and it does not work offline. To avoid compatibility issues, the scripts that are used for this prototype are ran locally. The visualization tool will serve as a prototype, since it would be out of scope of this project to implement it directly on top of a web-shop. Considering different screen-resolutions and the time scope of the project. The limitations and wishes from Valbo Trä can be summarized as: 1. The tool should work without any additional download for the user. 2. Should be easy to continue the development upon. 3. More of a general solution to work with all the baseboards instead of a selected few. 4. The tool should aim to work for all common web-browsers. 5. The tool should run smooth, with a good frame-rate.. 1.4. Structure of report. This paper will first present some related work in the area and then describe the background more in depth that is needed to understand the paper. Thereafter the method and implementation process will be described. Last but not least the results will be presented, discussed and future work suggested.. 2.

(14) 2. Related Work. In this chapter, relevant work from several studies and examples are presented. Firstly, this includes a comparison between different WebGL libraries. Secondly, a study regarding different maps and concepts that are relevant for this thesis. Thirdly a paper discussing photorealistic texturing for video games. Moreover the last four sections are examples of different tools made available on the web, displaying different techniques and libraries used to good effect.. 2.1. An optimal solution for implementing a specific 3D web application. A Master thesis was done at Uppsala University [12]. The goal of the Master Thesis was to find the most promising WebGL libraries without using any plug-ins for creating 3D web applications that includes game physics. It also evaluates the differences between the available WebGL 3D libraries. This was accomplished by having a set definition of requirements and matching these with the different libraries. Something that was used for this project as well but with different requirements and wishes. The two libraries that best matched the requirements was implemented in a game. The game was made to test the performance of the libraries against each other by doing challenging 3D rendering with game physics. It could be concluded that Three.js in conjunction with Physi.js was the best option giving the requirement of the defined application.. 2.2. Ambient Occlusion for Dynamic Objects and Procedural Environments. A Master thesis was done at Linköpings University [9]. The goal of the Master Thesis was to have a working implementation of methods that can handle ambient occlusion for dynamic objects and procedural environments. However this was not done in the web browser a lot of concepts are still relevant for this thesis. Since it covers a lot of broad subjects such as lighting and shadows and 3D methods such as ray-casting. Another interesting algorithm proposed is the SSAO which stands for Screen Space Ambient Occlusion, which calculates the approximate ambient occlusion in real-time by using the depths of surrounding pixels. This is done at almost no cost. 3.

(15) 2.3. Photorealistic Texturing for Modern Video Games. 2.3. Photorealistic Texturing for Modern Video Games. A Bachelor’s thesis was done at South-Eastern Finland at the University of Applied Sciences [10]. The paper focused on simulating realism in real-time rendering for modern video games. The objective of the thesis was to study texture mapping and define a work-flow for approaching a photorealism for video game production. Although this is for games the same theories works since both are real-time rendering and 3D texturing. This is a interesting topic and a lot of topics will be useful in one way or another in this project as well. To mention a few relating topics: different maps such as, normal/light/reflection/transparency and different texturing approaches for photo-realistic materials.. 2.4. IKEA - Home planner. Ikea have created a planning tool for the browser that can be used to customize and create your dream kitchen, workplace and more [8]. The detail is good and of high quality. You can drag and drop furniture to the scene. A small drawback is that it requires a plug-in to use and it cant be used on phones and mobile devices. The planning tool can be used by users in a creative way, while still being beginner friendly and having a good help section.. 2.5. Three.js - Physically accurate incandescent bulb. This is an example on how to make use of the Three.js library to make a physically accurate incandescent bulb [17]. The example shows a good, yet simple visualization on a scene. The scene have a few models loaded with some textures. A lighting source in form a a bulb and a floor with wood texture. The user can choose to toggle on and off shadows and increase the power of the bulb or decrease it, as well as changing the exposure and hemisphere radiance, through a GUI. The light sources used in the scene is one point light for the bulb, and a hemisphere light for the scene.. 2.6. Babylon.js - Physical based rendering. This is a demo made using the library Babylon.js [2]. It shows three spheres with different attributes and materials. As well as a skybox and a plane in the middle. A lot in the scene can be changed by the user using the control panel and updated during runtime. Physical based rendering is being used to render the scene. The visualization looks good and does not have any noticeable frame drops.. 2.7. Xeogl.js - Importing and loading a more complex model and using different materials. This example shows how the library Xeogl.js can be used to visualize a more complex model of a helmet[20]. The model in the example is a glTF file and it is a physically based material, which looks realistic. glTF stands for GL Transmission Format and it is a specification for the efficient transmission and loading of 3D scenes and models by applications. This example uses a reflection map to enhance the visual appearance of the model.. 4.

(16) 3. Background. In order to get a good understanding of the paper, knowledge about some concepts are needed. This chapter will present these concepts and describe them. Later on in the paper it will be described how they have been used within the project.. 3.1. HTML. HyperText Markup Language (HTML5) is a standard for developing in the web that includes many functionalities, and was fully developed in October 2014. The new features of HTML5 makes the web more dynamic and provides faster connections between servers and clients. Rendering graphics in 3D to the web became much easier by HTML5, because of the canvas tag. Web sockets is another part that is included in the HTML5 standard and allows full duplex communication between a server and a browser, which makes the web faster [16].. 3.2. Javascript and Libraries. JavaScript is a interpreted scripting language which makes it very flexible. Besides HTML and CSS it is one of the core languages for programming to the web. There exist dozens of different JavaScript libraries and frameworks, many of which use WebGL(Web Graphics Library), such as: Three.js, Babylon.js, Xeogl.js, Pixy.js, Unity and A-frame.. Three.js Three.js is one of the most popular JavaScript library, with exceptional documentation and examples provided. Most importantly, it got plenty of contributors and an active community. Three.js simplifies WebGL to the developer in a lot of ways with different objects, methods and features. Some of the features of the Three.js library used in the implementation of 3D graphics are presented below: 1. Renderers: WebGL, <canvas>, <svg> 2. Scenes: Addition and removal of objects 3. Cameras: Orthographic and perspective along with various controllers 5.

(17) 3.3. WebGL 4. Lights: Ambient, direction, spot and hemisphere lights 5. Materials: Basic, Lambert, Phong, MeshStandardMaterial and more along with textures 6. Geometry: Plane, cube, sphere, torus, and tube. 7. Objects: Meshes, particles, sprites, lines 8. Loaders: For different formats, such as obj, json, gltf, glb The scene node map of Three.js can be seen in Figure 3.1, from [11]. It describes what kind of 3D-object elements are added to the scene to render. The renders job is to render all the elements together and display it to the screen accordingly.. Figure 3.1: Scene node map for Three.js, showing the render flow. Babylon.js Babylon js can be seen used in 2.6 and is a big library that also runs on top of WebGL. Quote from Babylon official website: "Babylon.js 4.0 is here and marks a major step forward in one of the world’s leading WebGL-based graphics engines. From the powerful new Inspector, best in class physically-based-rendering, countless optimizations, and much more, Babylon.js 4.0 brings powerful, beautiful, simple, and open 3D to everyone on the web.". Xeogl.js As can be seen in 2.7 Xeogl.js can be used to create stunning visual representations of models in the web browser. The library uses WebGL for rendering and is open source from Xeolabs. It supports PBR materials and IBL and multiple file formats.. 3.3. WebGL. WebGL is a JavaScript API for rendering interactive 2D and 3D graphics within any compatible web browser without the use of plug-ins [5]. WebGL is fully integrated with other web standards, allowing GPU-accelerated usage of physics and image processing and effects as part of the web page canvas element from HTML5. All major browsers support WebGL, both for desktop and mobile devices. According to [4] 97 percent of all users can use WebGL. See Figure 3.2 below for more information on what browsers are supported. WebGL runs on the GPU and is a low-level programming language, meaning it is harder for developers to 6.

(18) 3.3. WebGL understand. As mentioned before a lot of JavaScript libraries have been made to simplify the coding experience but still being able to take advantage of working at the GPU.. Figure 3.2: Shows browser support of WebGL 1.0. WebGL uses a shader language called GLSL ES which is the same language used by OpenGL ES. It contains of two shaders, a vertex shader and a fragment shader. The vertex shader handles and describes the size and position of a specific vertex and the fragment shader handles fragment operations like colors.. WebGL 2.0 The newest release of WebGL is called WebGL 2.0 and comes with a lot of new features and retains the old ones from WebGL. While WebGL 2.0 is the newest release it only works for 74 percent of all users according to [4], as can be seen in figure 3.3.. Figure 3.3: Shows browser support of WebGL 2.0.. Scene, Renderer and Camera A 3D-scene contains all the objects that should be sent to the renderer. It consists of a three dimensional area where the different objects is positioned in a coordinate system (x,y,z). The scene handles the interaction between the different objects like camera, lights and 3D objects. The renderer in WebGL renders the scene object and takes in some parameters. Cameras are essential when building and rendering a scene. They determines how the objects should be presented to the user and by moving the cameras the view of the scene changes. This is done by a transformation matrix which changes the values in the vertexBuffer and will move the scene. There are two different types of cameras: Perspective and Orthographic. The difference between a perspective and an orthographic camera can be seen in figure 3.4 below, from [15]. Both cameras are used for their different projections in different situations. 7.

(19) 3.4. Lightings A perspective camera gives a better depth, while a orthographic camera have the quality that objects in the projection have the same dimensions, regardless of the distance from the observer.. Figure 3.4: Difference between a perspective and an orthographic camera.. 3.4. Lightings. In all visualizations lightings can make a huge difference on the visual appearance. There are plenty of different lightings to choose from and all have there unique strengths and weaknesses. A lot of times a combination of lights are used to make realistic and stunning lighting. However it can be really hard to know what lighting one should use to create an appealing or realistic scene. Below are some common lighting in WebGL and more specifically the ones in Three.js described. Most 3D-visualization libraries use the same lighting sources even though the name can be of slight variance. • Ambient light, is the light that globally illuminates all other objects in the scene equally. It is a non-directional meaning it cant cast shadow. • Hemisphere light, is a source positioned directly above the scene, with color fading from the sky color to the ground color. This light cannot be used to cast shadows. • Directional light, is light that is emitted from a specific direction. This is light that is coming from so far away that every photon is moving parallel to every other photon. For example, sunlight is considered a directional light source. It can cast shadows. • Point light, is a light that is being emitted from a point, radiating in all directions. This is how many real-world light sources usually work. A light bulb emits light in all directions. A point light can cast shadows. • Spot light, this light gets emitted from a single point in one direction, along a cone that increases in size the further from the light it gets. There is actually 2 cones, an outer cone and an inner cone. Between the inner cone and the outer cone the light fades from full intensity to zero. This light can cast shadow. • Rectangular Area Light, is the last type of lights in Three.js which represents exactly what it sounds like, a rectangular area of light like a long fluorescent light. This light only works with physical based materials. 8.

(20) 3.5. Ray-tracing. Image Based Lighting Image based lighting (IBL) evolved from the reflection-mapping technique and is the process of illuminating scenes and object with images of light from the real world. According to [6] the basic steps in IBL are: "1. Capturing real-world illumination as an omnidirectional, high dynamic range image; 2. mapping the illumination onto a representation of the environment; 3. placing the 3D object inside the environment; and 4. simulating the light from the environment illuminating the computer graphics object." Worth noting is that the images should be omnidirectional and in high dynamic range (HDR) for best result.. 3.5. Ray-tracing. Ray-tracing is an algorithm for tracing a ray from the camera through each pixel on the viewplane and out to the scene as it interacts with and bounces off objects in an environment. In order to determine where in the world the ray intersected an object, if it did, and details about the surface it intersected. The ray is then intersection tested against all objects within the scene to find the point of intersection. The tests can either be done for arbitrary meshes for each triangle in the mesh or implicitly. While this method is accurate, it can be computationally heavy during runtime.. 3.6. PBR - Physically Based Rendering. An approach in computer graphics that is commonly used today is PBR, it seeks to render graphics in a way that better models the flow of light in the real world. Most PBR pipelines have photorealism as their aim. According to [14] almost all photo-realistic rendering systems are based on the aforementioned ray-tracing algorithm to gather information about how light traverse the scene to get realistic lighting. It is possible to use PBR during runtime in the browser as could be seen in 2.6 and 2.5. PBR is more of a methodology than a set strict of rules, according to [1]. Therefore the implementations of PBR systems varies, even though the principal idea to render scenes as accurate as possible remain. To accurately simulate real-world materials, and their physical properties such as: albedo, gloss and reflectivity are studied. Also PBR uses microfacets and BRDF(bidirectional reflectance distribution function) and will often contain additional textures and mathematical models, making it easier to create realistic cavities and highlights on the model. [1]. The benefits of using PBR is that the assets, i.e models will look accurate in all lighting conditions. The work-flow makes it consistent between artists. Last but not least it removes the guesswork of authoring surface attributes such as reflectivity, since its algorithms and methodology are based on physically accurate formulas, which makes it easier to create realistic looking assets [1]. The Khronos group have developed two file formats that both takes advantages of PBR which are called .glb and .glTF and can be used to create realistic 3Dmodels and materials.. PBR workflows The fileformats .glTF and .glb defines materials using a common set of attributes that are based on widely used material representations from PBR. The two most common workflows that use PBR are the so called, metallic-roughness and specular-glossiness workflow. The metallic-roughness workflow is used commonly today in multiple areas and software, mostly in real-time PBR renderers, such as the game engine Unreal Engine 4, Quixel and Unity. Core attributes for this workflow is the basecolor, metalness and roughness [7]. Metalness is the attribute that says how metal the material is. Metals behave differently than non-metals and ranges from 0 to 1. Where a 0 is considered a non-metal and a 1 is considered 9.

(21) 3.7. 3D-models, maps and textures a pure metal. The next attribute that define the material is roughness. Something that has a high roughness, like a baseball does not have hard reflections whereas something that is not rough, like a billiard ball, is very shiny. The relation between the two attributes can be seen in figure 3.5 below, from [18]. Furthermore wood that will be used in this project has a high roughness value and a low metalness value.. Figure 3.5: Shows how roughness and metalness affects a material. Another popular workflow is the Specular-glossiness workflow, which instead uses diffuse, specular and glossiness as core attributes. The specular workflow is used widely as well in software such as high-end 3D-renderers, some examples are: Arnold renderer, Vray, Renderman, Corona [7]. Both workflows can be used to achieve good and almost identical results, but achieves it using different attributes, which can be seen in figure 3.6, from [1].. 3.7. 3D-models, maps and textures. 3D-models are commonly used everywhere nowadays. However increasing the detail of the model increases the loading time due to more vertex points added to the mesh. A good balance is vital to get the desired results but still keeping the loading times down, this is often the case in big scenes or applications such as a AAA video game, where you want to keep the poly count low. Materials are an asset type that change the way models look. They are made up of a collection of properties which determine the color, whether the object is matte or glossy, and whether the object is metallic or translucent for example. A material can use different mapping methods that often use a texture or even multiple textures to enhance the visual appearance of the model. Texturing and mapping a 3D-model can greatly enhance the realistic and visual appearance of the object if done correctly, see section 2.3. An image or even a real photo can be used to overlay a texture on the surface of a 3D-model. This is called texture mapping and allows the user to achieve a high level of detail to the object. It can be hard to know what type of texture to use, since there are many different methods and algorithms on how to texture the model. Therefore the following subsections will explain a popular technique called cube mapping and some common mapping methods will also be presented.. 10.

(22) 3.7. 3D-models, maps and textures. Figure 3.6: Image showing the two most common PBR workflows Metalness/Roughness and Specular/Glossiness.. Cube map A cube map is a texture that contains six individual 2D textures, one for each face on a cube, to form a textured cube. This can be seen in figure 3.7 below, from [19]. They are usually used for creating skyboxes and used for other maps and IBL as stated by Joey de Vries [19]. There exist other methods than cube mapping such as sphere mapping, however cube mapping is the most commonly used due to its relative simplicity. Cube mapping produces results that are similar to those achieved by ray tracing, but much less demanding in regards of computational power. Environment mapping: Using a cube map with an environment, it is possible to give objects reflective or refractive properties. Techniques that use an environment cube map like this are called environment mapping techniques and the two most popular ones are reflection and refraction. Environment mapping is an efficient IBL technique that uses a precomputed texture image. The texture stores the information from the image of the environment surrounding the rendered object. The storing of the environment can be done by different mapping methods, for example using the cube mapping method as previously mentioned.. AO map and Light map An ambient occlusion map does what the name implies in that it blocks ambient/indirect lighting by an amount, in areas depending on the texture used. However it does not block direct light sources. A light map on the other hand enhances the lighting on a material depending on the texture provided. This is a indirect lighting.. Normal map and Bump map A normal map describes the direction that light should bounce off a surface. This is a good mapping method for manipulating materials, because it allows for additional textural detail, bumps, and indentations across a surface without changing the vertices of the object. Hence normal mapping can drastically increase rendering performance since less calculations are 11.

(23) 3.7. 3D-models, maps and textures. Figure 3.7: Image showing a cube map. required in some cases. Another mapping technique similar to normal mapping is called bump mapping. Bump mapping can be used to change the vertices of the object with a texture that tells how the vertices should be changed and by what amount.. 12.

(24) 4. Method. This chapter aims to explain why certain techniques and libraries were chosen to be used for this prototype, it also aims to explain the approach to the research questions.. 4.1. PBR. PBR has recently become the standard in most 3D applications and there is plenty of reasons why that is the case. It comes with so many pros as opposed to not using it as described in section 3.6. Therefore it was determined early on when finding the book [14] that the implementation would become a PBR approach - when reading and discovering that WebGL and many JavaScript libraries supporting PBR in different ways. Since one big aspect of this prototype was to create an appealing visualization tool. Another big aspect was to make the prototype more of a generalized solution to work for different baseboards, see research question one and two. The usage of PBR seemed to fit perfectly for both of these aspects, i.e having objects and materials, reacting physically accurate to different lightings and being visually appealing. Many JavaScript libraries have special material that react to lighting in an physically correct way instead of using approximations on how the light should interact with a surface. However this comes of the cost of being more computationally heavy than the usage of simpler materials, since shading and reflectivity is calculated in a different way. But since the scene in this case is rather small and will only have few object in it, this should not be a problem. The lighting can also be made to be an accurate representation to the real world in terms of decay and intensity values specified in lumen. It was decided to go for a metalness-roughness workflow as described in section 3.6, since the library that was going to be used, Three.js supported that. Furthermore the paper [21] showed and discussed some of the possible materials in Three.js. The ones of interest in this thesis job was MeshStandardMaterial and MeshPhysicalMaterial, since those two are physical based materials.. 4.2. Libraries. The requirements and wishes from Valbo Trä was the starting point for the first research question regarding what libraries to use for this prototype, which can be seen in 1.3. Three libraries 13.

(25) 4.3. Lighting was further examined based on this list, these ones were: Three.js, Babylon.js and Xeogl.js. They can be seen used in different examples in the related work 2.5 2.6 2.7 respectively. All of the three libraries does a good job in rendering a 3D-scene to the web and supports PBR. To get a better feeling on how the libraries actually worked in terms of coding a simple implementation was conducted. The implementation was setting up a scene and adding objects such as models and various lighting. However none of them really stood out and further investigations had to be made to distinguish which one to continue on with for developing the prototype. A paper [13] was found that discussed the pros and cons of Three.js and Babylon.js. The authors of the paper compared the two libraries with a stress test. They came to the solution that Three.js outperformed Babylon.js significantly in all tests except one, that test became obsolete because of the small difference in result. Furthermore the paper [12] found in the related work section 2.1 that showed similar results. It compared a lot of different libraries against each other and categorized them into different groups. A performance test was conducted and it compared Babylon.js against Three.js and it showed that Three.js always had a higher FPS than Babylon.js. The conclusion could be drawn that Three.js worked better in terms of performance out of the papers. It was left to decide whether to use Xeogl.js or Three.js for this project. While Xeogl.js showed good promise, it was discarded due to it being lesser known and having a smaller community. This is not always a bad thing, but considering this project will serve as a prototype and being something that can be easily developed upon by others. Three.js was chosen to be the library to work forward with for this prototype. It fulfilled the requirements and wishes mentioned in the previous list, as well as being easy to work with, having good performance and a big community backing it up, i.e being easy to further develop on for the future.. WebGL It was chosen to use WebGL instead of WebGL 2.0 for this project. This was due to the former working for a broader audience as described in section 3.3, as compatibility was considered important for this project. Therefore WebGL 2.0 was discarded during the start of this project.. 4.3. Lighting. Many different types of lighting exist in WebGL as can be seen in section 3.4, but what provides the most promising result, i.e what lighting is needed for this thesis job? This question is hard to answer. Because it depends on what the scene one want to replicate look like. Brent Burley explains some of the difficulties in creating good and realistic lighting in paper [3]. The scene in this thesis would be basic in the sense that it would only consist of two walls, a floor and the chosen baseboard. Therefore it was decided to make a implementation of different light sources that could be tested in the prototype and then be answered and evaluated in the web-survey. Some of the lighting possibilities in Three.js is discussed in paper [21], it concluded that better result was obtained using multiple light sources to lit the scene and using realistic lighting. The different light sources that was chosen to begin with was: point light, spotlight, ambient light, hemispherical light and directional light, see section 3.4. Combinations of the light sources was tested with the goal of finding a good base lighting that could be tweaked for different scenarios. An important aspect, was to try and make the lighting generalized and tweaked during runtime for the user as this was a part of the first research question.. 14.

(26) 4.4. Mapping and textures. 4.4. Mapping and textures. After finding the thesis [10] and discovering different mapping techniques and maps, as can be seen in section 3.7, it became clear that mapping was a feature that would be tested and implemented for this prototype. However for a more generalized prototype it would be hard to find suitable maps and textures to work for all scenarios. Since different lighting sources can be tweaked during runtime, also the shape of the baseboards differ and so should the textures used for the maps. Therefore a decision was made to make the mapping techniques changeable during runtime. This way depending on the baseboard the user can tweak the mapping during runtime instead of needing to change the map and intensity of the map in the code. For example an AO map to cast shadows in the right places would simply not work if the baseboard looked different as the shadows would not be the same in most cases, so in that case the user can turn off the AO map or change it during runtime. Texturing the models was not a priority in this thesis work because of the aforementioned limitations on different baseboards needing different textures to look good. It would take to much time to create or find appropriate good looking textures for each model and different map. Instead a texture was given by Valbo Trä to be used for the baseboard and tested on for one baseboard model. Valbo Trä also gave a texture to use for the wallpaper and floor. The key mapping methods that were chosen to be implemented for this project was mainly chosen based on the work in the thesis [10]. It was also based on how good it would translate to the baseboards, and if Three.js and the material used, would support the mapping methods. This resulted in starting with the following maps: Environment map, Light map, AO map and Normal map. Moreover the importance of the AO map was found in section 2.2.. 4.5. Web-survey. To get results on certain aspects of the prototype it was decided early on to make a websurvey and send out. Several questions were asked about different topics such as the lighting, mapping, the shadows, how realistic and visual appeal of the prototype. This was done to get result that could be evaluated on to get a better understanding on what worked the best to answer research questions two and three. The results of the survey can be seen in section 6.2. The survey was a mix of different questions where the user was asked to type, rate and compare certain images. It was chosen to go with a web-survey instead of interviewing people in person to save time and get a bigger sample of data to later evaluate on.. 4.6. Camera and movement in the scene. It was chosen to go with a perspective camera given that the depth of the visualization tool was important, see section 3.3. Another important aspect was for the user to be able to zoom, pan and rotate the scene to enhance the visualization.. 15.

(27) 5. Implementation. This chapter explains how the methods chosen was implemented and used for the prototype. A combination of Three.js and smaller libraries was needed to create the prototype and a lot of different techniques were tested and implemented during the project.. 5.1. Localhost server - Node.js. The first thing to be made was to create a local environment to test the models. Due to security reasons in the browser to view and load in models a local server is needed. This was created and set-up using the JavaScript library Node.js. A JSON file was created called package as well as a JavaScript file called index.js. The index file was used to set up a local port that could be reached by specifying the port in the browser after running the node package manager in the console using the command npm start.. 5.2. Creating the scene. When the localhost server was up and running, Three.js was imported locally. Thereafter 3D-models could be loaded in and viewed in the browser using different loaders in Three.js for different file-formats. The base scenery was created using a 3D-model that built up the floor and the two walls, henceforth called base model. This was made so that it was one file but three different objects. The models were made separately from each other to being able to tweak each element separately and position them easier. The baseboard was then added to the scene with a position depending on what type of baseboard it was. All models were created using the 3D-software from Autodesk called 3ds Max. Implementing a working 3D-view in Three.js was easy and straight forward, due to plenty of examples on how to set-up a 3D-view already exists for different scenes. It is mainly about declaring a scene object through a constructor, adding and specifying the camera that should be used and the renderer to use in the scene. As well as assigning appropriate values in the constructors that suits the needs of the visualization. Furthermore a lot of variables regarding the renderer and camera exists that can manually be set in the code. An implementation to rescale the camera based on the user resizing the window was implemented early on.. 16.

(28) 5.3. Lighting. Skybox The scene looked pretty boring whilst only loading in the base model and some baseboards, and a black background. To fix this a skybox was added and implemented using the cubemapping technique described in section 3.7. It was easy to make the cube-map in Three.js by setting the corresponding images to the sides of the cube.. Movement A script was found in the Three.js library called OrbitControls.js. By including and utilizing this script, the user can traverse the scene in different ways. The movement options includes zooming, panning and rotating the scene which are done with different mouse options, for example zooming in the scene is done using the scroll wheel.. Tracking performance To track the fps and memory usage during runtime of the visualization tool a script called stats.js was found and implemented. This script was easily utilized by declaring a variable and calling the constructor and then running a code in the update function. This would come in handy to see that the prototype was running smooth without any noticeable frame drops or memory issues.. 5.3. Lighting. The implementation of lights started with just adding a ambient lighting to the scene. However this became quite dull and was further developed to include other light sources as described in 3.4. Using Three.js it was easy to try and add different lights to the scene, by defining different positions and starting intensity values. Another great thing with adding lights in Three.js is that you can define helper functions for specific lights. These helper functions shows how the light is interacting with the scene, i.e where it starts and what it target. In Three.js there is a setting on the WebGLRenderer called physicallyCorrectLights. Which if set to true it effect how the light falls off as distance from light like in the real world. This option however only affects the point light and spot light. Physically realistic light values in terms of power and falloff was tested this way but was hard to get right as also described by Brent Burley [3]. It became apparent that it would be good to have the user manually being able to change the power/intensity values of the different lights during runtime. This also made the lighting more generalized in the sense that the user could tweak the lighting to his or her liking. This was achievable by adding a corresponding parameter for the different light source to the GUI.. 5.4. Baseboards. The implementation of the baseboards begun using small baseboards and placing them accordingly on the screen to not overlap and a function was written to space them correctly. However later on this was improved by changing the baseboard size in 3ds Max and then just scale if needed in Three.js for any given axis. This way it became less code and better performance since less models were needed to be drawn. The baseboard were imported to 3ds Max, then given a physical material from the Arnold renderer, unpacked UVW and a texture was added. An issue occurred due to Arnold utilizing the Specular-Glossiness workflow, while the MeshStandardMaterial in Three.js utilizes the Metalness-Roughness workflow. Furthermore 3ds Max does not support saving files in .glb format by default. This was solved by installing and utilizing a plug-in called Babylon.js to export the baseboard model to .glb format and to the Metalness-Roughness workflow. This 17.

(29) 5.5. PBR was done to preserve the physical materials and being able to use a corresponding .glb loader in Three.js later on.. 5.5. PBR. Three.js supports physical based materials called MeshStandardMaterial and MeshPhysicalMaterial. The former is used in this prototype since it was deemed good enough and is slightly faster than the latter. The biggest difference between the two is that MeshPhysicalMaterial is an extension to MeshStandardMaterial and therefore has a clear coat value, that allows for greater control of the reflectivity. Many different materials were tested, and the physical ones described looked much better than the non-physical ones. A Metallic-Roughness workflow was implemented into sliders in the GUI to control the parameters on the Base-scene and baseboards separately from each other. This was achievable by making group object and adding the corresponding children to each node in the group. Then it was just a matter of traversing the scene with the group name and assigning the value when the user changed the value in the update function. This way one slider controlled the roughness of the material, and another slider controlled the metalness that could be changed during runtime. The technical details and approach to PBR in Three.js is based on the paper made by Brent Burley [3]. The MeshStandardMaterial got plenty of properties to set. Amongst the properties are different maps such as the ones that were discussed in chapter 4. The next section will go into how the mapping was implemented for the prototype.. 5.6. Mapping and textures. As previously mentioned in section 4.4, the maps that would be implemented were the following: Environment map, Light map, AO map and Normal map. The environment map in Three.js takes in a texture cube which had to be created. An option was then made to be able to change the environment map during runtime on the baseboards. This was only implemented on the environment map but could be made for all the maps. Moreover the intensity of the different maps could be increased or decreased during runtime and this was implemented for all maps. The light map and AO map was implemented using a single texture. However in Three.js these maps requires a second set of UVWs to work properly, which is explained in the documentation. Once the UVWs were added and assigned to the correct object, a texture could be added and a starting intensity value assigned. The normal map was tested on a baseboard by adding a texture. In Three.js the normal map works by letting RGB values affect the surface normal for each pixel fragment and change the way the color is lit. An unexplained bug appeared while testing the normal map and artefacts appeared on the side of the baseboard, as can be seen in figure 5.1. These artefacts most likely appear because of how the baseboard model is made, and because of how the normals are aligned on the model. Although this is not confirmed, since the map was only tested for this one baseboard at the time. The main texture for the baseboard, floor and wallpaper was given by Valbo Trä, however later on a free texture for the floor was found and used. The different maps did unfortunately not have the appropriate textures that fit the scenery in a good way. Instead textures was used to just show the effect that the different maps could accomplish. This is something that could be improved on for the future.. 18.

(30) 5.7. GUI. Figure 5.1: Artefacts can be seen on the side of the baseboard when using a normal map, inside the red rectangle.. 5.7. GUI. To make the prototype more generalized and interactive for the user, a GUI was implemented. The GUI allows the user to change certain parameters regarding the scene during runtime. These parameters include: Lighting, Metallic-Roughness workflow for the base model as well as separately for the baseboard and mapping options. Also some pre-sets regarding the material and color of the baseboards was added. The GUI was created from the JavaScript library dat.gui.js. This was done by creating a variable to store the GUI and then adding folders and different parameters to each folder that stored different variables, such as color, intensity value and boolean to mention a few. The GUI made it easy to implement different interactive components, such as a checkbox, value slider and color-picker. Most of these were tested and some can be seen utilized in the final prototype. To avoid updating the GUI each frame and keep a good performance a onChange() function was called when a certain parameter in the GUI was changed, instead of updating a variable each frame regardless on interaction.. 5.8. Shadows. Three.js comes with different shadow models. The material used in the scene uses the Phong shading model, which is a bit more complex than that of the Gouraud model. Therefore it is a 19.

(31) 5.8. Shadows bit slower but instead gives more accurate results. Shadows in Three.js works in the way that you declare objects that you want to cast shadow and the ones that should receive shadows. A object can do both. There are different type of shadows that can be used depending on the look. This is set on the renderer and was only tested briefly and chosen depending on the visual appeal at the time. Light sources that can cast shadows can also set the size of the casting shadow and the detail of the shadow. Not to much time was put on shadows due to the scene not having that much objects that would need shadows. However it was explored to a little extent and could be useful for the future if the scene would involve more objects.. 20.

(32) 6. Result and discussion. In this chapter the results are presented and discussed. Firstly the resulting prototype and implemented methods are shown. Secondly the web-survey results are presented. Thirdly the survey is evaluated and lastly a general discussion is presented.. 6.1. Prototype. The final result of the visualization tool can be seen in figure 6.1 and in figure 6.2. It contains the scene, the GUI in the top right and the performance window in the top left. In terms of performance the prototype is running with a stable 60 fps on a average computer with the following specifications: CPU - Intel core i7: 3.07 GHz, GPU - GeForce GTX 1050 Ti, 16 GB RAM-memory with 1066 MHz. The GUI can be seen in figure 6.3, it is separated in accordion components that can be in a max or min mode. The first accordion contains the lighting options, the second contains options to the scene, the third contains options to the baseboards. The fourth contains mapping options for the baseboards. The lighting options are: • Hemispherical light intensity in a drop down menu, ranging from no light to intense lighting. • Ambient lighting in the scene, slider that ranges from zero to three. • Spot lighting same as ambient lighting. • Point lighting power from zero lumen to 110 000 lumen (1000W bulb). The scene options are: • Roughness of the base model, from zero to one in a slider. • Metalness of the base model, from zero to one in a slider. The baseboards options are: • Roughness of the baseboard, from zero to one in a slider. 21.

(33) 6.1. Prototype. Figure 6.1: Resulting prototype, showing the base model, a baseboard, the skybox and the two windows containing the GUI and performance.. Figure 6.2: Resulting prototype, showing a white baseboard in close-up. • Metalness of the baseboard, from zero to one in a slider. • Color of the spline in pre-sets. • Change material of the baseboard to pre-sets. • Turn on or off wireframe for the baseboards with a checker box. Mapping properties of the baseboards are: • Choose different environment map textures from list. • Intensity slider for the different mapping methods. The ranges are slightly different for the maps but all can be disabled. 22.

(34) 6.1. Prototype. Figure 6.3: GUI components The implemented shadows can be seen in figure 6.4 and the metallic-roughness workflow can be seen in figure 6.5.. Figure 6.4: Image showing off the shadows. Note that there are two light sources in the scene. One spotlight and one point light. The spotlight is casting the sharpest shadow and the point light the lesser shadow. The model floating in the middle of the room was added to show the shadows more clearly.. 23.

(35) 6.1. Prototype. (a) Roughness 0.1 and metalness 0.9. (b) Roughness 0.5 and metalness. (c) Roughness 0.9 and metalness 0.9. (d) Roughness 0.9 and metalness 0.1. Figure 6.5: Shows four images of different roughness and metalness values. The only parameters changing in the images are the metalness and roughness values. Note that both the scene and baseboard have the same roughness and metalness values here, but they can be different.. Mapping Methods This section shows the different maps effect on the baseboards, even though the textures are not optimal, they can still be used to get the idea of how they work. Firstly the AO map can be seen in figure 6.6. Secondly the environment map can be seen in figure 6.7. Lastly the light map can be seen in figure 6.8.. (a) No AO. (b) AO 0.5, With spotlight. (c) AO 1, With spotlight. (d) AO 1, No spotlight. Figure 6.6: Shows the AO effect implemented on the baseboards with different intensity.. 24.

(36) 6.2. Web-survey results. (a) No environment map. (b) Intensity 0.7. (c) Intensity 1.4. (d) Intensity 2.1. Figure 6.7: Shows the environment maps effect implemented on the baseboards with different intensity. The lighting in the scene is minimal to easier see the difference.. (a) No light map. (b) Intensity 2. (c) Intensity 5. (d) Intensity 5 and blue color. Figure 6.8: Shows the light map effect implemented on the baseboards with different intensity. In image d, the color of the baseboard is set to blue, this can be useful to easier see the effect on some of the methods used.. 6.2. Web-survey results. In order to measure the quality of the visual appeal and get some result and feedback on the prototype a web-survey was constructed. The survey results are split in two tables. The first table 6.1 contains the result to the questions where the user was asked to rate certain aspects of the prototype from one-five, a one represent very bad and a five very good. Whereas the second table 6.2 correspond to picking the best looking image out of a couple of alternatives. Google docs was used to make the survey and the survey was then posted to a Facebook group with knowledge of computer science. Note that 35 people answered the survey. Summarization of result from table 6.1: 25.

(37) 6.2. Web-survey results Testing aspect Shadows/Reflectivity Realistic Visual Appeal. 1 2 1 0. 2 11 1 2. 3 14 11 15. 4 7 19 14. 5 1 3 4. Median 3 4 4. Mean value 2,83 3,63 3,57. Table 6.1: Results from the users grading certain aspects of the prototype. The testing aspects can be seen in the first column, each testing aspect correlates to one question in the survey. Furthermore the first row represent the grading 1-5 and the median and mean value can be shown for the different areas. The numbers below the grading numbers in row 2-6 are how many users picked the grading for each testing aspect.. • Shadows and reflectivity was tested by a screen-shot from the prototype, which ended up getting a mean value of 2.83, which can be seen in row 2. Some users thought the shadows was to sharp and that the materials reflected to much lighting. • A screen-shot was also used to test how realistic the prototype was, it received the mean value 3.63 as can be seen in row 3. • The visual appeal of the prototype was tested by having the users rate how close the prototype image resembled a real world picture, resulting in the mean value 3.57, see row 4. Results from questions in the survey that asked the user to choose the best looking image out of a selection of images can be seen below in table 6.2. The alternatives for each testing area will be further explained here, each alternative, corresponds to one image in the survey. For the lighting sources at row 2 the different alternatives represent different lighting in the scene: Alt.1 is a point light solution with small ambient light; Alt.2 is a hemispherical and ambient lighting; Alt.3 all implemented light sources; Alt.4 is a spotlight solution; Alt.5 is a directional light and small ambient lighting. For realistic aspect the alternatives represent different metalness and roughness values, similar to the ones that can be seen in figure 6.5. Alt.1 corresponds to: (0r, 0m), Alt2: (0.3r 0.3m), Alt.3:(0.5r 0.1m), Alt.4: (0.9r 0.1m), where r stand for roughness value and m for metalness value for the baseboards. The environment mapping and AO mapping only had two alternatives, i.e two images for the user to compare, alternative 1 represents with mapping applied, and alternative 2 without the mapping applied. Testing areas Lighting sources Realistic Env. Mapping AO Mapping. Alt. 1 15 4 24 13. Alt. 2 2 0 11 22. Alt. 3 5 8 -. Alt. 4 9 23 -. Alt. 5 4 -. Winning Alt. Percent 42.9% 65.7% 68.6% 62.9%. Table 6.2: Results from the users picking the best looking image. Column one describes the testing areas and each testing area corresponds to a question in the survey. Column two to six at row one are the different images the user choose from in each testing area and the rows below are the users picking each alternative. Finally column seven shows the percentage of the most picked alternative for each testing area. Summarization of result from table 6.2: • The users thought that the lighting with the bulb in combination with a small ambient and hemispherical light was the best out of the tested lighting conditions. The spotlight was the second best lighting in conjunction with a small ambient light and hemispherical light, this can be seen in table 6.2 at row 2. 26.

(38) 6.3. Survey evaluation • The roughness and metalness values on the baseboard showed that 0.9 on roughness and 0.1 on metalness was the best values out of the tested, 65.7 percent of the users thought this which is seen in table 6.2 at row 3. • The mapping methods that were tested in the survey was environment map and AO map. The users liked the environment mapping as it received 68.6 percent, whereas they disliked the AO mapping receiving 37.1 percent, which can be seen in table 6.2 at row 4 and 5, respectively. Other comments on the prototype where the user could write in a field in the survey: • Some users thought the shadows was to sharp. • Reflectivity to high, i.e to glossy materials. • Larger images for the survey to easier see differences.. 6.3. Survey evaluation. The survey was overall well received and pointed out some important information and feedback regarding the different aspects of the prototype. One important aspect was that the shadows appeared to strong and sharp and that the reflection light was to intense. This can be seen by the 2.83 mean value in table 6.1, row 2. This did not come as a surprise, since not that much focus and time was spent on the shadows. Also the image in the survey reflected way much lighting to look natural. Looking back on the image a higher roughness value on the base model would be needed to counteract this, as well as reducing the sharpness of the shadows. On one hand it can be concluded that the users thought the prototype was visually realistic, looking at the mean value of 3.63. On the other hand it could have been even higher if the floor would be less glossy and less reflective, according to the feedback from the survey. The visual appeal of the prototype was well received with a mean value of 3.57. Some feedback was that the prototype image looked a bit to perfect in comparison to the real world photo. This is something that could be fixed by having a better AO map texture for example or to just dirty down the main texture for the model. Regardless the mean value is surprisingly good in consideration that the baseboards, wallpaper and floor were not entirely the same between the prototype and the comparing real world image. By testing different parameters on the baseboard it can be concluded that 0.9 on roughness and 0.1 metallic was the best out of the tested options, 65.7 percent of the users thought this. This corresponds to the real world because wood is not that glossy and absorbs a lot of lighting and is not metallic, as explained in section 3.6. Almost 43 percent of all users thought that the point light solution was the best of the tested lighting solutions. Also the point light solution and spotlight solution together made up almost 69 percent. These alternatives where the only ones using physical correct lighting, except for the solution that used all lighting sources. It makes sense that these are the lighting most well received, since they simulate the real world more accurately, according to the theory chapter and it also corresponds to Brent Burley in paper [3]. The conclusion could be drawn that physical correct lighting is preferable for this type of prototype, even though it might take some time changing intensity values. It would be interesting to look into the rectangular area light as described in section 3.4 as well as doing more combinations of lighting to evaluate on. The testing mapping methods in the survey environment mapping and AO mapping showed two extremely different results. The users liked the environment mapping, receiving 68.6 percent, but disliked the AO mapping, receiving 37.1 percent. This is interesting and could be because of the different textures used for the two. However it could also be because 27.

(39) 6.4. Discussion of the other parameters affecting the scene. The light map was not tested because of not being implemented at the time of constructing and sending out the survey. As well as the normal map was opted out due to the unexplained bug explained in section 5.6. The survey could have been improved in multiple ways. More often the parameters had to be exaggerated to really spot a difference between them in the web-survey, because of the images being so small. This could have been solved by simply increasing the images in the survey, but was not a feature in Google Docs, some users even suggested this in the survey. This could be an explanation why the AO mapping was received poorly, as well as not having the correct textures for the mapping.. 6.4. Discussion. The progression of the project was mostly on point with the Gantt scheme that was created at the start of the master thesis. Although there are many improvements that can be made to the prototype, especially within performance and adding additional features and parameters. The main goals and techniques, were tested and implemented on time. Three.js proved to be a good library to implement and create this type of prototype in conjunction with supplementary smaller libraries such as dat.gui.js and stats.js. Physical based rendering was utilized within Three.js and the models and materials as well as using physical correct lighting for the scene. The requirements and wishes from Valbo Trä were achieved, see section 1.3. No additional download or plug-in is needed for the user to use the tool as was mentioned by Kanish in paper [5]. It is a big library with plenty of documentation and should therefore be easy to develop further in the future. The techniques and methods used are aimed to be of a more general solution even though more testing would be required on different baseboards. The tool works for all common web-browsers. Performance wise, the prototype is running with a stable 60 fps on an average computer, however more testing would likely be needed, for example mobile devices. A problem that arose is that it can be hard to evaluate on some of the data due to people experiencing visual appeal and realistic appeal in different ways. One person might think that a image looks stunning, while another person might think it looks horrible. This could be an explanation to some of the mixed rating in table 6.1, therefore a big sample of data is preferable. Another problem comes with the fact that a lot of parameters in this prototype depends on each other. For example if the lighting in the scene changes so will the appearance of a certain mapping method change. Therefore some of the information from the survey might not be completely accurate. The survey only covered one texture map for the environment map but should be further tested with different texture maps, to see if similar results are acquired. Furthermore it proved to be difficult using maps in a generalized setting due to being precomputed in a scene that can be changed during runtime, the implementation of SSAO mentioned in section 2.2 would most likely be a solution to this problem. With that said the maps still add an additional layer to the visualization that can be tweaked for the model. The roughness and metalness values also affects the different maps, which should be remembered. When testing a parameter in the survey the rest of the scene remained identical, when in reality this could be both good and bad and thus do not represent the best testing conditions. A combination of the parameters with appropriate values is hard to figure out, and needs to be tested and viewed by multiple people to get right. Although having a GUI and being able to change parameters during runtime, could help this process. If good values on some parameters were found they could easily be set as default, i.e the initial value, which could be beneficial for future usage of the prototype and visualization. With additional time it would be interesting to do some interviews in person to get further feedback on the different aspects of the prototype and how to improve it further. Another benefit with doing interviews in person is that the prototype could be shown and changed. 28.

No results found