The purpose of this article is very simple and straightforward: to identify common misconceptions in Source engine optimization process thus allowing people to avoid the costly pitfalls that could hinder their maps’ optimization setup.
I collected these misconceptions from people messaging and asking me about optimization, various forum threads in which I was helping the submitter with an optimization issue, and from comments and inquiries received on my papers and articles regarding optimization. It’s not an exhaustive list but it covers the most common misconceptions.
In presenting these misconceptions and using technical terms, I am fully assuming that you have at least a basic knowledge of the Source optimization process and techniques. For this reason, it is a prerequisite to read the Valve developer Wiki on optimization, followed by my comprehensive Source optimization papers Man vs Engine and Optimization Testing in Source Engine, and finish with my practical placement guide series on hints, areaportals and occluders.
Most common misconceptions
As I mentioned earlier, this list is not comprehensive, however, it pinpoints the most common misunderstandings that one is more likely to fall for. If you are aware of all these misconceptions, then good for you; you know your stuff. If you thought any of these was true, then it’s time to shake things up and turn a new leaf in your optimization chapter.
Not knowing Source/visleaves/BSP is not a big deal!
This is the ultimate winner in the “miss-conception” contest (not a beauty pageant like Miss World, mind you). Most beginners usually skip the “technical” details of the source engine and jump straight into level building; big mistake.
Until you know the source engine inside out, you will mostly be fighting losing battles. You’ll be randomly placing hints and areaportals, not knowing exactly what you want to achieve.
If you think PVS is a chemical compound and BSP stands for Big Squeaky Pistol, then it is high time to brush up on your Source terminology. Knowing at least the basics of the BSP theory and how the engine carves and divides visleaves is key to master your optimization process.
In my paper Man vs Engine, paragraph II spans 3 pages and explains the BSP concept as well as the Source visleaves in a friendly and approachable way that beginners and veterans alike will find easy to follow. If you’re feeling adventurous afterwards, then feel free to scout for in-depth technical papers on the BSP theory (papers written in the late 90s in the Quake era still apply).
Not measuring optimization/fps gain is OK!
Knowing the Source engine by heart and being able to come up with an ultra-sophisticated optimization system means literally nothing if you cannot measure the frame rate gains (or lack thereof) of the said system.
It is not OK to just optimize the map without actually measuring and gauging the progress in the fps department. Measurement complements optimization and one is incomplete without the other. Since measuring involves numbers, this means a standard procedure can be developed; SCIENCE.
I have shared my own devised procedure for testing fps and the overall efficiency and effectiveness of the optimizing system in a map. It is all nicely and clearly laid out in my paper Optimization Testing in Source Engine.
Too many areaportals is bad!
For areaportals (as well as for hints and occluders for that matter), there is no golden rule or magic number that you need to stick to for the total number. An overkill in optimization will start to negatively impact the overall performance due to the cost of the areaportal itself; going overboard with optimization will start to give you quite the opposite of what you want: lower fps.
The map itself dictates the number; it is a combination of map size and complexity: the larger and visually complex the map is, the more areaportals (and hints) will be needed to control visibility. Some maps can get away with as little as 10-15 areaportals while others will require 40-50 to keep your fps in check. In a previous project I worked on, I have devised one of the biggest, most complex optimization systems that I have ever worked on: 71 hints, 91 areaportals, and 5 occluders. The map was very complex both visually and layout-wise and warranted these high numbers. Of course, I'm not telling you that every map needs these numbers but don't be afraid of figures if the map dictates so.
How to tell then if your areaportals are adequate or if you need to add some more? The answer is testing, more specifically systematic fps testing. It is all clearly and methodically explained in my technical paper Optimization Testing in Source Engine
If you add 3 areaportals to a certain area and you get 240 fps, then you decide to add a 4th one in the hope of further improving frame rate; you test again and get 241 fps (or in worst cases 230 fps). This result is a clear indication that this 4th areaportal is totally not needed since the fps gain is negligible (1 fps) or negative (-10 fps). This scenario means that your 4th areaportal is not contributing to raising fps and its cost is outweighing its benefit.
Hints are overrated, the engine can divide leaves alone!
Many mappers leave visleaves’ division to VBSP but do not know that vbsp does a not-so-brilliant job in this regard. Whether you like it or not, a manual intervention with hint brushes is mandatory to ensure proper visleaves’ cuts across the map.
The first casualty of vbsp is usually horizontal visleaves cuts. Granted that many visleaves will be divided horizontally along the brushwork, many others will be left soaring to reach the sky, literally. The visleaf will go from ground level to the skybox level and once you stand in this visleaf, surprise, surprise, the whole map will be rendered at once (refer to Man vs Engine and the hints practical guide for a full explanation of this issue and the “visibility from a region” approach used in the BSP).
Another casualty is vertical hint cuts and my favorite poor vbsp judgment is something I like to call the poking hallway; it is simply when a visleaf extends through a hallway, corner, doorway, or window beyond their edge, which allows this visleaf to see other visleaves in the vicinity and render their content, needlessly putting an overhead on the engine.
Whenever the engine over-renders and “sees” more than it should, the fps will suffer and the map will under-perform.
Too many func_detail is good for fps!
Don’t get me wrong on this one, func_detail is the quintessential tool in your optimization tool bag and one of the deadliest weapons in your arsenal for your constant battle against the Source engine on the optimization front.
One has to be careful not to go overboard with func_detail though. I’ve seen folks turning almost the entirety of the map into func_detail, thinking that they are doing themselves a favor. Remember that you still need regular world brushes to cut visibility and to serve as a base on which you add your hints and areaportals. Make it a rule of thumb to keep your backbone brushes as regular world brushes (and as square/rectangle as possible to ensure a clean, uncluttered PVS), and switch your detail, decorations, and awkwardly-shaped brushes into func_detail.
Having too many func_detail in the map will get you closer to the maximum brush-count allowed in Source. If the amount of tiny func_detail reaches insane levels in concentrated regions of the map, then the fps will start to take a slight hit (you can watch the world rendering bar spiking when viewing the budget panel “+showbudget”), not to mention that parts of your brushwork in that region will start to appear/disappear when viewed from certain angles due to over-rendering and stressing the engine. In this case, switching to props and displacements will be your best bet to fight these symptoms.
Texture scale will affect fps!
This is true…if you still work in GoldSrc engine making levels for Half-Life 1. However, since this article covers Source engine optimization, I am afraid I have to break the news to you and tell you that this is…not true anymore in Source.
In GoldSrc, the lower the scale of a texture, the higher the polycount on the brush face, the higher the r_speeds and, you guessed it, the lower the fps. This was all governed and limited by the archaic and modest hardware available at that time (late 90s) compared to modern setups.
In Source engine, running on a proper modern gaming rig, this “rule” is obsolete. Even if you downscale your whole map textures to half or quarter of the original scale, your fps won’t budge (unless you still play on a Pentium running Windows 95 circa 1997).
What you should be aware of when downscaling textures is the ugly repetitive pattern that will get exaggerated on large surfaces.
Func_viscluster is good for optimizing!
This is a very common mistake that is simply not true.
Some people tend to confuse between in-game performance and vvis compile time. Basically, a func_viscluster tells vvis that all leaves contained within its borders can “see” each other, therefore, vvis should not perform any visibility calculations between them, which will result in shorter vvis compile time. This is great if you know how to properly use it in large open areas to curb vvis’s enthusiasm and propensity for crunching numbers. If you randomly use it though, results could be catastrophic as you would be preventing vvis from doing legitimate visibility calculations and forcing the engine to draw unnecessary additional visleaves that could have been appropriately culled by vvis or by proper hint brush usage.
So in short, func_viscluster is not an optimization technique and is not a substitute for hints and areaportals. If you notice that vvis is abnormally slow and taking forever to finish, then think of optimizing your map not visclustering your leaves.
A long vvis time means a badly optimized map!
VVIS shouldn't take long for most maps and should finish in a matter of seconds (multiplayer maps at least). In the case of the map I mentioned above in the third paragraph about areaportals numbers, vvis took around 20-25 minutes because of the sheer complexity of the visleaves but it was totally justified with the significant fps gains in-game (sometimes you have to sacrifice vvis time for in-game fps gain).
If the portalflow in the compile log is taking too much time for a small, simple map, then you guessed it...the map is un-optimized where vvis is spending too much time calculating visibility for additional useless visleaves.
As we have seen earlier, there are a lot of misconceptions, mostly costly ones that could sidetrack the level designer and put them on the wrong optimization track.
It is very imperative to know the Source engine and the optimization techniques, but equally important is to be able to identify the general misconceptions that are passed across “generations” of level designers.
I hope that I have shed enough light in this short article to help demystify some optimization “myths” and bust them once and for all.
August 27, 2015