Bachelor Thesis Digital Game Development Thesis no: TA-2013:06 05 2013

Improving Baked Textures as a Content Creator

Robin Karlsson

School of Computing Blekinge Institute of Technology SE-371 79 Karlskrona Sweden This thesis is submitted to the School of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Bachelor of Science in Digital Game Development. The thesis is equivalent to 10 weeks of full time studies.

Contact Information: Author(s): Robin Karlsson 910315-4416 E-mail: [email protected]

University advisor(s): Mr. Petar Jercic School of Computing

School of Computing Blekinge Institute of Technology Internet : www.bth.se/com SE-371 79 Karlskrona Phone : +46 455 38 50 00 Sweden Fax : +46 455 38 50 57 Abstract

Problems. This thesis will look at texture-baking for games and the various problems that surrounds it. Tex- ture baking is the process of transferring details from an often-times very dense high-polygonal details mesh to a lower detailed model that can be used in a game more ef- ficiently. The problems discussed include topics such as failed tangent basis synchronization and improving bakes by using methods such as cages, smoothing groups splits, etc. Motivation. The reason for looking at this is that it is an important topic in content creation for modern games. Yet people are still struggling with how to get normalmaps that are interpreted correctly in their game engine of choice and how to get clean bakes. Solution. The results are a few different methods for im- proving baked textures (such as proxy meshes and cages, etc.) and establishing a pipeline with tangent synchroniza- tion via Handplane. The practical results are in the end presented by some comparison images with models that do and does not use the techniques discussed in this work. The pipeline created in the thesis has the potential to improve the generation of baked textures in a way so that they will render better in real-time applications. Methodology. The results were established by basing it upon baking experiences regarding baking and texturing models for real-time applications. The experiments were set up so that the author would revisit older, somewhat complex models and try to improve their baking. There were also a comparison of applications that were compared by trying to generate noise-less ambient occlusion textures and comparing results such as render time and quality.

Keywords: Texture-baking, normalmaps, pipeline

i Contents

Abstract i

1 Introduction 1 1.1 Chapter Outline ...... 1 1.2 Background ...... 3 1.2.1 Real-time Rendering ...... 3 1.2.2 Texture Baking ...... 3 1.3 Research Questions ...... 5 1.3.1 Are there any differences worth mentioning between baking applications ...... 5 1.3.2 What methods are the to improve baked results? . . . . . 5 1.3.3 How can the baking pipeline be improved upon ...... 5 1.4 Purpose ...... 6

2 Production and Methods 7 2.1 Methodology ...... 7 2.1.1 Testmodels ...... 7 2.1.2 Testing ...... 7 2.2 Common Baked Textures ...... 9 2.2.1 Normal Maps ...... 9 2.2.2 Ambient Occlusion ...... 10 2.2.3 Displacement ...... 10 2.2.4 Light/shadow ...... 11 2.3 State of the Art of Texture Baking ...... 13 2.3.1 Blender ...... 13 2.3.2 Maya/Mental Ray ...... 14 2.3.3 xNormal ...... 14 2.3.4 ZBrush ...... 14 2.3.5 Comparison ...... 16

3 Results and Conclusions 17 3.1 Improving Baked Textures ...... 17 3.1.1 Smoothing-groups/edge-splits ...... 17 3.1.2 UV-seams and layout ...... 18

ii 3.1.3 Cages ...... 19 3.1.4 Support geometry ...... 20 3.1.5 Triangulation ...... 20 3.1.6 Exploding ...... 20 3.1.7 Unified meshes ...... 21 3.2 Diversified Baking Pipeline ...... 22 3.2.1 Pipeline ...... 23 3.3 Improving the Content Creation Workflow ...... 26 3.3.1 Standardized Tangents and Normal map Interpretation . . 26 3.3.2 Custom Tangent Basis ...... 26 3.3.3 Object Space Normal maps ...... 26 3.3.4 Image Masks ...... 27 3.4 Model Results ...... 29 3.4.1 Ball Mask ...... 29 3.4.2 Clock ...... 29 3.5 Discussion ...... 31 3.5.1 Pipeline Strengths ...... 31 3.5.2 Testing models ...... 31 3.6 Conclusions ...... 32 3.7 Future Work ...... 33 3.7.1 Tiling Textures ...... 33 3.7.2 Lightmap Baking ...... 33 3.7.3 2D Baking ...... 33

4 References 34

A Appendix 35 A.1 Word List ...... 35

iii List of Figures

2.1 Showcase of ambient occlusion: Clock A is without, Clock B is with AO...... 11 2.2 ZBrush detail transer: highpoly (A), lowpoly (B), reprojected high- poly (C) ...... 15 2.3 Table of the different rendertimes for ambient occlusion in the dif- ferent applications ...... 16

3.1 Demonstration of the difference normal splits make: texture A is without edge-splitting and texture B is with...... 18 3.2 Showcase of how important cages or support geometry can be. A is the original mesh (without anything extra to control the baking), mesh B have some support loops along the top and mesh C uses a cage to control the ray-casting...... 19 3.3 Demonstration of the difference of using exploded (A), split but unexploded (B) and unified topology (C) for the intersection of a cylinder with a cube. Wireframe model provided for clarity. . . . 21 3.4 Demonstration of unsynchronized (b) and synchronized (c) tan- gents space normal maps rendered in the Unity game engine. Only the normal maps are different. Highpoly model (A) is shown for clarity ...... 22 3.5 An example of a color-mask texture ...... 27 3.6 UDK render of two ballmasks with before (A) and after (B) com- parisons ...... 29 3.7 UDK render of two clocks with before (A) and after (B) comparisons 30

iv Chapter 1 Introduction

