Optimize a Map in Hammer Editor

Revision as of 04:40, 12 January 2016 by Kipkis (Kipkis | contribs) (importing article from wikihow)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Do you want to speed up your custom map's performance, not get bogged down in rendering hiccups and reduce compile time? Here are some tips to help you optimize any map in Hammer.

Steps

  1. Seal off rooms. This is a must. If there are ANY leaks in the map, the compiler won't be able to determine the boundaries of the map, and will attempt to render everything within the map all at once. Worse yet, any area portals, hint brushes and occluders in the map will not work, making them useless. Also, water won't render correctly if there are any leaks in the map.
    • In Fig. 1a, the room is obviously not sealed. If you compile this map with that leak, vvis (the portion of the compile that determines visibility data) won't be able to determine the boundaries of the map, since the visleaves  will just "leak" out into the black void outside our map.
    • In Fig. 1b, the room is sealed and will be compiled correctly.
    • To check for leaks, first make sure there is at least one entity in the map (such as an "info_player_start"), otherwise this will not work. Save and compile the BSP by pressing F9 or going to File -> Run Map. Select "Normal" for Run BSP, and select "No" for both Run VIS and Run RAD (also be sure to check the "Don't run the game after compiling" box). Once it's done compiling, close the compile log and go to Map -> Load Point File. If there are any leaks, it'll ask you to confirm the operation (ex. "Load default pointfile? [C:\Program Files\------>]) Select "Yes", and you'll see a red line protruding from the nearest entity* out through the area of the leak. (*This is why you need an entity, either brush or point, in your map. It doesn't work with world or detail brushes.) Seal the leak, recompile the BSP, and load the pointfile. If all is sealed, it should just go to an empty folder in the Steam\steamapps\GAMERTAG\GAME\mapsrc folder. Always check for leaks before the map is released to the public.
  2. Create brushes with "tools/toolsnodraw". Make sure you always create brushes with the tools/toolsnodraw texture first and then texture only what the player can see from the player's point-of-view. If you are only going to see one side of a wall, then texture that visible side only.
  3. Reduce the number of brushes and faces. Whenever possible, stick to creating geometry with a few large brushes rather than a thousand small ones. More brushes equals more faces, and more faces equals slower performance and compile time. Bottom line: if you can create complex geometry with one or two brushes, why use any more than that?
    • In Fig. 3a, there are two brushes: the one on the left was created using the Arch Tool which created an 8-sided brush with 40 faces, and the one on the right was made from a single clipped brush with only 11 faces. The latter was achieved by utilizing the Clipping Tool (Shift + X). To achieve the latter, it is recommended to first create the desired geometric shape out of the Arch Tool first for reference. Then, create a brush with the same length, width, and height as the reference arch and place it slightly above the reference. Select the brush and clip the angles. (you may need to change the grid size ("-" to decrease, "+" to increase) and/or manually move the vertices (Shift + V) of the reference arch to snap to the nearest grid point.) Now you have a geometrically identical brush, but only with fewer faces!
  4. Make good use of detail brushes. World brushes block visibility, seal the map, and split the BSP into "leaves", which are basically the compiler's way of determining what can and can't be seen at any given time and place. Detail brushes were designed to essentially be "invisible" to the compiler. The only brushes that should be world brushes are the walls, floor and ceiling of a room. Pretty much everything else in the room that isn't a working entity and doesn't significantly block the player's vision should be tied to a func_detail brush (tie using Ctrl + T). Since detail brushes don't block visibility, they won't be compiled in vvis calculations and won't split the map into more visleaves (which is good in most cases). Be warned though that it won't seal the map either. Just make sure that all the world brushes seal the map and there shouldn't be any problems.
  5. Use area-portals and hint brushes appropriately. Area-portals and hint brushes are great ways to limit visibility and increase performance if done correctly. However, you should not place these in every corridor and window, as the amount to calculate what's supposed to be rendered and when could very well surpass that of just rendering the entire room all at once. Instead, you should only separate rooms with lots of details. This will spare your computer having to render many unnecessary objects, and help increase performance without putting a major strain on visibility calculations.
  6. Use occluders (sparingly). Occluders are similar to a closed area portal, as it doesn't render what is behind it. However, it is different than a closed area-portal in that it doesn't need to seal a room (it can be free-standing and not touch world brushes) and it only blocks 3D models (aka props). This tool is very costly in terms of memory usage, so you should only use occluders when there is an expensive 3D model behind a free-standing wall that cannot be sealed by areaportals.
  7. Add 3D Sky-boxes. Not totally necessary, but it'll help make the map look much larger without drastically slowing down FPS (frames per second). 3D skyboxes are usually made for "large" outdoor maps, but it is possible to make it for an indoor map if you can see an exterior through a window or something. 3D skyboxes are very cheap to render and can make a small map appear up to 16x larger since 3D skyboxes are set to a 1/16 scale in Hammer and then scaled up during compile.
  8. Add fog. On large outdoor maps, fog can limit the amount of detail being rendered, and it can make your map look more realistic in the process. Simply add an env_fog_controller entity in your map. On the "Enable Fog" option in the Object Properties tab, select "Yes". Next, edit the Far Z Clip Plane to your liking, which will remove all brushes after that distance, eliminating the engine rendering unnecessary objects (The Far Z Clip Plane value should be greater than the Fog End value).
  9. Don't go crazy on the Lightmap Scale. The lightmap scale essentially determines how sharp or blurry shadows are rendered on geometry. Larger numbers degrade the shadow quality, but can increase performance. Contrariwise, a lower lightmap scale increases the visuals of the shadows, but can severely lower performance. Either too large or too small of a lightmap scale could produce an unrealistic lighting effect that is either too dull or too sharp, respectively. The default lightmap scale for all brushes is 16, which is a balanced area between visuals and performance.
  10. If your map has water, place a "water_lod_control" entity in the map. This entity determines how far away you have to be from "expensive" water in order for it to transition to "cheap" water. Expensive water looks much more realistic than cheap water, and therefore costs more in terms of memory usage and calculations on the computer. A shorter transitional distance will produce cheaper water at a shorter distance, and therefore will lose a lot of visual quality when at a distance, but will also increase performance.

Tips

  • Displacements do not block visibility, so to make sure the map is sealed, create a world brush with the tools/toolsnodraw texture underneath the displacement and seal the map with it (i.e have the corners of that brush touch the corners of the skybox). Like in the first step, always make sure the map is sealed, otherwise virtually every optimization technique that was mentioned is thrown out the window and into the black void of the Source engine.
  • This article assumes you have basic knowledge of Hammer Editor's interface (creating brushes, placing entities, tying entities, etc.), so if you're new to mapping and don't understand this article, it is highly recommended that you check out the links provided under Sources and Citations for more in-depth articles on the steps explained in this article.
  • When creating areaportals (by creating a brush textured with tools/toolsareaportal and tying it to func_areaportal), it is very important that the sides of an areaportal that aren't being viewed through are touching world brushes. For example, if you want to place an areaportal in a doorway, but that doorway has a frame tied to func_detail, you would not have the areaportal brush touching the doorframe because it is func_detail (and since func_detail brushes don't affect visibility, the compile log will come back with a leak). Instead, the areaportal brush should be touching the walls, ceiling, and floor of the door (which should all be world brushes), intersecting the doorframe. Don't worry that there might be "z-clipping" around the door frame; the frame is still going to be rendered correctly in game . . . it's simply there in Hammer editor for the compiler to use during vvis.
  • When creating hint brushes, only texture the faces acting as hint planes (the faces which will split the BSP) with the tools/toolshint texture. Texture every other face on the brush not acting as a hint plane with tools/toolsskip, otherwise you'll be creating more visleafs than you want.
  • You can link an area-portal's Open/Closed state to a working door such as a func_door, func_door_rotating or a similar entity. To do this, the door to which you want the areaportal to link needs a unique "name". (Give the name by double-clicking on the door to open up its Object Properties window and give it a simple name under Name in the Class Info tab.) Once you have the door named, go to the areaportal's Object Properties and scroll down to "Name of Linked Door" and select the door to which you want to link the areaportal. Also (and this is very important) you need to set the Initial State of the areaportal to the Initial State of the door. What this does is to ensure that when the door is closed, the areaportal closes with it. If you're curious about what exactly the Open/Closed areaportal states dictate, if an areaportal is Open, all visleaves that are visible through the other side of the areaportal are rendered. Contrariwise, if the areaportal is Closed, then nothing beyond the areaportal will be rendered. So if there is an open hallway that you'll always be able to see into, the Initial State of the areaportal should be set to Open, not Closed. And when linked to a door, you won't be able to see past the door anyway, so set it to Closed if the door spawns closed (unless it has a transparent window, which then you should have the areaportal set to Open and don't even bother linking it to the door).

