Antti Veräjänkorva Art Is A Mess: Developing A Content Pipeline for A Video Game.
Metropolia University of Applied Sciences Master of Engineering Information Technology
Master’s Thesis 7 July 2020
PREFACE
I have a dream that I can export all art asset for a game with single button press. I have tried to achieve that a couple times already and never fully accomplished in this. This time I was even more committed to this goal than ever before. This time I was deter- mined to make the life of artists easier and do my very best. Priorities tend to change when a system is 70% done. Finding time to do the extra mile is difficult no matter how determined you are. Well to be brutally honest, still did not get the job 100% done, but I got closer than ever before!
I am truly honoured for all the help what other technical artists and programmers gave me while writing this thesis. I especially want to thank David Rhodes, who is a long- time friend and colleague, for his endless support. Thank you Jukka Larja and Kimmo Ala-Ojala for eye opening discussions. I would also like to thank my wife and daughter for giving me the time to write this thesis. Thank you, Hami Arabestani and Ubisoft Redlynx for giving me the chance to write this thesis based on our current project. Lastly thank you Antti Laiho for supervising this thesis and your honest feedback while working on it.
Espoo, 06.06.2020 Antti Veräjänkorva
Abstract
Author Antti Veräjänkorva Title Art is a mess: Developing A Content Pipeline for A Video Game
Number of Pages 47 pages + 3 appendices Date 7 Jul 2020
Degree Master of Engineering
Degree Programme Information Technology
Instructor(s) Hami Arabestani, Project Manager Antti Laiho, Senior Lecturer
The topic of this thesis was to research how to improve exporting process in a video game content pipeline and implement the improvements.
Games have numerous visual assets which all must be exported. Doing that manually every time is time consuming. Optimizing the export process can significantly save time and auto- mating the exporting process makes exporting easy and simple. The faster the exports, the more iterations can be done and number of iterations equals better quality games.
In order to create an export tool which work also in batches and is stable and automatic, the tool alone will not be enough. There must be a supporting system or a base system to pro- vide additional meta data for the asset so that the computer can autonomously execute the export process without human interaction.
The base system was written first in order create required meta data. The base system was written mostly with Python programming language and some smaller parts were written with Mel and Batch languages. All data was stored in JSON data format.
Using meta data provided by the base system, a fully automated export tool which does not require human interaction was written in order to export asset to the game. The export tool was written into two content creation applications, Blender and Maya. In both applications, export tools were written with Python programming language.
Creating the system included research, solution proposal and implementation of it. Research heavily relay on interviews since there is not much of descriptions of similar systems as written articles. However many companies do create similar system and best to find infor- mation about them was to ask from the people who made them. There was three interviews in total and interviews confirmed that companies do create similar systems and gave lot of implementation tips and tricks.
The base system and exporter completed during this project successfully improve the effi- ciency of the export process by nearly 6 000 %. The base system improved data quality and reduced the number of human made mistakes. Automated exporting also improved working quality for artists by removing flow breaking manual exporting.
Keywords Export assets, Plugin development, Automated Processing, Maya, Blender
Abstract
Antti Veräjänkorva Tekijä Taide on sotkuista: sisällöntuotannon automaatio videopelin Otsikko kehityksessä.
Sivumäärä 47 sivua + 3 liitettä Päivämäärä 22.8.2020
Tutkinto Master of Engineering
Tutkinto-ohjelma Information Technology
Ohjaajat Projektipäällikkö Hami Arabestani Lehtori Antti Laiho
Opinnäytetyön tarkoituksena oli tutkia, miten optimoida peliresurssien vientioperaatiota ja implementoida parannukset.
Peleissä on useita visuaalisia resursseja, jotka jokainen pitää viedä peliin erikseen. Tämän tekeminen käsin vie aikaa. Vientiprosessin optimointi ja automaatio voi nopeuttaa vientiprosessia ja tehdä siitä vaivattoman. Nopea vienti ja iteraatioiden suuri määrä parantaa pelin laatua.
Sellaisen vientityökalun luominen, joka toimii useille resursseille ja toimii vakaasti ja automaattisesti, vaatii tukijärjestelmän tai pohjajärjestelmän, joka antaa tarvittavaa lisätietoa vietävästä resurssista. Lisätiedon perusteella tietokone pystyy suorittamaan vientiprosessin täysin itsenäisesti ilman ihmisen apua.
Pohjajärjestelmä oli tehtävä ensin, jotta sen tuoma lisäinformaatio olisi ylipäätään luotavissa. Pohjajärjestelmä kirjoitettiin pääosin Python-ohjelmointikielellä, joskin osia siitä on kirjoitettu myös Mel- ja Batch-kielillä. Tiedon tallennukseen käytettiin JSON-dataformaattia.
Pohjajärjestelmän tarjoaman lisätiedon avulla luotiin täysin automaattinen vientityökalu, joka ei tarvitse ihmistä pystyäkseen viemään mallin peliin. Vientityökalu kirjoitettiin kahteen sisällöntuontuotanto-ohjelmistoon, Blenderiin ja Mayaan. Työkalu kirjoitettiin molemmissa ohjelmissa Python-ohjelmointikielellä.
Järjestelmän luominen vaati tutkimusta, ehdotuksen järjestelmästä ja sen implementoinnin. Tutkimus tehtiin pitkälti haastattelujen varassa, koska artikkeleja aiheesta oli hyvin hankala löytää. Kuitenkin yritykset usein luovat vastaavia järjestelmiä ja paras tapa saada niistä tietoa oli kysyä ihmisiltä, jotka ovat ne tehneet. Haastatteluja oli yhteensä kolme, ja niistä kävi ilmi, että muutkin yritykset luovat vastaavia järjestelmiä omiin projekteihinsa, ja lukuisia yksityiskohtia niiden toiminnasta.
Valmis pohjajärjestelmä ja vientityökalu onnistuneesti nopeutti vientiprosessia liki 6 000 %. Järjestelmä paransi resurssien laatua ja vähensi ihmisen tekemien virheiden määrää. Automaattinen vientiprosessi myös parantaa taiteilijoiden työpäivän mielekkyyttä, koska ei ole taidetyötä katkaisevaa monimutkaista vientiprosessia tehtävänä.
Avainsanat Resurssien vienti, laajennusten kehitys, prosessiautomaatio, Maya, Blender
Contents
Preface Abstract List of Abbreviations
1 Introduction 1
1.1 Art Techincal Guideline 2 1.2 About Ubisoft Redlynx 3 1.3 About Ubisoft 4 1.4 About this study 5
2 Research 6
2.1 Initial discussions with artists 6 2.1.1 Autodesk Maya 8 2.1.2 Blender 8 2.2 Content Pipeline Breakdown 8 2.2.1 Export mesh 10 2.2.2 Assign material 10 2.2.3 Create materials 10 2.2.4 Export maps 10 2.2.5 Import to Unity 10 2.2.6 UV Mapping 11 2.3 Asset Postprocessor 11 2.4 Breakdown the export step 11 2.5 Timing the export step 15 2.6 External interviews 16 2.6.1 Remedy 17 2.6.2 Housemarque 17 2.6.3 Frozenbyte 18 2.6.4 Custom exporter 19 2.6.5 Digital content creation tools 19 2.6.6 Version control 19 2.6.7 Programming language 20 2.7 Conferences 20 2.7.1 GDC 22 2.7.2 Ubisoft Developer Conference 23 2.8 Literature study 23
2.9 Other sources 23
3 Solution Proposal 24
3.1 Purpose 24 3.2 Redlynx DCC Tools 24 3.3 Application 24 3.4 Multiple Projects 25 3.5 Programming Languages 25 3.6 Version Control 26 3.7 Custom File Structure 26 3.8 Custom File Formats 26 3.9 Installing the Redlynx DCC Tools 27 3.10 Application Versions 28 3.11 Redlynx Object 28 3.12 Automated Export 28 3.13 Outsourcing 29
4 Solution Implementation 30
4.1 Redlynx DCC Tools 30 4.1.1 Access to the Redlynx DCC Tools 30 4.1.2 File structure 30 4.1.3 Start-up logic 32 4.1.4 Loading global projects 33 4.1.5 Loading local projects 34 4.1.6 Application specific start-up 34 4.2 Application specific code 35 4.2.1 Project specific start-up for Maya 35 4.2.2 Project specific start-up for Blender 35 4.3 Redlynx Object 35 4.3.1 Maya’s Redlynx Object 36 4.3.2 Blender’s Redlynx Object 36 4.4 Export Tool 37 4.4.1 Export Process with Maya 38 4.4.2 Exporting Process with Blender 38 4.5 Future Improvements 39
5 Results 41
5.1 Speed 42 5.2 Improved Data Quality 42
5.3 Logical File Locations 43 5.4 Simpler export process 43 5.5 User feedback 44
6 Conclusion 46
References
Appendices Appendix 1. Interview of David Rhodes Appendix 2. Interview of Jukka Larja Appendix 3. Interview of Kimmo Ala-Ojala
List of Abbreviations
MB Project name for the Redlynx project where the system in this thesis is de- veloped for.
FBX FilmBox file format. Commonly used to store 3D data.
KPI Key Performance Indicator.
1
1 Introduction
A video game usually uses audio-visual elements, which we later in this study call assets, to communicate to a player what is happening in the game. Communication can some- times be merely functional when the quality of the art asset is not as important as seen in figure 1.
Figure 1. Screen capture from a game Papers, Please [1]
In Papers, Please player is an immigration officer who decides if a person can get through the border or not. Each applicant’s background must be checked to know if this person comes with good intensions. The art style is simple since the game is made by a single person, but still the game has plenty of assets. This kind of small, but often inno- vative games are sometimes called Indie Games.
In Papers, Please art assets are much simpler than in games made by big companies such as Rockstar which tend to make AAA-titles. AAA-title refers to big games, made by hundreds, if not thousands, of developers. These kinds of games use visual assets to emerge the player into the game world such as Red Dead Redemption 2 in figure 2. Red Dead Redemption 2 can have as many assets in just one view as the whole Papers, Please game in total.
2
Figure 2. Screen capture from a game Red Dead Redemption 2 [2]
Regardless of production values between these two games, each of them has at least hundreds of visual assets. Big games like Red Dead Redemption 2 can have tens of thousands of assets. If a game is exceptionally small and has only 100 assets, it is pos- sible to keep it maintainable manually without any custom tools. When the project has have multiple artists, complex assets and thousands of them, it is simply not possible to maintain those assets without very specific rules how to make them, how to name them, where to store them or how to export them.
1.1 Art Techincal Guideline
In Ubisoft Redlynx these rules together are called Art Technical Guideline. Rules can be very detailed and steps in the rules need to be specific in order to keep data consistent.
Creating a single art asset often takes multiple steps such as:
• Concept art • Block out • Modelling • Texturing
3
• Baking • Export
These steps together form a content pipeline, sometimes referred to as art pipeline. Steps may change depending on artist and what kind of art asset artist is creating, but the general structure mostly remains. Rules how to execute each step are described in Art Technical Guideline. Art Technical Guideline help artists, especially new artists, to learn how to make assets for this specific game and they can reference it later if needed. When rules are written down, those who use them should follow them, but in real situa- tions people are poor at following a complex set of rules. Mistakes on data may cause problems in the game and fixing the issues take time and slow down the development work. To fix this some companies develop systems which automate the parts pf the pipe- line which do not require human being to be accomplished. This study focuses on the automation part of the content pipeline.
1.2 About Ubisoft Redlynx
This study is made for Ubisoft Redlynx, which is a Finnish game development company. The company is named after two brothers who found it and it uses a lynx as their logo as seen in figure 3.
Figure 3. Ubisoft Redlynx logo.
4
Redlynx is located in Helsinki, Finland and it has been part of Ubisoft Entertainment SA since 2011. Originally Redlynx was founded in 2000 and their main products were inter- active TV-games, later mobile Java-games and games for Nokia N-Gage. Nokia was their big customer which kept the company floating for many years as Nokia did the same thing for many other game companies as well in Finland back in early 2000. In 2009 Redlynx got their first big break with Trial for Xbox Live. Today Redlynx employs around 150 people and it is still best known from its Trials series. [9, s. 95]
1.3 About Ubisoft
Ubisoft is a multinational, originally French game development company. The company was founded 1986 by five brothers, The Guillemont family and Yves Guillemont is still the CEO of the company. At first the brothers helped their parents with their farming business, but business did not go well and they started to sell CDs to farmers and then also computers and games. They also wanted to make their own games and hired young developers. They located their development office in an old castle, seen in figure 4, in Brittany, France to attract developers with a promise of a unique working environment. Ubisoft had an office in Paris as well which was handling their mail-order business.
Figure 4. Le château de la Grée de Callac. Ubisoft’s first development office.
Keeping the Castle quickly became too complicated, so they had to give it away and move the office to Paris. One key developer could not afford to live in Paris and left but came back some months later to show his game prototype which became Rayman. It was Ubisoft’s breakthrough game. Now Ubisoft is all around the world with €1.732 billion of revenue. [10]
5
1.4 About this study
This study is specifically made for Redlynx’s upcoming mobile game, with a project name MB. The goal of this study is to create a content pipeline for the game which is automated in those parts where it makes the most sense. Aim is to keep art content manageable without creating too much process overhead for the artists.
When creating a prototype of a game artists and programmers are free to do whatever is required to get ideas working. This “mess” is difficult to control and scale to a full-sized game, which is why game developers tend to write software to manage assets in a more controlled fashion. Sometimes software means just one script or it can be a whole system of tools. This study first researches different methods, describes a solution proposal, which is then implemented and taken in use in a real production environment.
The reason for the study is to optimize art pipeline to save time, simplify art production, reduce errors, get consistent data and keep art assets maintainable.
The study will focus on the export step in the content pipeline, but also describe the underlaying system which was developed as part of this study.
6
2 Research
Information about similar system was difficult to find since companies do not tend to openly tell much of this area of development. Maybe it is not seen as an interesting topic for general public to publish articles about it. A few books have individual chapters about the subject, but in many cases, books were not very helpful. Most information could be gathered from interviewing gaming industry professionals who work on handling data. The authors personal 15 years of experience was also used to form a solution proposal.
2.1 Initial discussions with artists
It was crucial that work started by defining requirements and scope. This was the basis for the whole work.
Several discussions were held with intended user groups which included MB team’s art- ists at the time. Discussions were touching topics such as which operating system should be supported. This was clearly Windows 10 64bit. Discussions also showed the team would prefer 3dsMax (https://www.autodesk.com/products/3ds-max) as main applica- tion, but Blender (https://www.blender.org/) was almost as popular as a choice. Redlynx has an internal target to favor Blender where it is possible, to cut down the development costs. To honor the company’s target and artist who were in favor of Blender, Blender was chosen as the main application. For animation work and rigging work Maya was chosen since Ubisoft’s earlier evaluation showed that Maya was stronger in that area. The evaluation was done in Ubisoft’s Massive studio for Division 2 game which was fresh enough, so re-evaluation was not needed. For texturing Substance was a clear choice and for general image editing Photoshop was also an obvious choice.
Many of the artists were also helping with on other projects as well and had to share their time with MB project and other on-going projects.
Artists also described their usual workflow or art pipeline they tend to use when creating an asset seen in figure 5. This was not written down or defined in content pipeline, but these were the steps artists usually took to get a visual asset into the game.
7
Concept
Block-out
High poly
Low poly
UVs
Texturing
Export
Figure 5. Usual art pipeline in MB project.
Each step in “the content pipeline” was made by human. When optimizing content pipe- line or any process it is common that humans are the weakest link or most expensive in the long run. Process automation is also linked to employee happiness and productivity. [19]
People also make mistakes and it is not possible to make humans to be perfect. The number of mistakes people make depends on many things like experience, distractions, being tired, hungry, etc. People may also understand instructions differently. [23]
By looking at the steps it was clear that on all other steps a human is required, but export step could possibly be automated.
From this initial discussion initial goals and requirements for future automation were de- fined.
• Automated export step. • Support Windows. • Script support for Blender and Maya. • Support for multiple projects.
8
2.1.1 Autodesk Maya
Autodesk Maya is a general 3D-software commonly used in videogame development and movies. Maya was released 1998 by a company called Alias. The software have won academy award and was bought by Autodesk in 2005, which has continued devel- oping it. Maya still is a widely used software especially on animation and rigging.
More about Maya in their webpage https://www.autodesk.com/products/maya/
[11]
2.1.2 Blender
Blender is an open-source general 3D-software and it has been very successful in past years since it has a rich set of features and the software is completely free of charge. Development of Blender started back in 1995 as an in-house tool for animation studio NeoGeo. Development of Blender was discontinued 2002, but development continued with support of user community and Blender became open-source project. Today Blender is very popular and often used for general modelling.
More about Blender in their webpage https://www.blender.org/.
[12]
2.2 Content Pipeline Breakdown
To get better understand dependencies and relationships in the pipeline, the whole pipe- line was drawn out as a flow chart seen in figure 6. Drawing the current workflow out like this was inspired by Value Stream Mapping presentation by Gaelle Robert, Laura Matzlaff and Salomé Jugan in Ubisoft Montréal 2020.
9
Figure 6. Content pipeline graph for static mesh.
Even this simple static mesh creation pipeline is rather complicated and may include several people. The whole idea of breaking it down like this is to understand the pipeline and see where it could be optimized and automated.
Parts which clearly cannot be optimized are the parts where an artist is needed to draw or model something. These parts are indicated with dotted lines in figure 7.
Figure 7. Red dotted line show parts which cannot be optimized.
Parts which are possible to optimize.
• UV Mapping
• Export maps
• Assign material
• Export mesh
• Import to Unity
• Create materials
10
Some of these parts would be easier to automate than others and some parts take longer to do manually than others. Each part was reordered in the way that the level of their difficulty and possible time savings were taken into consideration.
2.2.1 Export mesh
Exporting mesh include several steps which are described in detail in chapter 2.3 Break- down the export step.
This part is time consuming and done frequently. Because of its complexity, it is a com- mon source for mistakes, and was seen as high priority part to automate as much as possible. This thesis focuses on optimizing this particular part of the pipeline.
2.2.2 Assign material
Material assignment in DCC is necessary to see textures in DCC. This is often done for artist to see textures while modelling so he or she can see if material change is needed. This step would be simple to automate, but since this is not critical it was decided to not automate this in scope of this thesis. It is part of future improvements.
2.2.3 Create materials
Unity automatically creates material for meshes when importing them, but default mate- rial Unity uses is not used in MB project. It would be possible to automate this with asset postprocessor, but a decision was made to not to automate it in scope of this thesis. It will be a part of future improvements. More about Asset Postprocessors in chapter 2.3 Asset Postprocessor.
2.2.4 Export maps
Export maps would be simple to automate Substance Painter already does some auto- mation and artists do not re-export maps as often as they re-export mesh data. It was decided not to automate this part. Also, there are no future plans to automate it.
2.2.5 Import to Unity
Importing to Unity is already automated, but Unity must be opened. Although It would be possible to automate this part, but it would not be very elegant to open Unity after each
11 export since Unity takes quite a while to open. Since it can already be quickly done and since it mostly is just a small annoyance to switch focus to Unity, it was decided not to automate this.
2.2.6 UV Mapping
UV mapping is a time-consuming step, but difficult to automate efficiently. Automation is used in cases where UV layout does not need to be optimized for best possible usage of texture space. Decided not to automate this since it is too difficult. However, there are number of automatic UV tools which are getting better and better such as Ministery of Flat by Eskil Steenberg. [25]
2.3 Asset Postprocessor
Unity has a feature called Asset Postprocessor which allows the user to hook into Unity’s asset loading process. It triggers several events in different phases of asset loading pro- cess where user can hook in and customize the loading process. [21]
2.4 Breakdown the export step
As seen in chapter 2.2 Content Pipeline Breakdown, the export step is the highest priority for automation so next logical step was to break down the export step. This was done by writing down each step an artist needs to take in order to export the assets. Required operations are seen in image 8.
12
Check that the scene is in art source folder
Select objects which are needed to be exported.
Combine objects to single mesh.
Center pivot point.
Flip mesh to match coord. system in Unity.
Apply transofrms
Scale the object.
Apply transform
Make up a file name.
Export
Figure 8. Usual export pipeline in MB project.
Sometimes artists did not actually follow this, but instead they skipped a step or two or added steps which were not needed. This causes potential stability issues and even broken data. Consistent data is important since if all data have the same structure it can most likely be handled in similar way and less possibilities to errors caused by bad data.
Described export pipeline is for static meshes from Blender, export steps for Maya are different since Maya is bit different from Blender. Also, different asset types have different requirements for exporting.
Step 1: Check that the scene is in art source folder.
To find art source files, files need to be organized. Art source folder structure should reflect run-time folder, to make it possible to find source file from run-time file later on.
13
Step 2: Select objects which are needed to be exported.
A scene may have multiple game assets in the same scene. When an asset is exported correct meshes from scene need to be selected.
Step 3: Combine objects to single mesh.
Combine all selected meshes to one single mesh. In game it is faster to handle less objects since there are less matrix calculations and single meshes are rendered in one draw call. Draw calls can be performance heavy when there is lot of them.
Step 4: Center pivot point.
Place the pivot point to the center of the object to make sure that pivot point is somewhat decently placed. Currently there is no way to define the location of the pivot point manu- ally, but this feature will be added as future improvement.
Step 5: Flip mesh to match coordinate system in Unity.
Coordinate system in Unity is different than in Blender. Most commonly Cartesian coor- dinate systems is either right-handed or left-handed. Unity uses the same coordinate system as Direct3D which is a left-handed coordinate system. Blender does not use ei- ther of them as seen in image 9. [22]
In order to keep mesh data “clean” mesh needs to be counter rotated so that vertex data is correct in target coordinate system. In case of Blender to Unity X-axis must be rotated 90 dergees and Z-axis must be inverted.
14
Figure 9. Blender and left-handed coordinate systems.
If mesh is exported without flipping the mesh data to match Unity’s coordinate system mesh will appear to be oriented incorrectly if identity transformation matrix is used.
Step 6: Apply transforms
In Blender transforms can be baked into the mesh data with operation called Apply trans- forms. Transforms should be baked otherwise transforms will carry over to Unity.
Step 7: Scale the object
Scale in Blender is different than Unity. Unity operates in meters, but Blender is in centi- metres. To make sure that objects are correct size in Unity objects must be scaled before exporting them.
Step 8: Apply transforms again
As before also scale needs to be baked into the mesh data.
Step 9: Make up a file name
File needs to be named and placed into proper location. Location should be logical so that anyone can find it. If a human does this step it tends to get messy.
15
Step 10: Export
The final step is exporting the FBX. FBX exporter has lot of settings and changing them results in different kind of data. It is important that a user specifically follow the rules when setting the settings to keep the data consistent.
2.5 Timing the export step
It was clear that exporting manually is a slower process than an automated one, but not exactly clear how much. Since time used for exporting would be a key performance indi- cator for the new system, the process was tracked and timed to get valid data of the current situation and it could be compared with future improvements when the new sys- tem is functional.
Tracking was made with regular timer on iPhone 11. An artist started the export process and a timer ran until the export was done. This was made three times and for each dif- ferent type of asset and application. From the data the fastest export was picked, and tracking showed that fastest manual export was 72.5 seconds when the artist knew all steps well.
One artist can make roughly 500 assets per year, meaning that an artist would make 500 exports. Usually each asset is also iterated before it is approved and seen as done, we can assume in average 5 iterations per asset. This means,
푐(푥, 푦) = 푥푦 푊ℎ푒푟푒 푥 𝑖푠 푛푢푚푏푒푟 표푓 푒푥푝표푟푡푠 푎푛푑 푦 𝑖푠 푐표푢푛푡 표푓 𝑖푡푒푟푎푡𝑖표푛푠 푐(500, 5) = 2500 푒푥푝표푟푡푠
Then if we calculate time for it, since we are actually interested in of time spent on ex- porting,
푡(푥, 푦, 푒) = 푐(푥, 푦) ∗ 푒 푊ℎ푒푟푒 푒 𝑖푠 푡𝑖푚푒 표푓 푠𝑖푛푔푙푒 푒푥푝표푟푡. 푡(500, 5, 72.5) = 181250 푠푒푐표푛푑푠 = 50.3 ℎ표푢푟푠 푓표푟 푒푥푝표푟푡𝑖푛푔
16
A project can also have more than one artist. Let us assume there are 5 artists.
푇(푥, 푦, 푒, 푎) = 푡(푥, 푦, 푒) ∗ 푎 푊ℎ푒푟푒 푎 𝑖푠 푛푢푚푏푒푟 표푓 푎푟푡𝑖푠푡푠. 푇(500, 5, 72.5, 5) = 252 ℎ표푢푟푠 = 10.5 푑푎푦푠 푓표푟 푒푥푝표푟푡𝑖푛푔 표푟 36 푤표푟푘𝑖푛푔 푑푎푦푠
This is also the simplest and fastest possible export and in an perfect situation. In reality it is not always a perfect situation. There are many steps in export pipeline and humans tend to forget to do one or they may try to cut corners because it is a repetitive and boring task. Mistakes will happen and those can be difficult to fix since exact steps taken are not always clear since it was a human who made them. Sometimes an artist can fix the problem easily and an error is fixed in 15 minutes, but sometimes they might struggle for hours and ask for help from technical art and now the issue is taking two persons’ time and will cost more and more of money and time. In this calculation a simple case was used, where artist can fix the issue in 15 minutes and he or she makes an error in every 5th export,
푢 푟(푢, 𝑖, 푚) = 푚 𝑖 푊ℎ푒푟푒 푢 𝑖푠 푡표푡푎푙 푛푢푚푏푒푟 표푓 푒푥푝표푟푡푠, 𝑖 𝑖푠 푓푟푒푞푢푒푛푐푦 표푓 푚𝑖푠푡푎푘푒푠 푎푠 푒푥푝표푟푡 푐표푢푛푡푠, 푚 𝑖푠 푚𝑖푛푢푡푒푠 푡표표푘 푡표 푓𝑖푥 푡ℎ푒 𝑖푠푠푢푒. 푟(2500,5,15) = 125 ℎ표푢푟푠 = 5.2 푑푎푦푠 And lastly total time for exporting with errors is, 푇(500, 5, 72.5, 5) + 푟(2500, 5, 15) = 15.7 푑푎푦푠 푓표푟 푒푥푝표푟푡𝑖푛푔 표푟 53.9 푤표푟푘𝑖푛푔 푑푎푦푠
Within the year the project uses nearly three working months just for exporting and that is still a generous estimation and for rather small-scale project.
2.6 External interviews
External interviews included three known game studios in Finland, Remedy, House- marque and Frozenbyte. Each company is known for successful console games. These companies were chosen since their games are quite big, meaning that their project would have a need to handle large number of assets.
17
2.6.1 Remedy
Remedy is known for their many big games and their most known games are Max Payne 1 and 2, but they have also developed games such as Alan Wake, Quantum Break and latest game Control seen in image 10. Remedy was founded 1995 which makes it an old game company in Finnish scale. Their first game was Death Rally which sold decently, but first Max Payne was their big break-through game. [9, s. 59]
Figure 10. Screen capture from game Control [3]
Remedy was chosen to be one information source since their games have high number of assets which needs to managed.
2.6.2 Housemarque
Housemarque is the oldest game company in Finland and known for several successful games. Housemarque was founded 1995 when Terramarque and Bloodhouse game companies merged and formed Hoursemarque. The first game was Alien Incident which was point&click adventure game. They also made space shooter The Reap before their first big success, Supreme Snowboarding. There have been rough years, but they have made other successful titles as well such as Alienation, Resogun, Matterfall seen in im- age 11 and Outland. [9, s. 27]
18
Figure 11. Screen capture from game Matterfall [4]
Housemarque have been making games longer than anyone in Finland so they are likely to have a solid asset management system.
2.6.3 Frozenbyte
Frozenbyte is younger player than the other two, but still an old timer in Finnish scene. Frozenbyte was founded 2001. They have also made several games and the first one was Shadowgrounds and then sequel, but Trine 1 was their break-through game. Trine now has four sequels and Trine series is still their shining star. Trine 4 is seen in image 12. [9, s. 94]
19
Figure 12. Screen capture from game Trine 4 [5]
Since Frozenbyte’s games are also bigger games, they must manage their assets some- how.
2.6.4 Custom exporter
Remedy and Housemarque both use a custom exporter for creating custom data which standard export tools do not support. In both cases they also created a custom file format to support the most specific data. Exporters were made for Maya and later to Houdini when companies took Houdini as part of their art pipeline.
Frozenbyte does not do any of this, they decided to use Blender’s built-in general pur- pose FBX exporter manually, without extending it.
2.6.5 Digital content creation tools
All companies used various DCC applications, but most commonly Maya and Houdini were used. Frozenbyte however relies strongly on Blender. Also Substance and other Adobe software were widely used in all the companies.
In Frozebyte Blender is used for modelling and animation.
In Remedy and Housemarque Maya is used for animation and rigging. For modelling various applications are used, but in previous years both companies have started to use Houdini more and more.
2.6.6 Version control
Housemarque uses Plastic, Remedy uses Perforce and Frozenbyte uses SVN. All have evaluated GIT, but currently it is not in use.
SVN is open source centralized version control system meaning that the file history is stored in centralized server. SVN is also the oldest of these three, it was originally devel- oped in 2000 to be an improved version of CVS. It gained huge popularity at the time but has been losing lot of users to newer systems. [8]
20
Perforce version control is a commercial and widely used in video game development. It has been popular since it is fast and simple to use. SVN is similar with Perforce, but Perforce comes with easy to use graphical interface as well as a command line version. [7]
GIT is also widely used and it is open source. Originally GIT was developed by Linus Torvals in 2005 for developing Linux kernel. GIT was developed to be faster than SVN since it would have all data in every client computer. This type of system is called dis- tributed version control. With small code files this works well, but with large art files dis- tributed systems struggle since history for large art files can be rather extensive. [8]
Plastic was initially published in 2006 so it is the youngest in this group. Like Perforce also Plastic is commercial, but it is billed annually and not based on used bytes like Perforce. Plastic is distributed or centralized based on how it is configured which makes it quite an interesting tool. It can also lock files, works well with big files and has a good graphical interface which are problems for GIT. [24]
2.6.7 Programming language
Frozenbyte does not do much to extending on their dcc applications. They relay on artists manually doing all the steps. Remedy and Housemarque utilize extending extensively and use Python as their main language to extensions. Also C++ are used for custom plugins.
Python is a widely used programming language as scripting language for applications. Many applications today use Python as their scripting language including 3dsMax, Maya, Blender and Houdini. Python was first published in 1991 with version 0.9.0 by Guido van Rossum. Python was intended to be a successor for ABC language. Python was moved from company to company until 2001 Python Software Foundation was formed. It’s open- source and also GPL-compatible. [13]
2.7 Conferences
In gaming industry there are lot of conferences. Many are for making business connec- tions, but there are also some which are dedicated to technology. People very openly share information which benefit others in their projects. In gaming industry this sharing
21 is seen honorable. For a game developer it is an honor if others value your ideas and implement those in their systems. Good talks can come out from almost any conference, but GDC is the biggest which is dedicated to technology and developer to developer information sharing. GDC is not the only one, there are many other conferences as well.
• PAX Showcases indie games for public. There is several PAX events around the world. https://east.paxsite.com/ • Pocket Gamer Connects Mobile game conference which focus on B2B connections. https://www.pgconnects.com/ • DICE Summit Located in Las Vegas, USA. Conference is focused for business managers. https://www.dicesummit.org/ • White Nights B2B event for making connections. Several events in different locations. https://wnconf.com/ • GDC Focus on development technologies and information sharing. Usually takes place in San Francisco, USA. https://gdconf.com/ • Reboot Develop GDC equivalent, but smaller and located in breathtakingly beautiful Dubrovnik, Croatia. https://rebootdevelop.com/ • Everything Procedural Held in Breda University of Applied Sciences in Netherlands. It focuses creating procedural content and generation techniques. https://www.everythingprocedural.com/ • E3 Main gaming event for general public. It is biggest showcase event for big games. Usually held in Los Angles, USA. https://e3expo.com/
22
• FMX Focus on visual effects and animation on films. Event held in Stuttgart, Ger- many. https://fmx.de/home/ • Gamescom Europe’s E3. Much smaller and cheaper than actual E3. Held in Cologne, Ger- many. https://www.gamescom.global/home/ • Unite Unity’s own event which focus on new features and development for Unity. It have own events in America, Europe and Asia. https://unite.unity.com/ • Unreal Fest Similar even with Unite, but for Unreal engine. https://www.unrealengine.com/en-US/events/unreal-fest-europe-2020 • Ubisoft Developer Conference Ubisoft’s internal conference held in Montreal, Canada. Focus on information sharing between Ubisoft developers. • Many, many more.
[14]
2.7.1 GDC
David Lightbown talked about user experience of tools in GDC 2013. This talk had plenty of good points about mental -and conceptual models. [18]
Bioware’s Ross Patel had talk in GDC 2018 about learning existing content pipeline. Same methods were used in this thesis to study how artists worked before implementing new methods. [17]
Koray Hagen from Santa Monica Studio talks about God of War’s scene description problems and how they plan to fix them in future. Talk have lot of interesting points which were taken into consideration, but eventually not implemented in MB project. [15]
Links to these talks are listed in references.
23
2.7.2 Ubisoft Developer Conference
Gaelle Robert, Laura Metzlaff and Salomé Jugan had a talk about Value Stream Mapping in UDC 2020. Their method was an inspiration for drawing initial content pipeline as flowchart to understand it and its dependencies. [20]
2.8 Literature study
Most books used in this thesis were more about implementation details than higher level topics on how to approach data processing. Jason Gregory’s Game Engine Architecture (2009) book is a bit exceptional in this regard since it has interesting sections about Asset Pipeline design and version controls.
About dealing with specific implementation details books often referred were Maya Py- thon for Games and Film (2011) by Adam Mechtley and Ryan Trowbridge and Blender Scripting with Python (2019) by Isabel Lupiani. Both books played a crucial role to getting the implementation working.
2.9 Other sources
Moeen Sayed presented a technique to create snow in Houdini. This technique influ- enced to the decision to include SideFX Houdini into the project. Currently there are no actual tools support for Houdini and it is not in scope of this thesis. [16]
24
3 Solution Proposal
MB’s current vision of content creation, opinions and experience from colleagues and other professionals in other companies as well as my own professional knowledge have been taken in consideration in this proposal.
3.1 Purpose
Key performance indicator is time, which this system aims to reduce by removing manual clicks and reducing errors. In current art pipeline this means automating the export step as far as possible. Other steps may have room for improvements as well, but those are out the scope of this system for now. The focus is in exporting and getting this optimized.
3.2 Redlynx DCC Tools
A simple export tool would not be able to automate the process as much as possible. This is why other components are needed to be built-in before the export tool itself can be built. Later in this thesis these supporting components are called as Redlynx DCC Tools.
This thesis focuses mostly on components which together makes exporting possible in the way what it is described in this thesis.
3.3 Application
MB project wants to move towards Blender in content creation, since it is a free open source application which would mean lower development costs for the game. For ani- mation evaluation, which was done by Ubisoft’s Massive Studio in Malmö, it was found that Blender is limited, and recommendation is Autodesk Maya. Evaluation was done rather recently for Division 2 so using Blender for animation was not re-evaluated. Un- fortunately, evaluation document is Ubisoft’s internal document which contains classified information and therefor can not be shared in this context.
25
Also interviews with Remedy and Housemarque reveal that Maya is used as the main 3D-application for general 3D needs. Houdini is used at both companies for VFX work. Frozenbyte relay on Blender in most cases.
In personal experience from games which are launched, Maya have been used as the main 3D-application and also 3dsMax.
Considering all these points MB project will be using Blender for general modelling and Maya for animations. Since this tool system is developed for MB first it will need to sup- port Maya and Blender. If Redlynx DCC Tools is expanded to other projects other appli- cations may need to be supported.
3.4 Multiple Projects
Ubisoft has dozens of projects and already Redlynx has multiple projects and in multiple teams. This means that Redlynx DCC Tools needs to support multiple projects. For initial version there will not be further support for teams or specific users, but different projects can have different sets of tools. This will be part of future improvements.
Each project which is officially supported will be listed in 3D-application’s Redlynx menu. Project selection will be “global” selection so it will affect both Blender and Maya regard- less which software user made the selection.
3.5 Programming Languages
Programming language is Python since both Maya and Blender support Python by de- fault. This will enable an opportunity for a simple way to share code between the appli- cations. Code which is shared between application must be written in such a way that code does not have any application specific code.
Redlynx DCC Tools will not have a dedicated database server, but it will use JSON files to store information when needed.
26
In addition to Python code, there can be 3rd party application for some specific tasks, like converting images to another format or something similar.
3.6 Version Control
All tools are versioned with Perforce version control. Perforce has historically been used in Redlynx and it is also used in Remedy and Housemarque. The Issue with Perforce is their license model. Perforce costs by gigabytes used. This leads into a situation where we do not want to store very large files in Perforce depot. For large files network location is used which is backed up in a couple of days interval. Files in network drive are not versioned. This mostly affects Substance projects which can grow exceptionally large. As a rule of thumb, if file is over 1GB in size store it to network drive.
Redlynx Shared Tools are distributed via network drive. Since everyone has access to network it is a convenient location to share the tools which are not specific to any project. Project specific tools are stored with the project’s version control.
3.7 Custom File Structure
People tend to have widely different kind of file structures so Redlynx DCC Tools should not relay on fixed structures. In Redlynx Tools settings files are used to define important filepaths, but at least one of them is required to be in specific fixed location C:\Red- lynx\settings.json. This file defines where user’s Redlynx DCC Tools are. When DCC- application is opened it will generate a project menu which is done with Redlynx DCC Tools. When a project is selected, Redlynx DCC Tools will look for another settings file from the project files and this settings file defines the settings for the selected project. This way Redlynx DCC Tools can support any file structure and a project can be located anywhere in the client computer.
3.8 Custom File Formats
Most common file format used in Redlynx tools is JSON. JSON was chosen because Python has a built-in module to read JSON data, which is simpler to use than XML, which is also another generic and human-readable data format.
27
JSON comes from words JavaScript Object Notation which is JavaScript’s object serial- ization format. Developed 1999 for JavaScript ECMA-262, the format is simple, flexible and easy to read by humans. All that made the format widely popular and it has imple- mentations on several dozens of programming languages. [6]
3.9 Installing the Redlynx DCC Tools
Installing Redlynx DCC Tools is aiming to be simple. Installing script system should not be too difficult or it will be daunting task for new artists who may join to the project. This is why installation is done in batch script and the user only needs to run a batch file to get Redlynx DCC Tools installed. Flow of the process is seen in figure 13.
Figure 13. Install flow.
In network location where everyone can access Redlynx DCC Tools has a batch file which creates a C:\Redlynx folder and Redlynx DCC Tools into it. These files can be updated by running that batch file again. After running the batch file Redlynx DCC Tools are available, but DCC application will not know about it. Every user will need to write a small script file for their application which start Redlynx DCC Tools.
Startup script is just 2-3 lines of code. This part is something that is planned to improve in the future, but it will be left as a manual step for initial version.
28
3.10 Application Versions
Application versions can cause issues and despite efforts of trying to get synchronized updates on applications people still update their applications in different times. Tools are not always ready for a new version or new version may have parts which simply does not work yet. To make sure that tools always work there will be checks for this and only tools which are tested to work with that application version will be loaded. Otherwise a user get a warning about using unsupported version.
3.11 Redlynx Object
Redlynx object is a custom plugin which can define from the scene which objects from any scene are part of exportable assets. This is needed since scenes can contain objects which are not meant to be exported. These objects are there for intermediate steps, like for baking texture data.
Redlynx object would also define a type of the assets since different type of assets may require different export steps.
3.12 Automated Export
Since Redlynx Object defines the objects, no human is needed to do this. Exporting can be fully automated, and it can be done with multiple files or even all files in the project in batch process. Export will also automate file locations and file names. File name auto- mation always force certain type of file naming which is trackable back to source file. Export tool will always maintain the link between source and runtime files.
Automated export also forces a certain way of exporting. Each export is always done with exact same steps and therefor data will be more consistent. Errors are still possible but fixing them is easier since the export process is always known and can be executed step by step and see where it fails.
29
3.13 Outsourcing
The problem with custom tool systems is outsourcing. In order to get data exported to the game it has to be ran through custom tools. These tools must be installed to out- source partner’s computers as well if they are to export anything to the game. For this reason, it is important that people can work also without the tools since it might be too complicated to get an outsource partner to install your organization’s tools. This of course means that Redlynx will need to export the data, but since outsourced data will need to be verified and checked this will not be a big issue. Outsource partner will have detailed instructions about how scenes must be made so that they will fit into Redlynx DCC Tools. It will be possible to build automated step to create needed components and whatever Redlynx DCC Tools require to make outsourced data compatible.
30
4 Solution Implementation
As a part of the thesis proposed Redlynx DCC Tools was also written, implemented and taken into use in production environment. Work was done in steps, first Redlynx DCC Tools were written and then project specific implementations for Maya and Blender.
4.1 Redlynx DCC Tools
This is a collection of scripts which are meant to work with all applications which support Python. This code ideally does not contain any code which is specific for any application so any application can use it. This is not exactly the case, more about this in chapter 4.1.3 Start-up logic. The main purpose is to generate a list of projects which currently have custom tools. The secondary purpose is to act as utilities library and have low level functions like version control functions or math libraries, as well as all kinds of libraries which are not tied to any specific application.
4.1.1 Access to the Redlynx DCC Tools
When Redlynx DCC Tools are installed the system do not yet know which project user is planning to work with it or maybe the user work with multiple projects. Each project has their own version control systems and branches where project specific scripts and tools are stored, but Redlynx DCC Tools should work for all projects so it can not be stored under any specific project. Redlynx DCC Tools are placed it into Redlynx’s net- work drive. Network drives are backed up weekly and these codes do not update very often so it is a relatively safe option. Improving safety of this part will be more important when Redlynx DCC Tools is taken into use in other projects as well. When that time comes further improvements will be needed to handle studio needs.
4.1.2 File structure
Redlynx DCC Tools in network drive has the following structure.
• Data/ o Projects.json • Redlynx/ o Blender/ o Global/
31
o Maya/ • Update_dcctool.bat
Update_dcctools.bat is a Windows batch script (note that the system currently is not compatible with Mac or Linux) which is meant for installing and updating the tools. Batch script creates the C:\Redlynx folder which is the one of two hard requirements Redlynx DCC Tools have. Another requirement is Z drive mapping. Redlynx DCC Tools relay on that Z drive is mapped to Redlynx’s network location, which is part of standard computer setup in Redlynx. Batch script itself creates the Redlynx folder or clears it, if it exists, after a folder has been cleared the script copy files from Z drive to Redlynx folder. This way Redlynx DCC Tools makes sure that the folder is up to date and contains nothing but required files. Batch script logic is described in figured 14.
Figure 14. Update script logic.
Data folder has all settings and data Redlynx DCC Tools needs for things to work. Right now there is a single file projects.json, but this folder will fill up with all kinds of data files what Redlynx DCC Tools may need in future. Projects.json file has a list of all projects which currently have custom tools. It also defines which applications are supported. Ap- plications themselves can check against the supported applications list if these should attempt to load the tools or not.
32
Redlynx folder contains all the code, but actual code is inside of Blender, Maya and Global. Blender and Maya folders have start up scripts which generate project list menu in corresponding software and software specific utility functions. Global folder contains code which loads project list, logging, settings and some very basic functions which can be used regardless of the software.
4.1.3 Start-up logic
When DCC application is starting up it will look for a specific script file which will be executed if the script file is found. Each application works bit differently in this regard, but all applications an MB project has in production use will have a similar system. This allows the user to hook into the start-up sequence and load custom plugins and initialize data, etc. Redlynx DCC Tools uses it to load custom tools, but in case of MB project, there are multiple applications, so Redlynx DCC Tools needs to be told which application is being loaded.
Creating this start-up file is something what every user does by themselves. This could be an automated step, but it was scoped out from this version of Redlynx DCC Tools. The start-up script is very simple. It just loads another script with information of which application is about to open. This is only 2-3 lines of code, but just enough to tell Redlynx DCC Tools which start-up file to load and execute.
Listing 1 shows what a Maya start-up script looks like.
Listing 1. Maya start-up script. import sys sys.path.append(r"C:\Redlynx\DCCTools") import Redlynx.Startup as sta sta.Startup("Maya")
For Blender there is a similar script which calls same Redlynx.Startup.Startup() function with parameter “Blender”.
User created start-up file is only there to start the actual startup with a parameter which indicate the correct start-up routine in Redlynx DCC Tools. A start-up file in Redlynx DCC Tools is more complicated. It loads the current project settings if a current project is
33 found. If not then it loads only Redlynx DCC Tools part which for end-user looks as pro- ject selection menu. Project selection menu will always be under the Redlynx menu as shown in figure 15.
Figure 15. Redlynx Project Selection Menu in Maya. Please note that name of the project is blurred since project is unannounced and project name is classified information.
Redlynx menu may have menu options below the Projects menu. These are project spe- cific tools which are loaded only if the project is selected from Projects menu. In figure 6 project MB is selected which is indicated with bolded font.
4.1.4 Loading global projects
When an application is starting up, it will look like a start-up script (see. 4.1.3 Start-up logic). This script in turn runs Startup() function from Redlynx DCC Tools. The main pur- pose of the function is to load a list of projects. This is done in Redlynx.Global.Projects module. First the system loads “Redlynx\DCCTools\Data\projects.json”, which contains names of all projects and supported applications. Listing 2 shows what the content of the file looks like.
Listing 2. Example of Projects.json.
{ "Projects": [ { "Name": "MB", "ApplicationsWithToolSupport": [ "Maya", "Blender" ] },
34
{ "Name": "Southpark", "ApplicationsWithToolSupport": [ "Blender" ] } ] }
Redlynx DCC Tool reads this and creates Redlynx.Global.Project objects of all JSON objects in Projects array.
4.1.5 Loading local projects
Then Redlynx DCC Tools loads a list of projects which are locally in user’s computer. This list is a similar list with Projects.json, but it only lists projects locally on client com- puter. This list also include a path to the project settings and if the project is currently selected, project settings are loaded on a later stage.
4.1.6 Application specific start-up
So far this chapter has focused on what always happens regardless which DCC is started, but system also needs to handle application specific steps in order to create a menu bar to the application in question. Each supported application has their own start- up modules currently for Blender (Redlynx.Blender.Startup) and Maya (Red- lynx.Maya.Startup).
Both start-up scripts are very similar. They generate the menu with project list as shown in Figure 15. Also, they have a functionality to define the location of the project settings file, if settings file is not already defined. The same functionality also allow user to change a project at any time. Changing the project is important since tools which are later loaded are based on the selected project. Only one project can be selected at the same time. Project settings for a selected project is loaded and project specific startup module is imported since Redlynx DCC Tools now knows where project settings are located.
Finally, Redlynx DCC Tools calls startup.Run() function and at this point Redlynx DCC Tools has done its job and execution is handed over to the project specific code.
35
4.2 Application specific code
Apart from start-up, code in different applications can be very different since applications are used for different purposes. Also different projects have different tool needs.
4.2.1 Project specific start-up for Maya
The first thing that a start-up does is to check if Maya version is supported. Due to pos- sible differences between projects, an MB project will have only one Maya version which is supported at the time. If a user has some other Maya version any project specific tools will not load up.
If the version is all right, then plugins are loaded. After loading the plugins script paths are added. Then Maya will know where to find the scripts for that project. The only thing left is to generate the menu options for the tools there possible are in the project.
4.2.2 Project specific start-up for Blender
For Blender the start-up process is similar. First there is a check for Blender version. For Blender this is even more important than Maya. Blender may change a lot between ver- sions so it’s important to make sure that only one version is used by all artists. If the version is supported, then tools get loaded or registered as described in Blender terms.
Lastly menu is generated, as seen in figure 16.
Figure 16. Redlynx Project Selection Menu in Blender.
4.3 Redlynx Object
Both Maya and Blender have their versions of Redlynx Object. In Maya it’s a new node type, but Blender does not have a similar concept of nodes so additional data is added as custom property to the object.
36
4.3.1 Maya’s Redlynx Object
Maya’s Redlynx Object is a node which looks like the one in figure 17 when seen in Node Editor.
Figure 17. Maya’s Redlynx Object.
Each object which is a part of the game asset must be connected to the Redlynx Object. Redlynx Object has several connection slots which categorize the objects. The most important category is “Export Objects”. When a node is marked as Static Mesh, Exporter will look objects connected to Export Objects and use only those meshes to form an asset which goes into the game. Node can also be marked as Skinned Mesh; this is used when exporting characters or animations. Please note that this study focus on Static Meshes only.
A scene can have multiple nodes in case a user want to export multiple assets from the same scene.
4.3.2 Blender’s Redlynx Object
Redlynx Object in Blender is a custom property written as JSON object. The only prop- erty it has is Exportable boolean. Figure 18 shows how it looks in Blender’s inspector.
Figure 18. Blender’s Redlynx Object.
37
Blender’s exporter will look for objects with custom property RedlynxObject. It will fetch all children from that object and use them to form the asset for the game. There can be multiple Redlynx Object custom properties if the user wants to export multiple assets from same scene.
4.4 Export Tool
Again there are two versions of the tool, one for Maya and other for Blender. Blender version exports only static meshes, but Maya version also exports rigged objects and animations. Exporting can have multiple steps before mesh is ready for the game. Most steps are also different for Maya and Blender, but the main flow is the same. Figure 19 describes the export process flow.
Figure 19. High-level export process.
38
4.4.1 Export Process with Maya
Maya’s static mesh export is rather simple, but it’s not actually used independently. No static meshes are ever exported from Maya. Maya is used for animation work and rigging so Maya side exporter is developed to export those ones and not static meshes. Static meshes are still exported as part of rig export, but they are not exported independently. Maya’s export steps are seen in figure 20.
Get file path for game.
Get objects from export node.
Select objects.
Load FBX preset.
Make folder(s) for FBX file.
Export
Figure 20. Maya’s export steps.
Figure 20 shows the steps for static mesh export extracted from rig export. Steps are extracted from rig export since static meshes are made in Blender and Maya for anima- tions.
4.4.2 Exporting Process with Blender
In Blender exporting is a bit more complicated process, due to different scales and coor- dinate system between Unity and Blender.
39
Get file path for game.
Make folder(s) for FBX file.
Select children.
Merge objects.
Center pivot.
Flip mesh for Unity.
Export
Figure 21. Blender’s export steps.
Unlike Maya’s process in Blender there is a flip step. This flip is important or otherwise in Unity the identity transformation matrix will not show the mesh correctly. That is a problem since vertices in object space will not be oriented properly and that could be an issue in shaders, for example. Generally it is preferable to keep data properly oriented for the engine and keep all geometry consistent.
4.5 Future Improvements
There are a number of known limitations which were left away from first version, but those are recorded into the backlog for future improvements.
• Support for OSx.
• Better way to distribute Redlynx DCC Tools.
• Automate start-up script creation.
40
• Support for Houdini.
• Animation batch exporter.
• Several bugs, which are not listed here.
• Automate material creation in Unity.
• Automatic material assignments on DCC.
• Support for teams and users.
• Improve code security. Network location is not safe enough.
41
5 Results
The initial goal was to optimize the speed of the export process, reduce errors and keep data consistent. However, It is difficult to measure how many errors system might have reduced.
The actual end result of the export process is that the same mesh that a user has in Blender in format which Unity supports could be found in such fashion that data can be considered “clean”.
Figure 23. Mesh in Blender.
42
Figure 24. Mesh in Unity.
Clean mesh in this context means that when transformation matrix is set to identity matrix the mesh looks the same as in Blender.
5.1 Speed
At the beginning one export took in average 72.5 seconds. With export tool the average time is 1.2 seconds meaning that the new system is 5843% more efficient.
5.2 Improved Data Quality
Speed is an obvious improvement and easy to measure. The quality of the data is much harder to measure, but it is possible to understand how the data has improved. Visually a user will not notice any difference, but if transformation matrix from the object is com- pared to values after proper export steps, there is a clear difference. Figure 25 shows transformations of object in Unity when exported out from Blender without an export tool.
Figure 25. Object transform when exported from Blender.
Unity automatically tries to maintain visual appearance of the object by modifying its transformation matrix. This does not change the fact that vertices are “incorrect” in terms of Unity’s coordinate system and scale. When a user uses the export tool this transfor- mation issue is fixed by the flip and scale steps in the export pipeline as seen in figure 26.
43
Figure 26. Object transform when exported from Blender with the export tool.
Transformation is “clean” and there is no visual change on the object.
Export settings are also set by the code so the user cannot accidentally give wrong set- tings. This ensures that data is always consistent and if there is an issue it’s easier to fix if export settings are known.
Export steps are also written in code which is good for the artist since they do not need to do any of it manually. This speed up the export, but also helps if there is a problem, since the process can be retraced step by step to see where the problem is.
5.3 Logical File Locations
Since exporter generates file paths, it will be always logical. Also, a runtime file can al- ways be found based on the source file and vice versa. This is useful since a project might have multiple artists and artists may change and it can be difficult to find old source files if the current artist was not the person who originally made the asset.
Since runtime file locations are generated from source file, this automatically forces the same structure to the game side. This helps to keep game side assets in order.
5.4 Simpler export process
Before this simpler export process, an artist had to do several steps before mesh or meshes were ready to be exported as seen in figure 27.
44
Check that the scene is in art source folder
Select objects which are needed to be exported.
Combine objects to single mesh.
Center pivot point.
Flip mesh to match coord. system in Unity.
Apply transofrms
Scale the object.
Apply transform
Make up a file name.
Export
Figure 27. Same as figure 8, added here again just for convenience for the reader.
Now an artist needs to create Redlynx Object once per asset. When Redlynx Object is created exporting is just matter of clicking Export from Redlynx menu or the user can map the export command to keyboard shortcut if he or she wishes to do so. Redlynx Object does not need to be re-created if an asset is updated and re-exported, except when exporting the asset for the first time. Consequently, an artist will not need to do any other steps from the figure 24 except the last one.
5.5 User feedback
Artists using the system have been giving good feedback of the system and feel that it has been improving their efficiency and quality of working-life. When asked “Did the new system help you in anyway?” the answer was. “Yes. All automation is always great. Pre- viously I had to a lot of manual ape work, but now I only need to press a button and
45 things go where they should and with correct names, which saves time and prevent the loss of focus.” Said Jesse Peltomäki 3D Artist at Redlynx.
46
6 Conclusion
Since exporting of each visual asset as manual process too fragile and slow for produc- tion use, improvements had to be made. This thesis aimed at finding a solution to this problem.
Since there was a lack of written descriptions of similar systems, research was relaying on interviews. During the study it became clear that other companies have developed similar systems. The companies for this study were chosen because their staff were will- ing to provide and share further information on the topic. One company did decline the interview request, but in general all the companies were pleased to share their experi- ences.
Using the information gathered from the companies and keeping in mind MB project’s needs, a proposal of the future system was written and presented to the head of the project lead who authorized the development of it.
The system was written and taken into use within one month. Several bugs had to be fixed before the new system worked. It was bit unstable at first, but after several improve- ments system’s stability was increased, and the system was taken into production use. It was named to Redlynx DCC Tools and part of it is the Export tool.
The main goal at the beginning of this project work was to improve the speed of the export process. As mentioned in Chapter 5, the export tool is nearly 6000% more efficient which was an acceptable level. However, if a game would have exceptionally long ani- mations to export, some improvements would need to be done. Although currently the export process is not expected to have long cinematics, but if that changes then there are a number of optimizations which could be done.
As a result of this study, not only it did the speed of the export process improve, it also keeps data manageable and as a result, data quality is improved. Artists also like that exporting no longer breaks their flow. Exported file names are programmatically gener- ated so their location is always trackable from runtime to source and vice versa.
47
Redlynx DCC Tools have successfully increased asset production speed, but develop- ment still continues since several designed features were scoped out from the first ver- sion.
References
1. Papers, please. 2018. Internet-document. Lucas Pope.
2. Red Dead Redemption 2. 2018. Internet-document. Rockstar
3. Control. 2019. Internet-document. Remedy Entertainment.
4. Matterfall. 2017. Internet-document. Housemarque.
5. Trine 4. 2019. Internet-document. Frozenbyte.
6. JSON
7. Perforce < https://www.perforce.com/products/helix-core>. Accessed 12 May 2020.
8. Rab Rawson, 2020, Accessed 12 May 2020 https://biz30.timedoctor.com/git- mecurial-and-cvs-comparison-of-svn-software/
9. Pelien valtakunta, 2015, Elina Lappalainen.
10. Matt Bertz 2011, Internet-document
11. Alias 2003, Internet-document < https://web.ar- chive.org/web/20040410235608/http://www.alias.com/eng/about/his- tory/19901999.shtml#1998>. Accessed 14 May 2020.
12. Blender Foundation 2013, Internet-document
13. Python Software Foundation 2006, Internet-document
14. Gamsindustry.biz, Internet-document
15. Koray Hagen 2019, The Future of Scene Description, Internet-document < https://www.gdcvault.com/play/1026345/The-Future-of-Scene-Description>. Ac- cessed 16 May 2020.
16. Moeen Sayed 2018, Procedural Snow Gather, Internet-document < https://www.sidefx.com/tutorials/quick-tutorial-procedural-snow-gather/>. Ac- cessed 17 May 2020.
17. Ross Patel 2018, Learning an Established Content Creation Pipeline, Game Developer Conference, San Francisco, 2018. https://www.gdcvault.com/play/1025255/Technical-Artist-Bootcamp-Learning-an
18. David Lightbown 2013, The User Experience of Game Development Tools, Game Developer Conference, San Francisco, 2013. https://www.gdcvault.com/play/1019273/The-User-Experience-of-Game
19. Next Process 2020, Keeping Tech-Savy Employees Happy And Productive, In- ternet-Document
20. Gaelle Robert, Laura Matzlaff, Salomé Jugan 2020, Find the blind spots of your production with Value Stream Mapping, Ubisoft Developer Conference, Mont- réal 2020.
21. Unity 2019, AssetPostprocessor, Internet-Document
22. Direct3D 2018, Coordinate Systems, Internet-Document
23. Henriikka Ratilainen 2015, Miksi toistamme samaa virhettä?, Internet-Document
24. Plastic 2020, What is Plastic, Internet-Document
25. Eskil Steenberg, 2019, Internet-Document
Appendix 1 1 (2)
Interview with David Rhodes, Principal Technical Artist at Remedy Q: Which projects you have been worked at? A: I've worked on projects ranging from Academy Award-winning movies (The Golden Compass) to robotics (Sphero BB-8), but the majority of my career has been spent work- ing on AAA video games, such as: Star Wars: The Force Unleashed, Quantum Break, and the recently released Control.
Q: In your current and past work, what have been your area of responsibility? A: During my early career, I worked as a character rigging artist and I was responsible for preparing 3D models for animation, writing animation pipeline tools, and working with performance capture. In the last several years, I've begun to work more as a software developer and as a team lead, responsible for growing teams and mentoring others.
Q: In your personal experience which application has been most commonly used in pro- duction (name three)? A: Autodesk Maya is probably the most common digital content creation software in use at many studios, largely because of its animation tooling and pipeline extensibility. Per- force and Git are very popular source control software, which are critical for version- ing/backing up work during production. For programming, a good IDE, like Visual Studio or PyCharm is critical to write and debug code efficiently.
Q: If you have custom made tools, which programming language is most commonly used? A: C# and Python are the most common languages to write tools with in the computer graphics industry. Almost all major content creation software have Python support inte- grated, and it's one of the easiest programming languages to learn. C# is great because it has a wide variety of libraries available, is quite fast, but not as complex as C++. Unity and Microsoft XNA also helped push C# adoption for game development.
Q: Is there any other reason for that language other than software happens to support it? A: Ease of use in learning, readily available 3rd party libraries, community support, in- dustry adoption and saturation, simplicity and prototyping speed.
Q: If you have had custom made export tool. What was the reason to develop it?
Appendix 1 2 (2)
A: Games and CG pipelines almost always have some proprietary data serialization needs. In these cases, custom exporters are usually needed to convert data that off-the- shelf software generate to data that a game engine or editor can understand. Sometimes, though, these export tools are just written to simplify workflows or improve iteration times.
Q: Which file format you think is the best option to use today? A: Autodesk FBX is the current industry standard for game development, but it is slow and not open for extension. Pixar's USD and alembic are probably the most popular option for visual effects. In my professional opinion, game developers will slowly begin to adopt USD because it is open-source, can describe individual assets and large, com- plex scenes equally well, as well as support for custom data types/structures. It's also readily available for use in a large number of content creation software, which means content creation and scene construction could be highly portable and decoupled from game editors.
Appendix 2 1 (2)
Interview with Jukka Larja, Senior Programmer at Frozenbyte
Q: Which projects you have been worked at? A: I've worked on all Trine games since Trine 2. I officially work on engine side, but in practise I jump from project to project based on their needs.
Q: How long you have been at gaming industry? A: 2009, September. So roughly 10 years.
Q: Did you have a education for games? A: For games no. I have Master of Engineering from Information Technology. At school my focus was on content creations. Unfortunately, later at work I have noticed that I should have picked something more theoretical. Content creation would have been good if I would have made games by myself, but as a programmer in a team more theoretical focus at school would have been more useful.
Q: What is your area of responsibility in your current work? A: I don’t have very clearly defined borders of responsibility. For example in Trine 4, we had only two programmers who worked on console side and I was the other one. But when projects aren’t needing me then I will improve our own engine and general work- flows, like optimizing our asset import process.
Q: What DCC applications your artists are using? A: I’m not entirely sure their latest trend, but historically Maya have been used a lot. Now days many also uses Blender, but I believe that Maya is most used application.
Q: Do you have custom exporter for Maya or Blender? A: No. We simply use the default FBX exporter.
Q: Do you have your own engine? A: Yes.
Q: Do you use any other formats than FBX? A: Yes. Each FBX are “extracted” and we create custom formats for the engine. Artists use only FBX.
Appendix 2 2 (2)
Q: Do you have rules how to export files? A: Not so much. Each FBX file does come with meta data which include references to files.
Q: Do you a link between source file and runtime file? A: No, but each file should be mirrored to another repository, but there is no tool for it.
Q: Which version control you use? A: SVN. We have evaluated GIT, but it had issues with big files.
Q: Do you see that in 5 years there would some format which would replace FBX? A: I would say no. At least I haven’t heard of any.
Q: How do you make materials since you have own engine? A: No. Not really sure how artist really make the materials.
Appendix 2 1 (1)
Interview with Kimmo Ala-Ojala, Senior Technical Artist at Housemarque Q: What kind of experience you have with games? A: I have been at House for 15 years. Started technical artist work with Superdust HD with Mel. We used Maya at that time. Then Python support came to Maya and I studied that and now 2 years I switched to Houdini.
Q: What is the main motivation to make your own exporter? A: Before we had an issue that artist put files into wrong places. We also wanted to have a tool which can do totally automatic exporting and we wanted to do that in batches. We also had issues that assets might have had error and if human manually did the export it was really hard to figure out what steps were made. So we wanted to have more con- sistent data. Sometimes you also need to have a control to exports so that if there is some additional data which is need to be added to all assets. It would annoying if artists need to go through all files and some tiny thing and re-export manually again.
Q: Ever had an issue that people don’t use your tool? A: Yes!
Q: So you use Maya? A: Yes. In Alienation even level editor was Maya. Now we have been using also Houdini.
Q: What will be next DCC software? A: Houdini!
Q: Have you documented your character pipeline? A: No, no, no. Maybe, I don’t think so.
Q: Which version control? A: Plastic. We did have SVN and GIT, but we wanted to have more speed.