This thesis will discuss baking textures for realtime models using the content creation pipeline and discuss the problems surrounding this. To bake textures mean that one project details such as the normals and/or ambient occlusion (and other texture maps often based on the geometry) that a highpoly model contains. This baking is an offline rendering which means that it will not be done in real- time and only during the creation of the model. The subject were chosen because it is a very important part of the digital content creation process and there are still some problems surrounding it, most importantly tangent synchronization (which regards how normal maps are inter- preted) and problems surrounding making clean bakes for their models. To make a clean bake means that you manage to generate your baked textures without any artefacts, such as missed geometry along the smoothing group splits and/or asynchronous tangent bases. The latter meaning that the normal map is interpreted differently in the baking and rendering applications.

A thesaurus is included in the appendix that should include explanations for most of the terms used in this thesis. However the terms will be explained as they are brought up as well.

1.1 Chapter Outline

Chapter 1 will start out talking about what texture baking is and some of the problems surrounding it. It will then go on to describe the questions that this thesis hope to resolve.

Chapter 2 will then go on to describe the methodology behind the research and talk briefly about some popular textures to bake. Lastly there will be a look at some of the more popular baking applications as to see if there is a need for being able to freely choose baking application/applications.

Chapter 3 will finally attempt to answer the research questions posed earlier by talking about methods to improve baked textures and a pipeline that is a bit

1 Chapter 1. Introduction 2 more open regarding choice of baking applications. The thesis will then finish by showing the resulting models and some concluding thoughts and reflections.

Chapter 4 will contain the references for the thesis. Chapter 1. Introduction 3

1.2 Background

1.2.1 Real-time Rendering Real-time rendering is concerned with making images rapidly on the computer. It is the most highly interactive area of computer graphics. An image appears on the screen, the viewer acts or reacts, and this feedback affects what is generated next. This cycle of reaction and rendering happens at a rapid enough rate that the viewer does not see individual images, but rather becomes immersed in a dynamic process. (Akenine-Moller T. et. al 2012)

In short, real-time rendering today consists of sending data (geometry and textures) to the graphics card (GPU) where it will use that data to later render the images in very fast succession (preferably 30 renders per second or more). The need to render so quickly makes it necessary to use simplified rendering methods (such as simplified lighting methods), more optimized (lower polygon) models and smaller textures than you would otherwise need if the rendering were not occurring in real-time. The render method on the other side of the spectrum is called offline rendering. Offline rendering can handle millions of triangles with high-resolution textures, more complex lighting and advanced animation, etc. because it does not need to be nearly as fast as the real-time rendering. An offline render can take hours or even days to render a single frame. In short real-time rendering is used for interactive software or games (for example Mayas viewport or the game Crysis), while offline rendering is often used for movies (e.g Toy Story or Avatar). There is however a technique that can be used for making real-time rendering look a lot more like offline rendering, this technique is called texture baking.

1.2.2 Texture Baking The traditional algorithm for baking a normal map consists of project- ing points at the surface of a low-polygon mesh (the working model) in the direction of a high-polygon mesh (the reference model). (Nguyen H. 2007)

Texture baking is the process of capturing details from a high-detail model (highpoly) that is too detailed to be part of a game and project it down to a lower density game-ready model (lowpoly). The highpoly mesh can in many cases exceed millions of triangles which is way too much for a regular real-time model to be rendered along with everything else at a high frame rate with all the action going on in the background simultaneously. Chapter 1. Introduction 4

The main goal of simplification is to generate a low-polygon-count approximation that maintains the high fidelity of the original model. (Cohen J. et. al 1998)

The reason for baking textures is to capture details and properties that are too hard and/or time-consuming to handpaint and too demanding to be rendered in real-time. Texture baking has been around in AAA games since at least 2004 when the games The Chronicles of Riddick: Escape from Butcher Bay (developed by Starbreeze Studios and Tigon Studios, published by Vivendi Games) and Doom 3 (developed by id Software, published by Activision) came out. Chapter 1. Introduction 5

1.3 Research Questions

These are the research questions the thesis will focus on:

ˆ Are there any differences worth mentioning between baking applications?

ˆ What methods are the to improve baked results?

ˆ How can the baking pipeline be improved upon?

1.3.1 Are there any differences worth mentioning between baking applications The purpose behind the whole comparison is to see if there are any differences worth taking into consideration between the different baking applications that would make it beneficial to be able to choose freely which baking application to use. The applications that will be compared are Blender, Maya/Mental Ray, xNormal and ZBrush. Doing an objective comparison is not easy as most of the settings do not correspond perfectly with each other across the applications (e.g 100 samples for an ambient occlusion bake in xNormal will not match another ambient occlusion bake in Blender). The only objective method to compare these that could be identified was to compare the rendering times. Normal maps are in most cases very fast to render so instead ambient occlusion will be used as that is much slower.

1.3.2 What methods are the to improve baked results? Exploring the benefits of methods to improve baked maps (exploding models, skewed details, bevelled/sharp edges, UV-seams, etc.). This will be done to see how much better baked textures can turn out using relatively simple methods.

1.3.3 How can the baking pipeline be improved upon This section will discuss how to improve the texture-baking pipeline so it is not dependant on all artists being forced to use the same application (which might not be the best one) to get a working normal map. This is important because otherwise the normal maps will not look as good as they possibly could/should or one will be forced to use an application that might not be the best for the job to get the best normal maps. Chapter 1. Introduction 6

1.4 Purpose

The whole purpose behind this work is to make it easier for content creators (3D artists) to more easily render out better and cleaner (textures without problems such as missed geometry or otherwise) texture maps. This will be done by looking at the different applications and methods that can be used for rendering these maps as described in 1.3. Chapter 2 Production and Methods

2.1 Methodology

