The two ways areaportals work:The areaportals are brush entities that when done properly will do these beneficial things to your map:
- When you look through a door, for example, the only things that are rendered are the things you see, and its done in real-time.
- Not render a part of the map that is "selaed" with areaportals, when not seen, or when they are deactivated (ill go in details later in the text)
First of all, the areaportal is a normal brush, converted to a brush entity, called func_areaportal.
As you can see, there are 4 options, from which we can choose whether the door will act the first way, or the other, described above. There are no flags for this entity.
First wayNow, for the first use. Imagine you have a room, full of things that lower fps, for example many objects.
Now you can "block" all the entrances (Otherwise it will cause a leak), so it will be "sealed" with areaportals.
Now, when you move around, what you see is the only thing is rendered, when looking through the areaportal, from inside or from outside.
Second wayThe other use is when you enable the "named of linked door" property, or toggle the state through I/O connections.
If you have a prop_rotating_door entity for example, you can name it, and link the areaportal to it. But make sure all possible entrances are that way, and when you close all doors, its not necessary not be rendered, and the whole room stops being rendered.
ConclusionAreaportals is miracle when done properly. Sort of.
HOWEVER, this real-time optimisation is not cheap, and comes with a cost, and shouldnt be used excessively.
There isnt a reccomended number of areaportals per map or something, however, because of efficiency.
For example, one areaportal may cost 5 fps, provided it optimizes for 20 more fps, you gain 15 fps.
However, if you use an areaportal where it isnt needed, the cost is more than it optimizes, so it does more harm than good.
The point is that you can use lots of areaportals, but when needed.