It's easy to create a map that older (or even newer!) computers will struggle to draw at sixty frames per second. This article is the hub for all information on how to to prevent that by optimizing your map.1-Areas
3- Tips & Recommendations
There's no excuse! Leaks will invalidate almost all of your efforts elsewhere.
Reducing the number of surfaces and objects that are drawn in the first place. The single most important area.
Various tricks to avoid overloading the CPU with physics calculations.
Correct material choices will allow your map to scale down its demands on slower computers.
Performance and file-size optimisation.
A properly optimized skybox will significantly reduce lag and map size.
-CommandsThere are many more useful console commands than the ones listed here.
Note: Most performance-related commands require
A simple output of framerate.
1 is real-time,
2 is averaged over the past second.
showbudgetA panel which displays how your computer is spending its budget for each frame. It's the premier tool for working out exactly what's sucking up performance in your map. It's invoked with
-showbudget, which means that you can bind the former to a key (i.e.
bind <key> +showbudget) and it will only appear when you hold that button down.
A console variable that (when active) displays visleaves. The number of the leaf, area and cluster of the current leaf is reported in the console.
-Tips & Recommendations1- Try not to create as many polygons or add many props
An unnecessary amount of props can produce a considerable loss of fps
At the moment of creating your polygons do not forget consider turning it into entities func_detail. (This saves compilation time!)
2- Reducing compile time
- Use detail brushes appropriately.
- Keep world brushes on the grid as much as you can. Dimensions in the power of two are good.
- Use simple world brushes. Do not carve unless you're sure the results will be OK.
- Place func_viscluster in large areas with unbroken visibility. Leaves within it will be assumed able to see each other.
- Avoid creating large open areas that the player won't see or interact with in the first place, if it's reasonable to do so. Use a 3D Skybox to reduce sky size, and create a world brush skeleton beneath displacements.
The Orange Box version of Hammer has a new function to view the current map's leaves in the 3D view: Map > Load Portal File. This displays leaf edges that touch other edges as thick blue lines. It's a fantastic learning tool, as if you compile your map without VIS or RAD (then reload its portal file to refresh the display) you can see your changes' effects very quickly.
(HL2-Episode One must rely on the glview application.)
If a player cannot see a brush face without cheating or being a spectator, it's a good idea to apply the special nodraw material to it. Nodraw removes the entire face when the map is compiled without affecting visibility, which reduces both rendering time and, since no lightmap needs to be calculated, map filesize.
5- Areaportals (The Main Performance Solution!)
Areaportals serve two separate purposes: culling geometry and removing entire areas from rendering.
=>that can be used to 'seal' separate visleaves and control visibility<=
Areaportals are like doorways that are either open or closed. When an areaportal is closed, it blocks the visibility of the geometry and other objects in the area behind it. When it is open, the geometry is visible again. Areaportals can be dynamically opened and closed while the engine is running. They are typically set to open and close from sets of
trigger_multiplebrushes using the entity I/O system or by linkage with a door entity.
6- Draw distance
If you are dealing with a large open area without any cover at all then there isn't a lot you can do but remove detail or employ fog to disguise a low draw distance. Configure draw distance with Map > Properties > Far z_clip plane.
Draw distances can also be applied selectively to props, even prop_static, with the Start Fade Dist/Pixels and End Fade Dist/Pixels keyvalues. As the names suggest, these values can represent either distance in units or pixels on-screen as per the Screen Space Fade KV.
If you enter fade distances on props, it’s a good general rule to have the difference between the two numbers (start and end) be 200. It looks pretty good, and the larger that number is, the longer the model incurs an increased cost to render. Fading models do not go through the fast path and incur additional sorting cost.
func_lodis a special brush entity that can fade out. You can't use any brushes tied to it as any other entity, however!<=