From Valve Developer Community
Revision as of 07:24, 5 May 2011 by Zeph (talk | contribs) (Portals being 1 unit thick)
Jump to: navigation, search

Areaportal cost

Do open areaportals cost anything when they're out of sight? --Cargo Cult 08:07, 23 Sep 2005 (PDT)

They have a slight cost, I don't believe it's measurable, but possibly negligible considering map geometry and if they weren't used at all. --wisemx 09:18, 23 Sep 2005 (PDT)

Once there is alot of them it tends to become more costly.--Gear 13:45, 16 Sep 2007 (PDT)

Example map

Here's a test project we did with Jeff Lane on always open areaportals. 2.3MB ZIP archive. --wisemx 09:18, 23 Sep 2005 (PDT)

The link seems to be dead, could you please rehost it? --Tourorist 09:04, 28 Aug 2007 (PDT)
Link updated, sorry it took so long. --wisemx 05:28, 14 Dec 2007 (PST)

Reference to nothing

I just noticed that the there is a link to the page leaks explained. However, that page has a reference to this page. Basically, there is no further information regarding areaportal leaks. Just a comment. --Darthkillyou 09:49, 25 May 2007 (PDT)

Hopefully, enough information has been added since, but if you are still missing information about portal leaks, please let me know straight away, so that I can get on it. --Andreasen 08:55, 16 Sep 2007 (PDT)
I have noticed that I get vbsp errors with portals (WARNING: areaportal entity 664 (brush 183024) touches > 2 areas), but I get no pointfile to find it. Is there any way to track the offending areaportal by entity or brush number (since those are given) without the pointfile to help? -- Asinine 05:30, 24 Jan 2008 (PST)
Here Hammer_Go_To_Brush_Dialog --Angry Beaver 13:06, 24 Jan 2008 (PST)

Additional information

I found some additional information on areaportals here: Optimization_Tutorial, BSP Map Optimization This information should be moved/merged into this page. --Andreasen 10:13, 16 Sep 2007 (PDT)

Is it called "area portals" or "areaportals"?

I asked myself this question when I started working on this article, and I need evidence to support any theory. --Andreasen 10:13, 16 Sep 2007 (PDT)

I found indisputable evidence that it's called "areaportals" and not "area portals" in the listing of r_areaportal.cpp. This article needs to be moved to areaportal. --Andreasen 11:33, 16 Sep 2007 (PDT)
Yeah it is called areaportals. However there is already a func_areaportal page so keeping it Areaportal would be okay.--Gear 13:47, 16 Sep 2007 (PDT)
I don't understand. What does the entity page have to do with this page? We can't flood that page with the entire topic. --Andreasen 13:59, 16 Sep 2007 (PDT)
thats what i was saying, since there is already a entity page. Lol, never mind.--Gear 14:13, 16 Sep 2007 (PDT)

Portals needing to be block shaped

How have you come to the conclusion that portals need to be block (cube) shaped? --Andreasen 14:43, 16 Sep 2007 (PDT)

Ah yes i have tested it out, even with different settings and even on Func_areaportalwindow. The engine seems to act crazy why? Because each side represents a face or in other words a vis leaf. If a areaportal is a triangle then it creates 3 leafs, meaning no working geometry to hide. It can only be two leafes. Room 1 and Room 2 in example. Cant have two rooms in Room 1 get what i mean?--Gear 14:50, 16 Sep 2007 (PDT)
The reason I'm asking is that I created an octagonally shaped portal (with the MAIN surface shapes being octagonal), and it worked perfectly. I'll experiment further with wedges to see what you mean. --Andreasen 15:14, 16 Sep 2007 (PDT)
Actually, you're both correct in a way. func_areaportal entities can have more than 6 sides, although they can only be one brush. They certainly don't need to be orthogonal (cubes with all 90 degree sides). It is fairly common to have angled areaportals with six sides but "skewed" along the angle to connect two areas. That said, I would not go out of the way to explain the usage of areaportals with more than six brush sides, because it's quite easy to create degenerate leaves this way. Only someone with a deep understanding of the portal and leaf system would likely make one efficiently. I've seen them used this way only a handful of times by any designers in many years, and even then they could have used standard shapes just as effectively. I would not suggest it as a technique to anyone. --JeffLane 15:33, 16 Sep 2007 (PDT)
Still, I'll move this discussion to the areaportal discussion page, so that particularly curious minds can find this explanation if interested. --Andreasen 16:05, 16 Sep 2007 (PDT)
Yup so thats cool, theres alot more advanced ways to do so, but its harder eh? Thats interesting. Are any of those maps in your possession Jeff? Is so i'd like to take a a gander at em', that would be cool.--Gear 15:56, 16 Sep 2007 (PDT)

Portals being 1 unit thick

I've removed lots of these comments because I don't understand why this needs to be mentioned. Portals break visleaves, and should do so at appropriate locations. A normal dynamic door is 2 units thick, and I see no reason for archway portals to be any smaller than the thickness of the archway itself, as that would create additional visleaves. --Andreasen 16:12, 16 Sep 2007 (PDT)

