VBSP, VVIS y VRAD explicados: los tres pasos de la compilación

La compilación convierte tu VMF en un BSP jugable en tres pasos: VBSP construye la geometría y comprueba si hay leaks, VVIS calcula qué se ve desde dónde y VRAD calcula la iluminación. VVIS y VRAD se llevan la mayor parte del tiempo. Para las pruebas usas ajustes rápidos; para publicar, una compilación completa.

Resumen: quién hace qué

Los tres programas, vbsp.exe, vvis.exe y vrad.exe, están en la carpeta bin del juego. Hammer los ejecuta uno tras otro cuando pulsas F9 y copia el BSP terminado a la carpeta de mapas. Todo lo que imprimen los programas acaba además en un archivo de log junto a tu VMF.

VBSP: geometría y leaks

VBSP convierte tus brushes en caras, elimina las caras que quedan fuera del mapa y divide el interior en visleafs. También escribe en el BSP las entities, los props estáticos, los overlays y los displacements.

De paso, VBSP comprueba si el mapa está sellado. Inunda el espacio partiendo de las entities y avisa de un leak en cuanto llega al vacío exterior. En el log aparece entonces **** leaked ****, y VBSP escribe un pointfile que puedes mostrar en Hammer con Map > Load Pointfile como una línea que lleva hasta el leak. En ese caso no se crea el archivo de portales. Las consecuencias: VVIS no puede trabajar, el motor dibuja siempre el mapa entero y la iluminación solo se calcula de forma incompleta. Cómo encontrar el leak lo tienes en Solucionar un error de leak en el mapa.

El parámetro -onlyents es útil para las pruebas. Solo actualiza las entities de un BSP ya compilado, sin reconstruir la geometría. Ahorra tiempo cuando solo has cambiado lógica o ajustes de entities. Los brushes, incluidos los de las brush entities, se quedan como estaban. En nuestra prueba con el VBSP de GMod también se actualizaron los props estáticos; los overlays, no.

VVIS: visibilidad

VVIS lee los portales que hay entre los visleafs y calcula, para cada zona, qué otras zonas podrían verse desde ella. Más adelante el motor usa ese resultado para decidir qué hace falta dibujar.

En el log se distinguen dos fases: BasePortalVis es un cálculo previo aproximado, y PortalFlow, el exacto y normalmente mucho más largo. Antes de eso, el log indica el número de portales. Es lo que más determina la duración. Muchos brushes de mundo pequeños y los espacios abiertos grandes generan muchos portales.

• Con -fast, VVIS se salta el cálculo exacto. La compilación es rápida, pero en el juego el motor dibuja más de lo necesario. No sirve para publicar, y las mediciones de FPS hechas así no valen nada.
• Si VVIS tarda demasiado, convierte los detalles en func_detail y simplifica la geometría del mundo. Para zonas abiertas grandes existe func_viscluster. Los detalles están en VVIS tarda una eternidad.

VRAD: iluminación

VRAD calcula la luz directa de cada cara, después la hace rebotar varias veces en las superficies y guarda el resultado como lightmaps. A eso se suman los datos de iluminación de los props estáticos y de los objetos que se mueven.

Los parámetros más importantes:

• -fast: cálculo rápido y visiblemente más tosco, para pruebas.
• -final: cálculo más preciso para publicar, bastante más lento.
• -ldr, -hdr, -both: define qué rango de brillo se calcula. Con -both el cálculo se hace dos veces.
• -StaticPropLighting, -StaticPropPolys, -textureshadows: mejor iluminación y sombras más precisas para los props estáticos.

El tiempo depende del tamaño del mapa, del número de luces y del lightmap scale. Los valores pequeños de lightmap scale en caras grandes son un motivo habitual de las pasadas muy largas. En el log ves primero la iluminación directa (BuildFacelights), después cada uno de los rebotes y, al final, una tabla que muestra lo llenas que están las secciones de datos del BSP. Todo sobre la iluminación está en la guía de iluminación en Source Engine.

Ajustes para probar y para publicar

En el diálogo normal "Run Map" eliges entre "No", "Normal" y "Fast" para VIS. RAD tiene esos mismos tres niveles en Hammer++, y el Hammer incluido añade "Faster" y "Final". En BSP, la tercera opción no es un modo rápido, sino "Only entities". "Expert" te lleva a perfiles ya preparados y te deja editar los parámetros uno a uno.

Después de la compilación de publicación quedan dos tareas que no forman parte de los tres programas: generar los cubemaps en el juego y empaquetar el contenido custom en el BSP. Cómo se hace está descrito en Empaquetar contenido custom en un BSP.

Cuando la compilación falla

Lee el log de arriba abajo y busca el primer error. Los mensajes posteriores suelen ser solo consecuencias de él. Un leak en VBSP, por ejemplo, hace que VVIS no encuentre el archivo de portales. Si solo lees el último mensaje, acabas buscando en el sitio equivocado.

También puedes pegar el log en el Map Scanner. Detecta causas raíz, errores derivados y las soluciones correspondientes en los logs de VBSP, VVIS y VRAD.

Preguntas frecuentes

¿Por qué tarda tanto VVIS?

La duración depende del número de portales, y este sube con cada brush de mundo que trocea el espacio. Convierte los detalles en func_detail y mantén simple la geometría que sella el mapa. Los espacios abiertos grandes salen por lo general más caros que los interiores con recovecos.

¿Puedo saltarme VVIS o VRAD?

Para las pruebas, sí. Sin VVIS el motor dibuja siempre el mapa entero; sin VRAD el mapa tiene un brillo uniforme y no hay sombras. Un mapa publicado necesita los dos pasos completos.

¿Qué significa "leaked" en el log?

El interior del mapa no está completamente cerrado por brushes de mundo, o hay una entity fuera. VBSP no crea entonces el archivo de portales, y los pasos siguientes no dan un resultado aprovechable. Arregla el leak antes de investigar otros errores.

¿Tengo que recompilarlo todo después de cada cambio?

Tras cambios en los brushes, sí, porque la geometría, la visibilidad y la iluminación dependen unas de otras. Si solo has cambiado ajustes de entities que no afectan a la iluminación, para una prueba basta con una pasada de VBSP con -onlyents. No actualiza los overlays ni los brushes, y para publicar hace falta una compilación completa.