Trim Sheets, Tilemaps and Terrain: How We Remaster Game Maps
How to improve in-game environments without changing their layouts, while simultaneously increasing overall product performance.
In many games, the environments, which include levels and maps, take up more than half of the screen space. So, naturally, these should be eye-catching, expressive, and they should meet the graphic standards of your specific gaming platforms.
In 2020, we released a remastered version of War Robots, and reworking the maps and updating the art was the most time-consuming task. That’s because this wasn’t just about replacing all the map textures or merely arranging the lighting in a new way.
Remastering game maps involves the entire rendering pipeline rework, a change in the approach to texturing in general, and geometry mapping.
My name is Alexander Kolyada, and I’m a Senior 3D Artist at Pixonic, MY.GAMES. In this article, my colleague Aleksey Pastushkov and I will tell you how we remastered maps for War Robots.
What to start with: game design requirements
To start, we decided to take our four most atmospheric maps (with relatively few in-game assets): Canyon, Powerplant, Valley, and Moon. These choices were necessary for testing new technologies, and as soon as the pipeline was established, we would be able to update other more complex levels.
We were required to keep the same atmosphere, core game concept, general map layout and to maintain the dimensions of all the old colliders. In a nutshell, we needed to keep the gameplay as close as possible to its previous version. Player familiarity and attachment to old levels is an important consideration, and new solutions may cause some backlash.
On the technical side, we needed to significantly rework the geometry, increase the polygon count and the model complexity. That being said, updated graphics shouldn’t lead to a performance drop on older devices, but at the same time, they should meet the highest modern standards on powerful tablets with huge screens.
In other words, we needed to change everything without changing anything, and make the new environment look cool on all the latest devices, while also still working perfectly well on low-end devices.
Therefore, to avoid risk and unnecessary improvements, we decided to slightly update the outdated design of locations within the existing colliders. In order to achieve this, we needed new concepts for various kinds of buildings.
Concept art: shaping up the style of the updated game
One of the main tasks at the concept stage is to preserve the game location style and the familiar silhouettes of objects while creating something new and providing greater detail within the framework of the unchanged physical colliders. Since the style of War Robots is photorealism without any other stylization, we focused on bringing the scale and proportions of objects as close to their realistic counterparts as possible. Our intention was for players to get the feeling that they were really in control of a huge, four-story-tall combat robot.
Let’s look at the central building inside the Valley map. Below is the original concept, and its implementation in the “vanilla” version of War Robots:
And now, let’s take a look at the concept and 3D model of the same building in War Robots Remastered:
The new version has a lot of fine details which were put in place to emphasize the scale of the model. Some players had previously mentioned that, because of poor detailing, they didn’t really feel like they were at the controls of a giant robot, so in War Robots Remastered we set out to improve this.
Still, keep in mind that even on the latest devices, the updated War Robots has its limitations. So, for instance, instead of individual textures, we had to use limited texture arrays, which could lead to a shortage of materials used or an imbalance. Accordingly, even at the concept stage, we had to create a draft list of textures for the level geometry, determine their number, type, main color and many other aspects. Therefore, both concept artists and modelers formed a list of these textures, and then the former used it to develop the object image: the combination and frequency of materials, detailing, and their color distribution.
Faster, bigger, more powerful: changes in the technical pipeline
For a remaster you don’t simply create a beautiful new picture — it’s equally important not to end up with a drop in performance compared to your Legacy maps. In our case, this was achieved thanks to the work of our graphic programmers and technical artists, who provided us with modern, standard-compliant tools for creating environments.
Regarding the code, we rewrote almost the entire rendering pipeline (Scriptable Render Pipeline, SRP). So now, instead of classic material rendering (diffuse/normal/specular), we use modern, physically-accurate rendering — PBR (albedo/metallic/normal/smoothness). This allows us to more accurately display the physical properties of various materials.
In addition, we began to use a modern approach of tiles and trims instead of a large atlas of textures for the entire location. This allowed us to simplify the texturing of a large array of objects with the same type, and we were also able to save memory on mobile devices.
What are tiles and trims?
- A tilemap is a uniform texture that can be repeated N times both horizontally and vertically without any visible seams
- A trim sheet is the same as tile, but repeated in one direction: either horizontally or vertically
The primary texture limitation that comes from using low-end device memory is a maximum of two arrays with 16, 512x512px resolution textures for the main geometry of the level, which can and should be textured with tiles and trims. For the HD preset, we were able to use a resolution of 1024×1024 with more advanced compression algorithms, this led to almost no memory consumption increase, but in fact, the visual change on mobile device screens is insignificant.
We usually use one texture array per level geometry and per terrain, each employing its own shaders for specific tasks. For example, industrial objects don’t require such a smooth transition between textures as terrain. In general, any smooth blend is more difficult to render for GPUs, so we use the terrain shader only on natural objects.
As for polygon count, here we also took a step forward: now, for the HD preset, we have up to 500K triangles at our disposal, whereas before, we only had a maximum of 200–300K.
While we are on the subject of terrains…
Before we go any further, let’s consider a real, typical level breakdown. A typical War Robots game map consists of:
- Terrain. Usually, this is the main surface of the game location along which dynamic game objects move. The terrain is also the basis for arranging game statics. (But in our game, this is not always the case.) By terrain, we mean objects made of a material with a specific type of texture blending, designed to imitate natural surfaces realistically: rocks, sand dunes, gravel, soil, and more. It can also be successfully used to simulate human-created surfaces: broken asphalt, paving stones, concrete slabs overgrown with grass.
- Static game objects. These are objects in the game process which are possible to physically interact with. As a rule, this includes various types of buildings.
- Large, static non-game objects. These include objects that contribute to the visual perception of the location, but don’t participate in the gameplay, and don’t imply any physical interaction: rock masses in the location environment, lighting farms outside the gameplay zone, etc. These objects cannot be disabled to increase performance on low-end devices, and this means that we need to work with their level of detail (LOD) and change it depending on their distance from the game camera.
- Medium-sized, static non-game objects. These are static objects that also do not imply any physical interaction. In our case, their size is comparable to the average size of the robot — our main dynamic object. These objects can be disabled to improve performance, but due to their size, we still try to use the highest quality presets for them possible. Accordingly, we also can change their level of detail.
- Small, static non-game objects. These include objects the size of which are much smaller than our robots. We need these objects to create a sense of scale, and they’re only available when using the HD or Ultra-HD presets. That said, we try not to disable them on low-end devices, if performance tests allow.
Trims, tiles, props: breaking down the level geometry and creating textures
And now, finally, let’s move on to the main part concerning art.
Upon receiving the concepts in the form of 3D model blockouts, we can begin the level analysis. We conditionally divide all the geometry into large, medium, and small-sized forms and decide where we’ll use trims and tiles, and where we’ll use unique props with their own shaders.
At this stage, it’s also necessary to define cover objects and objects with collisions and to separate them from those that don’t affect the gameplay in any way. This is needed so that they can be easily turned off at lower graphics quality (LD / ULD).
Below is one of the concepts for the Canyon map:
What do we see here?
- The area where the player moves is called the terrain. The main terrain shader is a shader used for natural type objects.
- Blue objects are static objects that the player can interact with. They’re textured using trims and tiles, and use a separate and main shader.
- Green objects are static, non-game objects (props). These don’t have colliders, so players can easily go through them without affecting the gameplay in any way. These objects use a different shader with their own unique textures. They can be disabled on weak devices.
- Red items actually also indicate static game objects (like rock formations as part of the terrain), but the terrain shader is used for these.
- Finally, medium-sized, static non-game objects are highlighted in purple. They are textured with trims and tiles and use the main shader for large buildings on the map. These objects don’t have colliders, but we can’t hide them because they take up a lot of screen space and the difference would be too noticeable for players with LD and HD presets. In other words, it’s just part of the background, so they’re less detailed than static game objects, because the player won’t be able to get close to them anyway.
As soon as we identify the quantity of objects and their scale, we can start creating an array of textures. We recommend immediately embedding all the needed textures, while keeping in mind that you might have to edit existing ones and add new textures in the process anyway.
We usually use several tiles (floors, walls, etc.) for large surfaces and trim them to outline the geometry. It’s important to bear in mind that the trim structure shouldn’t change from texture to texture, otherwise the entire geometry will have to be remapped. We create mini-atlases for various details (windows, bars, doors, hatches, etc.).
An example of an atlas examples for the Powerplant map
The total texel density — texture pixel density per object scale unit — was decided to be set around 128 px/m2. This is enough to draw even small details on doors, windows, bars, and similar elements that won’t change when compressed to 512x512 ETC2.
We most often create textures with 3ds Max/Maya + Substance Painter or Substance Designer + Substance Painter, but some are borrowed from the Quixel Megascan library and edited to our needs. The pipeline here is simple: we model the geometry in 3ds Max or Maya, split it into ID Color, and then bake all the maps in Marmoset or Substance Painter. After that, all the work is done in Substance Painter.
Another option: we get all the necessary maps in Substance Designer (height, normal, AO, curvature) and upload them to Substance Painter for texturing. Sometimes we texture it in Substance Designer right away, however it is more convenient.
Modeling and mapping of the basic level geometry
Once the set of textures is ready, we start modeling the basic level geometry. To do this, we take the *.obj-file of the concept blockout (if it exists), create an optimized low-poly out of it, while trying to maintain an interesting silhouette. At the same time, we monitor the dimensions so that the building doesn’t look too flat and boring. Where necessary, we add extra geometry with small bevels. If it’s possible to get by with just a trim, we cut the geometry into strips and map the textures on them. (Although this is often not necessary when using tile and trim texture technology: the model is created simultaneously with texturing.)
The main thing at this stage is to not overdo it and to not exceed the total polygon count of the scene. For the HD quality preset, this limit reaches 500K triangles. This being said, our game maps vary greatly in their content: for some, 300–400K will be enough, and for some, even 500K will not. However, we try to keep in mind that limitations and optimization are above all, so, for their sake, sometimes we need to sacrifice the beauty of the picture.
As a rule, for the main buildings with LOD0, we have, on average, from 1K to 5K triangles. This is the original detail mesh that the player will see in front of them up close. Subsequent LODs are optimized depending on the distance of the camera.
In general, the polygon count per level of detail is defined as follows:
In the HD preset, we use only LOD0 and LOD1, in LD — LOD3 and LOD2 as the base mesh, in ULD — only LOD3.
We also take into account that some buildings can exceed the robot height by 2 or even 5 times. If a building is too large, we divide it into modular structures.
In addition to the buildings, we also work with the terrain. The base mesh is created in World Machine or World Creator. Further, Masks for SplatMap RGB, a texture that shows where and which tile to draw on the terrain geometry, are also generated there.
The mesh, as a rule, is then manually fine-tuned and optimized, and the SplatMap is finished in Substance Painter or in Unity using the Splat Painter plugin.
Before uploading *.fbx to Unity, we assign the vertex colors to polygons by ID according to our worksheet:
In Unity, the color shader determines which of the 16 array textures to use. Thus, the project gets one material ID per each mesh. And if you need to use different shaders, then you can simply divide this mesh into sub-objects.
From tweaking to release — the final stages
Once the main meshes are uploaded and configured, the design phase begins. The scene is filled with objects (props), the terrain with adjacent geometry is painted, test lighting is adjusted and baked, and so on. In addition, at this stage, we draw RGBA masks for buildings that simulate natural dilapidation: streaks of paint, dirt, dust, soot, rust, and so on. These additions help reduce any tile monotony on large surfaces, emphasize dimensions, and, in general, make the graphics more vivid and expressive.
This is what the map looks like without extra detail and before the light is baked:
And this is after the final polishing:
And again, the main thing here is not to overfill the scene with small objects which will later have to be removed at different graphic qualities (HD, LD, ULD). We also pay attention to object arrangement in the frame and make sure they look nice and harmonious from any angle of the game camera. If necessary, we adjust the shades and colors of the textures so that they fit in the overall picture.
Next comes optimization — one of the first technical stages, after which the map goes into the build. Here we set up LODs, materials, view distances, and, if critical bugs are detected, we adjust the geometry. As soon as all the objects are added to the source scene, it is submitted to the level designer to review the geometry and environment readability from the gameplay point of view. After that, the level is considered to be completely ready, and the next stage of generating different qualities (HD, LD, ULD) from the original source scene begins. Our technical artists have excellent tools in their arsenal to automate this process, but manual refinement is still inevitable.
After generating the map in different quality presets, it returns to the level designers. They again test the updated geometry, level readability, and give general feedback.
In addition, at the final stage of map creation, the level designers send it for external testing several times. This is carried out on a separate test server where we invite players to try out new content that is being prepared for release. This method allows us to collect feedback on gameplay aspects, graphics, and evaluate the map performance, so to speak, in field conditions.
As soon as all the edits and improvements are done, the QA department takes over the work on the map. The testers carefully check the level for various bugs related to graphics and gameplay. Testing is performed on all kinds of smartphones and tablets to make sure that the map will look good on a variety of devices, regardless of technical prowess. This is also where the final performance check of the scene takes place and its performance is compared with other maps.
Finally, the map goes into the game. After that, the artists and modelers can start working on the next map. At the same time, the level designers and the project technical team are monitoring the performance of the released map, the technical support specialists are collecting player complaints related to potential bugs in the level, and community managers are monitoring feedback on social networks. This post-release support process is just as important as the rest of what we do: here we catch undetected bugs and some other things that we’ll finalize for the next planned release. Thus, work on the map is an ongoing process that doesn’t end even when the level is ready for the release. This, of course, is considered normal for any GaaS.
Summing things up: what techniques seemed the most effective and why
- Switching to a new graphics pipeline (SRP) allowed us to use PBR textures instead of the classic diffuse/normal/specular model. This simplifies texture creation, since modern packages like Substance Painter/Designer, as well as Quixel are configured specifically for PBR.
- The use of texture arrays and trims/tiles gives us the opportunity to more efficiently use device memory when texturing a bunch of large, similar models. It also reduces the time needed to create more detailed objects.
- A “Smart” LOD system allows you to increase the polygon count and detailing on HD-maps without sacrificing overall performance in lower qualities and weak devices.
- Hand-crafting toolkits like Splat Painter make it easy to create Splat masks for terrain and more.
- Custom shaders and materials under SRP allow us to harness all the creative potential planned out at the pre-production stage of the map.
- The discovery of a shader supporting transparency allows us to use decals on vertical and horizontal surfaces. These decals can be in the form of markings on the road, as well as inscriptions and logos on buildings.
- Moving away from older technologies in favor of a more flexible and user-friendly toolkit has given us the opportunity to improve the overall visual quality of the levels and bring them closer to today’s mobile game graphics standards.