Ah but yet 1 unit is the default, ask jeff, he would know.--Gear 17:10, 16 Sep 2007 (PDT)
I've been told that the old SDK manual told editors that areaportals should be made 1 unit thick, but that doesn't make it a "default". If areaportals would somehow work better if they were only 1 unit thick, then I would support it, but as it is, this "default" just adds more visleaves. It's easy to tell designers that portals should be made 1 unit thick, because it's close enough, but it still isn't the best thickness. --Andreasen 18:53, 16 Sep 2007 (PDT)
Well it still makes 1 leaf either way, but alot tinier, which in this case is sort of better considering theres nothing passing through it. Yet 1 unit is sure a default and the best to use, but yet you can still make thicker sized brushes. Why 1? Because the areaportal makes two leafs, right, so in this case, 1 unit is smaller meaning alot easier to deal with due to certain limitations you might find in mapping. Yet you can make it any size you want, but 1 tends to be best for too many reasons too count.--Gear 21:03, 16 Sep 2007 (PDT)
It doesn't have to make a leaf that complicates the rest of the brushwork. Imagine that you have a door that is flush against a frame, or have a simple archway. Making the portal not tie into other leaves, can complicate the surrounding leaves. "Certain limitations you find in mapping"? "Too many reasons to count"? Unless you care to clearify that, I'm starting to suspect that you are making things up. One shouldn't go around doing things (like adhering to a certain thickness) just because everyone else is doing it. There has to be a reason for it. --Andreasen 03:20, 17 Sep 2007 (PDT)
I believe it is better to make the area portals the same size as the archway wall thickness, as it reduces the number of visleafs generated as shown in the linked images below. However i shall see if this causes visible problems when linked with a prop door which is thinner than the area portal itself (IE does it close off and therefore not render the door and the faces on the inside of the archway?). For always open Area Portals, it is always better to make them the size of the archway, not one unit thick. However, if that archway is so thick it's more like a corridor, clearly two area portals either end would be better! Perhaps a maximum thickness of 8 or possibly 16 units? Bad AreaPortal Good AreaPortal --Zeph 14:24, 5 May 2011 (UTC)

About the section about multiplayer games

I'm thinking I've made a mistake. While several players in both areas of a portal would render portals useless, it's not really the same map they're in. One player is in the map that his computer renders, while the other player is in the map that his computer renders, so the areaportals could possibly account for this by being in different states at different computers. --Andreasen 20:25, 16 Sep 2007 (PDT)

Huh? why different computers, you cant use these in mp maps.--Gear 20:55, 16 Sep 2007 (PDT)
Wait well in theory yes where the player stands is the current part of the map they are in. Meaning in theory that if an areaportal is active it will not effect the player in room 1. But only the player in Room 2. However if does effect the map globally, which is why they arent used in mp maps at all, rather just single player maps where you have alot more control over them. So in other words the only entity that never has an control using triggers is areaportalwindow, which can be used, but not Func_areaportal.--Gear 20:59, 16 Sep 2007 (PDT)
I'm betting that at least modders have tried to implement them, so are you sure that the areaportal code is specificly tied to singleplayer maps?
You're not making sense, and I think you've misunderstood me: Does the server or the clients (in the multiplayer network) decide if the each portal is open or closed? You see, if their states were a client issue, that would allow the closing of a portal to hide things for one player, while displaying it for another, making areaportals worth while. I'm thinking that this may be a security issue - that areaportals may be set serverside to avoid exploits.
You can theoretically have full control over areaportals for several players because of the OnTouch trigger input. If you cover an area in a trigger_multiple to open a portal, and then close it OnEndTouch, you have full control. --Andreasen 03:42, 17 Sep 2007 (PDT)
That is exactly what i was saying. But yes, Single player maps only. And yeah i would go with hiding visleafes, sounds more better than geometry since they do hide all, you do not know much about areaportals huh?--Gear 13:37, 17 Sep 2007 (PDT)
I guess that I should remove that multiplayer part entirely then, but I'm putting this article on hold until Jeff Lane gets around to adding to it within a couple of days. --Andreasen 15:36, 17 Sep 2007 (PDT)
...and no, I don't know much about areaportals. This merge is where I started my learning process. I thought this was going to be an easy merge, as the two articles I merged was full of repetitions like "Make sure to seal the room. ...and oh, Seal the room!" or unnecessary instructions like "Click this very button to tie this brush to an entity." Now the article has grown to seem bigger than the two parts combined. In all honesty, I just want to go back to design my hospital level, and not just have to stare at a friggin door all week. --Andreasen 15:43, 17 Sep 2007 (PDT)
Gear, ts2do just told me that portals work exactly the same way in multiplayer as it does in singleplayer, and an article I've just read goes on and on about areaportals being able to be used (client-side) in multiplayer, but that they have the potential to draw more and more resources during game-play. What did you mean by "Single player maps only"? --Andreasen 17:16, 17 Sep 2007 (PDT)
This why its not worth it giving this information away. It hurts the game more than saves it, and it is alot more complicated to fully pull-off yet I've seen it done, in Fortress Forever for example. It isn't worth the time. Yeah i know what you mean though, this is very complicated, mainly a art within itself.--Gear 17:20, 17 Sep 2007 (PDT)
Alrighty if it might help, im going to work out the Multiplayer side of areaportals for players, and mainly, this section. Not much regular area portals are used, but instead Areaportal_windows instead.--Gear 04:09, 24 Sep 2007 (PDT)

