Areaportal

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

An open areaportal (green outline).

A closed areaportal.

An areaportal is a brush entity, func_areaportal, func_areaportalwindow, that can be used to 'seal' separate visleaves and control visibility.

Areaportals serve two separate purposes: culling geometry and removing entire areas from rendering.

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_multiple brushes using the entity I/O system or by linkage with a door entity.

Properties

Trigger_multiples can be used to open and close areaportals and hide areas of a level.

Areaportals:

are tied to the func_areaportal entity.
must be constructed of only one brush. Areaportal entities with more than one brush will generate an error when compiled by vbsp.
must use the tools\toolsareaportal material applied to all faces of the areaportal brush.
cannot contain displacements and will generate a vbsp error if they do.
must be used to seal all areas they connect to, to avoid leaks.
are volumes, not single surfaces. Although areaportals can be any size, usually they are constructed of thin brushes that are the size of the areas (doorways) that they connect. (They can't be of any size, if you exceed a certain size limit, it will give you the error FindUniquePoints: overflowed unique point list (size 512) and a leak will happen!)
generate a new visleaf the size of the areaportal volume.
can be set to open or close based on entity logic, or by attaching them to a door entity.

areaportal_window

The func_areaportalwindow entity behaves like a standard areaportal, with the addition of fading out and closing if the player moves a specified distance from it. This avoids the "pop" of an areaportal suddenly opening.

Construction

Construction of a basic areaportal.

Create the areaportal volume with a single brush solid, completely sealing the space between the two areas that you wish to control. (Multiple areaportals side-by-side can do this if necessary. Avoid giving more than six sides to any single areaportal entity.)
If the areaportal is connecting two areas like a doorway, make the areaportal brush the size of the opening, and the thickness the same as the walls it is connecting. If the areas are open areas, such as an outdoor section, the thickness can be of any size (grid sizes of 8, 16, 32, etc. are typical).
Apply the tools/toolsareaportal material to all faces of the brush.
Tie the brush to a func_areaportal or func_areaportalwindow entity.
Set the Initial State keyvalue so that it doesn't end up blocking visibility when it shouldn't. If you wish to link it to a named door, set the Initial State of the portal to the same initial state as the door, and put the name of the door in the Name of Linked Door keyvalue of the portal. When the door is closed the Initial State of the areaportal should be Closed too, and vice versa.

Placement Tip:When linking an areaportal to a named door, make sure it is thinner than the door model itself to ensure the latter will be rendered when closed.

Performance impact

Open areaportals (whether they're always open, or triggered to open) have a behavior of culling geometry that is visible through the areaportal. Similar to looking through an open window of a house, only the visleaves that are directly visible through the areaportal will be rendered by the engine. In this way, the geometry in the next area is roughly 'culled' to the size of the window, decreasing the amount of geometry rendered, and increasing performance. On top of this, model (prop) geometry is not rendered at all unless part of the model is directly visible through the view frustum (or visible angle) of the areaportal. This makes open areaportals very useful to control visibility of model geometry.

An open areaportal tightly culls model visibility.

Due to these performance benefits, areaportals are often used in an always-open state. An always-open areaportal is created by setting the "Initial State" keyvalue on the func_areaportal entity to "Open". Always-open areaportals are used at the openings to other areas containing large amounts of visleaves and geometry. For example, simply placing an always-open areaportal at the end of the hallway that opens into a wider expanse can produce a substantial performance gain. While the player is inside, looking out of the doorway, only the geometry that is in the each leaf directly visible through the doorway will be drawn.

Overuse

Care must be taken to avoid having too many areaportals visible simultaneously. There is processing cost for each, and if portals are not culling enough detail drawing the scene without them becomes faster!

Areaportals don't form brushes in a compiled map, so don't count towards the brush lump's size limit. This can be useful when you have an incredibly full BSP and are using plenty of hints.

Compilation

Top view of an areaportal leak (left), and a fully sealed area (right).

It is vital that any areas that an areaportal is supposed to seal off don't leak into each other. Just as with regular leaks, an area of the map is only considered sealed from another if it is completely surrounded by world (non-entity) brushes (with the exception of areaportal brushes), without gaps. If there are multiple ways that areas connect, each must be filled with an areaportal.

It may help to imagine a fish tank filled with water with several holes in it's sides. An areaportal must fill each of those holes, or the area will leak, generating a leak error by vbsp.

Areaportals must be used to seal every entrance to the area. func_detail brushes, translucent textures, and displacements cannot seal an area, and will generate leaks that prevent the map from running. If the compiler can still find a way between the two main surfaces of any one portal, it will report a portal leak.

Spotting compile errors

Areaportal compile errors are output by VBSP. If a leak occurs, you will see this:

Brush <brush number>: areaportal brush doesn't touch two areas
done

These error messages are sometimes not as easy to spot as normal leak error messages, but when it comes to locating the leak in the map, vbsp will generate a pointfile to help you, just as for regular geometry leaks.

Bug:If your map has no entities in it, for example, an info_player_start, areaportals (and the rest of the map, for that matter) will create unusual leaks. To fix this, be sure to have at least one kind of entity within your map. [todo tested in?]

Tip:The glview application can be used to display areaportals, which as draw as gray surfaces.

Areaportals and water

When constructing areaportals with water, two separate areaportals must be used.

One other tricky aspect of using areaportals is that they are not allowed to cross water boundaries, like the water surface. To accomplish this, you will need to divide the portal into two - one areaportal above the water surface, and another areaportal below it - so that they both meet at the water plane.

Merging

For optimization reasons, areaportals that share the same plane (are aligned) are automatically merged by the engine. If this behavior is unwanted, simply ensure the areaportal brushes are not along the same plane. This is usually as simple as shrinking or moving one of the areaportals slightly in the editor so they are no longer aligned. Even one grid unit is sufficient to avoid an automatic merge.

Tip:You can see if areaportals are being merged in the engine by using the r_DrawPortals 1 console command.

Looking through areas

Visibility between leaf one and two is unaffected.

Areaportals only cull between the areas that they seal off. Consider the image to the right: while the contents of the building are culled away as you would expect, visibility between visleaf one and two is unaffected because they are connected to each other via the sides of the building.

This can be fixed by creating two further areaportals on either side of the building.

Console commands

You can debug and test portals in-game, using some portal-specific console variables:

r_DrawPortals 0/1: Outlines any portal border surface (between two areas) in green when set to "1". Sometimes more than one portal is condensed into one. If the portal belonging to it is open, a second green box is also drawn, showing what the visibility on the other side is clipped to.
mat_wireframe 0/1/2/3: Draws geometry in wireframe mode, making it easy to see the effects of areaportals in the level. When debugging areaportals, you should typically use mat_wireframe set to "1" or "2", as the "3" setting can hide geometry that is actually rendering.

Warning: mat_wireframe may lead to crashes in some occasions. Therefore r_drawworld 0 might be a good alternative, because it simply stops rendering walls. This allows you to see the props appearing and disappearing. Also useful for seeing which visleaf is visible.

r_portalscloseall 0/1: Setting this to "1" forces all areaportals closed (so that they cannot be opened). Overrides r_portalsopenall 1. (Try this if portals don't seem to be doing anything. It can tell you whether the problem is just that the portals aren't closing properly.)

Note:This command does not exist in:

r_portalsopenall 0/1: Setting this to "1" forces all areaportals open (so that they cannot be closed).

Tip:Use the BindToggle console command to allow a single key to be used to toggle a console variable.

In multiplayer

Areaportals are very useful in multiplayer games. Their creation is identical to those in single-player games, but their function and usage is slightly different. With multiple players in a game server, there is less control of when an areaportal is going to be open, and level performance needs to be optimized for worst case scenarios (i.e. when all visible portals are open). Because of this, in most cases, 'always open' areaportals are placed most often, followed by areaportals linked to doors, and then areaportals controlled by triggers. In worst case scenarios, well-crafted 'always open' areaportals will increase performance more than portals that are designed to be triggered.

An areaportal window can also be used seal structures in multiplayer, but are less useful because they can create gameplay imbalances in competitive multiplayer games. A player inside the structure that is near the areaportal window would be able to see any players outside, but players farther away outside would not be able to see the player inside.

Relationship to occluders

Areaportals are similar to occluders in that they help control visibilty. The main differences between them are:

Occluders only hide model (prop) geometry that is behind them. Areaportals hide all types of objects.
Areaportals must fully seal areas (allow no leaks), while occluders can be free-standing inside areas.
Occluders are more expensive per object than open areaportals.
Occluders have controls for the size of objects they will hide, based upon screen area.

Note:Brushes in areaportal and occluder entities should not intersect (touch) each other, and will not function correctly if they do.

Areaportal

Contents