Cogito, ergo sum
Anti portal occlusion
Anti portals can occlude entire actors and individual BSP surfaces. In either case, the object to occlude must be covered completely by any single anti portal. If even a tiny bit of the object sticks out behind the anti portal, then it will not be occluded. This also applies if only a part part of the object is covered by one anti portal and the rest is covered by another anti portal: neither of the two anti portals covers the entire object, so it will not be occluded.
Consider the following 2D example:
Here you can see two anti portals, represented by the red and green lines. The red and green areas behind them mark their individual occlusion areas. As you can see, the triangle and rectangle are completely hidden behind the green and red anti portal respectively. The circle is not hidden by any individual anti portal, only by the combination of them.
For the renderer the triangle and the rectangle are occluded, i.e. not considered for rendering. The circle, however, is not covered by any individual anti portal and thus does not get occluded. Keep this behavior in mind when deciding where to place anti portals.
General rules for using anti portals
- Don't use them right away
- Apply other optimization techniques first. Make sure you properly divide your map into zones and use "cheaper" level optimization techniques like bLonelyZone, ManualExcludes, CullDistance and ForcedVisibilityZoneTag first before using anti portals.
- Use as few as possible
- The engine needs to check every visible actor against all anti portals in the level. At a certain point adding more anti portals starts to hurt more than it helps.
- Make them as big as possible
- Remember, only if the entire actor or surface is covered by an anti portal, it will really be excluded from rendering. Thus anti portals should be as big as possible to fill out as much of the object that blocks the view.
- Keep the shape simple
- Again, there's a performance trade-of here. If a slightly more complex anti portal helps occluding more actors, then it may be fine. However, when it gets too complex, it takes too much time to check the occlusion.
Types of anti portals
Anti portal surfaces
Every surface of a brush can be flagged as an anti portal using the surface properties window. When doing this, the entire surface in its original shape acts as an anti portal sheet. The surface should be a convex polygon and will always be used in its unaltered form. Any holes created by other subtracted brushes will be ignored for the anti portal shape and may cause HOM effects!
Anti portal surfaces only have an effect in the zone they belong to.
In the above example the walls separate two zones. Zone A contains the viewer and some object. In zone B there is a wall that is flagged as anti portal and it appears to perfectly cover the object in zone A. However, zone B is no visible from zone A, so the anti portal surface in zone B is never considered when testing the object in zone A for occlusion.
If multiple surfaces are flagged as anti portals, they will act as individual anti portals for occlusion. If you need a 3D shape, use an AntiPortalActor instead. However, anti portal surfaces have the advantage of "hiding" actors in network games, while AntiPortalActors don't. So in order to optimize network performance of a level, you should prefer using anti portal surfaces, unless there's already BSP around the area you want to place the anti portal.
For anti portals that aren't just sheets, an AntiPortalActor(U2, U2XMP, UE2Runtime, UT2003, UT2004) must be used. It is created in a similar way as volumes or brushes, but must be convex (no holes and not "dented" in any way) and is added through the Add Antiportal button.
An AntiPortalActor is displayed as a brown (or bright orange if selected) volume in the editor. In real-time preview mode and in the game the AntiPortalActor itself is invisible and can only be noticed as it occludes actors and BSP surfaces it covers. While you should try to fill out an static mesh or terrain shape as closely as possible, make sure the anti portal does not stick out of the static mesh, as it may cause HOM effects.
An additional advantage of AntiPortalActors over anti portal surfaces is that you can turn them off dynamically during the game. This feature is mostly used in combination with door movers, where the mover directly controls the AntiPortalActor. To set this up, simply match the Tag of the AntiPortalActor with the AntiPortalTag of the Mover. If no mover is involved, AntiPortalActors can also be controlled through triggering if their InitialState is set to either TriggerToggle or TriggerControl.