Func viscluster: Difference between revisions
(Please verify claims. Func_viscluster is not a very well-understood entity and the bullet points are intended to give a concrete list of facts to refer to when understanding its behavior. I can confirm in the Garry's Mod engine.) |
(Note that visclusters shouldnt be used with VVIS++) |
||
| (35 intermediate revisions by 17 users not shown) | |||
| Line 1: | Line 1: | ||
{{ | {{LanguageBar}} | ||
{{this is a|brush entity|internal=1|name=func_viscluster|since=Source 2007|sprite=toolstrigger.gif}} | |||
}} | [[File:Tools Viscluster.png|thumb|160px|{{mono|tools\tools_viscluster}} from {{bms|4}}, 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 <tt>tools\toolstrigger</tt>. | |||
{{ | {{Internal entity note}} | ||
{{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 {{ent|mat_leafvis}} show the leaves to still be intact.}} | |||
{{note|The {{code|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 (shader)|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 <code>func_viscluster</code> on the other side. Never allow a <tt>func_viscluster</tt> brush to cross a water plane, or ''very'' strange things happen.}} | ||
{{ | == Caveat == | ||
{{code|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 [[RAD_(technical)|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 <code>BuildVisLeaf</code> 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 {{tf2}} 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. | |||
== See also == | |||
* [[Visibility optimization]] | |||
== External links == | |||
* [https://youtu.be/Ds5E7HBQ-nU Video tutorial] | |||
[[Category:Optimization Brush Entities]] | [[Category:Optimization Brush Entities]] | ||
Latest revision as of 00:50, 21 October 2025
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.