Cubemaps en GMod: arreglar los reflejos morados y negros
¿Reflejos morados y negros o incorrectos en tu mapa de GMod? Cómo colocar env_cubemap, generar cubemaps para LDR y HDR y conservarlos al empaquetar.
Los reflejos incorrectos o con cuadros morados y negros aparecen cuando los materiales reflectantes no encuentran cubemaps adecuados. O nunca se generaron, o se generaron solo para uno de los dos modos de iluminación, o se perdieron tras un cambio en el BSP. Coloca entities env_cubemap, carga el mapa en el juego y ejecuta buildcubemaps por separado para LDR y HDR. Después, recarga el mapa.
Qué son los cubemaps y por qué pueden faltar
Un cubemap consta de seis imágenes del entorno, capturadas desde un punto fijo. Los materiales con un componente reflectante lo usan como reflejo precalculado. No es un espejo en tiempo real. Al compilar, VBSP asigna a cada cara de brush reflectante un env_cubemap, por defecto el más cercano. Los modelos usan el que les queda más cerca.
Al compilar solo se crean marcadores de posición. Las imágenes de verdad las capturas después dentro del juego, y el motor las escribe en el pakfile del BSP. Hasta que eso ocurre, las caras reflejan el cielo como sustituto. En interiores eso se ve demasiado claro y a menudo azulado. Si tampoco se encuentra ese sustituto, en el reflejo aparece el patrón de cuadros morados y negros. Si los cubemaps solo existen para uno de los dos modos, en el otro los reflejos quedan, según la Valve Developer Community, demasiado brillantes o vacíos.
Esto no tiene nada que ver con materiales que faltan. La cara en sí está texturizada correctamente, solo el reflejo está roto. Para las superficies rosas y negras de verdad y los modelos ERROR, consulta el artículo sobre solucionar texturas que faltan y modelos ERROR.
Colocar bien los env_cubemap
- Uno por sala o ambiente de luz. Cada zona con iluminación o color de pared propios necesita al menos un
env_cubemap. En pasillos largos colocas varios, sobre todo en las transiciones. - A la altura de los ojos. El reflejo debe corresponder a lo que ve un jugador. Así que pon la entity más o menos a la altura de la cabeza sobre el suelo.
- Lejos de las paredes. Un
env_cubemapdentro de un brush o pegado a una pared captura una imagen inservible. - Asignar las caras a propósito. Con la propiedad «Brush faces» defines qué caras usan exactamente este cubemap. Eso ayuda con suelos reflectantes y cristal.
- No te pases. Cada cubemap aumenta el tamaño del BSP, y en los mapas con HDR se suman además las imágenes del segundo modo. Muchas entities en poco espacio no aportan ninguna mejora visible.
Cuánto refleja una cara lo determina su material. Los fundamentos de la luz y el HDR se tratan en el artículo sobre iluminación en Source Engine.
Generar los cubemaps: LDR y HDR por separado
Dos requisitos: el BSP procede de la compilación final y está en la carpeta garrysmod/maps como un archivo normal con permiso de escritura. Para un BSP sin permiso de escritura, el motor tiene su propio mensaje de consola (is not writable). Un mapa que solo existe dentro de un archivo de addon tampoco es un archivo normal de ese tipo.
Si el mapa está compilado con HDR, necesitas dos pasadas:
- Inicia el juego y carga el mapa.
- Escribe
mat_specular 0. Así los reflejos existentes y defectuosos no se cuelan en las imágenes nuevas. - Escribe
mat_hdr_level 0y recarga el mapa, por ejemplo conmap <mapname>. - Escribe
buildcubemapsy espera a que termine el proceso. La vista salta brevemente por todas las posiciones de captura. - Escribe
mat_hdr_level 2y vuelve a recargar el mapa. Para la pasada de HDR, la Valve Developer Community recomienda ademásbuilding_cubemaps 1, que mantiene la misma exposición en todas las imágenes. - Escribe
buildcubemapsotra vez. - Vuelve a poner
mat_specular 1, recarga el mapa y revisa los reflejos.
En un mapa sin HDR basta una sola pasada. En ese caso se omiten los pasos 5 y 6.
Trampas conocidas
| Síntoma | Causa | Solución |
|---|---|---|
| Todo se ve igual después de generarlos | No se recargó el mapa | Recarga el mapa o reinicia el juego |
| Los reflejos están bien en un modo y demasiado brillantes o vacíos en el otro | Los cubemaps se generaron solo para LDR o solo para HDR | Ejecuta la pasada que falta |
| Tras renombrar el BSP, los modelos, los props y las armas se quedan sin reflejos de cubemap | Para ellos, el motor busca los cubemaps en el pakfile, en una carpeta con el nombre del archivo BSP; las caras de brush conservan sus reflejos | Compila con el nombre definitivo y genéralos ahí |
| Las caras de interior reflejan el cielo | Los cubemaps nunca se generaron, o una compilación nueva los descartó | Vuelve a generarlos después de cada compilación final |
| El reflejo muestra colores de otra sala | La cara usa un env_cubemap de detrás de la pared | Coloca una entity propia en la sala o asigna las caras |
buildcubemaps se ejecuta pero no se guarda nada | El BSP es de solo lectura o no está como archivo suelto en garrysmod/maps | Quita la protección contra escritura y pon el BSP en garrysmod/maps |
| En los reflejos nuevos se ven el sustituto o reflejos antiguos | Los reflejos seguían activados al generarlos | Vuelve a generarlos con mat_specular 0 |
Qué vigilar después de empaquetar
Los cubemaps se guardan como archivos en el pakfile del BSP, en una carpeta dentro de materials/maps/ que lleva el nombre del mapa. De ahí salen tres reglas.
Cada compilación nueva los descarta. VBSP escribe el BSP desde cero. Por eso los cubemaps se generan siempre al final, y de nuevo después de cada compilación final.
El nombre tiene que ser definitivo. Decide el nombre de archivo definitivo antes de generar los cubemaps. Según la Valve Developer Community, renombrar el BSP después rompe los cubemaps en los modelos, los props y las armas, porque el motor los busca en una carpeta con el nombre del archivo BSP. Las caras de brush del mapa no se ven afectadas.
Revisa después de cada modificación del BSP. Genera los cubemaps solo después de la compilación final y comprime el BSP al final del todo, porque, según la Valve Developer Community, buildcubemaps hace que el juego se cierre con un BSP comprimido. Que empaquetes el contenido custom antes o después de los cubemaps importa menos que revisarlo después. Cualquier herramienta que reescriba el pakfile puede cambiar entradas. Así que carga el archivo terminado en el juego una vez más y revisa los reflejos en ambos modos.
El Map Scanner enumera los archivos Lua y de assets incrustados en el pakfile. Eso sí, si los reflejos están realmente bien solo se ve dentro del juego. Por eso, echar un vistazo a los reflejos forma parte de revisar un mapa antes de publicarlo.
Preguntas frecuentes
¿Por qué los reflejos de mi mapa son morados y negros?
Los materiales reflectantes no encuentran un cubemap adecuado. Una causa típica son unos cubemaps que una herramienta eliminó del pakfile, de modo que ni siquiera se encuentra el sustituto. Un BSP que se renombró después de generarlos es un caso distinto: según la Valve Developer Community, los modelos, los props y las armas pierden entonces sus reflejos de cubemap, mientras que las caras de brush conservan los suyos. Vuelve a generar los cubemaps con el nombre definitivo del mapa para LDR y HDR.
¿Tengo que volver a generar los cubemaps después de cada compilación?
Sí. Cada compilación produce un BSP nuevo sin cubemaps capturados. Mientras trabajas puedes saltártelo, pero antes de publicar es obligatorio.
¿Cuántas entities env_cubemap necesita un mapa?
Las suficientes para que cada sala y cada ambiente de luz claramente distinto tenga el suyo. No hay un número fijo. Más entities suponen un archivo más grande, así que compensa usarlas con moderación y con criterio.
¿Qué puedo hacer como jugador contra los reflejos morados y negros?
No puedes reparar los cubemaps de un mapa ajeno. mat_specular 0 desactiva los reflejos, con lo que también desaparece el patrón de cuadros. La solución limpia es una versión corregida del mapa.