Area Portal vs func_areaportalwindow ???

  • If you're asking a question make sure to set the thread type to be a question!

Open Blade

L420: High Member
Nov 30, 2007
439
34
Working on a new map (payload) and I have my first stage complete. Going through and doing the optimizing part. Never been the best at that but getting better. I looked through valve maps and on open doorways (even with no gates or doors) I see they use the area portal texture on the brush the covers the doorway. I tried this on my map and when I compiled it, the area portal texture was visible and the doorway was blocked. What have I done wrong? I tried to do some research on the web and saw a few others talk about making the brush a func_areaportalwindow. I went back to the valve maps to see if I overlooked that and they are not func brushes of any sort.


Ahhhhhh help me please. This is gonna be a good map but I want it to play smooth and fast. Thanks.

Forgive the brightness of the screenshot, I did not place my tonemap in yet.

snakebite01.jpg
 

A Boojum Snark

Toraipoddodezain Mazahabado
aa
Nov 2, 2007
4,775
7,669
Decompiles have flaws, because it is an operation that isn't supposed to happen. One of those flaws is APs ending up wrong. All your area portals must be tied to func_areaportal
 

Open Blade

L420: High Member
Nov 30, 2007
439
34
Decompiles have flaws, because it is an operation that isn't supposed to happen. One of those flaws is APs ending up wrong. All your area portals must be tied to func_areaportal

I just read some info at valve site and I guess there are two ways to use these. The standard func_areaportal, which is commonly used with triggers to fully open or close the portals, or the func_areaportalwindow, which as I understand it, does not have to be tied to any trigger, once a player gets a certain distance from it, the geometry in the other portal begins to fade and once far enough away, it no longer draws any of it.

So would using the func_areaportalwindow suffice to help optimizing? I don't want to get into all the triggers that control area portals.

Thanks Snark.
 

Sgt Frag

L14: Epic Member
May 20, 2008
1,443
710
I think in most cases you are fine with just tieing the brush to a func_areaportal.
That doesn't cull geometry but it culls all models that can't be directly seen, so that does alot by itself. That is default when you create one.

I think Valve triggers them open and closed on spawn doors. But unless you have really long view distances and didn't use hints there's probably not much need to trigger them to close (that blocks terrain too).

I used a few portalwindows in hoover, but that made a major difference in what was rendered. And just on glass windows that can't be passed through.

Nice screen btw. You should turn off the track shadows too.
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
What i can't seem to figure out is whether an area can be closed by both types of areaportals at once. A regular areaportal in one opening and an areaportalwindow in another. When i do this the areaportalwindow's simply close at any distance. Though i'm sure you should be able too.....

Blade: areaportal windows are what valve use extensively throughout their maps; in windows, doorways and narrow passsageways. The regular areaportals are only used on spawn doors that can't be seen through like on 2fort.
 

Open Blade

L420: High Member
Nov 30, 2007
439
34
Dammit. I can't get this right. I used func_areaportalwindow and left the default settings, which valves site says is fine. The are textured with the area portal texture on all sides and it completely touches all sides of the walls (which are not func_detail or displacement). The area portal texture is no longer visible when I check it in the game but you can't see anything on the otherside of the portal, it's all blurry, even if you are a few feet away. I read on another forum where somebody had a similar problem and they suggested he use the func_areaportal and to leave them open. What's the point then, if they are always open. Isn't the idea to have them close so they don't have to draw an area?

This is frustrating.
 

Waif

L7: Fancy Member
Mar 22, 2009
412
125
Dammit. I can't get this right. I used func_areaportalwindow and left the default settings, which valves site says is fine. The are textured with the area portal texture on all sides and it completely touches all sides of the walls (which are not func_detail or displacement). The area portal texture is no longer visible when I check it in the game but you can't see anything on the otherside of the portal, it's all blurry, even if you are a few feet away. I read on another forum where somebody had a similar problem and they suggested he use the func_areaportal and to leave them open. What's the point then, if they are always open. Isn't the idea to have them close so they don't have to draw an area?

This is frustrating.

