Areaportal: Difference between revisions

Latest revision as of 07:13, 20 May 2025

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.
should use the tools\toolsareaportal material on all faces (not required)
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.
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. Areaportals do count towards the edict limit, though!

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.

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 (they still count as separate edicts, though). 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:
Confirm:Test in other and games
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.

@@ Line 1: / Line 1: @@
-[[Image:areaportal_simple_open.jpg|200px|right|thumb|caption|An open areaportal (green outline).]][[Image:areaportal_simple_closed.jpg|200px|right|thumb|caption|A closed areaportal.]]
+{{LanguageBar}}
-An ''areaportal'' is a brush [[entity]], <code>[[func_areaportal]]</code>, that can be used to 'seal' separate [[visleaves]] and control visibility. Areaportals are like doorways that can only be fully 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 <code>[[trigger_multiple]]</code> brushes using the [[Inputs and Outputs|entity I/O system]] or attached to <code>[[func_door]]s</code>, synchronized to open and close with the door.
+[[File:Toolsareaportal.gif|left|link=]]
+[[File:areaportal_simple_open.jpg|200px|right|thumb|caption|An open areaportal (green outline).]][[File:areaportal_simple_closed.jpg|200px|right|thumb|caption|A closed areaportal.]]
-== Properties of areaportals ==
+An ''areaportal'' is a [[brush entity]], {{Ent|func_areaportal}}, {{Ent|func_areaportalwindow}}, that can be used to 'seal' separate [[visleaves]] and control visibility.
-[[Image:Areaportal trainstation04.jpg|200px|thumb|right|caption|Trigger_multiples can be used to open and close areaportals and hide areas of a level.]]
-A standard areaportal:
+Areaportals serve two separate purposes: culling geometry and removing entire areas from rendering.
-* is tied to the <code>[[func_areaportal]]</code> entity.
-* can be constructed of only one brush. Areaportal entities with more than one brush will generate an error when compiled by [[vbsp]].
+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 {{Ent|trigger_multiple}} brushes using the [[Inputs and Outputs|entity I/O system]] or by linkage with a [[Doors|door]] entity.
-* must the <code>tools\toolsareaportal</code> material applied to all faces of the areaportal brush.
-* cannot contain [[displacement]]s and will generate an vbsp error if they do.
+== Properties ==
-* must be used to seal the all areas they connect to, to avoid [[leak]]s.
+[[File:Areaportal trainstation04.jpg|200px|thumb|right|caption|Trigger_multiples can be used to open and close areaportals and hide areas of a level.]]
+Areaportals:
+* are tied to the {{Ent|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]].
+* should use the <code>tools\toolsareaportal</code> material on all faces (not required)
+* cannot contain [[displacement]]s and will generate a vbsp error if they do.
+* must be used to seal all areas they connect to, to avoid [[leak]]s.
 * 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.
 * generate a new [[visleaf]] the size of the areaportal volume.
