Introduction
The Half-life engine is pretty versatile for being 5 years old. However, it was designed with some limitations that can get very annoying when trying to make a map. Some people would say the maximum planes, patches, texture data, texture size, clipnodes, etc. limits are all way too low, but remember the game was designed for a 200mhz Pentium with a 4mb graphics card to be able to play the game! Most of the limits don't matter to the newbie mapper. There is one you should keep in mind, though - the r_speeds limit.

What are r_speeds?
R_speeds are a measurement of what the game can "see". They tell you how many polygons are being drawn from any point in your map. Higher r_speeds = more polygons = lower framerate. The goal, then, is to keep r_speeds as low as possible.

R_speeds are dependent entirely on how you build your map (barring some weird VIS error). A talented mapper can squeeze a whole lot of detail out of the r_speeds limit by following some simple procedures and using a few tricks. The rest of this guide will show you some ways to keep r_speeds low throughout your map.

What's a good number for r_speeds?
Opinions vary on this somewhat. One thing to remember is that when the game is playing in the software video mode, it has a hard limit of 800 polygons on screen at once. When r_speeds go above that number, the engine has to skip a few polygons to keep the total number drawn at 800. This shows up to the user as a "short xxx faces" message, and when it gets really bad, parts of the map will start to disappear! Some people think that computer technology has come so far that r_speeds really aren't an issue any more - those of us with a high-end system will rarely see HL running at less than 60 fps. This is somewhat true, but let's not alienate these people:

• Those running in OpenGL or Direct3D mode but with a less than top-of-the-line system
  
• Those running in software mode because their graphics card is so old it won't support the newer modes
  
• Those running in software mode because they didn't know there was any other way to play
  

A good rule of thumb is this: Keep r_speeds below 700 in areas of high traffic, or where a lot of action will take place. You can let the rules slide a bit in places the player will rarely reach, but keep in mind a hard cap of 1000 or parts of the map may start to disappear.

That's great and all, but how do I see my r_speeds?
This is a multiple step process. If you already have a console for Half-life set up, skip to step 2.

1. Right click your Half-life shortcut and go to "properties". On the Shortcut tab, check the Target box. Make sure you have -dev -console at the end of the box, as shown.
   

   

   
   
2. Start Half-life through this shortcut. Open the console and load your map (try "map ").
   
3. Bring down the console with the tilde key (the "~" at the top left) and type in: r_speeds 1
   

   

   
   
4. Now you should see a lot of numbers filling your console. Hit tilde again and you should see a few lines at the top left of your screen. The important number is the one in front of wpoly. This is the one you really have control over.
   

Don't worry about the fps or the ms displays, those are specific to your system. Also, don't put too much stock in the epoly rating. That number is the entity polygons being drawn, and includes things like your weapon in hand, weapons and bodies on the ground, other players, rockets in the air, etc. In other words, unless you have a whole lot of models or something around, this one probably won't become a problem.

My r_speeds are embarrasing. What do I do?
Here are a few simple procedures to keep r_speeds low.

• Use Zoner's Compile Tools and run full vis.
  First, make sure you are using Zoner's Compile Tools instead of the default ones included with Hammer. These tools are better, faster, look nicer, and won't let you get away with nearly as many map-damaging practices. In other words, they'll make your map nicer.
  
  The vis program's whole purpose is to decide what you can see from anywhere in the map. It keeps this information in your BSP file so that the engine won't waste time rendering things you can't actually see. (Without VIS, the game would just render everything in front of you - through walls, floors and ceilings too!) When it's working, your r_speeds throughout your map will be drastically reduced.
  
  A full vis is when you specifically tell your hlvis.exe program to work even harder at reducing r_speeds. You can turn it on by adding -full to the parameters:
  

  

  
  Always run VIS. Use it in -fast mode while testing and -full mode for final compiles.
  
  
• Visblock
  Vis does its job by trying to see into rooms from other rooms. If it thinks it can see it, it will draw it. This can lead you into some trouble if you fill all your rooms with complex stuff and then connect them with straight hallways, for example. A general rule of thumb is, if from anywhere in one room you can draw a straight line to another without hitting walls, then VIS will include that room too. Gollum posted these pictures a while back:
  

  

  
  Visblocking is something you need to keep in mind when designing the layout of your map. It's the main deciding factor in how your r_speeds will turn out... everything else can be considered just a tweak to squeeze more r_speeds out of something.
  
  
• Avoid unnecessarily complex geometry
  This one is pretty simple. If you make a giant stone statue in front of your building with all sorts of minute detail, your r_speeds will end up pretty high. Don't make things unneccesarily complex, and avoid intersecting brushes through other brushes... that tends to drive VIS nuts. That's not to say you can't have complicated objects, just restrain yourself the next time you want to use Hammer like 3DS Max.
  
  