Just make them func area portals, and make sure the initial state is open UNLESS they are linked to a specific door. (In which case you make the initial state the same as the doors)
That way they will only render whatever is behind them if they can be seen by the player.
 

Open Blade

L420: High Member
Nov 30, 2007
439
34
sooooooooo...........

I changed all the areaportalwindows to nomral area portals and, this is wierd, 2 of the doors were good but the rest bad. I did them all the exact same way, I don't understand it. You can clearly see in the screenshot, the doorway with the gate you can see the room behind it. I walked up to it and you can see all around and through it into that room. The doorway on the leftside, well, all you see is sky, yet there is a room with stuff just on the otherside of the doorway. What gives?


I also provided a download link to anybody who wants to check it out, maybe you can make sense of what's happening.

http://www.nikegames.net/zona/Misc/Hammer/Maps/pl_snakebite_b1.zip

snakebite02.jpg
 

Open Blade

L420: High Member
Nov 30, 2007
439
34
I'm determined to get this down. Upon last compile, I noticed that I was getting the error that stated areaportal brushes were not touching 2 areas. I triple checked the few area portal brushes I have and they all are touching the side of the world brushes where they should be. So, when it says they are not touching areas, I have to assume that it's not referring to the actual walls that the brush touches, rather "areas" of the map. WTF? Then funny part is, the 3 areaportal brushes the log refers to are the 3 that I can see through just fine. It's the other 4 that I can't see through but those are not in the log as a problem. This is confusing as all hell. The 3 problem area portals the log refers to are a single building with no leaks. The area portals seal the 3 doorways from the building into the outside area. I don't get it.

:huh:
 

Open Blade

L420: High Member
Nov 30, 2007
439
34
Oh thank god. I finally fixed the problem. Geez, it only took me 4 hours. When in doubt, go back to the basics.

What was throwing me off was a stupid model leak. Here's why. We've all had the model outside the map and also contained within a wold brush, which causes a leak, but for some strange reason, I've had a model cause a leak before that was well within the wold, in fact, it was a crate just floating above the floor not even touching a wall or anything. I deleted the model and the leak was gone.

Sooooo........on my last compile there was a leak from a window model that was clearly not outside my map in the void and it was only touching the sides of the wall, not within the wall at all. So, I figured it was another quirky model leak. I did follow the line and it brought me in a complete circle, first time I had seen that. I deleted the model window and same thing. I was thinking though, how odd that the red leak line went in a circle and didn't just shoot off to the void somewhere and end, it was continuous. So I started going back over my brush work and here's something I learned the hard way.

When people tell you to turn off func_detail before doing your area portals and for checking problems with area portals, go ahead and do that, but also check again with those turned on. What I had was a classic brush overlap. A func_detail overlapped onto a world brush, that was touching my areaportal. That's what caused it. If I didn't turn my func_detail back on, I never would have found that.


Whew, works great now. I will post up a few screenies tomorrow. Bedtime.
 

Nineaxis

Quack Doctor
aa
May 19, 2008
1,767
2,820
Blade: areaportal windows are what valve use extensively throughout their maps; in windows, doorways and narrow passsageways. The regular areaportals are only used on spawn doors that can't be seen through like on 2fort.

Really? Last I read was that we should only use func_areaportal, since areaportal_windows do clientside culling, so theoretically there could be situations in which an areaportal_window is preventing the player from seeing an enemy (think: sniper you can't see because areaportal_window has made that doorway fade to black).
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
Zooming in with the scope has some odd LOD control mechanisms that include rendering models that would otherwise be faded, regardless of distance. I can only assume the same would be true of areaportals?

But either way it would be the level designers job to make sure that area's are rendered when they are seen so that exactly this doesn't happen. For the most part areaportal sight ranges are limited for the player because of the abundance of 90 degree turns that physically block line of sight to them, allowing them to close at shorter distances. I've had numerous occasions though where my killer has managed to kill me from several rooms over and the walls/floor and/or ceiling are not being rendered for the deathcam due to the areaportals being closed in that area (Happens a lot on 2fort).
 
Last edited:

keeperofthetoas

L1: Registered
Jun 3, 2009
22
0
Oh thank god. I finally fixed the problem. Geez, it only took me 4 hours. When in doubt, go back to the basics.

What was throwing me off was a stupid model leak. Here's why. We've all had the model outside the map and also contained within a wold brush, which causes a leak, but for some strange reason, I've had a model cause a leak before that was well within the wold, in fact, it was a crate just floating above the floor not even touching a wall or anything. I deleted the model and the leak was gone.
QUOTE]

