Areaportal: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
m (Directed link.)
m (Setting bug notice hidetested=1 param on page where the bug might not need tested in param specified)
 
(81 intermediate revisions by 39 users not shown)
Line 1: Line 1:
Areaportals are used for in-game control of the visibility of world geometry from one area to another. They are similar to Occluders (which instead blocks models).
{{LanguageBar}}


A portal has two states: ''Open'' or ''closed''. While in its ''open'' state, the portal allows visibility of world brushes between its bordering areas. When the portal is closed, it blocks this visibility instead. (The result is black and opaque.) You can think of it like an invisible door, which still blocks visibility.
[[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.]]


Areaportals are typically linked to doors, matching their open/closed state, making the engine ignore drawing the world geometry behind a door while it is closed (despite the door not being able to block visibility on its own). They may also be triggered to open or close through the I/O system (like for example [[trigger_multiple]]s).
An ''areaportal'' is a [[brush entity]], {{Ent|func_areaportal}}, {{Ent|func_areaportalwindow}}, that can be used to 'seal' separate [[visleaves]] and control visibility.


For an easy-to-understand tutorial on areaportals, see the [[areaportal tutorial]].
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 {{Ent|trigger_multiple}} brushes using the [[Inputs and Outputs|entity I/O system]] or by linkage with a [[Doors|door]] entity.


== Properties ==
[[File:Areaportal trainstation04.jpg|200px|thumb|right|caption|Trigger_multiples can be used to open and close areaportals and hide areas of a level.]]


=== Open portals ===
Areaportals:


Additionally, open areaportals will also limit the amount of geometry rendered to the geometry that is directly visible through it, increasing performance.
* 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 a door entity.


Because of this behavior, always-open areaportals are sometimes used at the doorways to large outdoor areas. Simply placing an always-open areaportal at the end of the hallway that opens into a wide expanse, can produce a substantial performance gain. While the player is inside, looking out of the doorway, only the geometry that is in the leaves directly visible through the doorway will be drawn.
=== 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.


