T
the Specialist
Guest
i decompiled some of the original maps of cs:source tonight and they use the texture area portal often and i was wondering what it is used for?
Dead-Inside
Newbie
- Joined
- May 8, 2004
- Messages
- 1,922
- Reaction score
- 0
Ever heard of the official documentation?
http://www.valve-erc.com/srcsdk/Levels/performance_and_visibility.html
http://www.valve-erc.com/srcsdk/Levels/performance_and_visibility.html
I just finally got mine working, so now I'll try to explain it.
Basically, area portals can be imagined as doors (and, not coincidentally, have a lot to do with them.) Your map is divided into a bunch of different pieces, and an area portal is a way of controlling visibility between them.
Okay, so you've got two rooms, connected by a hallway.
Now you put some barrels (prop_physics) in one of the rooms and put a func_areaportal at one end of the hallway. There are two players in the other room, A and B.
Note that the geometry (world brushes) of both rooms will be drawn if you're in front of the hallway's entrance, even with the area portal. If you're not, there are places in one room where you won't be able to see into the other (just into the hallway connecting them, but not all the way down it.)
So now we add in what each player can see in terms of the "door" (really just a hole) at the far end of the hallway. Now imagine that I drew this correctly and put the area portal at the other end (it doesn't matter too much because I didn't put any props in the hallway anyway, but from a technical standpoint, this isn't quite what's going on.)
Player A can't see into the room at all, so (because there's an area portal between them) none of the barrels in the far room will be drawn for him.
Player B CAN see some of the barrels on the other.
The last image combines two principles. First, it shows which barrels won't be drawn, and it moves player B to show how his point of view changes. If I had drawn (in the third image) which barrels weren't drawn, Player B would still have the very edge of the barrel furthest to the left drawn (it doesn't just clip all or nothing - it cuts it at the edge of the area portal.)
In this image, Player B has moved a bit, so now he can't see that barrel at all. Thus, it would no longer be drawn.
Hopefully that makes some sense.
EDIT: Also, they won't work if they're not enclosed in brushes - func_detail won't work for the boundaries of them.
If you have them like I did in this case, you would have to set it's initial state to Open.
You can tie area portals to doors. In that case, what happens is that when the door is open, the area portal tied to the door acts as it does above. When the door is closed, it seperates the rooms completely - it won't draw any props past that door no matter where you are in relation to it. When the door is opened, it goes back to clipping prop geometry to where its edges are.
Basically, area portals can be imagined as doors (and, not coincidentally, have a lot to do with them.) Your map is divided into a bunch of different pieces, and an area portal is a way of controlling visibility between them.
Okay, so you've got two rooms, connected by a hallway.
Now you put some barrels (prop_physics) in one of the rooms and put a func_areaportal at one end of the hallway. There are two players in the other room, A and B.
Note that the geometry (world brushes) of both rooms will be drawn if you're in front of the hallway's entrance, even with the area portal. If you're not, there are places in one room where you won't be able to see into the other (just into the hallway connecting them, but not all the way down it.)
So now we add in what each player can see in terms of the "door" (really just a hole) at the far end of the hallway. Now imagine that I drew this correctly and put the area portal at the other end (it doesn't matter too much because I didn't put any props in the hallway anyway, but from a technical standpoint, this isn't quite what's going on.)
Player A can't see into the room at all, so (because there's an area portal between them) none of the barrels in the far room will be drawn for him.
Player B CAN see some of the barrels on the other.
The last image combines two principles. First, it shows which barrels won't be drawn, and it moves player B to show how his point of view changes. If I had drawn (in the third image) which barrels weren't drawn, Player B would still have the very edge of the barrel furthest to the left drawn (it doesn't just clip all or nothing - it cuts it at the edge of the area portal.)
In this image, Player B has moved a bit, so now he can't see that barrel at all. Thus, it would no longer be drawn.
Hopefully that makes some sense.
EDIT: Also, they won't work if they're not enclosed in brushes - func_detail won't work for the boundaries of them.
If you have them like I did in this case, you would have to set it's initial state to Open.
You can tie area portals to doors. In that case, what happens is that when the door is open, the area portal tied to the door acts as it does above. When the door is closed, it seperates the rooms completely - it won't draw any props past that door no matter where you are in relation to it. When the door is opened, it goes back to clipping prop geometry to where its edges are.
Dead-Inside
Newbie
- Joined
- May 8, 2004
- Messages
- 1,922
- Reaction score
- 0
Basically, always place an areaportal at your doors, and have the initial state as closed. Don't forget to bind it to the actual door, though.
Great typeup there Unvision
Great typeup there Unvision
Phisionary
Newbie
- Joined
- Jul 2, 2003
- Messages
- 1,305
- Reaction score
- 0
yes, ty univision, that does clarify some things.
does a areaportal need to be tied to a func_areaportal? I thought that it's properties were tied to the material (I haven't used them myeself, yet), and not the entity...
Does the material do anything by itself?
Second, any areaportal that you can, by default, see through needs to be open at start, correct? So if you have an open doorway, no door, it should be open? And closed is to be used when there is a view-blocking object covering said doorway? Also I read that func_areaportals automatically open and close... how does this work? does it work only when the portal is open first, and when it is out of view, then it closes automatically? I've seen several people have issue where the areaportal prevented an area from rendering (leaving a 'void' look) even when they walked right up to it.
thx to anyone who can help explain this a bit more.
does a areaportal need to be tied to a func_areaportal? I thought that it's properties were tied to the material (I haven't used them myeself, yet), and not the entity...
Does the material do anything by itself?
Second, any areaportal that you can, by default, see through needs to be open at start, correct? So if you have an open doorway, no door, it should be open? And closed is to be used when there is a view-blocking object covering said doorway? Also I read that func_areaportals automatically open and close... how does this work? does it work only when the portal is open first, and when it is out of view, then it closes automatically? I've seen several people have issue where the areaportal prevented an area from rendering (leaving a 'void' look) even when they walked right up to it.
thx to anyone who can help explain this a bit more.
One thing to bear in mind about the decompiler: it doesn't correctly tie the func_areaportal (or areaportalwindow or occluder) entities to their brushes. Currently, those brushes appear as regular world brushes. So don't blindly copy what you see in a decompiled map, it's not the correct way of doing it.
The areaportal texture on its own, not on a brush tied to the entity, does nothing, as far as I know.
The areaportal texture on its own, not on a brush tied to the entity, does nothing, as far as I know.
Phisionary:
Even if it IS tied to the material, you'd still need to make it a func_areaportal becasue you can't change the properties without it being an entity - without which you wouldn't be able to tie it to doors or set it to open initially (thus making it an "always open" area portal.)
Pretty much everything you said was right. To clarify, when they say "automatically" they mean that the game knows when the door is open and when it's shut (this being the door it's tied to - when someone "uses" the door and it swings open, it automatically sets the areaportal to open.) When an area portal is closed, it renders no props behind it no matter what.
The void problems were mine :E - I hadn't properly closed it off, and they were set to start closed instead of start open, which made it look void-y.
Even if it IS tied to the material, you'd still need to make it a func_areaportal becasue you can't change the properties without it being an entity - without which you wouldn't be able to tie it to doors or set it to open initially (thus making it an "always open" area portal.)
Pretty much everything you said was right. To clarify, when they say "automatically" they mean that the game knows when the door is open and when it's shut (this being the door it's tied to - when someone "uses" the door and it swings open, it automatically sets the areaportal to open.) When an area portal is closed, it renders no props behind it no matter what.
The void problems were mine :E - I hadn't properly closed it off, and they were set to start closed instead of start open, which made it look void-y.
