Areaportal tutorial

From Valve Developer Community
Revision as of 00:23, 23 May 2008 by Durub (talk | contribs) (Added table of contents and minor clean-up)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Areaportals are a means to partition off a portion of your map into a separate area. If you have no areaportals, your entire map is only one area. The major advantage of areaportals is that when you are in one area, the Source engine doesn't even bother thinking about drawing anything in any other areas unless there's a portal in sight - and then it only draws things that are in leaves visible through the portal.

A closed areaportal, as seen with mat_wireframe enabled.
The same areaportal when open.


Street example

As an example, consider a street full of houses. For simplicity, lets assume that each house has a single door that opens to the street, and no windows. Also, every house is on the same side of the (straight) street. If you are standing in one house, then, you can see some part of the house and possibly part of the street, but no part of any other house. Source should not even consider drawing any part of any other house, because there's no way you could possibly see it. And if the door is closed, you can't see the street, so there's no reason to consider any of that, either.

By placing an areaportal in the doorway, you can achieve this ideal. Here's what would happen. When the doorway (really, the areaportal) is not visible at all from the player's point of view, the game engine doesn't bother thinking about anything except what's in the current area: The house. If the doorway is in view, the engine looks at the area on the other side of it (the street) and figures out which leaves are visible through the doorway. It then only draws things that are in those leaves. When viewed with mat_wireframe activated, the effect can be dramatically illustrated.

Also, areaportals can be directly tied to doors (prop_door_rotating, func_door or func_door_rotating, but not physics doors), so that when the door is closed, the engine doesn't bother thinking about what's behind it. In summary, this part of your map becomes almost as fast as if there weren't anything else in the map.

Cabin example - defining an area

As an example for defining an area: Let's say that we want to make a log cabin with two doors, four windows, and a chimney that people can enter Santa-style. Let's also say that we've identified this building as something that we want to turn into its own area. To do this, the walls, floor, and roof would have to be world brushes (Not detail brushes!) so that it's completely sealed from leaks except for the aforementioned openings. Then all of those openings must be covered by areaportals: Both doors, all windows, and somewhere in the chimney. It doesn't matter where in the chimney the portal is, as long as a fly couldn't get inside without touching the portal. It doesn't matter if the portal overlaps some of the world geometry - if two windows are side-by-side, one areaportal could be stretched to cover them both (and then you could use a detail brush for the part in between, since the portal is sealing this part). But if there's so much as a single-unit gap between a door-frame and its areaportal, the area is no longer sealed, and the BSP program will get snotty, and the portals will refuse to work until you fix the problem and recompile.

Once the cabin is working (not before), put a door in each doorway and attach them to their respective areaportals. Since this is a log cabin, we'll put big (non-see-through) shutters in the windows (made of func_door_rotating entities) and tie them to their respective portals. The chimney portal doesn't have a door, but that's okay, especially as the view through that portal is pretty limited anyway.

See also

  • areaportal - A more in-depth article on this subject.