-* can be set to open or close based on [[Inputs and Outputs|entity logic]], or by attaching them to [[func_door]]s.{{clr}}
+* can be set to open or close based on [[Inputs and Outputs|entity logic]], or by attaching them to a door entity.
+=== areaportal_window ===
+The {{Ent|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.
-== Basic areaportal construction ==
+== Construction ==
-[[Image:areaportal_simple_ex1.jpg|200px|right|thumb|caption|Construction of a basic areaportal.]]
+[[File:areaportal_simple_ex1.jpg|200px|right|thumb|caption|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.
+# 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 <code>tools\toolsareaportal</code> material to all faces of the brush.
+# Apply the {{code|[[Tool textures#Optimization|tools/toolsareaportal]]}} material to all faces of the brush.
-# [[Entity Creation|Tie the brush]] to a [[func_areaportal]] entity.
+# [[Entity creation|Tie the brush]] to a {{Ent|func_areaportal}} or {{Ent|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.
+# 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.
-{{note|While areaportal brushes can contain more than six sides, the results are in most cases unusable. Better results can usually be achieved by simply creating more than one separate areaportal entity.}}{{clr}}
+{{ModernPlacementTip|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 value of open areaportals ==
+== Performance impact ==
-[[Image:areaportal_culling_top.jpg|200px|right|thumb|caption|An open areaportal in a doorway controls visibility through the opening, depending on the position of the player.]]
+<div style="text-align:center;">[[File:areaportal_culling_engine1.jpg|350px|caption|In-engine wireframe rendering of an areaportal. Only world geometry that is in visleaves seen through the areaportal are rendered.]] [[File:areaportal_culling_engine2.jpg|350px|caption|The same scene with the areaportal disabled. All geometry in the connected visleaves are rendered.]]</div>
 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.
-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 <code>[[func_areaportal]]</code> 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. A special type of areaportal entity, <code>[[func_areaportalwindow]]</code>, is also used in some of these cases. The <code>[[func_areaportalwindow]]</code> entity is a type of areaportal that can be open or closed based on a distance from the player instead of simply being triggered to open or close like standard <code>[[func_areaportal]]</code> brushes.
+[[File:areaportal_culling_top.jpg|thumb|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 {{Ent|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.
-[[Image:areaportal_culling_engine1.jpg|200px|thumb|left|caption|Wireframe rendering in-engine of an areaportal. Only world geometry that is in visleaves visible through the areaportal are rendered.]][[Image:areaportal_culling_engine2.jpg|200px|thumb|left|caption|The same scene with the areaportal disabled. All geometry in the connected visleaves are rendered.]]{{clr}}
+=== 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!
-== Sealing areas / areaportal leaks ==
+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. Areaportals ''do'' count towards the [[edict limit]], though!
-[[Image:hammer_leaks3.jpg||thumb|300px|right|Areaportals that do not seal areas will cause leaks.]][[Image:AreaPortalLeakFig.jpg|300px|right|thumb|caption|Top view of an areaportal leak (left), and a fully sealed area (right).]]
-It is vital that any areas that a areaportal is supposed to seal off doesn'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.
+== Compilation ==
+[[File:AreaPortalLeakFig.jpg|300px|right|thumb|caption|Top view of an areaportal leak (left), and a fully sealed area (right).]]
-It may help to imagine a fish tank filled with water with several holes in its 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|Detail brushes]] or [[displacement]]s cannot seal an area. If the compiler can still find a way between the two main surfaces of any one portal, it will report a portal leak.
+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.
-=== Compiling errors ===
+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]].
-Errors when creating areaportals are displayed during [[BSP]] generation (using [[vbsp|vbsp.exe]]).
+'''Areaportals must be used to seal ''every'' entrance to the area. [[func_detail|func_detail brushes]], translucent textures, and [[displacement]]s 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.'''
-When they compile correctly, the BSP program will report the following:
+=== Spotting compile errors ===
+Areaportal compile errors are output by [[vbsp|VBSP]]. If a leak occurs, you will see this:
- Processing areas...done
+<pre>
+Brush <brush number>: areaportal brush doesn't touch two areas
+done
+</pre>
-However, if a leak occurs, [[vbsp]] will instead report the following:
+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 [[Leak#Finding_leaks|pointfile]] to help you, just as for regular geometry leaks.
- Brush <brush number>: areaportal brush doesn't touch two areas
+{{bug|hidetested=1|If your map has no entities in it, for example, an {{Ent|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.}}
- done
-{{tip|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 [[Leak#Finding_leaks|pointfile]] to help you, just as for regular geometry leaks.}}
+{{tip|The [[glview]] application can be used to display areaportals, which as draw as gray surfaces.}}
-{{tip|The [[Glview]] application can be used to display areaportals, which as draw as gray surfaces.}}{{clr}}
+=== Areaportals and water ===
+[[File:areaportal_water.jpg||thumb|200px|right|When constructing areaportals with water, two separate areaportals must be used.]]
-== Areaportals merging ==
+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.
-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 grid one unit is sufficient to avoid an automatic merge.
+=== Merging ===
+For optimization reasons, areaportals that share the same plane (are aligned) are automatically merged by the engine (they still count as separate [[edict]]s, though). 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 <code>r_DrawPortals 1</code> console command.}}
-== Relationship to occluders ==
+== Looking through areas ==
-Areaportals are similar to [[occluder]]s 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 [[leak]]s), 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.}}
-== Window areaportals ==
-[[Image:Areaportalwindow coast12.jpg|180px|thumb|right|caption|A func_areaportal_window that hides interior geometry by turning black at a distance.]]
-Areaportals can be used for windows too, with the use of the <code>[[func_areaportalwindow]]</code> entity. This type of portal instead controls the transparency of a window depending on how close the player is to it, effectively shutting out any scenery beyond it if the player isn't interested in it.
-One common use for <code>func_areaportal_window</code> entities are for buildings in outdoor areas. They can be used to hide the contents of buildings until players are at close distances without the visual 'pop' of an standard areaportal being opened.{{clr}}
+[[File:Areaportal-areas.png|frame|right|Visibility between leaf one and two is unaffected.]]
-== Performance cost and overuse ==
+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.
-Although areaportals can give substantial performance benefits when used correctly, care must be taken with not to place too many areaportals where many of them would all be visible simultaneously. There is processing cost for each areaportal. If multiple portals are open and visible in the current view, and the portals are not culling (hiding) enough geometry, it's certainly possible that the overhead required to process the areaportals will be more costly to performance than if the portals were not there at all. Watch out for the 'worst case scenario' in these situations.
+This can be fixed by creating two further areaportals on either side of the building.
-=== Useful console variables ===
+{{clr}}
+== 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.
+; 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 {{ent|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 {{Command|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: {{Tf2}} {{Csgo}} {{confirm|Test in other {{tf2branch}} and {{csgobranch}} games}}}}
+; r_portalsopenall 0/1
+: Setting this to "1" forces all areaportals open (so that they cannot be closed).
+{{tip|Use the {{Command|BindToggle}} console command to allow a single key to be used to toggle a console variable.}}
-;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.
+== 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.
-;r_portalscloseall 0/1: Setting this to "1" forces all areaportals closed (so that they cannot be opened). Overrides <code>r_portalsopenall 1</code>. (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.)
+An [[func_areaportalwindow|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.
-;r_portalsopenall 0/1: Setting this to "1" forces all areaportals open (so that they cannot be closed).
+== Relationship to occluders ==
+Areaportals are similar to [[occluder]]s in that they help control visibilty. The main differences between them are:
-{{tip|Use the <code>BindToggle</code> console command to allow a single key to be used to toggle a console variable.}}
+* Occluders only hide model (prop) geometry that is behind them. Areaportals hide all types of objects.
+* Areaportals must fully seal areas (allow no [[leak]]s), 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.
-== Areaportals and water ==
+{{note|Brushes in areaportal and occluder entities should not intersect (touch) each other, and will not function correctly if they do.}}
-[[Image:areaportal_water.jpg||thumb|200px|right|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.{{clr}}
-== Multiplayer games and areaportals ==
-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 placed more 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.
 == See also ==
-* [[func_areaportal]]
+* {{Ent|func_areaportal}} / {{Code|[[CAreaPortal]]}}
-* [[func_areaportalwindow]]
+* {{Ent|func_areaportalwindow}}
+* {{Code|[[CAreaPortalOneWay]]}} (C++ code for new entity)
+* [[func_occluder|Occluders]], which are effectively the inverse of areaportals
 * [[Controlling Geometry Visibility and Compile Times]]
 * [[Leak]]
 * [[Visleaf]]
-[[Category:Level Design]][[Category:Glossary]]
+[[Category:Level Design]]
+[[Category:Glossary]]
+{{stub}}

Areaportal: Difference between revisions

Latest revision as of 07:13, 20 May 2025

Contents