Source SDK Tutorial - Optimizing
How to Optimize a Map in Hammer Editor
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" forRun BSP, and select "No" for bothRun VISandRun 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 theSteam\steamapps\GAMERTAG\GAME\mapsrcfolder. Always check for leaks before the map is released to the public.
Create brushes with "tools/toolsnodraw".Make sure you always create brushes with thetools/toolsnodrawtexture first and then textureonlywhat 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.
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 theArch Toolwhich 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 theClipping Tool(Shift + X). To achieve the latter, it is recommended to first create the desired geometric shape out of theArch Toolfirst 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!
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 afunc_detailbrush (tie using Ctrl + T). Since detail brushes don't block visibility, they won't be compiled invviscalculations 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.
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.
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.
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.
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 anenv_fog_controllerentity in your map. On the "Enable Fog" option in theObject Propertiestab, select "Yes". Next, edit theFar Z Clip Planeto your liking, which will remove all brushes after that distance, eliminating the engine rendering unnecessary objects (TheFar Z Clip Planevalue should be greater than theFog Endvalue).
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.
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.
Ask a Question
200 characters left
Include your email address to get a message when this question is answered.
- Displacements donotblock visibility, so to make sure the map is sealed, create a world brush with thetools/toolsnodrawtexture 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 underSources and Citationsfor more in-depth articles on the steps explained in this article.
- When creating areaportals (by creating a brush textured withtools/toolsareaportaland tying it tofunc_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 tofunc_detail, you wouldnothave the areaportal brush touching the doorframe because it isfunc_detail(and sincefunc_detailbrushes 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 duringvvis.
- When creating hint brushes, only texture the faces acting as hint planes (the faces which will split the BSP) with thetools/toolshinttexture. Texture every other face on the brush not acting as a hint plane withtools/toolsskip, otherwise you'll be creating more visleafs than you want.
- You can link an area-portal'sOpen/Closedstate to a working door such as afunc_door,func_door_rotatingor 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 itsObject Propertieswindow and give it a simple name underNamein theClass Infotab.) Once you have the door named, go to the areaportal'sObject Propertiesand 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 theInitial Stateof the areaportal to theInitial Stateof 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 theOpen/Closedareaportal states dictate, if an areaportal isOpen, all visleaves that are visible through the other side of the areaportal are rendered. Contrariwise, if the areaportal isClosed, then nothing beyond the areaportal will be rendered. So if there is an open hallway that you'll always be able to see into, theInitial Stateof the areaportal should be set toOpen, notClosed. And when linked to a door, you won't be able to see past the door anyway, so set it toClosedif the door spawns closed (unless it has a transparent window, which then you should have the areaportal set toOpenand don't even bother linking it to the door).
- Never make a complicated brush with theHollow 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 withhintandskipbrushes, then opt out of using occluders.
- Openareaportals are much more memory-intensive because the visleaves are calculated in realtime. It is advisable to use eitherclosedareaportals or hint brushes as often as possible.
Things You'll Need
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).
Video: Hammer Tutorial V2 Series #21 "Optimization"
Your salad drawer may not be as healthy as you think
Why Conservative Women Are Ok with Harassment
How to Pick a Bedroom Theme
How to Sew a Bandana for a Dog Collar
How to Make Chain Armor in Minecraft
Susanna Reid’s Pretty Dress from Debenhams Is On Sale
Easy DIY Yoga Headband To Enjoy Summer Workout
Managing Hepatitis C and HIV
Carpal Tunnel Syndrome Treatment
Beauty brands with lots of shades
Date: 09.12.2018, 15:23 / Views: 72235