Cleanup is going to take awhile, so the site is back up but editing has been disabled.

From HalfLife 2 Knowledge Base

by Motionblurrr

This tutorial covers contains some helpfull key bindings and methods to optimize your map.

Optimization (General/Other)

First of all, as you probably already know, bind a key to +showbudget. This will give you an overview of the time it takes to render different elements that are on screen.

Secondly, create a cfg file, (call it dev.cfg or whatever you want) and place it in your \Steam\SteamApps\[account@name]\[game name]\[game abbrev]\cfg folder. For example, \Steam\SteamApps\mapper@inter.net\half-life 2 deathmatch\hl2mp\cfg is for Half-Life 2 Deathmatch. Paste the following into this file and save it (change the keys that I've bound to these aliases if they conflict with your normal gameplay keys):

alias wire1 "mat_wireframe 1;echo mat_wireframe 1;alias togglewire wire2"

alias wire2 "mat_wireframe 2;echo mat_Wireframe 2;alias togglewire wire3"

alias wire3 "mat_wireframe 3;echo mat_wireframe 3;alias togglewire wireoff"

alias wireoff "mat_wireframe 0;echo mat_wireframe OFF;alias togglewire wire1"

alias togglewire "wire1"

alias +nostaticprops "r_drawstaticprops 0;echo STATIC MODELS OFF..."

alias -nostaticprops "r_drawstaticprops 1;echo STATIC MODELS ON..."

alias +noothermodels "r_drawothermodels 0;echo OTHER MODELS OFF..."

alias -noothermodels "r_drawothermodels 1;echo OTHER MODELS ON..."

alias +nodisp "r_drawdisp 0;echo DISPLACEMENTS OFF..."

alias -nodisp "r_drawdisp 1;echo DISPLACEMENTS ON..."

alias +nodetailprops "r_drawdetailprops 0;echo DETAIL PROPS OFF..."

alias -nodetailprops "r_drawdetailprops 1;echo DETAIL PROPS ON..."

alias +nooverlays "r_renderoverlayfragment 0;echo OVERLAYS OFF..."

alias -nooverlays "r_renderoverlayfragment 1;echo OVERLAYS ON..."

alias +nodecals "r_drawdecals 0;echo DECALS OFF..."

alias -nodecals "r_drawdecals 1;echo DECALS ON..."

alias +nosprites "r_drawsprites 0;echo SPRITES OFF..."

alias -nosprites "r_drawsprites 1;echo SPRITES ON..."

alias +noparticles "r_drawparticles 0;echo PARTICLES OFF..."

alias -noparticles "r_drawparticles 1;echo PARTICLES ON..."

alias +noreflections "r_waterdrawreflection 0;echo REFLECTIONS OFF..."

alias -noreflections "r_waterdrawreflection 1;echo REFLECTIONS ON..."

alias +norefractions "r_waterdrawrefraction 0;echo REFRACTIONS OFF..."

alias -norefractions "r_waterdrawrefraction 1;echo REFRECTIONS ON..."

alias +noentities "r_drawentities 0;echo ALL ENTITIES OFF..."

alias -noentities "r_drawentities 1;echo ALL ENTITIES ON..."

bind v +nostaticprops

bind b +noothermodels

bind n +nodisp

bind m +nodetailprops

bind , +nooverlays

bind . +nodecals

bind / +nosprites

bind ' +noparticles

bind \ +noentities

If you haven't already done so, create an autoexec.cfg file in the same folder as your dev.cfg file and add the following line: exec dev.cfg

The game automatically looks for this file and launches it when you start your game. I use it to launch several seperate files, but I suppose you could just throw everything into this file if you wanted to.

Now, when you launch your map, hold down the buttons you have bound and it should turn off the respective screen elements, such as all prop_static entities. You'll also get a little indication in the top left corner that tells you what you turned off. Release the button to turn the element back on. You can probably only get 2 or 3 buttons held down at once before your keyboard stops taking input so you may want to add several of these elements to a single line in the dev.cfg file. For example:

alias +nomodels "+nostaticprops;+noothermodels;+nodetailprops" alias -nomodels "-nostaticprops;-noothermodels;-nodetailprops"

bind p +nomodels

You can add as many of them to an alias as you want... you get the idea... Now keep in mind that pretty much all of these elements will turn off if you use +noentities, since pretty much everything that's not a brush is an entity.

Walk around your map and find an area where you want to see what's slowing you down. I recommend staying in one spot to test each of the screen elements, but that's entirely up to you. Check your +showbudget and see which item is high. Try turning that element off by using the associated key and see what a difference it makes in your FPS. (You might want to get FRAPS as it can throw up a big yellow FPS in the corner which can be easier than the built-in command "cl_showfps 1").

How to deal with the slowdowns:

Prop_static Entities: These are the lines which appear in light blue when you have mat_wireframe turned on. Using a Func_Occluder is the defacto choice for this, but they can be difficult to setup, require the models to be in sealed areas, and can be more expensive than they're worth if you don't block several large models. There are other tutorials that cover the func_occluder, so I will not cover it here.

My recommendation is to setup the fade min distance and fade max distance of your prop_static entities. Unless the models are contained entirely inside of a leaf that is not visible, they will be drawn by your video card, so having them fade out can make a huge difference. Here are some tips for setting fade distances:

-Make sure "Show Helpers" is checked on the view menu Hammer so you can see the spheres representing the fademindist and fademaxdist values.

-Fly through your map in Hammer and put your camera view at the fademindist and fademaxdist to see if you've got the values setup where you want them.

-They do not get any less expensive until the player is past the fademaxdist value (ie: they are still drawn by the video card until they fade out completely)

-The lower the fademindist is from the fademaxdist, the slower the model will fade out and this can make it less obvious that the model is fading out to the player.

-smaller objects should fade out faster as they are more difficult to notice.

-prop_static entities that are inside of a building/room might as well fade out as soon as the player is no longer in visible range of them.

-Test! First just compile your map just using VBSP (since the others aren't necessary for this) and walk through the map and see when the models fade out and how noticeable it is. Keep in mind that when you compile with VRAD (ie: lighting) your fades will probably be much less noticeable unless your map is really bright.

Other Models: Pretty much the same as the Prop_static Entities section, although you may want your fademindist and fademaxdist values to be a bit higher on physics models (such as prop_phyiscs, and prop_phyisics_multiplayer) since they could potentially be moved to a place where they can be seen from longer distances.

Displacements: Displacements are very well done in this game as they don't take nearly as much GPU as you might think, but if they do get slow, you may want to lower the triangle count (ie: Power) to 2 or 3. Not much else to do about displacements if they are causing your slowdowns.

Dynamic Lighting: The Point_spotlight entity can cause a great deal of dynamic lighting stress on your map. With more than a couple, you can suck the FPS right out of the simplest of rooms. However, you can keep the cool volumetric lighting effect and the static light by checking its No Dynamic Lighting flag.

Prop_Detail Entities: These are the little things like grass and small vegetation that is automatically generated on some textures. If they are slowing you down, use a texture that doesn't have them... although I doubt this is causing anyone any major problems. If you are using this entity class for things that should be static, you may want to switch them to prop_static instead.

Overlays, Decals, & Sprites: Reduce the number of them in that section of your map. I don't think this has ever been a problem for anyone though.

Particles: Might want to lessen the spawn rate of the particles from whatever type of emitter you've chosen. Also reducing the min/max size of the particles and the life/duration should help. I think this would only be a problem on older video cards... anything in the last two years shouldn't have problems with these.

Swap Buffers: This is typically caused by transparent textures/effects such as glass, env_steam, env_smoke, and of course, func_water. As long as it doesn't do it for a large section of your map, you will probably be ok. So if the swap buffers only go crazy when you stare RIGHT into an expensive water texture or some heatwave style env_steam, you probably don't have a problem... that's just what they do.

World Rendering: These are the brushes you created in Hammer. In "mat_wireframe 1" and "mat_wireframe 3", these are the red lines. Don't even bother with this unless you've run VVIS on your map. If you have created hint brushes properly, VVIS should make a large impact on how many brushes are drawn. Hint brushes (and func_detail brushes) are an unbelievable wonderful thing. If you've avoided using them because you're afraid, you need to overcome your fears and use them. I took one of my maps down from taking several hours to run a full VVIS to taking only 15 minutes by using hint brushes and func_detail. I will write a tutorial on speeding up compile times another time.

Other Information:

All of these command can also be very useful in going through the single player levels of HL2 to see how their levels are built. I especially like looking at the destroyed buildings without the static models on so you can see how they fit the brushes with the broken wall/ceiling/floor models.

NOTE: The +noreflections and +norefractions aliases don't do what I expected them to (nor what the console says they do) but I left them in here anyway.

mat_wireframe 1: shows wireframe for everything being drawn by the GPU, including the diagonal edges of each face.

mat_wireframe 2: shows wireframe for every brush face that is currently visible and ALL lines for models being drawn by the GPU.

mat_wireframe 3: shows wireframe for everything being drawn by the GPU, without the diagonal edges of each face.