The methodology used for writing this thesis will mostly be based on my own work and experiences with texture baking. Some of the research will also be done with the help of both books/papers and internet articles. This thesis will look at baked textures for individual assets that will work under all lighting conditions (such as ambient occlusion, normals, etc.). Therefore this thesis will not look at baking direct lighting such as the light coming from the lights in the 3D environment at all.

2.1.1 Testmodels The model that was used in the thesis and described in Chapter 2.3 was purpose- fully chosen because it would be difficult as it contained both mechanical and soft parts. It was known beforehand that some packages would have a hard time using it. Had simpler models been utilized like a naked character or a flat model (e.g a brick wall) the results would have been better, but this was supposed to show how the applications dealt with something more difficult. Other models were also used to try the different techniques outlined in the the Chapter 3.1. These were mostly based on older models that were created by the author so that it would be easier to show clear improvements in the bakes.

2.1.2 Testing When comparing the different baking applications under Chapter 2.3 a pretty low output resolution of 1024*1024 pixels were chosen not because that is what is commonly used, but because it would be faster to render out. The test times are based on trying to bake noise-less ambient occlusion with the mentioned model and resolution without any anti-aliasing. Some of the baking applications will have built-in timers to count how long something took to render but in some of the cases there are none. In these cases a

7 Chapter 2. Production and Methods 8 stopwatch will be used and to counter human error the times will be will rounded off to the closest minute. Chapter 2. Production and Methods 9

2.2 Common Baked Textures

Here follows some explanation of what the different common textures are so that their usage will be motivated.

2.2.1 Normal Maps Normal maps can be used for simulating more surface detail on an object than it actually contains. Here is how they generally work:

So the key idea is that instead of using a texture to change a color component in the illumination equation, we access a texture to modify the surface normal. The geometric normal of the surface remains the same; we merely modify the normal used in the lighting equation. This operation has no physical equivalent; we perform changes on the surface normal, but the surface itself remains smooth in the geometric sense. Just as having a normal per vertex gives the illusion that the surface is smooth between polygons, modifying the normal per pixel changes the perception of the polygon surface itself, without modifying its geometry. (Akenine-Moller T. et al. 2012)

There are a few different kinds of normal maps: ˆ World/Object Space

ˆ Tangent Space

ˆ Camera Space

World/object space normal maps work by essentially replacing the normals of the lowpoly with the normals of the highpoly. The normals here are either referenced from the world or just the object itself. The upside with this method is that it does not matter how the lowpoly geometry shades as the normals of that will be discarded completely. A common misconception about this type of normal map is that it cannot be animated/transformed or mirrored, but this is false as long as this is accounted for in the shader.

Tangent space normal maps compare the normals of the highpoly and lowpoly and store the difference between these as referenced from the lowpolys normals orientation. The advantage of using this is that it can more easily be manipulated (e.g one can add smaller details directly on top of the baked map) and they can more easily be animated and mirrored. The downside of this method is that it is dependant on the lowpolys normals so they need to look reasonable before baking the normal map. With this method a single generic normal map can be used for Chapter 2. Production and Methods 10 multiple objects with different geometry (e.g a single normal map for both a flat and a curved brick wall) which cannot be done with an object space normal map.

Camera space normal maps are the least useful compared to the other ones as the normals here are referenced from a static camera. It is very limited as it will only look good seen from one angle and position.

This thesis will mostly cover tangent and object space normal maps as they are the most useful in the technology that is used today.

2.2.2 Ambient Occlusion Ambient occlusion is a lighting model that approximates the amount of light reaching a point on a diffuse surface based on its directly visible occluders. It gives perceptual clues of curvature and spatial proximity. (Bavoil L. et al. 2008)

Ambient occlusion is a technique used to simulate the effect of light not bounc- ing into crevices. This is mostly accomplished by casting rays in different direc- tions for a pixel either on a texture or in screen space and calculating how occluded the surface is. Usually the results will be improved by casting more rays but this is more performance heavy so it will take longer. Ambient Occlusion textures are most often black and white where the black represents the absence of light. This texture can most often be used to make a model look a lot more realistic and less ”flat” as can be seen in Figure 2.1.

In modern real-time applications such as games it is becoming increasingly common to see real-time ambient occlusion, but this is still a costly effect which does not replace baked ambient occlusion and instead only complements it.

2.2.3 Displacement Displacement mapping is in some ways similar to a normal map. The purpose of this texture is to add detail to a model, but as opposed to a normal map this actually does alter the geometry. Displacement mapping works by most often pushing the geometry either out- wards or inwards along the normals with the distance determined by a black and white value in texture. Vector displacement is becoming more popular as well which is still similar to a displacement map. The difference between vector and regular displacement maps is that a vector displacement can push the geometry in other directions than just the normals. This direction is described in 3 dimensions via the RGB channels, just like a normal map. Chapter 2. Production and Methods 11

Figure 2.1: Showcase of ambient occlusion: Clock A is without, Clock B is with AO.

Tessellation seems to become more and more important for game models, to make it work displacement maps are needed. When using tessellation in games a displacement map is not enough as most often a normal map is needed as well as it would otherwise be too expensive to re-calculate the normals in real-time every frame.

2.2.4 Light/shadow Many game-engines choose to use pre-baked lighting on both world geometry and custom meshes. Pre-baked lighting mean that you make a texture containing all the static light information which includes how much light something receives, light-color and shadows. The reason for doing this is because it will be faster to use than having it all dynamic and this also makes it possible to add expensive lighting and shadowing techniques that otherwise would be too expensive to use (global illumination for example). To use baked lighting on a model a second UV-unwrap with all UV-islands Chapter 2. Production and Methods 12 assigned unique UV-space is most often needed. It is also possible to use vertex colors for this as that would be cheaper, but in the process a lot of precision would be lost if the mesh is not very dense. The problem with using baked lighting is that it will not work well with dynamic objects as these cannot be baked because of their very nature as dynamic.