Ahh the leak. has caused me many a troubles too in previous maps ;)
glad you got it all settled!
 

l3eeron

L8: Fancy Shmancy Member
Jan 4, 2008
593
88
Ya, areaportals have to be perfectly touching the surrounding wall/ceiling/floor on all 4 sides, and seal in the section. As far as I know, a func_detail (and other stuff like displacements, but not water) can be touching it, but not fully envelope it.
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
As far as I know, a func_detail (and other stuff like displacements, but not water) can be touching it, but not fully envelope it.

I thought an areaportal still had to placed along a seem of a displacement? :confused:

But yes, for water, you will need to create an areaportal under the water, and another corresponding areaportal above the water.

/marches over to interlopers for a touch up on areaportals.

edit, for your interest: http://optimization.interlopers.net/index.php?chapter=areaportals
 
Last edited:

Sgt Frag

L14: Epic Member
May 20, 2008
1,443
710
they suggested he use the func_areaportal and to leave them open. What's the point then, if they are always open. Isn't the idea to have them close so they don't have to draw an area?

This is frustrating.

No, as I stated already they have a major impact on a busy scene even if left to open.

They cull ALL OBJECTS that can't be seen directly. That can be alot of polys and particle effects if there are a few players outside fighting it out.

If you make them close then you have to have a door or something that blocks the vis so you don't see skybox. It also takes more power to do this so if they aren't needed there's really no need.

Areaportal windows also have a problem in multi player. If they close at distance a player close to them could see though and shoot at a player that is far away, a player far away couldn't see the player that is close to the window.
Unfair advantage.

I really don't think valve used them in all doors and windows. First off they have a well optimized map, so once you go through a door and around a corner in 2fort the terrain and objects would be culled anyway. I can't think of anywhere in 2 fort where they would be a benefit. (other than blocking a closed spawnroom off) and that benefit is negligable.
 

Open Blade

L420: High Member
Nov 30, 2007
439
34
Is there something to this?

Check it out. So I made a copy of my map last night and I had removed the areaportals at the spawn doors, which were the problem. I compiled and the rest of the areaportals worked great. I had fixed that overlapping func_detail brush and I thought that was the reason I had solved the problem. So I go back into the original map, fixed that overlapping func_detail brush again and there it was again, the same 3 spawn room areaportals leaking. I went over the brushwork too many times to mention and everything was perfect. The pointfile shows the leak going from one of the gates outside and back through one of the windows and again into the spawn room. I checked the glass on the windows 5 times and totally sealed up to the world brushes around it. So, I guess part of the problem solving routine, I removed the glass windows and the window frame models and just made them solid wall. That solved the problem.

So I have to ask, the window brushes themselves were totally sealed, I would swear upon Gods feet, would the problem have been transparent glass texture? Does the areaportal know that it can't turn off stuff behind it if a player can still see through glass? The only other thing it could be is the model window frame itself, but I don't see how, they were touching the wold brushes but not fully withing them which would have caused a leak.

Totally confused about this one.
 

HojoTheGreat

L5: Dapper Member
Nov 11, 2008
206
34
Always func_detail glass windows that connect two areas and put a func_areaportal sealing the window. I don't remember the technical reason for this but it works.

Also I have not read the whole thread, as there is a LOT of reading to do and you seem to have resolved your problems, however I wanted to note as I think others have mentioned, never use areaportal windows in TF2. APWindows basically stop rendering things inside a window at a certain distance, which gives an unfair advantage to any Snipers within that window (since players at a distance will not be able to see them in the window).

Plus you should never have a window with that long a sight-line anyway.

