In this article we'll examine every facet of building an optimized map for Empires. Part tutorial and part analysis, this is aimed at increasing every mapper's awareness and knowledge of the process of optimization, and the techniques and tools at their disposal. I'll be adding to this in parts, starting with the most important methods and moving on to more niche applications and information later. First, a little bit about the concept of optimization itself. Dictionary.com defines it as "an act, process, or methodology of making something (as a design, system, or decision) as fully perfect, functional, or effective as possible." A very vague definition, but it holds true for mapping. More specifically, however, optimization in mapping centers on one thing: The minimization of waste. Every tool available for optimization is there to reduce waste. Waste can appear in many aspects, such as wasted compile time, wasted rendering, even wasted file size. Many mappers assume there is a trade-off between optimization and detail, that you have to somehow choose between the two. The nature of optimization is actually the opposite. Optimization allows and encourages for MORE detail, by virtue of reducing the wasted processing that would discourage more detail. A properly optimized map can have much, much more detail than any unoptimized map and perform better to boot. However, the nature of optimization is that it strives for perfectly optimal scenario. In contrast, there is practically no such thing as an "optimal map." When we optimize, we can never take a map to it's fully optimal extent. This is acceptable though, because we don't try to. We only need to optimize to the point that waste is negligible, "negligible" being the point where the mapper deems it acceptable. There is always a way to further reduce waste in a map, but we only need to bring it to the point where we're happy with it. So why, then, is optimization so often ignored or misused? It's effects are not directly seen by the mapper. It is done by manipulating mechanics most mappers are not aware of, let alone familiar with. Even experienced mappers are not aware of or intimate with ALL the tools at their disposal. Optimization is seen as unnecessary or trivial by mappers with modern hardware. It is seen as too hard to be worth learning about. None of these are legitimate reasons to ignore optimization though, and hopefully none of these will apply to you after learning a bit more. Part 1: The Visibility System Since the Visibility (vis) system used in source maps is arguably the most important and confusing part of optimization for Empires, we’ll start with that. Understanding the vis system. First we’ll take a look at the vis system optimization in some official maps. You can take a look at the visleaves in any map and see what’s being rendered and what’s not with a few commands in console. These were taken by spawning in, walking to parts of the map, entering r_lockpvs 1 in console and then taking an overhead look. These shots of the official emp_canyon show what is being rendered when the player is standing in the rax at the BE or NF start: It’s clear that a lot of the ground on parts of the map the player can’t see isn’t rendered, as well as the rock models and such on the other side of the map (the trees do not appear because their LOD Models can’t be viewed from above). This is a great example of the desired effect of vis optimization. Since a player obviously wouldn't be able to see the other side of the map, vis optimization has been used to save the engine the trouble of rendering it all. It isn't just the terrain that's being culled, it's also applied to anything going on in that area, be it cannon shells and bullet tracers flying around, or buildings and turrets placed there. It seems fairly effective but there is still a bit of waste. There are some smaller areas that the player can't see but are still being rendered. All of the vertical displacements making up the cliffs can be seen, as well. This is a direct result of what we’ll call the “open sky” system that we use in most empires maps. This shot of the official emp_coast shows what is and isn’t rendered when the player is standing on top of the bunker in the middle. We can see that much of the far away ground geometry isn’t rendered, but again, there is still a bit of waste in the form of models and terrain that the player renders but can’t see. The separate vertical cliff displacements are again always rendered because of the nature of the system we use. This last shot of the official emp_slaughtered shows the large difference between what the player sees and what they have to render. We can see that although there is at least some basic optimization there is also a large amount of waste. Slaughtered is different from the previous examples because instead of using separate vertical cliff displacements, the whole map is one mesh of displacements. We’ll look a little closer at the different approaches and how they relate to our vis optimization later. For these next parts I’ve put together an example map that demonstrates the implementation of Optimization concepts in a map layout mockup that’s easily related to most other map designs. I strongly urge you to download it and follow along in it because it’s far easier to learn directly in hammer than follow along on just pictures and text. The map uses displacement geometry from Omni’s Silo, and it is only for example purposes. DOWNLOAD IT HERE As you hopefully know, the Source engine uses “visleaves” as a basis for it's vis optimization (unrelated to "visgroups" in hammer). A map is divided into a number of visleaves, at first into a horizontal grid of 1024x1024 visleaves by the VBSP compile program, and then each leaf is further divided using the faces of every World brush or hint plane in it. Then the VVIS compile program determines, for each visleaf, which other visleaves are directly “visible”. This is called the Potentially Visible Set, calculated using only World brushes (all non-entity brushes, excluding those textured with alpha textures) as “visblocking” brushes. When the player walks around the map, the engine loads the PVS for the current visleaf, and only renders objects in or touching it’s PVS. Since most Empires maps are very large maps constructed completely or mostly with displacements, this leads to two issues: The number of visleaves increases with map area, so exponentially more time is required to calculate the PVS for every leaf, meaning extremely long unoptimized VVIS compile times for fullgrid maps. Virtually every visleaf can see every other visleaf, since displacements or brush entities are ignored by VVIS, and unoptimized Empires maps generally don’t include large world brushes which block visibility. Manipulating the Visleaf system to correct these problems, however, is a simple task that can be done with any map more complex than emp_moors. The way we do this is a technique we’ll call the “open sky." This method involves designating the large open area above the actual playing field as the "sky", with the playing field below divided up by brushes under the terrain blocking visibility between areas of the map that shouldn't be able to see each other. As with any other method, this method has it's advantages and disadvantages; most importantly we have to concede that any player viewing the map from in the "sky area" can see every part of the map. Naturally this is very relevant to the Commander view, however since Commander view chiefly looks down upon instead of across the map, there is less potential use for visleaves, and more benefit from other culling methods such as Frustum culling. The open sky also allows for much easier movement in the Commander view, so all in all the main pitfall of the open sky method is not a problem for us. The advantages of this method are that it is simple, quick to implement, and does not require changing the form or any visual aspects of the map. The open sky system involves adequate use of three things: visblocking, hints, and visclusters. First, we use the technique of visblocking: using world brushes underneath all the major hills or cliffs to block visibility for the PVS calculations.