This thesis will however not cover baked lighting as it is more based around creating the individual assets that should be able to work under any lighting conditions. Chapter 2. Production and Methods 13

2.3 State of the Art of Texture Baking

This section will look at the differences between some of the popular baking applications to see if they are all mostly the same or if there is a real point in being able to choose more freely which application to use fi they do not all offer the same quality of baked textures.

2.3.1 Blender Blender is a powerful free and open-source generalist 3D application. The pro- gram is most often used by independent developers, as opposed to big AAA studios. With Blender all the steps of the content creation process (that is modelling, UV-mapping, baking, texturing, rigging, animation and rendering) can be per- formed. The application also includes its own built-in game-engine. The thing that makes Blender stand out most from the rest of the 3D appli- cations (aside from the price) are the very unique and hot-key driven interface. The application is also famous for having powerful UV-tools.

The baking process with Blender is very fast and streamlined. All that is needed is to select the highpoly and lowpoly models with an assigned image to bake to, select texture of choice that is desired to bake and hit the bake button. The baking here is very fast as it took just 4 minutes to bake a noiseless AO map. Blender is able to render out a lot of different maps. Most of Blenders baked maps are for material data which makes it very fast and easy to quickly replicate said materials for the lowpoly mesh via the textures instead of constant material values. All of Blenders baked textures can easily be baked to vertex paint/colors which can be very useful. One application for this could for example be to bake ambient occlusion on trees or buildings to make them seem more voluminous, but with regular textures this would not be possible because traditionally these types of models use repeating textures. The problem could be solved with using a second UV-set as well with a baked ambient occlusion map, but that would potentially be more costly performance-wise. Blender is very limited in the control the user have over the ray-casting and settings for the baking as there are no support for cages or anything else to control it, besides a few constant values. This can in some instances be very problematic, because if something goes wrong there is not much that can be done to correct it. Chapter 2. Production and Methods 14

2.3.2 Maya/Mental Ray Maya is the industry-leading 3D generalist package. It can be used to create most types of 3D content such as models for games, movies and commercials.

Mayas texture baking is good compared to other applications such as ZBrush. The package contains most of the maps that would be expected. However the pro- cess is a bit impractical, as it requires a full non-overlapping UV-layout for both the highpoly and lowpoly models. The reason for why it needs UV-coordinates for both meshes is because it bakes the data to an image texture mapped to the highpoly object and then projects that texture onto another model (the lowpoly). This workflow is suboptimal because it requires the highpoly model to be unwrapped as well while trying to limit the amount of stretching on that models unwrap as that could potentially result in stretching on the lowpoly as well. Maya is very slow at baking textures, as AO baking took 25 minutes for a single noiseless 1024*1024 texture. Even after these 25 minutes there were still a few bright pixel artifacts left but they did not seem to go away.

2.3.3 xNormal xNormal is a free application dedicated completely to baking textures. It is a simple program to use but still very powerful and flexible application. xNormal is very powerful in that there are a lot of different maps that can be output. All of the maps here are geometry based except for the base texture generation with a lot of control over the settings for these maps.

The baking process with xNormal is pretty easy to learn. All that is needed is choosing one or more lowpoly and highpoly models, what textures are desired to bake and then just hit ”Generate Maps”. So it is a very user-friendly program in that aspect as it does not get much easier than that. The programs settings for the bakes are highly customizable so if something do go wrong or does not look right it can easily be fixed. xNormal is about as fast as Blender as it could output an ambient occlusion map in just 4 minutes.

2.3.4 ZBrush ZBrush is a sculpting application often used to make extremely detailed 3D mod- els either from scratch or from some finished geometry imported from another 3D application. It is heavily used in both the game and movie content creation pipeline. One of the reasons for ZBrush’s popularity is that it can push several millions of triangles without struggling too much. Chapter 2. Production and Methods 15

With ZBrush most of the standard maps (displacement-, normal-, color- and ambient occlusion maps) can be output, but also cavity- and vector displacement maps. ZBrush’s baking process is a bit peculiar as it does not allow for a lowpoly and highpoly in the way other applications do. What ZBrush requires instead is that the lowpoly desired is imported as a basemesh and then the application automatically subdivides this and does its best to transfer the details from the old mesh to the new one. This transfer of details can potentially go wrong, especially if the new lowpoly that is input is heavily optimized or there are holes in the meshes (e.g for eyes). The ideal scenario for ZBrush baking would be that an already evenly subdivided and UV-unwrapped mesh is used for the the sculpting and then have that same model be used as the lowpoly with only the subdivision levels turned down. This solution can be motivated because it would sidestep the issue of transferring detail from one mesh to another (because the mesh is never changed). This transer of details will also change the shape of the lowpoly model so the model that end up baking to will in most cases not be the exact same as the one that was imported and this could result in problems with some minor stretching or skewing of the UV-layout.

Figure 2.2: ZBrush detail transer: highpoly (A), lowpoly (B), reprojected highpoly (C)

As can be seen in Figure 2.2 ZBrush can often have problems transferring details from a highpoly mesh to a lowpoly mesh. The problems occurred here because the different meshes have very different topology (the highpoly mesh has mostly even polygon distribution all over and the lowpoly only have geometry where it is deformed). The problem can be fixed by subdiving the highpoly model a lot more and then importing the lowpoly mesh. This works because ZBrush will treat it as a new basemesh (with the same level of detail) and it therefore tries to just transfer the details for that from the highpoly and keep the same number of levels. The downside of this however is that it would require a lot more memory. The problems would be minimized by using a simpler highpoly model or a more powerful computer (with more memory primarily) where you Chapter 2. Production and Methods 16 could then subdivide the highpoly further (which would result in the reprojected lowpoly being more detailed as well). If the model were all made inside of ZBrush as one single model (or subtool) with all the subdivisions intact there would have been less of an issue, but this thesis looked at using ZBrush as an external baker. This is what resulted in Figure 2.2.