Area portals can be finicky, however for anyone still reading this who ever has AP problems in the future, follow these steps and if you go through them properly, your problems SHOULD be solved:
  1. In Visgroups, turn off everything but world geometry. That means turning off props, func_details, lights, etc. Basically anything that will obscure your view of the map, and that does not seal a room.
  2. Run map using Normal BSP, no VIS and no RAD. Make sure Do not run map in game is checked (you do not want TF2 to launch)
  3. Click Map, Load Pointfile (about halfway down the menu)
  4. A red line should appear if you have a leak. With areaportals this line will show you how the two faces of an areaportal are connected/touching. Start at one side of the areaportal and follow the red line all the way until you see where the leak is (usually two brushes not fully touching, or a previously func_detailed brush.
  5. Seal the leak, the repeat steps 2-4 until no Pointfile can be loaded.
It sounds like you already know this, but regardless it is a good summary.
 

Open Blade

L420: High Member
Nov 30, 2007
439
34
Always func_detail glass windows that connect two areas and put a func_areaportal sealing the window. I don't remember the technical reason for this but it works.

Also I have not read the whole thread, as there is a LOT of reading to do and you seem to have resolved your problems, however I wanted to note as I think others have mentioned, never use areaportal windows in TF2. APWindows basically stop rendering things inside a window at a certain distance, which gives an unfair advantage to any Snipers within that window (since players at a distance will not be able to see them in the window).

Plus you should never have a window with that long a sight-line anyway.

Area portals can be finicky, however for anyone still reading this who ever has AP problems in the future, follow these steps and if you go through them properly, your problems SHOULD be solved:
  1. In Visgroups, turn off everything but world geometry. That means turning off props, func_details, lights, etc. Basically anything that will obscure your view of the map, and that does not seal a room.
  2. Run map using Normal BSP, no VIS and no RAD. Make sure Do not run map in game is checked (you do not want TF2 to launch)
  3. Click Map, Load Pointfile (about halfway down the menu)
  4. A red line should appear if you have a leak. With areaportals this line will show you how the two faces of an areaportal are connected/touching. Start at one side of the areaportal and follow the red line all the way until you see where the leak is (usually two brushes not fully touching, or a previously func_detailed brush.
  5. Seal the leak, the repeat steps 2-4 until no Pointfile can be loaded.
It sounds like you already know this, but regardless it is a good summary.


and, as you mentioned, if you are using glass, I guess you have to follow your instructions regarding that as well. I KNEW something weird was happening. Thanks for the tip, I will try to put my windows back in now, I kinda liked them.........lol

FYI, here's a few screenies I took just now. I didn't run HDR and no cubemaps so they are a tad bland lighting wise and I've only done a small amount of prop and overlay detailing on this first stage, if you can call it a stage, more like, the first check point. It's gonna be like badwater where there are checkpoints but no stages. I wanted the start blu area to be very industrial looking with buildings and such and then graduate to more wooden stuff as you go along. I'm having a blast working on it, well except for the few problems I've had yesterday.

I guess I can throw the pics under WIP also. Although I didn't see that section anymore, maybe it's gone now.

sb1.jpg



sb2.jpg


sb3.jpg


sb4.jpg


sb5.jpg


sb6.jpg


sb7.jpg


sb8.jpg


sb9.jpg
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
Sgt Frag said:
If you make them close then you have to have a door or something that blocks the vis so you don't see skybox. It also takes more power to do this so if they aren't needed there's really no need.

I'm pretty sure it doesn't. The only thing that really puts load on your computer when it comes to optimisation techniques are occluders, and this is because they work in real time.

Also all this "omg, players wont see other players at a distance" is crap. Give the areaportal window the appropriate render distances and you shouldn't have a problem. They are designed to act in this manner (as defined by the tutorials) for Half-Life single player, level designers have to be more vigilante about line of sight in their multi-player maps and increase areaportal open/close distances to avoid this experience. This constant repeatition over a technicality that is easily worked around is starting to get on my nerves.

areaportal windows are used in unison with hints because hints are not full proof (and obviously allow for more manual control over what is rendered ingame).