Reducir el tamaño de un BSP: qué hace grandes los mapas y qué ayuda

Un BSP casi siempre se hace grande por tres cosas: los lightmaps, que en una compilación HDR se guardan dos veces, el contenido empaquetado en el pakfile y los cubemaps HDR. Mide primero qué bloque domina en tu mapa. Después, un lightmap scale más alto en las caras grandes, un empaquetado cuidadoso y cubemaps pequeños ayudan donde de verdad importa. Comprimir el BSP terminado es el último paso y no sustituye nada de lo anterior.

Qué ocupa espacio en un BSP

Un BSP se compone de bloques de datos llamados lumps. Su estructura se explica en ¿Qué es un archivo BSP?. Para el tamaño solo importan unos pocos:

Dos de los mapas originales de GMod muestran lo distinto que puede salir (1 MB = 1 000 000 bytes):

• gm_construct ocupa 36,7 MB. De ellos, 24,5 MB son lightmaps: 12,3 MB para LDR y exactamente la misma cantidad otra vez para HDR. El pakfile ocupa 3,8 MB, incluidos 2,1 MB de cubemaps HDR y 1,4 MB de iluminación de props. Los datos de colisión suman 3,1 MB, y los lumps de los 110 displacements, 0,8 MB en total.
• gm_flatgrass ocupa 47,4 MB aunque el mapa está casi vacío. 41,6 MB corresponden al pakfile, y 39,1 MB de ellos están en solo ocho cubemaps HDR.

Mide antes de recortar

Al final de su log, VRAD enumera todas las áreas de datos. En la columna Memory, el número que hay antes de la barra es el tamaño en bytes. Las filas que importan tienen este aspecto (de un mapa de prueba pequeño):

Object names       Objects/Maxobjs  Memory / Maxmem  Fullness
LDR lightdata         [variable]       36320/0        ( 0.0%)
HDR lightdata         [variable]       36320/0        ( 0.0%)
pakfile               [variable]       24864/0        ( 0.0%)
physics               [variable]        4178/4194304  ( 0.1%)

bspzip muestra qué hay dentro del pakfile. El primer comando solo lista los nombres. El segundo escribe el pakfile como archivo ZIP, que puedes ordenar por tamaño en un programa de compresión de archivos:

bspzip -dir mymap.bsp
bspzip -extract mymap.bsp pakfile.zip

Para un BSP subido, el Map Scanner también muestra el tamaño del archivo, el número de archivos del pakfile y un extracto de ellos.

Lightmaps: scale y HDR

El lightmap scale indica cuántas unidades cubre una muestra de luz (luxel). Cada luxel ocupa cuatro bytes y, según la wiki de Valve, las caras con bump map guardan cuatro veces más. Si reduces el scale a la mitad, el número de luxels se multiplica aproximadamente por cuatro. En nuestro mapa de prueba con dos salas, la iluminación ocupaba unos 10 KB con scale 32, unos 36 KB con el valor por defecto de 16 y unos 564 KB con scale 4.

• Sube el scale a 32 o 64 en caras grandes e iluminadas de forma uniforme. El precio son bordes de sombra más suaves y menos precisos.
• Bájalo solo donde una sombra tenga que ser realmente nítida.
• Aplica tools/toolsnodraw a las caras que nadie ve. VBSP las elimina, y con ellas desaparece su lightmap.
• En Hammer, el modo de vista 3D «3D Lightmap Grid» muestra la densidad de luxels de cada cara.

La segunda gran palanca es el HDR. VRAD conoce -ldr, -hdr y -both. El texto de ayuda del VRAD de GMod no recoge los tres parámetros, pero el programa los acepta. Sin ninguno de ellos solo calcula LDR. Con -both, VRAD escribe un segundo lump de iluminación del mismo tamaño; con -StaticPropLighting, además un segundo archivo .vhv por prop, y generas los cubemaps dos veces. Por eso un mapa solo LDR es bastante más pequeño, pero renuncia al HDR para todos los jugadores. Lo que se gana y lo que se pierde se describe en la guía de iluminación de Source Engine.

Pakfile: contenido y cubemaps

Empaqueta solo lo que el mapa usa, y nada que todos los jugadores ya tengan con el juego. Las texturas se llevan casi siempre la mayor parte. La resolución, el formato y la revisión de la lista se tratan en empaquetar contenido custom en un BSP.