== Construction ==
[[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. (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|[[Tool textures#Optimization|tools/toolsareaportal]]}} material to all faces of the brush.
# [[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. When the door is closed the ''Initial State'' of the areaportal should be Closed too, and vice versa.


=== Creating an areaportal ===
{{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.}}


# Create the portal volume with a brush solid, completely sealing the gate between the areas that you wish to control.
== Performance impact ==           
# Make it just as thick as its door (or frame, in case there is no door). (Area volumes are designed to be very thin. One of its two main surfaces sets the border between the areas, while the opposite surface blocks the visibility between them. There also seems to be no way to specify exactly which of these two surfaces that will be used for which purpose. The compiler decides this, probably according to the leaf compile order. This order can be hard to keep track of, so to be on the safe side, and considering that both surfaces cut visleaves, a portal should stretch between two acceptable border positions, usually with the same thickness as its door or frame.)
<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>
# Texture all the faces of the brush with the <code>tools\toolsareaportal</code> material.
# Tie the brush to a [[func_areaportal]] entity.
# Make sure that the ''Initial State'' keyvalue is correctly set (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.


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.


[[Image:AreaPortalLeakFig.jpg|200px|right|thumb]]
[[File:areaportal_culling_top.jpg|thumb|An open areaportal tightly culls model visibility.]]


=== Sealing an area / Portal leaks ===
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.


It is vital that the areas that a portal 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 brushes (with the exception of areaportal brushes), without gaps. Detail brushes or displacement brushes can not seal an area. Additional portals must be used to seal ''every'' entrance to the area. If the compiler can still find a way between the two main surfaces of any one portal, it will report a portal leak.
=== 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!


Picture: In the left picture we see an obvious portal leak (shown by the red line). On the right, another portal is added to seal the area(s).
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!
{{clr}}


=== Compiling Portals ===
== Compilation ==
[[File:AreaPortalLeakFig.jpg|300px|right|thumb|caption|Top view of an areaportal leak (left), and a fully sealed area (right).]]


Areaportals are handled by the [[BSP]] program ([[vbsp|vbsp.exe]]).
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.


When they compile correctly, the BSP program will report the following:
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]].


Processing areas...done
'''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.'''


However, if a leak occurs, [[vbsp]] will instead report the following:
=== Spotting compile errors ===
Areaportal compile errors are output by [[vbsp|VBSP]]. If a leak occurs, you will see this:


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


These error messages are not as easy to spot as normal [[leak]] error messages, but when it comes to locating the leak in the map, the BSP program will generate a [[Leak#Finding_leaks|pointfile]] to help you, just as for regular geometry leaks.
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.


[[Glview]] will display areaportals as gray obstructions.
{{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.}}


{{tip|The [[glview]] application can be used to display areaportals, which as draw as gray surfaces.}}


=== Areaportals and water ===
[[File:areaportal_water.jpg||thumb|200px|right|When constructing areaportals with water, two separate areaportals must be used.]]


=== Portal specific console variables ===
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.


You can debug and test portals in-game, using a couple of portal specific console variables:
=== 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.}}


== Looking through areas ==


==== map_noareas [0/?]====
[[File:Areaportal-areas.png|frame|right|Visibility between leaf one and two is unaffected.]]


"Disable area to area connection testing." Probably something to do with areaportals. ({{todo|Please find out what it does.}}) Seems to fix the stuttering bug if activated! (I'm thinking that the opening of areaportals in mid-game is the actual cause of the infamous HL2 stutter, and setting this to 1 will instead load all areas at once. ({{todo|Again, please verify this.}}))
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.


{{clr}}


====r_ClipAreaPortals [?/1/2]====
== Console commands ==
 
You can debug and test portals in-game, using some portal-specific [[console]] variables:
No idea what this does, but it has got "areaportals" in it. According to [http://www.inxbus.net/hldoc/d8/d2b/r__areaportal_8cpp-source.html r_areaportal.cpp, line 468] it has been commented out due to occasionally huge performance hits.
 
;r_ClipAreaPortals 1: This is the default setting.
;r_ClipAreaPortals 2: Line 500: "Just leave the area clipping how it was (for debugging)."
 
 
 
====r_DrawPortals [0/1]====
 
;r_DrawPortals 0: This setting is default. Portals are not drawn.
;r_DrawPortals 1: Outlines any portal border surface (between two areas) in green. (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 geometry on the other side is clipped to.
 
 
 
====r_portalscloseall [0/1]====
 
;r_portalscloseall 0: This setting is default. Portals are displayed according to their state.
;r_portalscloseall 1: Forces all portals 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.)
 
 
 
====r_portalsopenall [0/1]====
 
;r_portalsopenall 0: This setting is default. Portals are displayed according to their state.
;r_portalsopenall 1: Forces all portals open (so that they cannot be closed).
 
 
 
====r_PortalTestEnts [0/1/?]====
 
;r_PortalTestEnts 0: Entities inside visible leaves are drawn, even these entities are not visible themselves.
;r_PortalTestEnts 1: This setting is default. Clip entities against portal [[Wikipedia:Frustum|frustrums]]. (Don't draw entities that aren't directly visible through the portal.)
 
 
 
====r_snapportal [-1/?/1/2]====
 
No idea what this does, but it is mentioned in [http://www.inxbus.net/hldoc/d8/d2b/r__areaportal_8cpp-source.html r_areaportal.cpp, line 293].
 
;r_snapportal 1: Sets up some kind of drawing of a box with the origin at the player origin. (It seems impossible to get rid of without restarting the game.)
;r_snapportal 2: Sets up a different kind of drawing.
 
 
 
=== Window portals ===
 
Areaportals can be used for windows too, with the use of the [[func_areaportalwindow]] 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.
 
 
 
=== Performance cost and overuse ===
 
While areaportals are designed to ''save'' resources (by hiding unnecessary geometry) giving substantial performance benefits when used correctly, each areaportal require some run-time calculations whenever open and visible in the current view. This presents somewhat of a trade off between the benefit and the cost of the portal, as too many open areaportals simultaneously visible in the current view, while not hiding enough geometry, could even cost more performance than they save.
 
 
 
=== Areaportals and water ===
 
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 portal above the water surface, and another portal below it - so that they both meet at the water plane.
 
 


=== Portals in multiplayer games ===
; 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.}}


Areaportals are overall somewhat less useful in multiplayer (and especially deathmatch) games than in singleplayer. The multiple player presence will not only prevent portals from closing as often (to free resources) but players in both of its areas renders even renders them unable to hide non-visible geometry, making them completely useless, and only costing resources instead of saving them. Only seal off rarely frequented areas of such a map, possibly with doors that automatically close.
== 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 [[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.


== Relationship to occluders ==
Areaportals are similar to [[occluder]]s in that they help control visibilty. The main differences between them are:


=== Further reading ===
* 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.


For more details, see the entity documentation for the [[func_areaportal]] and [[func_areaportalwindow]] entities.
{{note|Brushes in areaportal and occluder entities should not intersect (touch) each other, and will not function correctly if they do.}}


== See also ==
* {{Ent|func_areaportal}} / {{Code|[[CAreaPortal]]}}
* {{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]]


=== Example maps ===


Unfortunately, there is no SDK sample map for areaportals.
{{stub}}
{{note|See the [[Talk:area portal|discussion page]] for info on a demo map.}}

Latest revision as of 07:13, 20 May 2025

English (en)Español (es)Русский (ru)中文 (zh)Translate (Translate)
Toolsareaportal.gif
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.
  1. 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.)
  2. 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).
  3. Apply the tools/toolsareaportal material to all faces of the brush.
  4. Tie the brush to a func_areaportal or func_areaportalwindow entity.
  5. 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.
PlacementTip.gifPlacement 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

In-engine wireframe rendering of an areaportal. Only world geometry that is in visleaves seen through the areaportal are rendered. The same scene with the areaportal disabled. All geometry in the connected visleaves are rendered.

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.

Icon-Bug.pngBug: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.pngTip: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.pngTip: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.pngWarning: 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.pngNote:This command does not exist in: Team Fortress 2 Counter-Strike: Global Offensive
Confirm:Test in other Team Fortress 2 branch and CS:GO engine branch games
r_portalsopenall 0/1
Setting this to "1" forces all areaportals open (so that they cannot be closed).
Tip.pngTip: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.pngNote:Brushes in areaportal and occluder entities should not intersect (touch) each other, and will not function correctly if they do.

See also


Stub

This article or section is a stub. You can help by expanding it.

Retrieved from "https://developer.valvesoftware.com/w/index.php?title=Areaportal&oldid=478818"