Hint : Hint planes are used to split visleaves during compile time and, as such, are a way of optimizing the results of the Vis map compile stage. Here a few examples of when and how to use hints. In all cases the goal is to hide the green players from each other. The upper three work as they should. The left one illustrates that it doesn't even matter if its one hint-brush spanning the corner, as long as its angle is > 180° the two players will not "see" each other's leaves because no straight line can be drawn between their leaves. The bottom-left example shows you that can happen when the angle is less than 180°. One can easily draw a straight line from leaf to leaf, resulting in non-functional hints. Learning how visleaves work may aid the understanding of this article.
Sometimes, certain leaf shapes are preferred over others simply because that shape makes those leaves see less other leaves. Whenever a leaf is not seen, the contents of the leaf is not drawn, speeding up rendering.
When the corner in the hallway is 180°, as in the middle top picture, two hints will suffice. In fact, they can even be closer to the players, but that would decrease their effectiveness (more stuff will be drawn "around the corner". ) In the example in the middle bottom, the hints have been lowered and vbsp is forced to cut up the top visleaf because visleaves can't be concave. No matter how vbsp cuts up this corner, the hints will always work less effectively and create extra leaves (more work for vvis). In the example, the left player can see leaves 1 and 2 (same surfaces as above), but the right player will see all three numbered leaves (which is more than the top example.).

In summary, since hints have no direct rendering cost during the playing of a map, when used wisely they are a primary way to speed up your map and control your visibility.

They are commonly referred to as hint brushes since they are placed in a map in the same way as a normal world brush. The hint plane is defined by the side of the brush that is covered with the tools/toolshint texture. Multiple hint planes can be defined by texturing multiple sides of the brush, or by using multiple brushes. The other sides of the brush that are not acting as hint planes must be covered with the tools/toolsskip texture; these faces will be ignored by the compiler.
Lastly, hints can be used to simplify a map. Sometimes, vbsp cuts up a level into more leaves than necessary. This increases compile time. Hints can be used to counteract this. For instance, hints can be placed in doorways to prevent the doorways from cutting up the rooms they connect. Or, if you get an error that a certain visleaf is cornering too many other visleaves, hints can used to cut that leaf into multiple leaves that corner a smaller amount of leaves. Lastly, hints can be used to simplify a map. Sometimes, vbsp cuts up a level into more leaves than necessary. This increases compile time. Hints can be used to counteract this. For instance, hints can be placed in doorways to prevent the doorways from cutting up the rooms they connect. Or, if you get an error that a certain visleaf is cornering too many other visleaves, hints can used to cut that leaf into multiple leaves that corner a smaller amount of leaves.

Note : Visleafs will always be divided every 1024 units (at each red or blue line in the 2D views)

Placement Tip : Each instance of a hint node must be positioned in exactly the right location on the map - dumb hint node placement will lead to dumb NPC behaviour. Each hint node can only suggest one hint, as each NPC can only use one hint at a time. Thus, sometimes you may need to position a variety of hint nodes very close to each other.
Placement Tip : Ground nodes (such as info_node_hint) fall to the ground when they spawn, so you can place them up to 128 units above any solid world geometry, which excludes func_brush, and they will still work. When placing ground nodes on displacements, place them slightly above the terrain to ensure nodegraph connections are properly made. By contrast, info_hint and info_node_air_hint entities will not move from their original placement positions

Skip : Skip textures are applied to the surfaces on brushes with hint textures that should not be used to break up visleafs (or leafs in short). Usually, a brush used for hinting is rectangular and has a hint texture on one or two surfaces and skip textures on the rest. Skip textures do nothing more than making the tools skip this side of the brush. For the usage of hints, see the hint brush section.

Skip textures can also make it easier to group/copy/move objects in large maps: Create a normal brush around these objects entirely textured with tools/toolsskip. This allows groups of objects to all be on a normal measurement, such as 256 x 256 x 256, making movement of these groups on par with the Hammer editor's graph. This brush is a tool for the design phase and will not be compiled into the map.

Areaportals : An areaportal is a brush entity, func_areaportal, that can be used to 'seal' separate visleaves and control visibility. Areaportals are like doorways that can only be fully open or closed. When an areaportal is closed, it blocks the visibility of the geometry and other objects in the area behind it. When it is open, the geometry is visible again. Areaportals can be dynamically opened and closed while the engine is running. They are typically set to open and close from sets of trigger_multiple brushes using the entity I/O system or by linkage with a door entity.
Func_areaportalwindow is a brush entity available in all Source games. It creates an areaportal that automatically closes as the camera moves away, fading a second, opaque brush in to fill the gap.
A standard areaportal: is tied to the func_areaportal entity.
Must be constructed of only one brush. Areaportal entities with more than one brush will generate an error when compiled by vbsp.
Must use the tools\toolsareaportal material applied to all faces of the areaportal brush.
Cannot contain displacements and will generate an vbsp error if they do.
Must be used to seal the all areas they connect to, to avoid leaks.
Are volumes, not single surfaces. Although areaportals can be any size, usually they are constructed of thin brushes that are the size of the areas (doorways) that they connect.
Generate a new visleaf the size of the areaportal volume.
Can be set to open or close based on entity logic, or by attaching them to a door entity. The func_areaportalwindow entity behaves like a standard areaportal, with the addition of fading out and closing if the player moves a specified distance from it. This avoids the "pop" of an areaportal suddenly opening. Create the areaportal volume with a single brush solid, completely sealing the space between the two areas that you wish to control. (Multiple areaportals side-by-side can do this if necessary. Avoid giving more than six sides to any single areaportal entity.)
If the areaportal is connecting two areas like a doorway, make the areaportal brush the size of the opening, and the thickness the same as the walls it is connecting. If the areas are open areas, such as an outdoor section, the thickness can be of any size (grid sizes of 8, 16, 32, etc. are typical).
Apply the tools\toolsareaportal material to all faces of the brush.
Tie the brush to a func_areaportal entity.
Set the Initial State keyvalue so that it doesn't end up blocking visibility when it shouldn't. If you wish to link it to a named door, set the Initial State of the portal to the same initial state as the door, and put the name of the door in the Name of Linked Door keyvalue of the portal. When the door is closed the Initial State of the areaportal should be Closed too, and vice versa.
The func_areaportalwindow entity behaves like a standard areaportal, with the addition of fading out and closing if the player moves a specified distance from it. This avoids the "pop" of an areaportal suddenly opening.
Areaportals only cull between the areas that they seal off. Consider the image down: while the contents of the building are culled away as you would expect, visibility between visleaf one and two is unaffected because they are connected to each other via the sides of the building.