The maps that were output from the application with the testmodel were not good enough but the rendering speed for them were fast. With ZBrush normal maps for flat models can be extracted by just dropping a normal map material on them and taking a viewport screenshot of it. This last approach might be the best for that kind of model as there is a minimum amount of things that can go wrong. The resulting normal- or heightmap could then be taken into a 2D baking application (such as nDo or Crazybump) to generate the rest of the textures you might want/need (such as ambient occlusion, cavity, curvature, etc.).

2.3.5 Comparison The most objective way to compare the models were found to be to compare the rendertimes for a noiseless AO texture with a resolution of 1024*1024. Other factors such as quality could be compared as well but they would be harder to rate objectively so they were ruled out. The results of this comparison can be seen in Figure 2.3.

Render time Blender 4 min Maya 25 min xNormal 4 min ZBrush 1 min

Figure 2.3: Table of the different rendertimes for ambient occlusion in the different applications Chapter 3 Results and Conclusions

3.1 Improving Baked Textures

This section will present a few different methods that can be used either together or alone and will in most cases result in better bakes.

3.1.1 Smoothing-groups/edge-splits Edge splits or smoothing groups are used to control how a mesh is shaded by breaking the normals of said mesh. This results in a hard edge where the normals are split. This was very important in the times before normal mapping as there was no other way to control how a whole surface would shade (there were bump- maps but those were most of the time used for adding smaller details). Today normal maps exist that gives us control of the shading of the surfaces in a major way. It is easy to think that if the model have unique normal mapping all over that the hard edges/smoothing-groups can be skipped but this is often not the case. If the tangents are completely synchronised with the renderer it would look right as long as it seen close up with full quality textures.

The problem is that if splits are not used along extreme angles ( 80+ degrees angles) gradients will appear in the normal map as can be seen on the left in Figure 3.1. The flatter a normal map looks, while preserving the baked details, the easier it will be to get a good result with it. As long as the texture does not get mip-mapped (downscaled for performance) it will work fine. However once the mip-mapping and compression starts the quality will drastically decrease. A common format for compressing textures is DDS, this works by dividing the texture into cells consisting of 4x4 pixels which are then interpolated between the two most extreme colors. If there are a lot gradients all over the normal map (like in Figure 3.1) it will be harder to represent those with the interpolation of only two colors only so this will possibly result in some faceting.

Contrary to popular belief it is the vertex count that is important in games when talking about geometry and not the amount of triangles. The disadvantage

17 Chapter 3. Results and Conclusions 18

Figure 3.1: Demonstration of the difference normal splits make: texture A is without edge-splitting and texture B is with. of using splits all over the model is that every time a split is added, an additional vertex is also added along every hard edge. These extra vertices can quickly add up for hard-surface models. In practice this means that as long as UV-seams or hard edges are not used along the edge it can just as cheaply be bevelled instead.

3.1.2 UV-seams and layout A UV-layout is a flat 2 dimensional representation of a 3 dimensional model that is most often used for projecting textures on a model. UV-seams are used for cutting up the model into different pieces so that it can later be laid out with as little stretching and wasted space as possible.

A good way to begin the UV-unwrapping process is to just add seams where the hard edges or smoothing groups already split the geometry (the reverse does not apply, all UV-seams does not need to be hard). UV-seams work much like smoothing groups in that they also split the geometry (instead of using different normals, these vertices will use different UV-coordinates). What this means is Chapter 3. Results and Conclusions 19 that UV and normal-splits cost as much in practice. But if a smoothing-group- /edge-split and UV-seams were used along the same edges it will not cost anything extra performance-wise. This is one of the reasons to use UV-seams everywhere hard edges are present. Reason number two is that if there is a smoothing group split in the middle of a UV-island and baked normal maps are used there will potentially be black lines along the split. The reason for this black edge showing up, is that the normals are so different from each other and yet they have to be interpreted between which might result in bad normals that cannot be lit as one would desire. In Figure 3.1 the results of placing UV-seams everywhere edge-splitting occurs can be seen (on the right side).

3.1.3 Cages Cages are models used to control the ray-casting directions on the lowpoly mesh. The reason for having to do this may be that there are splits in the geometry (which without cages would lead to the ray-casting rays to miss parts of the mesh) or to control the rays direction and length to minimize wavy lines in the bake. The easiest way to create a cage is to just scale up the regular lowpoly mesh along it’s normals until this new cage completely covers the highpoly model (if it does not there will be holes in the baked maps). Customized cages can help a lot to reduce wavyness especially on cylinders as can be seen on the right cylinder in Figure 3.2 compared to the cylinder to the left.

Figure 3.2: Showcase of how important cages or support geometry can be. A is the original mesh (without anything extra to control the baking), mesh B have some support loops along the top and mesh C uses a cage to control the ray-casting. Chapter 3. Results and Conclusions 20

The need to use cages can in many cases be diminished by adding support geometry, but that is not always justifiable as it could result in a mesh that is too dense to use.

3.1.4 Support geometry ”Support geometry” is geometry that is created just to improve or support the shading of the lowpoly model, in many cases they will not deform the mesh itself only the shading. The reasons for using such geometry can vary, but in most cases it would be because it will in many cases result in better ray-casting again as there will be less of a need for extreme interpolation. The effects of using support geometry can easily be seen in the middle render of Figure 3.2 where it improves the bake to the degree that there are no visible wavyness.