• Don't split faces / Scale large textures
  These are somewhat advanced techniques. First, here's a quick primer on face splitting.
  Suppose you touch a cylinder to a wall (maybe you're making a pipe or something). The game engine will actually divide up the wall into a lot of triangles and build the wall "around" the cylinder. If the cylinder has a lot of sides, the wall will be made into a lot of triangles. This means more r_speeds. You want to avoid this, and there are a couple of solutions. First, if you make a block into a func_wall it won't break the wall into triangles any more. Second, if you leave a 1 unit gap between two blocks they won't split each other up.
  
  I ripped this part straight from the Hammer guide, so if you want to look it up yourself just go to the Help file:
  
  There are a number of things to keep in mind concerning r_speeds / polygon count. Entity brushes will not break up other solid brushes, world brushes will That is, if you have a 10 sided cylinder that makes contact with a flat brush, that flat brush will be broken into many pieces (polygons). This can affect both how the brush looks and how many polygons are required to be drawn. There are two main ways to work around this problem:
  
  1) Where one object meets another, leave a 1 (or more) unit gap. This is best done when the player can't see the area where the gap is (ie: at the top of a pillar, or under some shallow water.
  2) where one object meets another, leave a small gap and join the two objects with a func_wall. For example, if you've got a set of pipes that meet up with a wall, put a pipe flange on the wall and connect the pipe to that. Make the flange a func_wall.
  
  

  

  
  Below are some screenshots of the above concepts in action. I used columns as examples but the concept is applicable to many different things.
  
  

  

  
  This picture shows a normal column with no polygon reduction efforts made.
  
  

  

  
  This picture shows a normal column with the above mentioned polygon reduction methods.
  
  The above two pictures were taken in software mode with r_drawflat turned on. This will draw the world in flat/solid polygons (similar to the editor's flat-shaded view). This is an excellent way of checking out your level for areas that may be causing problems with high polygon counts.
  
  Note: To turn on r_drawflat, type r_drawflat 1 in the Half-Life console. You need to have run Half-Life with the -dev and -console parameters for this to work (but then, you should use those parameters anyway when you're testing maps).
  
  Note 2: Most of you aren't playing in software mode. In that case, use gl_wireframe 2 at the console. That way you can not only see where face-splitting occurs, but you can see everything VIS can see, to diagnose problems requiring hint brushes or areas that aren't being visblocked properly. -Greg
  
  

  

  
  This picture shows a normal in-game shot of both columns.
  There isn't a heck of a lot of difference between the two columns, except that the column on the right has a much lower polygon count.
  
  Another thing to keep in mind is texture size. The compile tools split brushes along their texture sizes. For instance, if you apply a 128 x 128 texture to a large wall, that wall would be split into 128x128 polygons. If you change the scale of the the texture to X*2 and Y*2, the wall will be split into 256x256 polygons. The scale of a texture can have a big effect on the the number of polygons. Whenever possible, when it wont be visually negative, increase the scale of a texture (this isn't that often, mind you, but for outdoor areas, it can be handy).
  
  Note: You can access the scale properties of a texture in Hammer by pressing shift+A to bring up the Texture Application Tool, then clicking on a brush face to select it. Modify its scale and press the Apply button to change the brush face.
  
  You'll notice in the included pictures that the walls and ceiling/floor are single polygons. What I've done is stretched them to X*1000 Y*1000 scale. In the in-game shot, you'll see that this produces a flat shaded texture. The only time you would do this in a real map would be one that is completely surrounded by blackness, when the stretched texture wouldn't be visible. Of course, in that case, you could just use the black sky.
  
  Last, remember that the game engine isn't as smart as you. Or maybe its a whole lot smarter. It can see through doors (and any other brush entity), and can see somewhat around corners. Make sure you have world brushes sufficiently blocking sight into other areas, otherwise the engine will be drawing those areas too.
  
  
• FIX LEAKS
  This one seems pretty obvious. If you have leaks in your map, VIS won't run, and neither will RAD (so you either get blackness or fullbright lighting). However the solution is a bit more complicated. NEVER EVER EVER SURROUND YOUR MAP WITH A HOLLOW BOX TO FIX LEAKS.
  
  Let's think about this one for a minute. When VIS and RAD run, they consider what's "inside" your level. So, it doesn't matter what's on the outside of your level at all... it's disregarded by the tools (e.g. removed from the compile process entirely). If you have a leak and then surround it with a hollow box, VIS and RAD consider your level to be the inside of this new box, the outside of your level and the inside of your level. r_speeds will suffer tremendously, it will take hours to compile your map, lighting will look bad, the BSP will be bigger (and may suffer from errors as a result), and there may be places where you can see outside gaps in your walls to some textured box outside.
  
  For more information about leaks, their causes, and how to fix them PROPERLY, click here.
  
  
• Use Hint brushes when all else fails
  This is the least used method, and it does require Zoner's Compile Tools. I won't go any detail about them here, but if you think you can outdo the VIS algorithm in some area of your map, then you might look into them.
  
  Hint Brush resources: Here and here.
  

What doesn't work in maps?
A general rule is to avoid big open areas. If you want to make a huge outdoor map with rolling hills and trees, you're creating content for the wrong game. That's not to say you can't make outdoors areas - there are plenty of (beautiful) outdoors maps out there. But they're not open areas. There are probably walls, canyons or tall cliffs around that keep the game thinking in "room" terms while giving the illusion of being outdoors. Try running around the Half-life "surface tension" areas with r_speeds on to get an idea. These desert maps are fabulous, and yet they easily stay within acceptable r_speeds.

This can also put a damper on city maps. These are still possible (check out cs_italy) but it's important to remember that again, don't make wide open areas. Especially avoid big empty streets lined with hollowed buildings and windows into every room. (Windows won't visblock, since even a small gap into a room allows VIS to work on every room and the streets will have really high r_speeds!)

Conclusion
Thus concludes my r_speeds tutorial. Hopefully it will change your maps for the better. If you have questions feel free to ask around on the forums. Also, be sure to check those links for more information about each section.

Thanks to Gollum for those images explaining visblocking.