Los cubemaps se subestiman. buildcubemaps escribe en el pakfile una textura por cada env_cubemap, y en un mapa HDR además un .hdr.vtf. La versión HDR guarda 16 bits por canal y, en los dos mapas originales, ocupa unas dieciséis veces lo que la versión LDR comprimida: unos 77 KB a 32x32, pero 4,9 MB a 256x256. Cada paso en el campo «Cubemap Size» cuadruplica el archivo. Así que deja el tamaño en «Default» y súbelo solo en puntos concretos con grandes superficies reflectantes. Más sobre cubemaps en arreglar los reflejos de los cubemaps.

No toques bspzip -deletecubemaps en un mapa empaquetado: según la wiki de Valve, el comando borra todos los archivos VTF del pakfile y no solo los cubemaps.

Comprimir el BSP: bspzip -repack -compress

bspzip puede reempaquetar un BSP terminado y, de paso, comprimirlo con LZMA. El archivo sigue siendo un .bsp. Según la wiki de Valve, el motor de GMod carga estos mapas, y el changelog de GMod de marzo de 2025 menciona expresamente la descompresión LZMA para archivos BSP.

La pega está en la herramienta. El bspzip de GMod nombra la opción en su texto de ayuda, pero en nuestra prueba (build del 3 de septiembre de 2026, 32 y 64 bits) terminó con -repack -compress devolviendo el código de salida 1, sin ninguna salida, y dejó el archivo sin cambios. -repack por sí solo funcionó. Por eso, para GMod la wiki de Valve remite al bspzip de Team Fortress 2. Con él comprimimos copias de los dos mapas originales:

No hemos comprobado en el juego si GMod carga exactamente estos archivos sin errores. Así que prueba tú mismo un mapa comprimido en cliente y servidor. La wiki de Valve menciona además tres restricciones, que determinan el orden:

1. Empaqueta primero todo el contenido. bspzip no empaqueta nada en un BSP comprimido, así que tendrías que descomprimirlo otra vez con -repack sin -compress.
2. Después genera los cubemaps para LDR y HDR. En un mapa comprimido, buildcubemaps crashea.
3. Comprime al final y comprueba los sonidos. Para sonidos empaquetados en formato ADPCM, la wiki documenta errores de reproducción, probados allí en Team Fortress 2 y Counter-Strike: Source.

Por qué el tamaño importa para los servidores

Cada jugador necesita el BSP en local antes de entrar. Con FastDL, el cliente pide primero una versión .bz2, y con el Workshop el addon se comprime al subirlo. Por tanto, el tamaño en disco no es el tamaño de la descarga. Cada una de las vías se explica en FastDL o Workshop.

La tabla de arriba muestra lo que se deduce de ello: el BSP comprimido con LZMA es solo entre un 9 y un 19 % más pequeño que el .bz2 del original, y envolver además un BSP comprimido como .bz2 cambió el tamaño menos de un 1 % en nuestra prueba. Uno de los dos archivos incluso creció ligeramente. Así que la compresión ahorra sobre todo espacio en disco en el servidor y en el equipo del jugador, además de tiempo de descarga allí donde no hay ningún .bz2 disponible. En cambio, lo que ahorras en lightmaps, cubemaps y texturas compensa por cualquier vía y además reduce lo que el juego tiene que cargar en memoria.

Preguntas frecuentes

¿Por qué mi mapa es de repente mucho más grande después de buildcubemaps?

Los cubemaps se escriben en el pakfile como texturas, en dos versiones si el mapa es HDR. Los valores altos de «Cubemap Size» y muchas entities env_cubemap suman enseguida decenas de megabytes. Comprueba los tamaños con bspzip -extract.

¿Un BSP más pequeño hace que el mapa vaya más rápido en el juego?

No directamente. La tasa de fotogramas depende sobre todo de cuánto dibuja el motor por fotograma. Eso sí, unos lightmaps más toscos y unas texturas más pequeñas ahorran memoria y tiempo de carga. Qué determina la tasa de fotogramas se explica en optimizar el rendimiento de un mapa de GMod.

¿Hay un tamaño máximo de archivo para un BSP?

No podemos confirmar un límite superior fijo para el archivo completo en GMod. Lo que sí está limitado son áreas de datos concretas, consulta los límites de los mapas de Source, y la descarga directa desde el servidor de juego. En la práctica, el límite lo pone el tiempo de espera de los jugadores.

¿Puedo modificar más adelante un BSP comprimido?

Sí, pero no directamente. Descomprímelo con bspzip -repack sin -compress, haz el cambio y vuelve a comprimir. De todos modos, una nueva compilación genera un BSP nuevo y sin comprimir.