Areportals

Nov 14, 2009
1,257
378
I am finally starting to optimize my map, and I can't for the life of me figure out how to use areaportals. I assumed that they were put in doorways to stop rendering of stuff in the background rendering. However, when I load up my map, they are solid: I cant walk through them. They show the "areaportal" texture, and stop rendering, but I can see them. Also, I really dont get the use of hint/skips! I have read multiple tutorials, and still dont get it. Can someone come up with an explanation for a noob?

Thanks in advance!
 

Firest0rm

L4: Comfortable Member
Sep 27, 2009
171
33
you have to tie your areaportals to func_areaportal. However, read the guides i linked to below before you use areaportals, because there are some things you need to make sure of before you randomly throw areaportals in doors.

for optimization, use these guides, and play around with it a bunch in hammer. It may also help to look through valve maps for optimization help, because they seem to be pretty good at it
 
Last edited:

lana

Currently On: ?????
aa
Sep 28, 2009
3,075
2,778
Keep in mind that areaportals are also useful when open (though I'm not particularly sure why.) Even when a doorway doesn't have a door, but separates two major areas, consider placing an areaportal there that remains open. Also remember that any section of your map that is divided by areaportals can leak into other areas. They must all be individually sealed or otherwise blocked off with APs to prevent them from ruining your compile.

I recommend reading the Interlopers' guides on optimization, as they walk you through how each entity works very well (they've already been linked here, but a second link couldn't hurt.) The tutorials also have images that describe what each does, so it's a good read. It's also what I used to learn more about optimization as well, so I recommend you take a read through.

Finally, before you go off placing areaportals willy-nilly, consider that they do have a small cost on the engine. Think about where an areaportal isn't as necessary when you can use, for example, a hint.
 
Last edited:

Cynick

L4: Comfortable Member
Feb 7, 2010
153
284
Keep in mind that areaportals are also useful when open (though I'm not particularly sure why.)... *snip*

Because open portals cull visibility into a cone of leaves that you can see (while closed ones block all visibility through them). From the VDC:

Areaportal_culling_top.jpg


Shows what an open areaportal does to aid optimization.
 

lana

Currently On: ?????
aa
Sep 28, 2009
3,075
2,778
I see, so like the opposite of an occluder (which, by the way, culls visibility of any entity directly behind it.)
 

cadeonehalf

L1: Registered
Oct 19, 2009
32
6
So what exactly does it mean when your areaportals become untied from the solids during compiling?
Let me explain:
I am starting optimization by creating some basic "always open" areaportals to cull visibility a little bit before I get into portals associated with doors and hint/skip. I make the areaportals in my doorways/windows, making sure there are no leaks. Then (obviously) I compile them.
During compile, I get a ton of errors that it doesn't touch two solids (even though I made sure the areaportal solids were flush with the sides of each doorway) and when I select the appropriate brush number, they are no longer tied to func_areaportal.
What exactly causes that? It doesn't say its leaking at all.
 

Psy

The Imp Queen
aa
Apr 9, 2008
1,706
1,491
I see, so like the opposite of an occluder (which, by the way, culls visibility of any entity directly behind it.)

The tutorial that TPG explains it as well.

An areaportal is a means of reducing the amount of objects that the engine has to render based on the player's viewing angle (the view frustrum) through an areaportal or a bunch of areaportals that are visible.

Here's a simple diagram.

diagram_1.png


Imagine this as a room with a wall dividing the area into 2 parts and in the center of the wall is a window. In this window, an areaportal is placed. On the one side of the wall is the player and on the other are 4 oildrums in a neat row represented by little black circles.. In red is the area outside the view frustrum and in green is the area inside the view frustrum.

As you can see, the two oildrums are inside the view frustrum (remember, this is the player's view) and so they are being rendered whilst the oildrums outside the view frustrum are not. This means that everything which the player cannot see is not being rendered. Useful!
 

Cynick

L4: Comfortable Member
Feb 7, 2010
153
284
So what exactly does it mean when your areaportals become untied from the solids during compiling?
Let me explain:
I am starting optimization by creating some basic "always open" areaportals to cull visibility a little bit before I get into portals associated with doors and hint/skip. I make the areaportals in my doorways/windows, making sure there are no leaks. Then (obviously) I compile them.
During compile, I get a ton of errors that it doesn't touch two solids (even though I made sure the areaportal solids were flush with the sides of each doorway) and when I select the appropriate brush number, they are no longer tied to func_areaportal.
What exactly causes that? It doesn't say its leaking at all.

If you haven't already fixed the problem:

Brushes not being tied to a func_areaportal is usually caused by having ignore groups :)ig:) enabled. Turn it off, as it will show the entities as solids rather than the entities they are tied to.

There are other minor limitations: EACH INDIVIDUAL brush must be it's own func_areaportal, they cannot be grouped together under a single entity like func_detail can be. Also, areaportals cannot cross the surface of water, so if they do, you must cut them in two at the water line. (Remember the above, they must be TWO SEPARATE areaportals)

If they're still leaking...use that pointfile!