3.1.5 Triangulation When using tangent space normal maps (which are the most common ones) it is important that the model is identical in both the baking and rendering engines. The reason for this being so important is that tangent space normal maps adjusts the normals on the lowpoly and if the triangulation or other geometry is different between baker and render so will the normals be as well. An easy way to make sure the geometry stays the same is to simply trian- gulate it in the 3D application of choice. Preferably it would be possible to set this up so that geometry is automatically triangulated upon export, this can in many instances be scripted. This method would be optimal because it would not triangulate the working model which could otherwise result in further problems down the road.

3.1.6 Exploding To explode models means that the loose parts are moved away from each other so that they no longer intersect with each other. This can be useful to make sure that AO on models does not spill over or miss the actual intersections on the lowpoly. The problem is that the geometry is not dense enough to represent the intersection correctly or it simply does not match the highpoly close enough. If a part on a mechanical model (e.g the pump on a pump action shotgun) will be animated it will need to be explode/moved aside when baking. Otherwise if the model is not exploded it will get shadows where there really should be none when the part is animated.

If the mesh is modelled in loose parts it will most probably need to be exploded and then bake ambient occlusion from the lowpoly geometry for the intersecting parts. If the model with loose geometry does not get exploded problems can Chapter 3. Results and Conclusions 21

Figure 3.3: Demonstration of the difference of using exploded (A), split but unex- ploded (B) and unified topology (C) for the intersection of a cylinder with a cube. Wireframe model provided for clarity. potentially arise where the baker hits unwanted geometry for that part (as can be seen in the middle model of Figure 3.3 where the intersection point is messed up). One way to try to work around having to explode models too much is to instead try to make a more unified or ”watertight” lowpoly model.

3.1.7 Unified meshes Unified or ”watertight” modelling means that the models does not have any holes or intersections. This can in many cases be an easy way to produce better bakes (especially where two parts intersects). The reason for this looking better is that the ray-casting will be contiguous over the whole mesh. This means that there will be no breaks for the baking so it will smooth out intersections automatically so they do not look as lowpoly (see Figure 3.3 for reference). The downside of doing this is that this will in many instances requires more geometry to accurately represent the intersection between the different parts. Chapter 3. Results and Conclusions 22

3.2 Diversified Baking Pipeline

There is a point in being able to choose freely what baking application works best as there is a great deal of differences between them (speed, ease of use use, control, the kinds of maps, etc.) as has been shown in Chapter 2.3. The point is that until recently one could not choose freely which application to use for texture baking without potentially giving up perfectly synchronized normal maps. Synchronized normal maps mean that the calculations used to create the tan- gents for the model are the same in both the baking and rendering application. Failing to make synchronized normal maps means that that the normal map will not looks as good as it potentially could/should because of said differences. This is most apparent on models with a lot of gradients in the normal map as then the normal map is more responsible for how the final shading of the surface is represented, which is part of the reason for why one should strive to make normal maps that have as few large gradients as possible. So if one were to make a game with Unity for example the normal maps could not be baked with 3Ds Max as it does not support Unity’s tangent basis (out of the box) [see O’Hare J. (2012)]. Of course there are ways to improve the unsynchronized normal maps as outlined above in Chapter 3.1. With a synchronized pipeline there is less of a need to use these steps (they will still improve the textures) and the normal maps will look even better without locking yourself in with using a single baking application (see Figure 3.4 for a visual example of unsynchronized tangents).

Figure 3.4: Demonstration of unsynchronized (b) and synchronized (c) tangents space normal maps rendered in the Unity game engine. Only the normal maps are different. Highpoly model (A) is shown for clarity

The differences in the baking application’s tangent generation can be worked around by instead outputting an object space normal map as these are more consistent across the different applications. Some game engines support these directly but they are harder to use and control (e.g it is more difficult to overlay Chapter 3. Results and Conclusions 23 details on top of it), but there is no reason to stop here. These normal maps can then be converted into tangent space via the use of an application developed specially for this. This application is called Handplane, with this it is possible to select specifically what engine to target and use tangents that will match perfectly with that engine. Another perk with generating object space normal maps is that they com- pletely disregard the shading of the lowpoly and instead try to overwrite it com- pletely. What this means is that it does not matter how the lowpoly shades because the normal map will look the same with either more or less geometry (with potentially more or less skewing of details). This in turn results in the possibility of using slightly different geometry for the proxy model that will be used for baking the object space normal map. The proxy model is a model that is very similar to the regular lowpoly model that will later be used in the game engine. The proxy model can just be the lowpoly model with some extra support loops (extra loop-cuts along edges) or it can be as simple a the lowpoly model without hard edges (which is useful if the modelling application does not support smoothing-groups like for instance Blender). If one uses a proxy model there can sometimes be less of a need for a cage if the cage were only used to control ray-casting between split parts of the geometry. However if possible one should try to avoid changing the geometry too much (preferably at all) because if the model has to be changed later down the line (e.g parts of the UV-mapping needs to be re-done) the extra geometry will then need to be recreated which can be troublesome especially considering that someone else might need to fix it. In an optimal scenario there would be no need to use support geometry on the proxy model, but the option is there if it is needed.

A final advantage of using a proxy model is that this is just a regular model. This can be imported and used without any problems in any of the baking ap- plication, no matter how fundamental they are. This means that if one wanted to bake my geometry based maps in xNormal and the material based ones in Blender one would just need to send a single simple model between them. There would be no extra hassle because of the fact that Blender does not support cages.

3.2.1 Pipeline The actual content creation pipeline would not need to be changed a lot to ac- commodate for Handplane and the improvements that can bring. The regular pipeline often looks like this:

1. Model the lowpoly and highpoly meshes

