Sometimes you have visleafs that need to be visible at one time, but hidden at another time. Conditional visibility if you like. The way we do that in HL2 is by using areaportals. Remember what a portal is, and how they are used for visibility? The areaportal is a conditional portal. In it's closed state it acts like a solid wall, meaning it blocks visibility, in it's opened state it acts like any other portal ( allowing visleafs to see through them ). Areaportals are defined by giving a brush the "tools/toolsareaportal"-texture ( all sides of the areaportal brush need to have this texture ) and making the brush a func_areaportal or func_areaportalwindow ( the difference between these two will be explained later ).
However, we have a problem. Areaportals can open or close ingame, and our visibility table ( the table of data containing which visleaf can see which other visleafs ) is static. This clashes somewhere, doesn't it? Nope, it doesn't. Because of one thing: AREAportals. Areaportals divide the level into areas, mini-levels if you like. Each area is a complete mini-level indeed, as each has it's own entities, it's own visleafs, etc. They can even LEAK seperately!
The four (blue) areaportals divide this level into four area's. Topleft, topright, bottomleft, bottomright. Each of these area's must be sealed like a normal level. They can't even leak to each other:
See how the top-left area leaks into the bottom-left area, actually creating a single area? The left areaportal says these two area's must be seperated, but there is only one area ( I failed to seperate both area's with world brushes and areaportals ). This situation is considered as a leak. The pointfile will show a leak from one side of the areaportal to the other. This also explains why areaportals need to be fitted exactly. Any space around them results in a leak, just like above. For instance if you are trying to stop the inside of a house to be rendered don't just put an areaportal in the front door, but also put ones in the backdoor, all the windows and maybe even the chimney. It's very easy to forget an entrance, so be carefull.
If a line can be made from one side of an areaportal to the other side without crossing world-geometry or other areaportals, this areaportal has leaked!
This shows that you can't just place areaportals wherever you like: Each areaportal must seal an area completely. Areaportals are only allowed to touch two area's, no less (this will cause a leak as previously explained) but also no more (you can't have areaportals cross other areaportals or area-dividing world geometry). Since areaportals may span through brushwork, it's also possible to use one areaportal for two doors by stretching the areaportal brush across both doors, if they are next to each other.
If ALL areaportals between the player and a certain area are closed, this area doesn't exist for the renderer. In other words: You must not be able to walk to this area without crossing world geometry or closed areaportals. In the first example that means:
- If only North is open, only the top area's are considered to be drawn
- If East is open, only the right area's are are considered to be drawn
- If North and East are open, only the bottom-left area isn't considered to be drawn
- If North and East and South are open, all area's are considered to be drawn
Offcourse the normal visleaf visibility rules apply to whatever is considered to be drawn. Areaportals only affect visibility, whatever entity or player is bouncing around in these other area's happily keeps bouncing. Areaportals are NOT solid, you can walk, shoot, bounce or fly straight through them. They won't block light either. Areaportals cause a slight slowdown ingame, but usually this slowdown is much lower than the slowdown caused by any geometry they hide. Still, it's always good to check if the effects of an areaportal are good for the framerate or not. Areaportals are also said to cull visleafs (in their open state), but whether or not this effect is solely caused by the areaportals cutting up any visleaf that touches them is unknown to me.
In multiplayer games, areaportals are considered seperately for every player. That is, if player 1 cannot see area A because of a closed areaportal, then that doesn't mean that player 2 cannot see area A too; Player 2's computer will also determine what area's he can or cannot see, and they don't have to be the same as that of other players. So you don't have to worry about players seeing the rooms around them disappear because an areaportal has closed.
When looking straight at an closed areaportal a player will see either HOM or the skybox, just like with NODRAW-brushes. So unless you want that, you need to cover up your closed areaportals. For instance by a door!
As said earlier, there are two types of areaportals, the normal func_areaportal and the func_areaportalwindow
This areaportal can recieve open and close inputs, so you can use triggers (eg trigger_multple's, doors) to open and close them! They can also be linked to a door so they open when the door is open, and close when the door is closed. The effect is the same for all players in a level though, if the areaportal is open then it's open for all players, and if it's closed it's closed for all players.
Imagine a room behind a solid door: It's stupid to render this room when the door is closed, but even more stupid to not render it when the door is open.
Imagine this room. The player (purple) wouldn't be able to see anything in the room, because the door is closed. However still everything in this room is rendered. If we put an areaportal in the doorway, and link it to the door that gives access to this room, then we can make sure this room is only rendered when the door is open or when the player is INSIDE this room make sure the hallway is only rendered if the door is open.
In this example, when the areaportal is closed, any player outside this room won't have anything inside the room rendered, and any player inside the room wont have anything rendered outside the room. How cool is that?
To make sure the door itself is rendered when the areaportal is closed (and to hide that ugly HOM or skybox appearing instead) we need to make sure the areaportal is COMPLETELY INSIDE the door. This is easiest when the areaportal is as thin as possible, 1 unit:
With both doors the door is still visibile when the areaportal is closed. For models only the bounding box needs to be on both sides of the areaportal, for brushes atleast a part of that brush (and only the part that needs to be rendered).
To link the areaportal with the door either:
- Enter the name of the door in the "linked door" property of the func_areaportal
- Use the OnOpen and OnFullyClosed outputs of the door to trigger a Open or Close command with the func_areaportal
The Open and Close inputs can also be used to control the areaportal using triggers. This can be usefull for instance when you want to link the areaportal with a func_breakable (OnBreak->Open), or Close or Open an areaportal if a player has reached a certain part of your level.
It's sometimes a good idea to have areaportal-linked doors autoclose, so you have the optimal effect of your areaportals. Though it looks stupid, it's great for those players that can't close the doors behind their backs. Some players just don't have any manners.
The func_areaportalwindow differs from the func_areaportal in two ways:
- It has no in- or outputs
- It opens or closes depending on what distance the player is at
- It is clientside, meaning that it can be open for player 1, while being closed for player 2.
Wow, what was that second one? Opens or closes depending on the distance? Yes. Aren't you excited now? You should be. These areaportals have two properties, the "Fade start distance" and the "Fade end distance". The idea is that when you are far from a window you can't really see through it, so the window brush is visible only. But, as you come closer, the window brush becomes more and more translucent untill it is completely see-through. This areaportal is closed when the window-brush is visible, and as soon as the window-brush becomes more translucent (as the player moves from out of the "Fade end distance" to the "Fade start distance" ) the areaportalwindow opens and the 'outside' is rendered.
Take this example. When the player is near, the window is translucent and the room with the drums is visible. As the player moves further away from the window, the window becomes less see-through. When the player is outside the "Fade end distance" the window isn't see-through at all, the areaportal has closed and the drums and their room isn't rendered.
Setting up an func_areaportalwindow isn't as easy as setting up a normal func_areaportal.
You (again) need an areaportal, the func_areaportalwindow and a brush to cover it up (in this case a func_brush with a window-like texture). Setting this up is more diffucult, luckily the func_areaportalwindow does everything we need:
- Fade start Distance: Where the window-brush should start fading (default is 128 units)
- Fade end Distance: Where the window-brush should be completely opaque and the func_areaportalwindow should close (default is 512 units)
- Rendered window: The brush that is going to be faded in our out (the glass of the window). In this case the func_brush
There are more options, but I'll leave you to experiment with them yourself.
Note that the func_areaportalwindow only has one usefull input, the Kill command. If the window is destroyed (eg broken) you should also Kill the areaportalwindow as you can't fade a brush that doesn't exist... Failing to do so will make your map look stupid.
Areaportalwindows work awesomely with env_lightglow: You can simulate a window which looks really bright from far ( use the env_lightglow for the blinding effect, and use a brush with a white texture to fade in and out with the areaportalwindow ), and normally seen through from close. An EXCELLENT way to optimize maps, as long as the effect fits your theme. Make sure you match the fading distances between the two entities for optimal effect.
Areaportalwindows can also be used without a fading window, which is great for hiding area's the player can't see if he is far away from the areaportal. A good example is when you have a hill made out of a displacement and don't want the player to see the other side. The nice thing about areaportals is, is that when you have a skybox in your map, closed areaportals also show skybox. So if we would close this areaportal (purple) the player will see skybox! Which he would also see without the areaportal. You can also throw grenades through the closed areaportal, as if it wasn't there.
View from the player ingame: (wireframe, shows outline of everything that is being drawn)
Notice how you see ( should see ) exactly the same if we didn't have wireframe on, only to the right the boxes are not rendered because the areaportal was closed. For the rest, it works just like the previous window, just make sure the window brush is non-solid if you plan on it being passable.
The only problem with this method is that you need to make an area of "the part behind the hill", so that may be a problem for complicated outdoors. Still, it's probably better than nothing.
Again, for areaportals and -windows, experiment a bit. Build yourself an example level, place a few of these entities in them and find out what is rendered (see this chapter for how to do that). Use entity inputs (type "ent_fire [name of areaportal] [open or close]" in the console to open or close an areaportal in your level. Experimenting is the greatest way to learn.
|«- Previous Chapter||Next Chapter -»|
© Webdesign Copyright by Kolezan, contents Copyright by Ralph 'zombie@computer' van Hoorn