Introduction

This tutorial helps you understand how the engine renders your map and how to improve the performance. Many tutorials have been written about this in the past, but some of that information is outdated or incomplete. Also, this guide aims to help you through the process of improving the performance by optimizing an example map, rather than just give you generic information. Really good for newbies, but also for veteran mappers as it might give you some new insights.

For this guide we're going to use vluzacn's v34 compile tools and his version of zhlt.fgd. It's got many extra features to optimize the map. Get it here (dead link, Wayback Archive).

I've created a very basic and very badly optimized example map. We're going through some steps to fix it, which will become gradually more advanced. You can skip paragraphs you're already familiar with but if you encounter some terminology you don't understand, look for explanation in earlier paragraphs.

1. Checking the performance

In the main menu, open the console and enter these commands:

developer 1
maxplayers 1
sv_cheats
r_speeds 1
map <yourmapname>

In the top left corner, you'll notice some values:

59 FPS: Current amount of frames/sec.
0 ms: The current latency (lag)(Lower is better btw).
363 wpoly (World Polygons): the amount of brushes (walls and such) being rendered.
53338 epoly (Entity Polygons): the amount of polygons in models being rendered.

Let's start with the optimization of the epolies.

2. Epolies

There are quite a lot of epolies (entity polygons) at work here. The pistol takes up 2,359 of those epolies. You could use a lower detailed pistol and save some epolies but I don't want to sacrifice detail for that. Instead, I'm going to look at my map and see what I can do. Behind the door are 12 monster_human_grunts. Those grunts are currently doing nothing but are being rendered by the engine for 50,979 polies. I only want them to pop up once it's necessary. So I'm going to change them all to monstermaker and name them. Then I'll place a trigger_once in front of the door and target the squadmakers. I'm also going to reduce the amount of grunts to 6 and let others spawn in a few seconds later from behind the crates. This way there will only be 6 grunts rendered at the same time at the most and I only use 25,489 polies max.

Next to the epoly reduction, it will also increase performance since your computers CPU doesn't have to calculate effects and AI, and it will also improve the server load in multiplayer.

3. Wpolies

The wpolies (world polygons) is where you, as a mapper, can make a difference. There are several techniques to improve them but lets first try to understand how the rendering works.

Go into the console and type:

gl_wireframe 1

(Wireframe colour in red is only available in SvenCo-op. In regular HL it will show up in white). You can see how the map is being cut up into squares and sometimes triangles. This is called [B]face subdivision[/B] and it's the way the engine works. Each square/triangle is a face and the more faces, the more polies. This is how the engine sees your map, but that's not the full story. Go into the console and type:

gl_wireframe 2

A lot of extra faces appeared in the room behind the door. Now this is how the engine actually renders your map. You might not see that room, but the engine does and adds the wpolies from that room to the total amount. We're going to try to bring that number down by using some tricks. We'll start with the easy tricks and move down the list to the more advanced measures to optimize our map as much as possible.

3.1 func_wall & func_detail

3.1.1 func_wall

Whenever a brush touches another brush it will generate more faces, as you can see from the following screenshot. The crates touch the floor and generate extra faces there and the pipes cut really bad faces into the ceiling. To stop this from happening, we're going to turn them into func_wall. As you can see, the extra faces are gone and we've nearly saved 100 wpolies here! I'm also going to use this for all the other things in the map, except for the outer walls, since that would cause a leak. Everything in purple is now a func_wall. Everything fine, except for this part: Since I considered them as 1 object, I tied the pipe and the panel into 1 func_wall. This however, makes them cut into each other. Turn the pipe and the panel both into separate func_walls and the problem is gone. When you are using a func_train or func_tank it will be difficult to separate brushes because then the movement of the individual parts might be screwed up. With a func_breakable however, you can set up the individual parts to target the other parts once they break. I mostly set up small details to break only by trigger and only have the larger part of the breakable take the damage.

3.1.2 func_detail

Instead of func_wall, you can also use func_detail. func_detail can also help to prevent unwanted face cuts but it works in a slightly different way.

