Texture Memory

/meminfo

This is a straightforward test and will likely not be an issue for most mappers. id set forth some guidelines for the maximum memory "footprint" (for lack of a better word) for its maps. id wanted to ensure that its maps would be playable on systems that meet the minimum requirements to play the game, i.e., systems with a minimum of 64 megs of system memory. Therefore, id recommends keeping the number below 56 megs. This test is run simply by typing /meminfo into the console. The problem with this tool is that if you've exceed the total hunk in use, then you will probably not be able to load the map (and not be able to get the /meminfo numbers for it). Anyway, the results should look like this:



The important number is total hunk in use, underlined in yellow. Hunk is the amount of memory being used by the map. If you are mapping for a mod that intends to maintain the minimum requirements as set forth by id, like Reaction Quake 3 at the moment, then keep this number under 56 megs.


/imagelist

This is probably the most important measurement you can make, and one that is often overlooked by level designers. /imagelist reports back to you the "total number of texels in use" (see the screenshot below). The generally accepted maximum number of texels in use should be no more than 3,600,000 to 4,000,000, or 4 megatexels (this number is based on the average users video card). However in Reaction, since we're using the Q3:TA user interface (UI), the imagelist will come in significantly higher. This won't hurt a map's performance, but you do need to factor it in. The adjusted maximum number of texels in use for Reaction should be no more than 4,800,000 to 5,200,000. In other words, the Reaction UI adds about 2,200,000 texels of overhead to the /imagelist.

Here is how it will look after entering the command:



How do you use /imagelist?

What does this number mean, total texels? A texel is a textured element, or textured pixel. The total texel number is a rough measurement of the memory usage of the textures in a map.


"How do I figure out how much one of my textures is adding to the total texel count?"

____X dimension * Y dimension / 4 (to factor in /r_picmip 1)
____256 * 256 / 4 = 16,384 texels

A 256x256 texture will add about 16 kiloTexels to your total texel count.


"How does the texture size translate into memory usage on the video card?"

____Roughly: texel count * 4 (bytes) * 4/3 (for mipmaps)
____256 * 256 / 4 * 4 * 4/3 = 87,381 bytes

A 256x256 texture will add about 87 kiloBytes to your texture memory usage. This calculation assumes no texture compression.


You can see that if your texel use is too high, the textures of the map will use up the texture memory of the video card. Then you will end up with "texture swapping" where the textures need to be retrieved from the system memory or swap file (on the hard drive), which will be slower than getting the texture from the video card memory. This is obviously much slower than using the on-board video memory, so it can lead to serious performance hits (much more so than too many polys). You may recall playing Q3DM9 and wondering why it performed so much more slowly than the other Q3DM maps.

So what do you do if your map exceeds that number and you are having performance problems? If you've taken a close look at the above formula, you can see that the size of the textures will impact the total texel number (a 256x256 texture is equivelent to 4 128x128 textures). You can also see that alpha channels, by adding another 8-bit channel to the texture, will also increase the total texel number. Finally, the sheer number of textures in your map, by virtue of there being more textures to add to the final number, will also increase the total texel number. That leaves you three areas you can try to reduce your texel number. Before you change anything, take a "big picture" look at your map. Are there some textures that do not need as much detail that you could make smaller? Are there some textures that you use once or infrequently that the map can do without? These will be tough questions, but in the end the point of making the map in the first place is to have people play and enjoy it, so you will be broadening the map's playability by making these tough decisions.

Also, please note that you can go over this number and not necessary see a significant performance hit. First, using compressed textures will help substantially. Second, a map could be designed in such a way that the texture swapping occurs in a low traffic area, like a corridor or something, and it will be less noticeable.

One more final word of caution: make sure you test your map within Reaction Quake 3 because it uses different menu textures, weapon skins, etc. that will definitely affect the /imagelist result.



Return to Mapping Guide




Last updated: June 15, 2002
Valid for RQ3 Beta 2.1