¿VVIS tarda una eternidad? Cómo reducir el tiempo de compilación

VVIS se pasa horas trabajando cuando tu mapa contiene demasiados visleafs y portales. La causa más frecuente es la geometría de detalle construida como world brushes. Convierte en func_detail todo lo que no tape la vista en una superficie grande. Así baja el número de portales y el tiempo de cálculo suele reducirse de forma drástica.

Qué calcula VVIS en realidad

VBSP divide el interior de tu mapa en visleafs. Son trozos convexos de espacio delimitados por las caras de los world brushes. Allí donde se tocan dos visleafs se crea un portal. Después, VVIS calcula qué visleafs pueden verse entre sí a través de esos portales. El motor usa el resultado en el juego para no renderizar las zonas que no se ven.

El esfuerzo no crece de forma proporcional al tamaño del mapa. Con cada portal adicional, el número de combinaciones que hay que comprobar aumenta de forma desproporcionada. Por eso una sola sala grande mal construida puede costar más tiempo que todo lo demás junto. Cómo se relacionan las tres herramientas de compilación lo explica el artículo sobre VBSP, VVIS y VRAD.

Leer el número de portales en el log

Al empezar, VVIS muestra dos cifras antes de que arranque el cálculo propiamente dicho. El siguiente ejemplo muestra la estructura:

 842 portalclusters
2302 numportals
BasePortalVis:       0...1...2...3...4...5...6...7...8...9...10 (3)
PortalFlow:          0...1...2...3...

numportals es tu medida más importante. No hay un umbral fijo, porque el tiempo de cálculo también depende del procesador y de la distribución de las salas. Lo que importa es la comparación: apunta la cifra antes de un cambio y después. Si baja de forma clara, vas por buen camino.

La fase larga es PortalFlow. Mientras sigan apareciendo cifras ahí, VVIS sigue trabajando y no se ha colgado. El artículo sobre cómo leer un compile log explica cómo interpretar el resto de líneas.

Por qué se crean demasiados portales

• Detalles como world brushes: Cada cara de un world brush puede seguir dividiendo el espacio. Los pilares, los escalones, los marcos de ventana, las molduras, las barandillas y los muebles hechos con brushes generan así muchos visleafs diminutos.
• Formas inclinadas y redondas: Los cilindros, los arcos y los brushes rotados cortan el espacio en ángulos especialmente desfavorables.
• Grandes zonas abiertas: En un exterior amplio casi todos los visleafs se ven entre sí. Aun así, VVIS tiene que comprobar cada combinación.
• Espacio hueco innecesario: Una caja gigante alrededor del mapa o enormes volúmenes de aire sobre la zona de juego aumentan el volumen que se divide.
• Demasiados hints: Cada hint brush añade cortes y, con ellos, portales.

Soluciones, ordenadas por efecto

1. Convierte los detalles. Selecciona los brushes, pulsa Ctrl+T y elige func_detail. La regla general: solo sigue siendo world brush lo que sella el mapa o tapa la vista en una superficie grande, es decir, paredes exteriores, suelos, techos y tabiques entre salas.
2. Simplifica la envolvente. Construye las salas con world brushes rectos y sencillos y pon delante la forma visible como func_detail. Las paredes curvas y los arcos nunca van en la geometría del mundo.
3. Usa props y displacements. Los modelos y los displacements no dividen el espacio. Construye el terreno como displacement con un brush sencillo debajo que use tools/toolsnodraw.
4. Agrupa las zonas abiertas. Con func_viscluster marcas un volumen en el que de todos modos todo se ve con todo. VVIS trata los visleafs de dentro como visibles entre sí y se ahorra comprobarlos uno a uno.
5. Coloca los hints con criterio. Un hint brush lleva tools/toolshint en la cara de corte y tools/toolsskip en todas las demás. Ponlo solo donde un corte concreto mejore de verdad la visibilidad, por ejemplo en la esquina de un pasillo.
6. Comprueba el resultado. Con Map → Load Portal File, Hammer muestra los portales de la última compilación. En el juego, mat_leafvis 1 muestra el visleaf en el que estás en ese momento; el comando requiere sv_cheats 1.

En el paso 1, ten en cuenta que func_detail no sella. Si conviertes una pared exterior por error, VBSP avisa de un leak. Qué hacer entonces lo cuenta el artículo sobre solucionar el error de leak del mapa.

Qué hace -fast y cuándo tiene sentido

Con el parámetro -fast, VVIS se salta el cálculo preciso y solo entrega un resultado aproximado. En Hammer equivale al ajuste "Fast" de "Run VIS". La compilación termina rápido, pero en el juego el motor da por visible mucho más de lo que realmente se puede ver. La tasa de fotogramas lo paga.

Un mapa que publicas o vendes necesita el cálculo completo. Si solo termina en un tiempo razonable con -fast, eso apunta a un problema de estructura y no es motivo para quedarse con el atajo. Encontrarás más medidas para la tasa de fotogramas en el artículo sobre optimizar el rendimiento de un mapa de GMod.

Si VVIS sigue tardando mucho

• Compila secciones sueltas con la herramienta cordon y compara numportals. Así sale a la luz la zona que genera más portales.
• Carga el archivo de portales en Hammer y busca los puntos donde las líneas se vuelven muy densas. Casi siempre hay ahí geometría de detalle olvidada.
• Mira si el log contiene además advertencias o errores. Puedes pegar un compile log en el Map Scanner. Detecta causas raíz, errores derivados y las soluciones adecuadas en logs de VBSP, VVIS y VRAD.

Preguntas frecuentes

¿Cuánto debería tardar VVIS?

No hay un valor fijo. Un mapa bien construido suele estar listo en minutos, y los mapas muy grandes tardan más en proporción. Si VVIS lleva horas, el motivo es casi siempre la geometría y no el hardware.

¿Puedo saltarme VVIS sin más?

Para pruebas rápidas, sí. Para una publicación, no, porque sin datos de visibilidad el motor renderiza el mapa entero en todo momento. En mapas grandes la tasa de fotogramas se hunde.

¿Los areaportals acortan el tiempo de VVIS?

No. Los areaportals actúan en tiempo de ejecución y ocultan en el juego las zonas que no se ven a través de una abertura. Mejoran la tasa de fotogramas, pero no resuelven un problema de compilación.

¿func_detail hace que el mapa vaya más lento en el juego?

No, siempre que lo uses bien. Eso sí, func_detail no bloquea la visibilidad. Las paredes que separan dos salas tienen que seguir siendo world brushes; de lo contrario, el motor renderiza las dos salas a la vez.