You can put two func_detail against each other but they will then start cutting into each other's faces. What's going on? If you look into the properties of the func_detail, you'll notice an entry called 'Detail level' or zhlt_detaillevel. Faces on brushes with the same detail level number will cut into each other. In this case, both entities use detail level 1 and cut into each other: To fix this, I can set the detail level of the smaller func_detail to 2 and thus remove the cut. This is a simple example but with complex objects it can become tricky to figure out which detail levels to use. To truly grasp the concept, you'll have to see the map as the compiler does. Even though your entire BRUSH is a func_detail, the compiler only cares about the individual FACES. It's the FACES that carry the detail level information.

The compiler checks if a face is being cut into by another face that has the SAME or a LOWER detail level. If that is the case, then a cut is made. If the detail level is HIGHER then no cut is made. Here's an example: On the left side, a face with level 2 cuts into a level 1 face. 2 is HIGHER than 1, so no cut is made. On the right side, a level 2 face cuts into a level 3 face. 2 is LOWER than 3 so a cut is made. To make sure no unnecessary cuts are made, you'll have to set it up like so: So, as a rule of thumb: the LARGER face should have the LOWEST detail level. If a small thing cuts into a big thing, make the big thing level 1 and the small thing level 2. Here's a right example and a wrong example: As the compiler only cares about individual faces, you can put as many func_detail together as you like without any issue. As long as you stick to the rules of the detail levels. When objects become more complicated you might need to add more detail levels to prevent cuts. In the example below, I had to assign level 3 to the diagonal beam, to make sure it would not cut into the level 1 and level 2 faces. Adding more detail levels will slightly slow the compile time and increase the BSP size, so do not go overboard when assigning detail levels. If you put your head to it, you'll figure that you often do not even need more than 2 or 3 levels to fix your face cuts. Just a few clever tweaks made this lamp model go from 220 to 136 wpoly and detail level 3 was only used once. When using func_detail make sure not to set the detail level to 0 because that's the level of all normal world brushes.

The benefit of using func_detail is that they do not count towards the model limit, as func_walls do. However, using func_detail can lead to higher wpoly in certain cases, because they will render outside of your Field of View (FOV). More on this in paragraph 5.1 (Part 3).

3.2 NULL

As wireframe mode shows us, the engine renders far more than we can see. Also some faces that players are never going to see. Luckily you can manually remove these by putting the NULL texture (from zhlt.wad) onto that face. Like the backsides of these crates: players will not be going there so I'm going to put the NULL texture on there, so those faces will not be drawn. This way I'm saving some more wpolies. But you don't have to NULL all and every backside. The compiler already takes care of that for you, but not always. Go into the console and type:

cl_noclip 1

When I fly around my map I see many faces already removed by the compiler. The compiler will remove all backfaces on world geometry and all func_detail brushes. It doesn't do so on brush entities, like this func_door: All brush entities (like func_wall, func_door, func_rotating, func_train, etc.) will keep all their faces. You're going to have to manually use the NULL texture on the backfaces of these entities. Because many of those backfaces aren't lit, it is sometimes hard to see if a face is there or not. Get really close to the face and then activate the flashlight to see it better.

3.3 Texture scaling

Another way to improve the wpoly is to scale the textures up. The textures will become a bit blurry because of the scaling, so I'm going to use it on a texture you won't see up close: the ceiling. I'm using a value of 2.0 for the scale. Let's compare the results. The top half is the ceiling on scale 1.0 and the lower one 2.0. On scale 1.0 there are 4 horizontal faces and on 2.0 only 2, thus there is a reduction of 30 wpolies. It's good to know this trick, but just scaling up isn't always going to help or even necessary. It's better to know exactly why this happens, so you'll have to know a bit more about face subdivision.

3.4 Face subdivision

The wireframe mode shows you quite clearly where the faces are being made but how does the engine determine those? The engine creates a new face every 240 pixels when a texture is on scale 1.0. Scaling the texture up will also increase that pixel limit. So on 2.0 the faces are being cut at 480 pixels, and on 0.5 on 120 pixels.

Knowing this, you can experiment to find the optimal scale rate. If you look closely at the 2.0 scaled ceiling you can see that the faces on the left are smaller than the faces on the right. That means that this scale is not fully efficient. So I'm going to scale it to 1.75 and compile again: As you can see, the faces fit the ceiling perfectly at this scale and we didn't lose a single wpoly. Yet, the texture looks a little bit better! The only way to improve the wpoly now is to scale it up to 3.5 (creating 1 large face across) but that would make it look horrible. So, some guides might tell you to scale up your textures to ridiculous amounts but now you see that it's not useful to do that.