2. Unwrap the lowpoly Chapter 3. Results and Conclusions 24

3. Possibly create a cage

4. Export lowpoly model

5. Bake to the lowpoly model

If one were to use Handplane the same pipeline could for the most part be followed but there might be less of a need for a cage as the proxy model can be fully smoothed without any hard edges. Another change that would be necessary would be to make sure that the UV-coordinates are non-overlapping (including mirroring and duplicates). So any and all overlapping UV-islands could be moved 1 unit outside of the UV-range. This UV-translation should really be performed even if Handplane is not used, but with Handplane it is more important). The reason behind doing this is that if it’s not done overlapping faces will rendered to twice (or more) which can cause problems. You move the overlapping faces outside 1 full unit as the texture will (with most shaders) just repeat outside the 0-1 range, which results in the texture looking exactly the same there. One could also adjust the proxy model if needed as mentioned before to get some better projections. It is also necessary to export the lowpoly model with all the smoothing-groups/hard edges intact. Other than that there will not be all that many differences in the pipeline. So in short this is what the pipeline would look like:

1. Model the lowpoly and highpoly meshes

2. Unwrap the lowpoly (no overlapping parts)

3. Make a proxy model and adjust it if needed

4. If needed create a cage model if the lowpoly is complex

5. Export proxy, lowpoly and eventual cage models

6. Bake to the proxy

7. Bring resulting object space normal map into Handplane

8. Rebake said normal map to a specific tangent space with the intact lowpoly model

There are some additional steps in this pipeline but the results are good enough to justify them. Taking these additional steps can take a bit longer, but most often it will not take more than a few minutes if the mesh is not very complex to begin with. In the worst case scenario you would just need to go in and add extra edge-loops along sharp edges to make the proxy meshes normals behave more like the highpolys. Chapter 3. Results and Conclusions 25

It would be hard to go back to not using Handplane as it would then be necessary to choose the baking application which are most closely synchronized with the tangent generation. This baking application might again not be the best one for the job in other respects besides the tangent synchronization. Chapter 3. Results and Conclusions 26

3.3 Improving the Content Creation Workflow

In this section some improvement to the content creation pipeline and workflow will be proposed. If these proposals were to be implemented it could make content creation a bit simpler and faster.

3.3.1 Standardized Tangents and Normal map Interpre- tation In a perfect world all of the bakers and render engines would use the same tangent basis and interpret normal maps in the same way. This would be desirable as there would be less of a dependency on extra applications such as Handplane for outputting normal maps that would work optimally. It would also make it easier to change game engine as there would need to be minimal changes in the pipeline. However there applications that can help with this part, so there will probably be no standardization coming as there are ways to work around said problem.

3.3.2 Custom Tangent Basis The best solution would be to have a standardized tangent basis, but this will probably not happen, so one could improve upon the situation in a different way. The second best solution would be to include custom tangent basis calculator functionality in the bakers. As stated above, there are work workarounds for syncing tangents, but with this kind of feature there would not be a need for any third-party programs. It would minimize the risk of something failing along the line as all baking could be done in a single application. The baking process would be sped up somewhat as well, as it would mean there would be one less program to export to. Pipelines with application such as Handplane do have some advantages of their own, but they should not be mandatory.

3.3.3 Object Space Normal maps Object space normal maps are less divergent than tangent space ones, as there is simply not as much that can go wrong. These normal maps simply use the highpolys normals (in object space) while completely disregarding the lowpolys normals. If unique assets (for instance a weapon or a unique prop) in a game were to use object space normal maps it would be a lot easier for the artist to bake the textures for it as not as much care need to go into the shading of the lowpoly model. Chapter 3. Results and Conclusions 27

A big disadvantage with using these normal maps would be that one cannot, out of the box, mirror them. It should be possible to fix this behaviour with a shader that takes the UV-coordinates into consideration (the mirrored parts could be moved outside the UV-range corresponding to how they are mirrored), this has however not been researched and/or verified to be true. Another smaller disadvantage is that it would be harder to overlay any photo-sourced detail (e.g a jeans pattern on pants) on top of it as well.

A common misconception is that models using object space normal maps can- not be animated and this is simply not true any more. To transform or deform the model one do need a special shader that takes these into account but it can be done (Skyrim for instance uses it for the characters).

Object space normal maps should not be used for every asset in a game, as they will mostly work on models that they are specifically baked for. This means that if one want to make a brickwall and use it on several different models (buildings in this case) it would not really work as the normals, for all one knows, could point in the opposite direction of the one on the bake. This is however not a problem as these repeating texture meant for reuse are most often baked to flat planes and the tangents of the models will not matter when baking the object.

3.3.4 Image Masks A color mask is an image containing several different flat colors that can be used for selecting where among other things different materials should be applied (see Figure 3.5 for an example). Many packages support this kind of functionality in some way or another.

Figure 3.5: An example of a color-mask texture Chapter 3. Results and Conclusions 28

xNormal base the mask upon which of the loaded model files the ray is hitting, while Blender and Maya bases it upon what material is applied. This behaviour could be improved by making it behave like an index buffer in real-time rendering in that every time it hits a new sub-mesh it assigns it a unique color. This would be an improvement because it would make it faster and easier to extract these kinds of masks, instead of either having to export every piece as a new model or assign a lot of different materials to the mesh. Improving upon this would simplify adding different material and painting in dirt along with wear and tear. Chapter 3. Results and Conclusions 29

3.4 Model Results

The methods described in this thesis were tested on a few different models. Most of the models were as earlier stated based on older projects created by the author. Here follows some renders and brief explanation for some of the models created for the thesis with the aforementioned methods. Most of the problematic models were just sent to the baking application with- out any regard for the methods mentioned in section 3.1. This is why the results look so bad.