Mystery variables

Please provide more information about the following variables:

map_noareas [0/?]

"Disable area to area connection testing." Probably something to do with areaportals. (To do: 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. (To do: Again, please verify this.))

r_ClipAreaPortals [?/1/2]

No idea what this does, but it has got "areaportals" in it. According to 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_snapportal [-1/?/1/2]

No idea what this does, but it is mentioned in 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.

The term for what exactly is hidden.

I undertook creating this article under the misconception that "geometry" (in previous articles) meant world brush geometry, but as I tested it out, and read other articles, I found that areaportals hid EVERYTHING, including entities and models, so now I'm asking, what's the proper term for what areaportals are hiding? "PVS"? "BSP"? "Visleaves"? I'm going to go with "visleaves", but this is a guess.

Also, I'd like to know if "culling" is a well-used term that I can use. At first I thought it was just a vague description, as "culling", according to my dictionary, means to "sort something out". --Andreasen 11:14, 17 Sep 2007 (PDT)

Okay, based on the Wikipedia:Back-face_culling article, "culling" and "clipping" are common 3D techniques. According to r_areaportal.cpp areaportals uses both these techniques. If I understand correctly, the hiding caused by a closed portal, is called "culling", and the hiding outside the frame of an open portal is called "clipping". --Andreasen 11:59, 17 Sep 2007 (PDT)
No, the articles are confusing me: They are refering only to open portal hiding as both "culling" and "clipping". I now have no idea what closed portal hiding is called. I need help. --Andreasen 12:15, 17 Sep 2007 (PDT)
According to this article, closed portal hides geometry by using a technique called "cell-based occlusion culling", but the latter part of that section also says that the portal system uses some kind of "analytical clipping" which is too advanced for me to understand. --Andreasen 14:40, 17 Sep 2007 (PDT)
I should have time to work on clarifying some of the issues with this article within the next few days. --JeffLane 15:08, 17 Sep 2007 (PDT)
Thank you. I really appreciate it. --Andreasen 15:36, 17 Sep 2007 (PDT)
Thank You JEff that would be nice, theres still alot of things that are quite mysterious about areaportals.--Gear 17:21, 17 Sep 2007 (PDT)
I also appreciate if you both could tell me which things are mysterious/inaccurate, so that I can explain these things better in the article, because as the subject is mostly clear to me, I've lost the "newbie perspective". Edit: Also keep in mind that there exists an areaportal tutorial for those who would like a lengthy, simple and non-technical explanation. I haven't touched that article much, so if you think that a specific thing could be explained using more words, that article is the obvious choice. --Andreasen 06:56, 18 Sep 2007 (PDT)
I went ahead and did a pass on the article. The main thing that remains is to create examples of triggered areaportals, and perhaps areaportalwindows. This could likely be done in the separate tutoral article and then link it here when it is completed. --JeffLane 17:11, 18 Sep 2007 (PDT)

Code tags

(Large off-topic discussion moved to Help talk:Editing.) --Andreasen 09:14, 23 Sep 2007 (PDT)

Always-open? Windows?

"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"." Jeff, this, and the follow text in that section, looks bluntly copied from the old text. For instance, is "always-open areaportals" a common term? Is this "special type of portal" actually created when set to "Open"? Shouldn't it say Open instead of "Open"? Why would func_areaportalwindow be mentioned in the same section without even being explained as a concept first? A lot of thought went into editing away the stupidity of that section in particular. Why is it back? Is this the "accuracy" that you told me I had removed earlier? --Andreasen 21:26, 23 Sep 2007 (PDT)

Users, if you want to read a better article than the current one, I suggest this revision, as Jeff Lane seems to have reverted lots of edits when he put the pictures up. I'm linking to it here so that at least *I* have easy access to it. --MossyBucket (formerly Andreasen) 04:56, 1 March 2011 (UTC)

Recent Edit

Whoops my bad, I left my sig in the page by accident, probably wasn't paying all that much attention.--Gear 13:29, 10 Sep 2008 (PDT)


The page says "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." but I'm wondering if this is a typo, because if anything hides something, it's mat_wireframe 2 (that only displays what's visible). (It's hard to verify if mat_wireframe 3 sometimes hides geometry it's rendering - I'd have to read through engine code for that.) (Jeff Lane himself is responsible for this, and he previously only recommended mat_wireframe 1. Could he have removed the wrong number?) --MossyBucket (formerly Andreasen) 20:44, 31 January 2011 (UTC)