El 90% de las personas que se quejan de que su compilación tarda horas normalmente suelen tener un problema con el VIS (el otro 10% piensa que varias horas de compilación es algo normal) y de ese 90% aproximadamente entre el 10% y el 20% saben realmente cuales son los pasos de los que consta una compilación y cual es su funcionamiento. Así que el objetivo de esta sección es conocer cuales son los pasos que se dan en una compilación y como funciona, algo indispensable si queremos entender perfectamente otros apartados, como la optimización.
1.1 BSP
Al compilar, el BSP tiene el papel más primitivo, puesto que antes de que cualquiera de las otras herramientas entren en funcionamiento, se debe primero construir el mapa; y ese es el papel del BSP. En primer lugar, lo que hace es pasar por alto todas las entidades como los func_details y crea la estructura básica del nivel usando los polígonos. En el caso del Half-Life 2; todos los objetos se construyen a partir de triángulos.
Por lo tanto, su función principal es reducir el mapa en triángulos. El motor Source, que es en el que se basa el videojuego Half-Life 2, no admite polígonos con más de 3 vértices, al igual que la mayoría de los motores 3D actuales; así que Hammer tiene la obligación de convertir un polígono de 4 o 5 caras en 2 o 3 triángulos.
Aunque antes hayamos señalado que el BSP pasa por alto las entidades; esto no es realmente cierto, ya que no las ignora del todo, si no que realmente es que no están en el mapa. Debemos diferenciar por tanto el espacio particionable, tales como habitaciones y el Binary Space Partitioning [BSP] mediante el cual se registran las posiciones de las entidades y posteriormente, y dentro del juego, será el propio motor el encargado de mostar dichas entidades en relación con el espacio registrado en el BSP.
El particionamiento del espacio consiste en determinar la superficie jugable y los huecos existentes; además. hammer determinará cuáles son los lugares que probablemente el jugador sea capaz de encontrar. Lógicamente, se detiene en los sólidos que rodean el mapa (como por ejemplo la skybox) así que todo lo que quede fuera del mapa, simplemente, no existe. Y cuando digo lógicamente es por que si tu mapa no tiene ese sólido que indique al BSP dónde empieza y dónde termina tu mapa; aparecerán los temidos leaks (que veremos más adelante), puesto que no puede calcular el infinito; necesita unos límites.
1.2 VIS
Esta es la segunda herramienta que se ejecuta en el proceso de compilación, el cual tiene un papel muy importante en la optimización. Cuando el BSP ha terminado de reducir el mapa a triángulos y ha dividido el espacio jugable, es el turno del VVIS. ¿Alguna vez has probado tu mapa sin compilar con VVIS? Normalmente tendrás menos FPS ¿Por qué? Muy sencillo, el VIS actúa como si fuese los ojos del jugador puesto que calculará la visibilidad de cada objeto y todas las posiciones posibles. El saltarse este paso implica que todos los objetos son visibles por el jugador; disminuyendo así el número de FPS y aumentando el número de entidades mostradas innecesariamente.
Vamos con un ejemplo para entenderlo mejor:
Tenemos un pasillo (número 5) con 4 habitaciones conectadas entre ellas (números 1, 2, 3 y 4) Si nos situamos en la sala 1 ¿crees que es necesario calcular lo que hay en la sala 3? Definitivamente no; y eso es exáctamente lo que hace el VIS. Dado que no hay ninguna manera de ver la habitación número 3, esta simplemente no se mostrará. Por el contrario, si nos situamos en el pasillo, se calcularán todas las habitaciones puesto que podremos verlas.
1.3 RAD
Es la última herramienta que se ejecuta durante el proceso de compilación. El papel del RAD es la generación de luces y sombras y finalizar el mapa.
1.4 El tiempo de Compilación
Muchas personas afirman que un mapa bien optimizado no debería tardar más de una hora en compilarse; sin embargo esto es totalmente falso, ya que la compilación dependerá de otros factores como: