A modern asset pipeline: The pipeline
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
This is the fourth and lastÂ post in a series about a modern asset pipeline. Here are the previous posts:Introduction 7 reasons to optimize content How much time is spent optimizing?
A modern asset pipeline
Everything points towards a modernized asset pipeline in which the bulk of the optimization work is done behind the scenes, automatically. Artists should focus their efforts on the creative side of game development, rather than working with the mundane task of optimizing content.
Here is a schematic of what a modern asset pipeline looks like.
Let us break this down.
Letâ€™s say that we have been building a character like this one. Traditionally the artist would create a number of LODâ€™s and other optimized versions of this character when committing it into the repository. However, in reality he would probably wait a while before optimizing the character. It might need approval and before that there is no point in doing any optimization work. It might also be so early in production that art direction might change, and in that case it might be better to wait a while with optimizing content to avoid any wasted effort.
In this pipeline the artist would only check in the hi-res asset.
Automatic Optimizer and Optimization Controls
Behind the scenes there is an automatic optimizer that recognizes that a new asset has come into the repository. It could be as simple as a script checking for new assets coming into Perforce. Here is an example of what that could look like:
It would know exactly what to do with the asset and automatically generate a number optimized versions of that asset. For example:
- The low PC specs might not be able to handle as many draw calls as the high end PC, so the material count should be reduced.
- The character should have four levels of details for different viewing distances.
- The mobile version canâ€™t have as many joints so the least influential are removed.
When all the different optimized versions of the asset are generated they will be sent them into an asset cache.Â The automatic optimizer has the responsibility of keeping the asset cache in sync with the source at all times. This means that whenever a new asset arrives or an asset is changed, the optimizer should kick in and generate the content.
The optimization controls provides us with tools to touch many assets with the tweak of a parameter. Within that we can divide assets by class and specify optimization settings per platform and class. This way we can easily balance performance and memory by tweaking and tuning parameters. We can answer questions that would take a lot of manual labor. For example:
- We are running out of memory what would happen if we remove 5% of the polygons of all models?
- We are having issues with performance and we believe that draw calls are the main bottle neck. What happens if we merge materials on characters when they are 30 meters away?
Any time settings change the automatic optimizer should kick in and re-generate all affected assets. In a large game this could take a lot of time to process, but as opposed to manual labor itâ€™s just a matter of adding more processing power to shorten the iteration times for testing.
The build server just needs to know which asset version to use for which game version. As long as the asset cache is in sync with the source repository the build server should not be affected in any way.
Here comes the caveat, not all assets will be perfect. There will be some that didnâ€™t tolerate the optimization. If there is a mechanism that allows you to tag broken assets within the game that then adds the asset to a fix list, it could be an efficient way of only spending your energy optimizing the assets that are problematic. An automatic safety net would be to have a secondary set of optimization rules that doesnâ€™t optimize the asset as much to see if that works. Finally, if the broken asset ends up a second time on the fix list we might just have to get our hands dirty and manually fix the asset.
The goal with an asset pipeline like this should be that every asset automatically is perfectly optimized, and the closer we can get to that the more benefits there are. However, there is a sweet spot somewhere, where the cost of refining the solution further will pay very little dividends. My guess is that if 80-90% of the assets can pass through without any problems, the cost of improving it further might be hard to recoup over a project or two.
Benefits and drawbacks
Reduced manual reviewing
Manual reviewing of optimized assets isnâ€™t very efficient. If we look at the image to the right, the optimized version of the character doesnâ€™t look very good up close. Will tweaking it actually improve the look at a distance?
Modelling happens up close, so the artist has to zoom in on the asset, fix things then move the asset away and repeat until the asset looks good.
A machine doesnâ€™t care what it looks like up close, as long as it doesnâ€™t differ too much at the distance itâ€™s intended for.
Utilize platform capacity
When a game is being built for multiple platforms, the assets are usually created with the weakest platform in mind. Rarely itâ€™s affordable to build different asset versions for each SKU, thus you would go by the least common denominator. With an automatic solution in place, you can build content with the strongest platform in mind and then use optimized assets for the weaker platforms.
Final foot print immediately
Waste is one of the biggest enemies of a game producer. To reduce waste in content optimization you donâ€™t want to spend time on optimizing assets before they are final. If most work are done manually the game will run with un-optimized content for large parts of the production.
Any game developer knows that the earliest assets in a game production are likely going to change a number of times before the game is shipped. Many of them will not even make it into the game. Itâ€™s better to wait with optimizing them. Secondly, you donâ€™t want to create LODs, for example, before the asset is approved by art direction.
At any given moment the game will contain lots of assets that arenâ€™t final, which will give a faulty impression of how much memory the game is consuming and performance will not be indicative of the end result.
One of the most important benefits is the fact that an automatic solution will lead to a more correct performance and memory footprint earlier. With early knowledge about this, the end phase contains less unknowns. You donâ€™t want to know how much work remains to get the game to run on the target platforms two months before shipping the game.
With an automatic solution behind the scenes, content that is coming into the game will be representative of the final result as soon as the high-res is checked in.
In the final phase of the game production every game will encounter problems with memory and/or performance. With an automatic solution, the team has a strong tool to balance between the two.
They can answer questions like this:
- Will adding another LOD-step to all characters improve performance or does it cost too much memory?
- Can we reduce the draw call amount enough by merging material one LOD-step earlier?
- What if we merge modular assets closer to the player?
Manually each of these decision will require a significant effort just to evaluate the benefit, not to mention applying it to the whole game. With a modern asset pipeline itâ€™s a matter of waiting for the servers to process all the assets. Too slow? Acquire more computing power.
There is an initial cost of setting up a pipeline like this. It requires tweaking and tuning to get the results youâ€™re looking for. The earlier it is done, the bigger the benefits will be.
Perfect is very hard to reach
As stated earlier the goal should be to have every asset passing through the pipeline without any problems, which might be unattainable. Being satisfied at 80-90% of the assets smoothly passing through is probably a more realistic goal. Then itâ€™s just about tweaking and tuning to slowly reduce the number of problem assets.
When to consider this?
Long viewing distances and big environments
Any game with long viewing distances will have to make a choice, sparse vistas or heavy optimization of content. If the choice is the latter a modern asset pipeline will make life a lot easier.
Large amounts of characters
Games that are striving for a lot of characters on screen, with high visual fidelity will have to do a lot of smart optimizations to push the character count. An automatic optimization solution behind the scenes will provide the team with a tool that allows them to push the character count as far as possible.
Large player freedom
When the player can roam around as he sees fit a lot of content is required to fill the world. To allow the player to view the world from the top of a mountain, or rapidly fly over a city, you need to be smart in how the content is optimized. Typically this kind of game requires a large number of assets and they all need to exist in a number of versions for different viewing distances.
Many games today are built using modular content which usually leads to a large number draw calls. Having something behind the scenes that combines modular pieces will make the content cheaper to draw, allowing you to have more content and more variation in the game.
When your game is targeting multiple devices with very different capabilities a modern asset pipeline can help you in creating content that utilizes the platforms strengths. It can also be a great tool when porting a game from a stronger platform to a weaker one.
A modern asset pipeline can help teams that are striving for greatness in visuals, without having to drown in the amount of work required to make the game run properly. Competition to get your game in to the hands of the players is always increasing and so too are the costs with making games that are visually appealing to the player and high on performance. The risks these days are extremely high, so every cent saved, is a step in the direction of risk reduction. If optimizing assets automatically can drastically reduce time spent your creative artists on the mundane and boring tasks, you have taken a step in the right direction of solving quite a few problems and your creative people can stick to doing what they do best, creating imaginative and artistic assets for the players to enjoy â€“ it is why they were hired.
If we combine the goal of 80% of the assets automatically passing through the pipeline with the stats indicating that 20-100+ man months are spent on optimizing content, the conclusion is that you should be able to free up somewhere between 16-80 man months of optimization work in an AAA project.
So, what can automatic optimization save you?