A number of sites have suggested that when a smaller brush is in contact with a larger one it is a good idea to make the smaller one into a Func_Wall entity. The theory is that if both brushes are regular world brushes, the larger brush will be broken into multiple polygons around the smaller one. If the smaller brush is a Func_Wall entity however, the larger brush will not be broken up.

For this test I created a box identical to the one used in the last experiment, 64x64x64, covered with the C1A0_LABFLRD texture, and placed it directly on the floor of the Test Chamber. Then I tested it again after making it into a Func_Wall.

Some effect, but not a lot. Perhaps more interesting than the effect on maximum wpoly is the effect on minimum wpoly. The minimum wpoly is actually higher when Func_Wall is used. Apparently Func_Wall entities do not act as view blocks the way a regular world brush can. This shows why you need to be careful about which brushes you make into Func_Wall entities.

Given the theory behind using Func_Wall to reduce r-speeds it seems likely that this technique would be more effective on a more complex brush, so I tried the same experiment using a octagonal cylinder instead. As before the cylinder is 64x64x64, and covered with the C1A0_LABFLRD texture.

As expected, the effect of using Func_Wall is much greater for the cylinder.

So how does epoly effect overall r-speeds? In my tests up to this point I've considered only wpoly, but r-speeds include epoly as well. It seems logical that the more epoly you have, the less wpoly you can get away with, but what is the relationship?

To test I decided that FPS ("Frames Per Second" or "frame rate") would probably serve as the best measure of the combined effect of wpoly and epoly on r-speed. Keep in mind that hardware has an effect on FPS, so a better PC will get higher frame rates than I got in this experiment.

For the initial test I needed a bit more room, so I enlarged the test chamber to 256 wide x 512 long x 256 high. After taking a baseline reading of r-speeds, I began adding 2 monster_barneys at a time, then rechecked the r-speeds before adding the next two. I kept adding Barneys until my PC screamed for mercy (the action became too choppy to allow smooth play).

So on an old machine at least, epoly much over 9000 starts to cause a problem. But if wpoly were higher, how much less epoly would be possible?

To answer this question I first tried to increase wpoly by changing the scale of the brush textures in the test chamber to 0.25 .

The results were interesting. Even with no Barneys in the chamber frame rates were very low and movement was choppy. Yet wpoly was only 250 - not really that high, and on other maps I've run a wpoly of 250 works very well. Clearly reduced texture scales effect FPS in ways not reflected by wpoly or epoly alone. I'll explore this phenomenon further in Experiment 8. In the meantime, lets get back to my original question . . .

For my second attempt to measure the relationship of wpoly and epoly I added some world brushes. I created 12 cylinders, each with 16 sides, 128 wide x 128 long x 8 high (so they would not block vis), and covered in the crete4_wall01b texture. I placed them directly on the walls, floor, and ceiling at the end of the room where I would place the Barneys, spaced so that they did not touch each other .

Basically the extra 250 wpoly effected FPS as if there were about 3140 more epoly in the room (the equivalent of 4 Barneys) , when compared with my first epoly experiment. This suggests that 1 wpoly is worth about 12 epoly.

I wanted to see if that ratio would hold true for a map with even greater wpolys, so I added 12 more cylinders to the chamber (for a total of 24).

In this case the extra 520 wpoly or so (over the those in the first epoly experiment) effected FPS as if there were about 6280 more epoly in the chamber (or 8 additional Barneys). Again it appears that each 1 wpoly is worth about 12 epoly.

On the assumption that my PC is close to the least powerful that one might be playing Half-Life on, and given the observation that problems start to occur when FPS gets down to about 7, I would propose a formula for calculating maximum acceptable overall r-speeds:

(12 * wpoly) + epoly should not exceed 10,000

I think I'll make that rule number 6 in the Rules for the Novice Mapper section.

Of course if you are aiming your level at those with better PCs you might increase that number somewhat (go ahead, leave me out of the fun. . . ). I'd do some tests to see just how much you could increase it by, but I'll need to get a better PC myself first.

By they way - remember that the animation for the player's hands and gun is worth about 900 epoly by itself.

Return to Top