Asset-based optimizations
Asset-based optimizations are simply those optimizations you can implement and affect during asset production. Assets are the art we create, and they present the first opportunity we have to apply any optimizations. Technically, there are always opportunities from day one to keep optimizations in mind and apply them during the design phase, but, often, the artist is not present during this time. Our first opportunity is usually when we start to create the assets for the game. Some optimizations are possible in the design and planning of the assets; for example, the design of how a texture is laid out affects how the UV maps are laid out, and that, in turn, can affect performance.
MIP mapping
MIP mapping, sometimes called texture level of detail, is usually a programmer-controlled function, but sometimes the artist is given control of this, too. The explanation is pretty simple. A large texture seen at a far distance in a game world looks the same as a smaller texture due to the fact that both are being displayed using the same number of pixels on screen; it is therefore a waste of resources to use a large texture on an object that is far away in the game world. In addition, using a larger texture on a small, faraway object usually doesn’t look as good as the smaller texture would, due to the fact that the larger texture is being resized on the fly by the game engine? To solve both these problems, programmers usually implement some form of MIP mapping.
Texture pages (or T-pages, atlas textures, or texture packing)
This section comes with a bit of a disclaimer. It seems that the industry is now moving away from texture atlases. While atlases will continue to be an effective solution for some hardware, things are shifting over (for technical reasons beyond me) to individual textures. That’s great news to me—I find that texture atlases slow things down in the typical artist workflow. As you build a game world, you create many textures to cover the many three-dimensional (3D) objects in the world. When the game world is loaded and run in the game engine, the game engine has to access (call) each of those textures for each frame it renders. These calls slow everything down, so it is desirable to reduce the number of calls. There is a technique you can use called texture packing or creating a texture atlas that can accomplish this.
Unlit textures
An unlit texture is a texture that is unaffected by lighting and displays at 100% brightness—sometimes called a full bright or self-illuminated texture. Note that this not the same as a texture that uses an illumination map. When an illumination map is used, it must calculate lighting for a texture and take into account the grayscale illumination map. Since calculating the lighting for a texture can be one of the biggest resource hogs in a game, it can be much more practical to use an unlit texture, which renders much faster. Using unlit textures is a way to boost performance. This is easy to do with some materials such as water or certain signs, and, in some game types or genres, you can get away with using large numbers of unlit textures.
Multitexturing or multiple UV channels
Increasingly, in today’s game engines, you are not limited to one UV channel. This allows you to combine textures on a surface in real time. That, in turn, allows a great degree of variety from a relatively smaller set of assets.
Light maps
Light maps are retendered images that define the light and shadow on the surfaces of your world. Since light maps are created before the game runs and are saved as separate grayscale images, this means that
Conclusion
That was a quick overview of the most common artist-accessible game optimizations. As we progress through the book, we will use some of these optimizations in the projects so you can see how they might be implemented in an actual game development scenario.
