Dominik Luska is a 3D graphic artist working at the SCS Software for more than 4 years and has worked on almost all currently released map expansions. His job description consists of recording animations in motion capture, modelling, retopology of a high-resolution model, texturing and importing the model into the game. He works alongside Animator and Map Designers to create pedestrians, workers and other living characters that can be seen in our truck simulator games.
If you are interested in how are we create people and animal animations that can be found within Euro / American Truck Simulator, you've come to the right place. First and foremost, I need to emphasize that pedestrians and other characters don't play an important role as trucks and depots, not even close. However, they still play a role in our games, so we need to make sure they receive the appropriate care. At this moment, we have over 30 character models in our trucking titles. They are all characters you can see around our world. For example, you can see, security workers, police and customs officers, people taking photos of oversized cargo on their phones and more. To create a world full of life, we need to differentiate them from each other by their actions, their animations and by their looks. Some of them are universal, of course, so we use them between projects to save work and time. Besides those universal, we have specific characters for a more specific project, country or city. For each character, there are four textures, two for clothing and two for the body. There are also additional items (or as we call them props) which our characters can hold or use, these items are included in final animation files. The amount of data for these models and animations are not insignificant, and to help us not to become confused between textures and models, we're using an absolute classic - Total Commander. Every file has a naming convention in English language to make it accessible and understandable to everyone.
When we're importing finished data into the game, we need to save exported model or animation and also a source file for these animations od models; just in case we need to make some adjustment or change in the future. We have a whole folder structure specifically for animations, models, textures, and a skeleton. Data organization doesn't end by files, folders and their naming convention though. We can't forget about the flawless management of each model in definition files that is nearly as important as previously mentioned folder structure. To give you some basic introduction to definition files, every single model has to have the correct unique designation number and a brief name for Map Designers.
At the very beginning, we create a model according to a reference file. These references are sourced from our Researchers - a special department in our company who are responsible for searching up data, pictures and information; simply anything the rest of the company needs, saving a lot of time to Modellers, Animators and Map Designers. This first model is called "LOD 0". This abbreviation means Level of Detail and this system serves to toggle between lower and higher resolution models according to the range from the point of view. We have 4 LODs in our game for characters; in which the last of them serves for 100+ meters distances. LOD has to be thoroughly checked too for drastic changes, for example, we don't want to have legs or head disappearing within 10 meters of its viewpoint. Some animated models also have a "collision model", which stops players going through a character. Such a collision model are found on non-animated and static models too. And why don't we allow people to go through buildings and characters? Because our games have received an age rating of 3, which we'd like to keep. Thanks to it, anyone can play our games, even kids. [table][tr][td]
[/td] [td]
[/td][/tr][/table] When we're satisfied with the model and its LODs, we will move to the UV mapping, or rather unwrapping of a 3D model on a 2D plane, so the texture can be created. This process also takes some time mainly because of the more important parts of the model get a bigger space on the texture. That means UV unwrapping must be created as effectively as possible. For example, we mirror small parts of the model like caps, helmets and other props, which spares a precious space on the following texture for this model. After this, we create a texture for this model according to the references we have received. Every character gets a normal map. A normal map is a picture, which simulates a soft geometric structure, which is used to create an illusion of higher detail on a low-resolution model. Normal maps are used for folds, buttons, embroidery, pockets and similar details. [table][tr][td]
[/td] [td]
[/td][/tr][/table] After we're done with the textures and model, a more interesting and yet also a little bit frustrating process begins, recording character animations. To save time and energy on NOT doing it the most time and energy demanding way, we're using an improvised motion capture (MoCap), which we use to record rough animation foundations. I'm saying "rough" because amongst the disadvantages of this type of mocap is its accuracy on important bones, such as collarbones or wrists. We're not using full-fledged mocap, but a cheaper variant built on two Kinect sensors (2nd generation). These sensors use a depth camera, and since they're standing against each other, they "see" how a man or woman moves on the scene with some accuracy. This animation method has one advantage, you don't need any special clothes or markers, so anyone can get on scene and start recording. Thanks to this technology we can take anyone in the company and put him in front of the cameras to bring the character models to life. Before we start recording an animation, our mocap has to be prepared and calibrated. It is necessary to do a short test & calibration recording. This takes up to two hours because there may be problems on different levels, for example, the stations may encounter problems communicating with each other, operating system might be updating just in the right moment when we would like to use it and many other issues can appear. After successful calibration and recording session, we need to adjust these recorded animations "manually" in different programs. In this case, we commonly adjust noise and tremors, movements of bones in the wrong axes, or movements of the wrists that our mocap did not pick up. To understand the recording process fully in detail, we would need to create a separate article, so let's go to the final stage, importing data into our game. [tr][table][td]
[/td] [td]
[/td][/table][/tr] So our finished model with animation is now ready to be put into the game. To make the editor "see" our model, we need to define it correctly in a text file (definition file). In this file, both animated and unanimated models have a link to the model, to its LODs and potentially animation and collision. When we successfully define the model, we can finally see it in the editor. The editor is our own tool, in which Map Designers build the whole map and in which our Graphic designers are checking on their own models. If there's something wrong, we'll adjust the model or animation in 3D programs like Maya or Blender and re-export it. Since the definition is already there, we can just refresh the model in Editor to see changes right away. It's similar to refreshing a website on the web browser. Models and animations are created in Autodesk Maya, and textures in Adobe Photoshop. To create a normal map, we have to import the model to Marmoset Toolbag software, which serves for "baking" details from the high-resolution model to the low-resolution model. The whole process is more complicated than what I have written here, but then this blog would be twice as long (and maybe even more). I do hope that I've explained it well enough for you to have some insight into our work. And if you liked the article and you'd like to want more, let us know in comments - and don't be shy to say what exactly interests you.