Map Optimization

Optimising a map is a balancing exercise between building a great looking map and keeping the polycount under control.

Some History

In UT, level optimisation was primarily about keeping the number of visible polygons to a sensible number (150 polygons was considered about the most you wanted in view in the beginning although most PCs will handle 250 with ease these days. In addition the number of visible objects (or meshes) needed to be kept to a minimum.

Because BSP geometry (the only kind available in UT) automatically occluded things behind it the only tools available for ensuring good map performance were effective Zoning of the map and the simplification of comlpex areas of geometry. In large areas, hiding object meshes behind BSP geometry was also a technique that could be used.

A Change in Occlusion Behaviour

In the original Unreal Engine a piece of BSP geometry would occlude other pieces of BSP geometry, removing them from the rendering queue before rendering started. However, the processing resources required for this behaviour scale with the polygon count. With a hundredfold increase in polycount (in favor of much more detail) it's clearly understandable that there's a huge performance benefit in defining a few simple shapes for occlusion than having the engine automatically process hundreds of thousands of polygons per second.

The result of this is that there are only two map elements that can be used for occlusion. The Antiportal and the Zone. BSP geometry no longer occludes automatically, and static meshes (added after UT) have never had this behaviour.

Techniques

Using Zones

Zoning splits the map up into separate areas called zones. These provide a way for the engine to eliminate a large proportion of the map from what it has to consider for rendering, simply because the player can't see it.

Zones are much less flexible than Antiportals as they are static within the map and can only be formed using BSP geometry. Static meshes cannot be used to form zones.

Even though zones are not as flexible as Antiportals they are much faster to use for in-game occlusion. In addition to giving excellent performance, Zone Portals also only render the geometry you can see through the portals inside the zones they enclose. That is, even if you can see a Zone Portal not everything within that zone will be rendered. However, it is the source geometry of the portal that is used for determining what is visible, not the part of it that creates the zone portal surface. Because of this you should use the 2D shape editor to make your zone portals fit the hole they're filling as close as possible (within reason - don't go above 6 points or so). Note that this only applies to portals you look through. The visibility of a zone portal is determined by the visibility of its BSP polys, so if you're only optimizing for looking at a portal, then its brush size doesn't matter much because the BSP polys will always be the same.

Essentially, if you cannot see a zone then none of the geometry within that zone will be considered by the rendering engine. The entire level segment within the zone is occluded.

A popular optimization technique in the Epic maps is to place zone portals at either end of a hallway. This way if you're viewing the hallway from an off angle the portal at the far end won't be visible through the portal at the near end, and everything beyond the hallway can quickly be thrown out.

In every ZoneInfo it is possible to set an array of zones which will not be rendered if the player is within that zone. This is known as the ZoneInfo manual exclude list, set in the ZoneInfo actor's ZoneVisibility → ManualExcludes property. Note that because zones can only be referred to at the script or map level by referring to their ZoneInfo, you must place a zoneinfo actor in any zone you wish to exclude in this manner. It is possible to make a zone without using a zoneinfo, but you will not be able to exclude it from rendering using the ManualExcludes.

Using Antiportals

An Antiportal is a special type of brush that will occlude objects behind it. It occludes in the same manner as BSP did in UT. It can be any shape you want, and the specific shape does not make a big difference in the performance of the antiportal. Antiportals are relatively slow but if they occlude a large number of polygons it is generally worth it. An anti-portal can, for instance, be placed inside a static mesh to basically make the static mesh occlude, or it can be made to the shape of an existing BSP brush to make that brush appear to occlude. Note that anti-portals are invisible and cannot actually be used to make geometry. If an anti-portal is visible to a player, a HOM effect can occur.

Antiportals are generally used in large outdoor areas or other areas that cannot be reasonably zoned off. For example, if you had an outdoor area with a large hill, it is usually not practical to try to zone of the hill, because you are pretty well always going to be able to see into the other zones, just not into much of them. In this instance an anti-portal could be used to occlude the objects behind it. (see CTF-Magma for a counterexample)

It is worth noting that an Antiportal will only be used for occlusion if some part of it is contained within a zone visible to the player. As a result, you can place as many anti-portals in a level as you'd like, but you shoudl try to keep the number of anti-portals in any given zone to a minimum.

Devastation also adds a new type of Antiportal to the mappers arsenal. This is the Zone Antiportal. A Zone Antiportal allows a level designer to specifiy a set of zones that will not be occluded by the Antiportal, even if that zone is behind the Antiportal.

Combining The Two

Anti-portals can be used to occlude zone portals the same way that zone portals can be used to occlude them. For example, lets say you have a set of large pillars in front of an area with a small doorway at the back. Obviously you should put a zone portal in the doorway, but it would be useful to not render the zone inside the doorway if the doorway isn't visible. The two options are to either put a zone portal between each pillar (one big zone portal won't work), or to put an anti-portal inside each pillar. Depending on the specifics of the map the later may be the better option as it saves you a zone (you only have 63 available, which can become an issue in a large CTF/BR map).

Simplify Collisions

If you have a lot of complex static meshes in your level either make them non-collidable or use a simplified collision hull. You can do this either with a blockingvolume or by saving a brush into the static mesh using the static mesh browser. If you do the latter, the brush will be used for collision but the static mesh will be displayed. If you do not use either of these, straight triangle collision is used on every polygon in the static mesh. This can have a significant impact on the performance of your level.

Discussion

inio: Is anyone interested in a demo map with examples of the various occlusion methods? There seems to be a lot of "here's how you do it" but no "here's how it's done" relating to this topic.

King Mango: Yes I would be interested in that. I am curious if antiportals are even used in UED2... It would be nice if there could be rooms connected to one another, with a sort of "stand here" design on the floor. Then when a player stands there a series of triggered messages explains what to put the crosshairs on and why the info displayed by "stat fps" is different for each occlusion type.

EntropicLqd: Antiportals do not exist in UED2 at all. PS - It looks liked you are cutting and pasting from notepad with word wrap turned on - hard line breaks are generally a bad thing.

inio: Antiportals weren't needed in UnrealEd 2 because it didn't have terrain, it didn't have [static mesh]]es, and BSP ocluded in the engine versions it worked with.