In experiment 7 I discovered that reduced texture scales have an effect on frame rates that is disproportional to the increase wpoly that they create. In this experiment I wanted to explore this further, and try to answer three questions:

• At what rate does FPS decline as texture scales are reduced?

• How does this compare to a similar increase in wpoly achieved by increasing the number of brushes but leaving texture scales at 1.00?

• How does this compare to using smaller textures but leaving them scales set to 1.00?

Starting again with the base Test Chamber, I simply reduced all texture scales and measured r-speeds as shown below. I reduced texture scales in steps of 0.20, and also tested scales of 0.75, 0.50 and 0.25 which I suspected might be significant.

Interesting. Notice that FPS declines slowly as scales reduce from 1.00 to down to 0.60, even though wpoly does not change. Wpoly doesn't increase until scales reach 0.50. And notice the nose-dive that FPS takes at scales of 0.25 .

To answer the next question of how this compares to increased wpoly achieved by adding brushes (but leaving texture scales at 1.00), I went back to the base Test Chamber. I created a simple cylinder brush, 16 sides, 64 wide x 64 long x 8 high, and covered it in the Generic015P (64x64) texture. I attached it directly to the floor. Then I copied it and added directly to one wall, and repeated this several more times.

Note that with 2 cylinder brushes wpoly is 65 and FPS at 40+, while in the earlier experiment with texture scales at 0.50 wpoly was only 54 but FPS had dropped to 30+. The effect is even more pronounced with 6 cylinder brushes where wpoly is 151 and FPS holds at 30+, while in the earlier experiment with texture scales at 0.25 wpoly was at 150 but FPS had fallen to only 10+

The final question of how using smaller textures (at scale of 1.00) compares to using scaled down large textures brought me back to the basic Test Chamber. I replaced its textures with ones that were exactly half the size of the original - walls in Crate02 (64x64), floor in Duct_Wall03 (64x64), and ceiling in Frostceiling (32x32). I then tried it again but with textures that were exactly one quarter the size of the originals - walls in Ca1x_con1b (32x32), floor in Lab1_glu3b (32x32), and ceiling in Generic99c (16x16). By the way - these textures were chosen for their sizes - not for their aesthetics. I really don't plan to use combinations like these on my real maps!

Now this is fascinating! Using smaller textures has no effect on either FPS or wpoly, even though they must be replicated across the polygon surfaces many more times. This directly contradicts much of the advice commonly offered on a number of websites!

This leads me to conclude that texture scale effects FPS much more than it does wpoly, while simply using smaller textures doesn't effect either FPS or wpoly. Based on this I'm ready to add another to my Rules for the Novice Mapper:

7. Do not scale down your textures (except to cover small objects). Use smaller textures instead.

 

What's going on here?

There are two phenomenon revealed in this experiment: First, the size of a texture has no effect on WPOLY. No matter what the texture sizes are, when scaled at 1.00, the compiler breaks the faces up into polygons as close to 240x240 as possible - limited by the size of the face. The texture may have to tile many times to cover the poygon, but this will not effect WPOLY. If texture scales are reduced the polygons are also reduced, so if texture scale is 0.50 the polygons can be no more than 120x120. For more complete information, read Debunking a Myth: Texture Tiling over at Triangular Illusions. Second, texture scale not only effects polygon sizes, it also effects the size of the patches used in light mapping. The default patch size is 64x64, but where textures have been scaled down to 0.50 they would be only 32x32. The additional light calculations are what causes FPS to decline more than would be expected for the given WPOLY.

Return to Top