- Shopping Bag ( 0 items )
A computer game must look good and run well. This is the mantra for the game artist. Until you have tried to accomplish this goal, you have no idea how at odds each of these objectives is with the other. Although the primary focus of this book is the generation of art assets for computer game environments, we can't escape the fact that creating art for a game is more than just making a pretty picture. When you create art for a game you need to create art that will accomplish several goals, the least of which is that your art must work technically in the game environment and work as efficiently as possible in that environment. This requires planning and creating your art to very specific guidelines. Those guidelines may change depending on many variables (we will examine these later), but they are all essentially the same variables. In any case, you need to be very well aware of what those variables are and build accordingly.
Making a game run at its very best is called optimization. It is a common belief that this is solely the domain of the programmer-but nothing could be further from the truth. It is, in fact, everyone's job to optimize from day one. The artists have a huge impact on how well a game runs, so we need to know every trick possible to achieve this. It cannot be stressed enough that you have to be familiar with the most common methods of game world optimization, because much of what can be done to optimize a game is under your control and takes place during asset creation or the implementation of the asset into the world.
There are many things that can or need to be done during the actual assembly of the game world-which might fall to you. Since the computer game must not only look good, but run well too, throughout the book we look at how to apply many of these optimization techniques. You will have to use every trick available to you. If you don't, the game world will not run well enough to use or will not look as good as it can. If you fail to make the game look as good as possible due to a lack of optimization, you are wasting an opportunity as valuable as gold in game development.
Performance is usually expressed as frames per second (FPS) in a game, and there is a definite limit to what you can do as an artist, programmer, or designer based on this-no matter what system specs you are working with. If frame rate is inefficiently used in one place and goes undetected, then it is by definition diminishing the available frame rate in other areas of the game. One of my pet peeves is the last-minute gutting of a game to make it run. I have seen entire levels that have taken weeks and months to perfect gutted at the last minute. Trade-offs are unavoidable, but if you don't look at your game in its totality and track your frame rate (among other resources), you are going to get caught unaware at the end of development as the game comes together and doesn't run as you had hoped.
Let me repeat (because this drives me absolutely nuts): you have to track your resources. Just because you can run through your level at 120 frames per second doesn't mean performance is assured. You have to consider several things first before celebrating the blistering frame rate. Are you using the target machine, or are you using a high-end machine typical of most development studios? What is left to implement in the game? Are the collision detection and physics in place? What about running artificial intelligence (AI) and game logic? Sometimes the addition of a heads-up display or interface slows things down. As soon as you fire a weapon you are potentially triggering collision detection, creating hundreds of assets (particles) triggering sound events, displaying decals on walls, and so on. Think about the addition of other players and characters, and their weapons. Suddenly you have thousands more polygons on the screen, a few more large textures loading, and other assets and events. In short, can you think of every possible thing the final game will have running and guess what your frame rate target should actually be? You probably can't get a dead-on correct answer early in development, but an educated guess (have lunch with the programmers and question them-they'll love you for it) and the awareness that your actual frame rate will be cut in half when the game is up and running in full will help you hit a more realistic target and prevent the total raping of a game level at the last minute.
This chapter looks at some of the most common tools and techniques (accessible to the artist) used for optimizing a game world. I present them from the artist's point of view, meaning how the tool or technique works and what control the artist generally has over it. Usually you will see that most of these tools and techniques are explored or presented from the programmer's point of view (they are very involved programmatically, to put it mildly), but artists really need to understand these devices, as they are critical to making a level look good and run well. I break optimization down into three major areas: asset, collision, and occlusion based. Aside from the things we as artists can do to optimize the game, there are of course many other areas that also need to be optimized. Most of these optimizations are found in the program code. Things like memory management, CPU and GPU code, artificial intelligence, collision code, networking, sound, and the game play itself all eat up resources and need to be optimized by the programmers.
Note: YOU! Yes, you! You the artist are responsible for a great deal of the optimization in a game. In every phase, from planning to creating the assets, to producing the assets, to introducing those assets into the game world, there are opportunities to optimize.
Even after your assets are introduced into the game world, there are opportunities to optimize. In fact, many of the optimizations possible in a game are available to the artist in the game itself. Most game development engines have a tool that will show you a read-out on screen that allows for the viewing and analysis of all the aspects of the game as it runs. As the artist you can look at the world in many modes and see what areas can be optimized. You can look at the number of polygons on screen, overlapping textures that may cause an inefficiency, and you can even see what the computer is drawing that we may not see as a player. In Figure 1-1 you can see that while the player can't see the rat on the other side of the wall, the game engine would draw it anyway because the radius of visibility can be seen by the player camera. You can improve performance by going into the editor and correcting this in a variety of ways: removing the rat, setting a draw distance, and other ways we will look at in this chapter, which are listed below.
Multiple UV channels
Masking and transparency
Texture size and compression
Occlusion and culling
Cells and portals
Asset-based optimizations are simply those optimizations you can implement and effect 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, sometimes called texture LOD (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. MIP stands for the Latin phrase multum in parvo, which means "many things in a small place." MIP mapping is the creation of multiple sizes of a texture for display at various distances in the game (Figure 1-2). Sometimes you can see the MIP maps pop as they change from larger to smaller, especially in older games. MIP mapping allows the texture to be viewed close-up and in detail, as well as render faster (and look better) from a distance. Figure 1-3 shows the MIP-mapped texture of some jungle vines. Notice the alpha channel is MIP-mapped as well. Fortunately NVIDIA created several tools to make all this easier for the artist (Figure 1-4). The DXT Compression Plug-in is one of the most useful, and I discuss that later in this chapter in the section on texture size and compression. With this tool you can control many variables that affect the visual quality of the image.
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 (due to 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 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. Basically it involves taking a large group of textures that are related in some way (usually geographically close to one another in the game world) and putting them together to create one large texture. You can see a texture atlas of foliage created for a jungle level in Figure 1-5. You can create an atlas by hand or with a tool. Of course, NVIDIA makes such a tool (Figure 1-6). The primary benefit of a tool like this for the artist is the speed at which atlases can be built and altered. This tool creates the one large texture and with it a file that tells the game engine where each image is placed on the master image.
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. Large forested outdoor areas can benefit from the use of unlit textures on the foliage. Figure 1-7 shows an example of a texture that is lit in one scene and then unlit in the next. Notice how the sign is at full brightness and remains unchanged by the lighting affecting the walls. Particle systems typically look better unlit and run faster as well (Figure 1-8).
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. A grayscale image may simply define the dark and light areas of a surface, another map may define color, and another some unique detail. You can see an example of this method in Figure 1-9. The building mesh has a base-colored material applied; on a separate channel I applied dirt, and on another I added details such as posters and cracks. Multiple UV channels are also used to apply bump mapping and other shader effects.
Lightmaps are pre-rendered images that define the light and shadow on the surfaces of your world. Since lightmaps are created before the game runs and are saved as separate grayscale images this means that the total file size of your assets is increased. There are two things you can do to optimize lightmaps: lower their resolution or compress them. A smaller lightmap will result in a faster loading and running level, but lowering the resolution also lowers the quality (Figure 1-10).
Note: For a great article on compressing lightmaps, go to Gamasutra (www.gamasutra.com, one of the largest game development sites on the Internet) and look up "Making Quality Game Textures" by Riccard Linde.
Usually you can opt out of using a lightmap or can determine at what size the lightmap will be created. This allows you to increase the resolution of the lightmap in those areas where the player can go and lower the resolution for less accessible, but visible areas.
MASKING AND TRANSPARENCY
When possible, it is preferable to use masking instead of transparency because masking renders more quickly. Take a look at Figure 1-11, as these concepts are much easier to grasp pictorially.
Masking typically uses a specific color that is designated the "clear" color, and this creates hard jagged edges (although newer hardware can handle larger-resolution textures and can post-process the images and smooth the edges).
Transparency uses a separate, additional channel, a grayscale image called the alpha channel, to determine the opacity of a pixel. The trade-off is that transparency looks better, but it requires more file space and more processing power. This is because while masking simply either draws the pixel or not, transparency must look at two pixels (the source image pixel and the on-screen pixel behind it), consider the grayscale pixel of the alpha channel, and calculate the color of the final on-screen pixel. Technically what you are seeing isn't real-world transparency, but rather a new image composed of a blending of two images that gives the illusion of transparency.
Of course, NVIDIA makes a tool that allows for the rapid adjusting and viewing of textures before outputting them (Figure 1-12).
TEXTURE SIZE AND COMPRESSION
You want to consider the size of each texture you create. A texture that covers most of the walls and/or floors in your world, and has to tile well while still holding up visually, needs to be larger than a texture that is displayed infrequently and is not subject to direct examination by the player. The other factor is compression. A compressed texture file can be significantly smaller than an uncompressed one yet still maintain visual integrity using the right combination of compression options. NVIDIA makes a plug-in for Photoshop that allows for the rapid and easy iteration through many compression schemes before final output of the file (Figure 1-13).
Remember that there are many factors to consider when determining texture size and compression. How close will the player get to the asset? How often will the asset appear in the world, and how many times is it expected to tile or repeat? Can you achieve the same effect with a more efficient solution? Can you use three small textures on multiple UV channels as opposed to one enormous texture? How much can you compress or reduce the resolution of an image and still maintain visual integrity? One of the most valuable but underappreciated skills a game artist can acquire is knowing not only the various ways of implementing game art solutions, but what methods and combination of those methods comprise the best solution.
Excerpted from 3D Game Environments by Luke Ahearn Copyright © 2008 by Elsevier, Inc.. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Posted May 22, 2010
No text was provided for this review.