func_viscluster
func_viscluster is an internal brush entity available in all 
Source games since 
Source 2007.
Black Mesa, a custom trigger texture designed to make it easy to identify visclusters.It allows you to manually tell VVIS that the visleafs inside its volume can all see each other and should be treated as one. This is useful in large open areas where visibility calculations would otherwise take a very, very long time to complete. Poor use may be expensive for in-game performance. It can be textured with any material, but is conventionally textured with a trigger material, such as tools\toolstrigger.
Note:This is an internal entity. When the map is compiled by VBSP, it is processed and then removed; it does not exist when the map is running.Note:This entity does not actually change the location or number of leafs in a map. Hammer's portal file says this occurs, but commands such as mat_leafvis show the leaves to still be intact.Note:The func_viscluster must cover at least 10% of a leaf's volume for it to be merged.
Warning:The brush should not cross the surface of a water material or an areaportal. If it really does need to be used over water, bring the brush level with the surface of the water on one side, and then create a second, separate func_viscluster on the other side. Never allow a func_viscluster brush to cross a water plane, or very strange things happen.Caveat
func_viscluster is a trade-off: it reduces the visibility compile time at the expensive of performance. A more obscure fact is that it also increases the lighting compile time. This is because VRAD uses the visibility data to accelerate bounced lighting calculations, and visclusters will strip away this optimization. Reckless use of visclusters can make using them not worthwhile, due to the net compile time being higher after including the longer lighting calculations. The usual symptom is being bottlenecked on the BuildVisLeaf step in VRAD. This can be partially mitigated by splitting visleafs up with hint or reducing the area the viscluster covers.
For games that support VVIS++: it is recommended to NOT use visclusters at all. VVIS++ is fast enough that wide, open areas do not make visibility calculations grow exponentially in time anymore. In-fact, visclusters will hinder VVIS++ optimizations, and it has been tested (on recent community 
maps) that compiling maps without visclusters with VVIS++ is faster than compiling with VVIS++ and visclusters together. Compiling without visclusters will also make the map run at better performance in-game.