Warnings

  • Never make a complicated brush with the Hollow Tool. The vertices (corners of the brushes) will be intersecting each other and will just create a big sloppy mess.
  • Only use occluders as a last resort. It is very memory-intensive, so if a prop can be sealed in a room with areaportals or if it's possible to split the visleaves with hint and skip brushes, then opt out of using occluders.
  • Open areaportals are much more memory-intensive because the visleaves are calculated in realtime. It is advisable to use either closed areaportals or hint brushes as often as possible.

Things You'll Need

  • A computer
  • Steam
  • Source SDK Base 2007, or Source SDK Base 2013 Singleplayer / Multiplayer (Can be downloaded from the Tools tab on Steam)
  • Source SDK (Can be downloaded from the Tools tab on Steam, but this is only required if using base 2007, if using 2013, do not bother downloading Source SDK as it is included with the download for Source SDK base 2013).
  • Hammer editor (comes with SDK)
  • Basic/Intermediate knowledge of Hammer Editor

Related Articles

  • Add Water to Your Map in Hammer Editor
  • Make Custom Portal Maps in Hammer World Editor
  • Make a Map With Valve Hammer Editor

Sources and Citations

You may like

Retrieved from "https://kipkis.com/index.php?title=Optimize_a_Map_in_Hammer_Editor&oldid=38286"