So yeah, what's the true difference between these 2? Some maps use hint, others use area portal to optimise.. But I don't really get the difference, pros and cons..

Anyone can explain?

hints cut vis leaves wherever you set them up. This can be useful to block the rendering of things "right around the corner that you don't see yet".

Areaportals can be used as hints in that sense, but they're much more elaborate as they exist in two kinds (func_areaportal and func_areaportalwindow) and two status (open or close)

Areaportal either block the rendering permanently until the player crosses the areaportal (a closed areaportal) or renders things beyond progressively, instead of at once like the hints do. That can help when you are entering a new area of a map and you experience a couple seconds of lag due to too many things suddenly being rendered at once. If you do it progressively you also spread the hit on resources progressively.

The major difference remains that an areaportal seals off an area, as opposed to a hint which doesn't seal off anything. So an areaportal can't be used by itself in any room or building, as more areaportals will be needed for each hole (windows/doors, etc) your building has.

Think of areaportals as volume containers. Any leaks and your areaportals won't work. Hints would only be a knife cutting through your map.

Generally speaking, areaportals are more powerful, but won't work if they don't seal off an entire area (if one of your room uses an areaportal, all doors/windows/gaps within that room need another areaportal). They are therefore a bigger pain to set up.

Hints are less powerful, but easier to set up, and also happen to be known by the HL mappers (areaportals are a Source particularity).

NB: func_areaportalwindows are client side entities. func_areaportal are however server side, and can cause massive lag if set to change status through a trigger (open or closed). It's therefore best in a MP environment to always set areaportals as "open", including within doors, and to never assign them to any brushes.

nice one Furyo.
maybe someone should move/copy your post to the tutorials, as that's the most easy to understand explanation of hints and portals i've read yet.

even i could understand it. :)

So, I should use area portal to seal houses (doors/windows) and hint to cut the outside..

Allthough I'm struggling quite hard to hint up the forest part of my map.. it's 90% displacement with quite a few open areas (read, skyboxes placed far away from eachother).. I gave it a try, and didn't change a thing in fps or rendering, so I guess it didn't work :)

Well hint placement is a whole subject in itself. It's very easy to place them wrong and have even less FPS than what you started with.

But yes, "areaportals should be used for buildings and hints for outside" can be a good rule of thumbs. But it's not always the case.

If you look at salerno_rc1, Insta uses hints for buildings. His answer to my question about that was "I don't know why I used them, areaportals are better". So there you go, it's not always what you see elsewhere that's the good solution. I believe he changed them in rc3 but I'm not sure.

For a long while, I was using areaportals for outdoor places on Dijon, using multiple areaportals and vertex editing them so they would span across a whole street. I had the hardest time setting them without leaks (that was during the Source Beta) and once we got the final game, they started acting up, and caused all sorts of hell. So I deleted them all and used hints instead.

You can easily reach a couple hundred areaportals if you try and seal off every single part of your map (relatively big map). The limit is very high, so you can use them as you see fit, however you'll always have a hit in game with areaportals, because the engine needs to calculate what you see and don't see through the areaportal, so it knows what to render.

Obviously that's not a huge cost, but if you see areaportals starting acting up, you can always delete some off.

For example, two adjacent rooms divided by a door are fine as long as the windows have areaportals. The door itself doesn't need any. Both rooms would remain sealed off and transformed into one area as far as rendering is concerned. It won't change anything for you because if you see an areaportal through an areaportal (1 areaportal standing between you and another areaportal) the engine will continue to render what beyond the second one. The first areaportal in this case only serves as a hint, and therefore can be replaced by a hint, that's less costly (as hints are not calculated within the game but during the compile).

The end result will be less in game calculations, but an increase in compile time (one more hint)


EDIT: I've noticed in my church on Dijon that if you use an always closed areaportal within a wall (I had some within the walls on the second floor, in between the stained glass windows) and also have open areaportals sealing off the same area (church entrance, other church doors), the always closed areaportals turn into always open ones.

So it would seem that for always closed areaportals to work, all areaportals sealing off said area need to be closed at all times. In which case, I have yet to find a good opportunity to use them in a MP environment. Well I guess I did find one with my secret room in the church. The altar has an always closed areaportal within it, that opens up only with the opening of the altar. That way I saved some brushes from being rendered too...

The solution for me was to insert 1 unit wide brushes (world brushes of course, to block VIS) in the place of the closed areaportals, or the outside would be rendered from within the church, which cost me about 20-25 FPS.

This is also the reason why my main stain glass model (same one as on avalanche) can not be shot (as opposed to its avalanche counterpart). If one was to shoot it, you'd have a brush standing in between you and the area beyond the stained glass window.

So it's also about compromises. People want to shoot that window, as it was originall intended to be a sniper position, but that was costing too much in terms of performance, so I had to settle with that solution