3.5 256x textures

Now you know that faces are being made every 240 pixels, which means that 256 units high walls with 256x (or larger) textures will always make an additional cut, as you can see here: So, I'm going to grab the texture (C3A2A_W3) from the halflife.wad with Wally and export it to a TGA. Now in Photoshop (or any other editor) I'm going to reduce the size of the texture from 256x96 to 240x96. Make sure you always use a power of 16 or Wally won't accept it when you upload it into your own WAD file. I'm going to rename the texture to C3A2A_NEW, so it doesn't conflict with the original. Then I'm swapping the new texture with the old and setting the scale to 1.067. This will make the 240x texture fit perfectly on the 256 units high wall and will also be the perfect scale for the face subdivision. Let's compile and see! The faces now fit perfectly and I've already won 20 wpolies in this corner! There is a tiny loss in quality (it has 16 pixels less) but it's hardly noticeable on this texture and there is quite some gain. Since the face subdivision is 240, 240x240 textures are the perfect size. However you scale them up or down, it will always give you the most ideal quality/wpoly balance.

Some guides might frown upon 240x textures, because older version of the engine scaled the textures down to 128x first and then back up to 240x resulting in a very blurry texture. As of October 2019 this problem has been removed in the Steam release of HL, so 240x240 textures are as sharp as they are meant to be! More info on that topic here (dead link, Wayback Archive).

3.6 Texture alignment

Faces are also affected by the alignment of a texture. Like this example: sometimes grass or sand can look better if you rotate the texture, but that also means the faces are being rotated. Using no rotation means less faces are being generated in this area. So if you really want a better effect you're better off editing the texture itself. The alignment also matters, especially on sloped surfaces. This wedge uses the FACE alignment which makes it shrink a bit horizontally and thus generating another face cut. Setting the texture to WORLD alignment fixes this problem and gives us back 1 wpoly. Texture alignment is also very important wherever 2 brushes meet, like in this corner: If you look closely, you can see that these textures are not properly aligned to each other. And above you can see the result of it in game, it created an extra face. To fix this, align the textures by selecting one of them, and then RIGHT CLICK on the other (Lift+Select mode should be on by default). As you can see, the problem was solved: It's easy to miss those faces, so a general good practice is to cut corners with a diagonal line. This way there won't be a potential extra face and I was also able to create a way better looking effect on the top of the brush. Some guides claim that this practice will always improve wpoly, but as you can see it actually comes down to the alignment of the textures in adjacent brushes.

3.7 Texture merge

Very often, you see mappers use multiple textures on walls to make maps look interesting. Many texture packs even come with these 'border'-textures. They are smaller (32x or 64x) textures with the same visual style, which can accompany a larger texture (128x or 256x) to create a nice effect. Here is an example from the hl.wad: The lower border texture is 64px high and the higher main texture is 128px high. And since they're separate textures, additional faces will be created. It looks like I'm going to use this combination a lot, so a little math tells me that merging these two textures will result in a single 192px high texture. This is well within the 240px face subdivision cut-off, so definitely worth the effort. I'm exporting both textures from the hl.wad, combining them into a new texture and load it into game. And there you have it. Looks exactly the same and we've saved half the wpoly! Even if you're combining two 128px textures into one 256px texture then simply rescale that texture to 240px and you're back within the face limits.

3.8 -subdivide

So, we've read about the face subdivision limit, which is 240px. However, there is a compile command that can override this limit and create larger faces and thus less wpoly. I'm going to add -subdivide 256 to the BSP option and here is the result. Only 182 wpolies, which is quite a gain in performance! So why haven't we used this before? Well, there is a very likely chance this option will cause your compile process to crash once it reached RAD. Over-scaling the face subdivision can interfere with the way the engine handles the lightmap. If your map is simple and small enough (like mine), you might try to give this a shot. But as said, it's very likely this won't work for your map, so I'm not going to include this technique in my final optimization results.

3.9 Results

So, back to our starting area. With these simple tricks we've managed to bring down the wpoly from 363 to 205 from this point of view. This is a great improvement, especially considering we haven't touched the main design of the map. Yet, there are more ways to make this map perform even better. Let's dig deeper into the workings of VIS.