This can be fixed by creating two further areaportals on either side of the building...but is it really worth it?

Care must be taken to avoid having too many areaportals visible simultaneously. There is processing cost for each, and if portals are not culling enough geometry and models it's quite possible that the expense of processing them will be more than that of drawing the scene without them. Areaportals don't form brushes in a compiled map, so don't count towards the brush lump's size limit. This can be useful when you have an incredibly full BSP and are using plenty of hints.

Tip : When linking an areaportal to a named door, make sure it is thinner than the door model itself to ensure the latter will be rendered when closed. It may help to imagine a fish tank filled with water with several holes in its sides. An areaportal must fill each of those holes, or the area will leak, generating a leak error by vbsp. Areaportals must be used to seal every entrance to the area. Detail brushes or displacements cannot seal an area. If the compiler can still find a way between the two main surfaces of any one portal, it will report a portal leak.
Brush <brush number>: areaportal brush doesn't touch two areas done
These error messages are sometimes not as easy to spot as normal leak error messages, but when it comes to locating the leak in the map, vbsp will generate a pointfile to help you, just as for regular geometry leaks.

Areaportals and water
One other tricky aspect of using areaportals is that they are not allowed to cross water boundaries, like the water surface. To accomplish this, you will need to divide the portal into two - one areaportal above the water surface, and another areaportal below it - so that they both meet at the water plane.

Merging
For optimization reasons, areaportals that share the same plane (are aligned) are automatically merged by the engine. If this behavior is unwanted, simply ensure the areaportal brushes are not along the same plane. This is usually as simple as shrinking or moving one of the areaportals slightly in the editor so they are no longer aligned. Even grid one unit is sufficient to avoid an automatic merge.

Tip : You can see if areaportals are being merged in the engine by using the r_DrawPortals 1 console command.

Console commands
You can debug and test portals in-game, using some portal-specific console variables:

r_DrawPortals 0/1
Outlines any portal border surface (between two areas) in green when set to "1". Sometimes more than one portal is condensed into one. If the portal belonging to it is open, a second green box is also drawn, showing what the visibility on the other side is clipped to.
mat_wireframe 0/1/2/3
Draws geometry in wireframe mode, making it easy to see the effects of areaportals in the level. When debugging areaportals, you should typically use mat_wireframe set to "1" or "2", as the "3" setting can hide geometry that is actually rendering.
r_portalscloseall 0/1
Setting this to "1" forces all areaportals closed (so that they cannot be opened). Overrides r_portalsopenall 1. (Try this if portals don't seem to be doing anything. It can tell you whether the problem is just that the portals aren't closing properly.)
r_portalsopenall 0/1
Setting this to "1" forces all areaportals open (so that they cannot be closed).

Tip : Use the BindToggle console command to allow a single key to be used to toggle a console variable. Areaportals are very useful in multiplayer games. Their creation is identical to those in single-player games, but their function and usage is slightly different. With multiple players in a game server, there is less control of when an areaportal is going to be open, and level performance needs to be optimized for worst case scenarios (i.e. when all visible portals are open). Because of this, in most cases, 'always open' areaportals are placed most often, followed by areaportals linked to doors, and then areaportals controlled by triggers. In worst case scenarios, well-crafted 'always open' areaportals will increase performance more than portals that are designed to be triggered.

An areaportal window can also be used seal structures in multiplayer, but are less useful because they can create gameplay imbalances in competitive multiplayer games. A player inside the structure that is near the areaportal window would be able to see any players outside, but players farther away outside would not be able to see the player inside.
Areaportals are similar to occluders in that they help control visibilty.
The main differences between them are :
Occluders only hide model (prop) geometry that is behind them. Areaportals hide all types of objects.
Areaportals must fully seal areas (allow no leaks), while occluders can be free-standing inside areas.
Occluders are more expensive per object than open areaportals.
Occluders have controls for the size of objects they will hide, based upon screen area.

Note : Brushes in areaportal and occluder entities should not intersect (touch) each other, and will not function correctly if they do.

I hope this short tutorial-version of 3 diffrent tutorials helps u. It tooks one hour work.
If not visit the best Developer page ever :

http://developer.valvesoftware.com/

And search in the left Searchbox for ur problem as example :
Type in hint then search. Gl, hf and happy maping m8´s Trek