[Request] Areaportals + Occulation

I know about visleafs hint/skip textures in terms of optimising and i understand the general application of the areaportal brush and setting its class to func_area portal. I have made small test maps will multiple rooms only and use areaportals in the doorways to understand it, but when it comes to using them outside in the open, i get a bit confused.

When i decompiled granary, i saw moderate use of areaportals but couldnt understand how the portals were behaving since the portals seemed to leak but were ok (if they did infact leak, this would be a problem)

Like i explained, inside buildings / closed spaces im fine with them, but closed spaces connecting to outside areas is where i get confused. I have used the following as referance, and have read the Valve dev community wiki too.

Areaportals act kind of like seperators making each part they seperate thier own mini map. As long as you seal all entrances to the outside(acts as a void or leak) youll be fine.

As far as I know about occluders they block props from being prerendered though walls so covering the outsdie of a building that uses alot or props inside would be good(i may be wrong about how they work though)

Occluders block direct line of sight to models. so placing them against walls where a player might see around the corner due to bad leaf nodes is a good option to increase performance. How ever occluders work in real time and do cost memory to work, so using them can be a tricky business as you may end up making your performance worse, if you cannot balance the amount of props blocked by the occluder itself with the justification for its use. Also larger occluders cost more memory than smaller ones.

Occluders are handy when heavily utilising displacements, as displacements do not block vis, and tend to leave objects rendered on it's opposite side. Valve used occluders heavily in HL2 and it's subsequent episodes. If you have them, check out sdk_d2_coast_12 to see how they have used occluders to block visibility through displacement cliffs.

mat_wireframe is a useful console development tool to check what is being rendered at any one time.

Areaportals are harder to use in open space. As long as you have the oppotunity to use a single face to block two area's without any leaks then it is possible to use one. But chances are you cannot, and you'll just have to leave it.

sdk_pl_badwater is a useful reference for areaportal usage. If you cannot find them in your sdk_content folder then refresh your SDK content from you SDK window.

After a while you learn to use them intelligently. Valve maps actually are good examples of how to use them, if you can get your head around how complex they usually look.

occluders are good in that they don't need to close off an area. The better way of using them is to create a nodraw brush, tie it to a func_occluder, and then apply the occluder texture to the main two larger sides that will help to hide props. having the whole brush as occluder texture just adds an overhead.

areaportals & the window version are probably the most annoying optimization tool, due to them leaking all the time. However, even when you don't link them to a door, their benefit is a strong one as they only render props and func_details, and other detail objects that are visible through the portal. looking at a forest through a window with areaportal on it will only render the trees that are visible through it.

they both have overheads, and it takes experience to know when to use which type where.

The face textured with occluder will only work one-way. Skip faces are deleted during the VBSP process so I don't see why it would affect occluders but for that matter I don't see why you would even texture an occluder using skip. >_>

eh...occluder with skip...generally not a good idea: use nodraw, no need to break your head over whether some texture can be used for something or not. As psy said, occluder faces are one-way. I.e. a nodraw cube with one face with occluder will hide props that are behind the square occluder texture [invisible in-game]. it only works that way, as a simplistic method of explaining it is that occluder texture is not double-sided. Intimate knowledge of how source does it's occlusion & visibility detection which is generally not accessible to mappers/modders is needed to fully understand why. But that's not a problem.

Place a solid fence prop; make a thin (1 inch) thick nodraw brush and place it roughly along the fence; tie to func_occluder; apply occluder texture to the two large flat brushes; Done. Any props that are completely hidden behind the func_occluder will not be rendered, from both sides. There is an overhead for placing a func_occluder, though, as it has to do line-of-sight methematics in the background, but don't be afraid to use them at all. Just...be sensible about them.

Areaportals are actually easier (Okay, i lied: at least until you get areaportal leaks). create a brush the exact size of your doorway/window/opening with the areaportal texture, tie to func_areaportal. Done. Do remember that areaportals cut visleaves, so it's best to try to line them up to the thickness of whatever you're using them in.
Areaportalwindows are similar, just that instead of being open or closed, they can fade into the closed position-hiding the visleaves behind the areaportal, but require a func_brush larger than the areaportal to avoid getting a nodraw-esque problem. A named func_brush. Generally not used in tf2 due to giving an unfair advantage to snipers as they can clearly see through the areaportal, but someone who's beyond the fade distance will just see a black blob, or whatever the texture applied to the func_brush is. It is used *everywhere* in L4D, though. /trivia

Cheers guys.
Been doing some broader testing in hammer with area portals, and opened up some of the HL2 sdk files in CSS to have alook wat what valve did. I understand area portals alot better now

As i understand, occluders are best used in primarily 1 player games in general, as there usually is only one playable player, and you can control what you see with ingame events (such as buttons / triggers) alot more by having the buttons tied to activating / deactivating the occluder.

I always knew occluder was a dodgey one, hence why i used hint/skip and areaportals for primarily controlling visibility. So ill just stick to areaportals and hint/skip

well, occluders don't need to have an I/O system linked to them. They are optimization tools that can stab you in the back when you least expect it in the form of huge performance drop due to line-of-sight calculations.

An example of where occluder *could* work is in ctf_2fort, along the sniper fences. placing an occluder there could hide objects, and gain a few fps that way.

The other most commonly used area for occluders are walls & floors, especially the func_detail walls & floors as they stop the visiblity of objects behind them, but they don't stop the game from rendering those objects. A general rule is to consider placing func_occluders exactly over the detail walls. Placing them in the floors and ceilings can also be done, but remember not to over use them. I don't really use them that much in tf2 anyway as the environments need to be "clean", with a few strategically placed props in the corners to allow a fluid gameplay.

Also, another major performance tool in source is the fade distance of props. This is much more widely used in tf2 than using occluders as the props fade by distance from every angle not just by looking through a 'window'. Most of the time people won't even notice that distant props are fading, with the exception of the bloody sniper.