3.4.1 Ball Mask

Figure 3.6: UDK render of two ballmasks with before (A) and after (B) comparisons

The model in Figure 3.6 were used to try baking on a very smooth (almost organic) model without many sharp edges. As can seen on the left side with the older model there are lighting issues because of unsynchronized normals which leads to problems with the mirroring (primarily seen on the gemstone), while there are a lot less such issues on the one to the right.

3.4.2 Clock This clock model in Figure 3.7 were used to see how well the baking would work on a more hardsurface model. Again on the old model (the left clock), that did not utilize any of the techniques written about, one can see that there are lighting problems due to unsynchronized tangents and several other problems where the Chapter 3. Results and Conclusions 30

Figure 3.7: UDK render of two clocks with before (A) and after (B) comparisons baking did not succeed such a skewed details, etc. Whereas the newer version does not display any of these problems, due to using improved baking methods. Chapter 3. Results and Conclusions 31

3.5 Discussion

3.5.1 Pipeline Strengths The strength of the pipeline laid out above are that it is both very cheap and flexible. It is cheap as it does not require much of an investment (Handplane only costs 50-150 dollars per seat depending on if a freelancer or a studio license is needed) as compared to other applications that freelancers/studios might be using. The other software packages needed (for modelling, UV-mapping and texture baking) can be obtained as cheaply as desired (Blender/xNormal are free and Maya/ZBrush are commercial). The pipeline is of course flexible in that it is still possible to use whatever programs that is wanted/needed and still get perfectly good normal maps. The pipeline can also speed up the creation of models somewhat as it might not be as necessary to create cages as often. This pipeline does not eliminate cages entirely but it eliminates the need for them to be used to ensure good hard edges. This will not make that big of a difference in the time it takes to go from start to finish with a model, but it is still an improvement.

3.5.2 Testing models The testing models utilized to motivate the techniques presented in Chapters 2.3, 3.1 and 3.2 could be criticized for not being the same in both the bad (older) and good bakes. However this can be motivated with the fact that to use some of the improvements the meshes would need new UV-coordinates, new sharp edges and everything else. If it was fine to change those, it should be fine to change the geometry as well. Some of the models are quite a bit more highpoly in the newer versions, but this was because they were updated to further match technological advancements as to be more representative of what would be expected today. Chapter 3. Results and Conclusions 32

3.6 Conclusions

There are a lot of tricks and methods that can be use to improve the baked textures. This conversely means that there is also a lot that can fail along the way.

In conclusion this thesis have answered the posed research questions and proven that:

ˆ There is a need for being able to choose what baking application to use as they all have their advantages and disadvantages. Some applications are slower and some can output more exotic maps than others. Depending on what is needed/wanted one can choose between baking applications with a workflow that have been created to support portability between baking applications (proxy meshes).

ˆ There are many different methods and workflows to guarantee better bakes. It has also been proven that these methods do have a big impact on the kind of quality that can be expected from the bake by showcasing models before and after their usage (as can be seen in Figures 3.6, 3.7 and ??).

ˆ There are pipelines that can be used to create baked normal maps that can be synchronized with most engines out there. This means that whatever baking application can be used for most of the engines on the market, while still getting good results.

I have learnt a lot while writing this thesis and hopefully the reader of it will feel the same. Chapter 3. Results and Conclusions 33

3.7 Future Work

Future work that could be done includes tiling textures, light baking and 2D based baking with normalmaps (with applications such as crazybump, knald and nDo2).

3.7.1 Tiling Textures Methods and applications used to create tiling textures that could be used for environments could be explored as these are often a bit different from the other model-specific textures as these need to be baked to a plane and often need to repeat seamlessly in one or more directions.

3.7.2 Lightmap Baking Future work could explore light baking (described in section 2.2.4) by looking at the different applications for baking these lights and shadows to the geometry. One could also look at comparing different methods in time versus quality to generate UV-coordinates that are usable for light-mapping.

3.7.3 2D Baking Comparisons between the different 2D applications could also be done to measure the quality versus regular highpoly bakes, speed and other qualities. Chapter 4 References

1. Nguyen H. (2007) GPU Gems 3, Addison-Wesley Professional

2. Cohen J., Marc O. and Manocha D. (1998) Appearance-Preserving Simpli- fication, Proceedings of the 25th annual conference on Computer graphics and interactive techniques, p. 115-122

3. Akenine-Moller T., Haines E. and Hoffman N. (2012), Real-time Rendering, Third Edition, A. K. Peters

4. Bavoil L., Sainz M., Dimitrov R. (2008) ’Image-space horizon-based ambient occlusion’, Proceeding Siggraph’08 ACM SIGGRAPH 2008 talks.

5. O’Hare, J. (2012) Unity3D Tangent Basis Calculator Plugin for xNormal, [Online], Available: http://www.farfarer.com/blog/2012/06/12/ unity3d- tangent-basis-plugin-xnormal/ [Accessed 21 April 2013]

34 Appendix A Appendix

A.1 Word List AAA High budget AO Ambient Occlusion Baking Projecting details from one model to a another Framerate/FPS How many frames/images you are rendering every second Highpoly Highly detailed 3D model that is too dense to be rendered in real-time Lowpoly Low detailed 3D model that can effectively be rendered in real-time Mesh 3D model consisting of polygons Mipmapping Downscaling of textures Offline Something that does not need to happen in real-time Poly Polygon, a face consisting of an unknown amount of triangles Quad Quad, a polygon consisting of two triangles Texture/map A flat image usually projected onto a 3D model Tri Triangle, the most basic building block of a mesh UDK Unreal Development Kit, a 3D game-engine developed by Epic Games Unity A 3D game-engine developed by Unity Technologies

35