Buscar en la comunidad

El Proceso de Compilación (ZHLT) Bueno, este es el articulo que busqué yo hace bastante tiempo, no lo había en ningun sitio asi que tube que hacerlo yo mismo y hubiera dado lo que sea en su momento por tenerlo . Todo buen mapper ha de saber que ocurre cuando su .rmf, exportado ya a .map, es compilado; que hace que de tener un .map, todo lleno de coordenadas de los solido, entidades y demas pase a ser un un archivo llamado Binary Space Partition (Espacio de Particion Binario) o comunmente llamado .bsp. Espero que este articulo, satisfaga las ansias que yo tube en su momento por saber que ocurria exactamente cuando ordenaba al ZHLT la compilacion de mi .map. El tema va a estar dividido en 5 partes en las que se tratarán las 5 principales aplicaciones del la suite de compilación para el Half-Life, Zoner´s Half-Life Tools; que es constituido por: -HLCSG.EXE -HLBSP.EXE -HLVIS.EXE -HLRAD:EXE -RIPENT.EXE Quizas mucha gente no haya oido hablar del ultimo o solo lo haya visto en su carpeta del ZHLT pero no haya hecho nada mas, pero les aseguro que es una herramienta bastante útil. Sin mas preámbulos comienza este humilde articulo para los que gozen de las cosas mas "extrañas", por decirlo asi, de este gran mundo que es el Mapping. HLCSG hlcsg.exe; la primera de las herramientas del ZHLT que usamos para compilar nuestro .map. ¿Qué significa HLCSG? Pues significa Half-Life Constructive Solid Geometry ( Construcción de la Geometría Solida) Que es un .map? LA gente curiosa ya habrá descubierto que son un "simple" archivo de texto; por qué digo simple? Esto es un cubo en un .map { "classname" "worldspawn" "MaxRange" "4096" "mapversion" "220" "wad" "\archivos de programa\valve\valve\halflife.wad" { ( -64 -128 -64 ) ( -64 0 -64 ) ( 64 0 -64 ) AAATRIGGER [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1 ( -64 0 -192 ) ( -64 -128 -192 ) ( 64 -128 -192 ) AAATRIGGER [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1 ( -64 -128 -192 ) ( -64 0 -192 ) ( -64 0 -64 ) AAATRIGGER [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1 ( 64 0 -192 ) ( 64 -128 -192 ) ( 64 -128 -64 ) AAATRIGGER [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1 ( -64 0 -192 ) ( 64 0 -192 ) ( 64 0 -64 ) AAATRIGGER [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1 ( 64 -128 -192 ) ( -64 -128 -192 ) ( -64 -128 -64 ) AAATRIGGER [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1 } } { "classname" "info_player_start" "angles" "0 0 0" "origin" "0 -256 -128" } { "classname" "info_target" "targetname" "soy_un_info_target" "origin" "-256 -256 -128" } { "classname" "trigger_push" "angles" "0 0 0" "speed" "100" { ( -320 -128 -64 ) ( -320 0 -64 ) ( -192 0 -64 ) AAATRIGGER [ 1 0 0 16 ] [ 0 -1 0 16 ] 0 1 1 ( -320 0 -192 ) ( -320 -128 -192 ) ( -192 -128 -192 ) AAATRIGGER [ 1 0 0 16 ] [ 0 -1 0 16 ] 0 1 1 ( -320 -128 -192 ) ( -320 0 -192 ) ( -320 0 -64 ) AAATRIGGER [ 0 1 0 -16 ] [ 0 0 -1 -16 ] 0 1 1 ( -192 0 -192 ) ( -192 -128 -192 ) ( -192 -128 -64 ) AAATRIGGER [ 0 1 0 -16 ] [ 0 0 -1 -16 ] 0 1 1 ( -320 0 -192 ) ( -192 0 -192 ) ( -192 0 -64 ) AAATRIGGER [ 1 0 0 16 ] [ 0 0 -1 -16 ] 0 1 1 ( -192 -128 -192 ) ( -320 -128 -192 ) ( -320 -128 -64 ) AAATRIGGER [ 1 0 0 16 ] [ 0 0 -1 -16 ] 0 1 1 } } Analicemos esto, cada solido o entidad va entre { }, al principio de cada map simpre estará la entidad worldspawn, la entidad primaria sobre la que se basa el map y que le da parametros como el MaxRange, version del map, texturas que utiliza,etc. Aunque el mapa esté vacio, siempre habra una entidad worldspawn, que como se deduce por su nombre es la que "spawnea" el map, es decir, lo crea, y a partir de esta entidad se colocan todos los solidos y entidades. A continuación se crean los solidos, siguiendo este patron { ( -64 0 -64 ) ( 64 0 -64 ) ( 64 -128 -64 ) AAATRIGGER [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1 ( -64 -128 -192 ) ( 64 -128 -192 ) ( 64 0 -192 ) AAATRIGGER [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1 ( -64 0 -64 ) ( -64 -128 -64 ) ( -64 -128 -192 ) AAATRIGGER [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1 ( 64 0 -192 ) ( 64 -128 -192 ) ( 64 -128 -64 ) AAATRIGGER [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1 ( 64 0 -64 ) ( -64 0 -64 ) ( -64 0 -192 ) AAATRIGGER [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1 ( 64 -128 -192 ) ( -64 -128 -192 ) ( -64 -128 -64 ) AAATRIGGER [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1 } Como podemos deducir, es un cubo, cada linea corresponde a una cara del solido, por lo tanto al tener 6 lineas es un cubo Al comienzo de cada linea estan colocadas las coordenadas del solido, seguidamente la textura usada (aaatrigger en mi caso) Todos los numeros que siguen son las propiedades de la textura, posicion, tamaño, etc, pueden en el VHE seleccionar un sólido, darle a Shift + A y ven arriba las inbox donde meter los parametros que corresponden a los numeros anteriormente mencionados Seguidamente las entidades creadas con el Enitity Tool { "classname" "info_player_start" "angles" "0 0 0" "origin" "0 -256 -128" } { "classname" "info_target" "targetname" "soy_un_info_target" "origin" "-256 -256 -128" } Primero el nombre de la entidad, info_player_start y mas abajo un info_target, seguidamente sus propiedades, el PITCH YAW ROLL del info_player_start y el name del info_target; como ultimo el origin de la entidad, que viene siendo las coordenadas donde están ubicadas las entidades. Y por ultimo los solidos con una entidad { "classname" "trigger_push" "angles" "0 0 0" "speed" "100" { ( -320 -128 -64 ) ( -320 0 -64 ) ( -192 0 -64 ) AAATRIGGER [ 1 0 0 16 ] [ 0 -1 0 16 ] 0 1 1 ( -320 0 -192 ) ( -320 -128 -192 ) ( -192 -128 -192 ) AAATRIGGER [ 1 0 0 16 ] [ 0 -1 0 16 ] 0 1 1 ( -320 -128 -192 ) ( -320 0 -192 ) ( -320 0 -64 ) AAATRIGGER [ 0 1 0 -16 ] [ 0 0 -1 -16 ] 0 1 1 ( -192 0 -192 ) ( -192 -128 -192 ) ( -192 -128 -64 ) AAATRIGGER [ 0 1 0 -16 ] [ 0 0 -1 -16 ] 0 1 1 ( -320 0 -192 ) ( -192 0 -192 ) ( -192 0 -64 ) AAATRIGGER [ 1 0 0 16 ] [ 0 0 -1 -16 ] 0 1 1 ( -192 -128 -192 ) ( -320 -128 -192 ) ( -320 -128 -64 ) AAATRIGGER [ 1 0 0 16 ] [ 0 0 -1 -16 ] 0 1 1 } } Se agregan al final del .map, colocando primero la entidad, trigger_push en mi caso, y sus parametros y a continuación el solido y sus propiedades. Qué es lo que hace entonces el HLCSG.EXE? El HLCSG.EXEhace los cálculos de geometría del espacio constructivos al mapa, "rompe" los solidos complejos en otros mas simples y crea 5 archivos para el posterior uso del HLBSP.EXE Nota: Esto no pretende ser un articulo para explicar que ocurre cuando hay un error en el map, para ello habra otro artículo Lo primero que hace el HLCSG es cargar su configuración (comandos, log ativo, developer, etc) Seguidamente chequea el si se ha añadido alguna wad con el -wadinclude, lo que se dice "añadir la textura al mapa". Un ejemplo: Using mapfile wad configuration Wadinclude list : [zhlt.wad] Como se puede ver, el HLCSG incluye automaticamente la .wad zhlt.wad que contiene las texturas: -HINT -SKIP -NULL -BEVEL -CLIP -AAATRIGGER -SKY -ORIGIN Las llamadas "texturas especiales" por sus funciones "especiales" que sirven desde para crear un cielo hasta setear el eje de rotacion de un solido Seguidamente, el HLCSG comienza a "pasar" las lineas de texto el .map a objetos solidos, cabe aclarar que en este momento no existe el .bsp, dado que este archivo es generado por el HLBSP.EXE, por lo tanto lo que hace el HLCSG es escribir estos solidos en los archivos con extension *.p0, *.p1, *.p2 y *.p3 para el posterior uso del HLBSP.EXE ( " * " indica el nombre del mapa) Nota: No he comprobado si usando un .map de gran tamaño se crean mas archivos .p* donde * puede ser cualquier numero. Ademas de estos 4 archivos, se crea un 5 archivo con el formato *.wic en el que se muestran las texturas incluidas en el mapa Esta archivo con formato .wic se crea en la parte final del HLCSG , en le denominado Texture Usage (Uso de Texturas) que ademas muestra las wads añadidas en el .map, el numero de texturas usadas de un .wad, el porcentaje del mapa usando esa .wad y la cantidad de texturas qu etiene la .wad; aqui un ejemplo: Using Wadfile: \archivos de programa\valve\valve\liquids.wad - Contains 0 used textures, 0.00 percent of map (32 textures in wad) Using Wadfile: \archivos de programa\valve\valve\decals.wad - Contains 0 used textures, 0.00 percent of map (222 textures in wad) Using Wadfile: \archivos de programa\valve\valve\halflife.wad - Contains 3 used textures, 75.00 percent of map (3116 textures in wad) Using Wadfile: \archivos de programa\valve\cstrike\de_piranesi.wad - Contains 0 used textures, 0.00 percent of map (160 textures in wad) Using Wadfile: \archivos de programa\valve\cstrike\cs_747.wad - Contains 0 used textures, 0.00 percent of map (143 textures in wad) Using Wadfile: \archivos de programa\valve\cstrike\cs_assault.wad - Contains 1 used texture, 25.00 percent of map (22 textures in wad) Texture usage is at 0.06 mb (of 4.00 mb MAX) 0.08 seconds elapsed Como pueden ver, estoy usando 7 wads (las que estan añadidas en el VHE, lo que hace el .map es tomar esas texturas y si se fijan hay algo que suele tener mucha gente pero que no se fijan en ello, hay 4 .wad que no estoy usando: - liquids.wad -decals.wad -de_piranesi.wad -cs_747.wad Es recomendable quitarlas, en el VHE o a mano en el .map (aunque no lo hagas si no sabes lo que haces), para reducir el peso del mapa y demas errores que se puedan producir, por ejemplo colocando mas de 8 wads en el .map Al final de todo nos dice el uso en .mb de texturas y si colocamos mas de 4.Mb (el maximo) se producira un error impidiendonos compilar. Por ultimo, añade la parte del HLCSG a archivo *.log, que es el log de la compilación Con esto último se acaba el HLCSG.EXE y pasamos al HLBSP.EXE HLBSP hlbsp.exe, la pregunta del millón que hacen todos los recien llegados al Mapping: "¿Como paso mi mapa a .bsp?" La respuesta, compilando el .map con las herramientas del ZHLT, todas y cada una de las herramientas precisa de las otras para su funcionamiento, aunque alguien me dirá: "¿Como es eso si puedo compilar perfectamente usando solo el HLCSG o usando todas menos el HLVIS?" Muy sencillo, puede compilar solo con el HLCSG porque puede compilar un map por partes, imagina que no tienes muhco tiempo, compilas primero usando solo el HLCSG y el HLBSP y cuando puedas, haces el HLVIS y el HLRAD ¿Por que puedo compilar sin el HLVIS? Porque el HLVIS podríamos decir que es "prescindible", porque si, puede compilar el mapa sin el .HLVIS y podrás cargarlo en tu CS, pero haz la prueba y mira que pasa; mala iluminacion, no hay sombras, bajos FPS (Frames Per Second o en español Imagenes Por Segundo) ¿Que significa HLBSP? Significa Binary Space Partition ( Espacio de Partición Binario) Comenzemos pues el HLBSP, aqui dejo una compilacion exitosa del HLBSP SolidBSP [hull 0] 25 (0.00 seconds) BSP generation successful, writing portal file 'C:\zhlt\zhlt253\maps\articulo_zhlt\armasastaAWP.prt' SolidBSP [hull 1] 25 (0.00 seconds) SolidBSP [hull 2] 25 (0.02 seconds) SolidBSP [hull 3] 25 (0.00 seconds) 0.06 seconds elapsed El HLBSP toma los archivos *.p0, *.p1, *.p2 y *.p3 y los escribe en el *.bsp, hace que el GoldSource (el Engine del Half-Life) "entienda" las coordenadas y demas datos de los *.p0, *.p1, *.p2 y *.p3 y pueda renderizarlos, hacerlos solidos, agregar las funciones de las entidades, etc. Genera ademas 3 archivos: - *.lin -*.pts -*.ptr Son los llamados portal files que crean los leafs, los leafs definen un "sector" de superficies visibles en del mapa Generalmente los archivos están vacios menos el .ptr que es donde estan lo archivos de los portales Los archivos *lin y *.pts se llenan cuando hay un LEAK . Nota: Un LEAK es un agujero en el mapa, cuando haces un mapa y no queda cerrado totalmente o hay alguna entidad fuera del mapa, en el "negro" del VHE cuando el HLBSP esta construyendo los solido detecta esta parte no cerrada o la entidad fuera del mapa y se produce este error que provoca una sobreiluminación, no haber sombras en el mapa y bajar completamente los FPS (hay mas causas para el LEAK como por ejemplo un solido de gran complejidad que requiera de la textura ORIGIN). Se acabó el HLBSP.EXE por lo tanto toca ver el HLVIS.EXE HLVIS HLVIS.EXE quiere decir VISIBLE INFORMATION SET (Establecedor de la Información Visible) y su trabajo es el de generar la matriz de visibilidad (especifica que polígonos que el jugador no puede o no podría ser capaz de ver) para el mapa y ayuda a acelerar su interpretación. Es el que se encarga de calcular las sombras y demás efectos luminosos Aquí muestro el proceso del HLVIS completo: BasePortalVis: (0.11 seconds) LeafThread: (2.75 seconds) average leafs visible: 63 g_visdatasize:2035 compressed from 2261 2.92 seconds elapsed El HLVIS también usa el archivo.ptr para leer los portales, los descomprime y al acabar los vuelve a comprimir, por eso dice g_visdatasize (la variable del tamaño del VIS) :2035 compressed from 2261 Lo siento mucho pero esta es la utilidad de la que menos información dispongo, en cuanto tenga más información la pondré, si alguien sabe más y quiere añadirlo que responda a este Tema o por MSN: S34Qu4K3.CS@hotmail.com Nota: Esto último no es del todo exacto, se que es lo que ocurre en cada momento en el HLVIS, lo que no se es como expresarlo para su entendimiento, lo que seria dar una buena definición de ello) Goto HLRAD:EXE HLRAD La penúltima herramienta del ZHLT y mi favorita: el RADiosity (radiosidad en españo), se encarga de generar y aplicar todos los efectos de luz para el mapa, como las entidades light y el cielo y haceque el mapa se vea bien. Este es por lo general es la herramienta más lenta del ZHLT debido a la gran cantidad de información que debe volcar en el .bsp Seguidamente muestro una compilación completa del HLRAD: [Reading texlights from 'C:\zhlt\zhlt253\lights.rad'] [59 texlights parsed from 'C:\zhlt\zhlt253\lights.rad'] 88 faces Create Patches : 1312 base patches 0 opaque faces 25258 square feet [3637248.00 square inches] 1 direct lights BuildFacelights: (0.19 seconds) BuildVisLeafs: (0.69 seconds) visibility matrix : 0.3 megs MakeScales: (0.95 seconds) SwapTransfers: (0.17 seconds) Transfer Lists : 1378816 : 1.38M transfers Indices : 8576 : 8.38k bytes Data : 5515264 : 5.26M bytes GatherLight: (0.25 seconds) FinalLightFace: (0.41 seconds) 2.83 seconds elapsed Paso a explicar que es cada cosa: [Reading texlights from 'C:\zhlt\zhlt253\lights.rad'] [59 texlights parsed from 'C:\zhlt\zhlt253\lights.rad'] En la carpeta del HLRAD tenemos un archivo llamado lights.rad, en el se encuentra el RGB de ciertas texturas que estén agregadas y el brillo, modificando el brillo podemos hacer que la textura se más o menos luminosa, llegando a la posibilidad de poder verla sin que haya ninguna luz en la habitación (cosa absurda por cierto); el HLRAD lee este archivo y carga la configuración de cada textura que tenga en el lights.rad, en mi caso hay 59 XX Faces: Cantidad de caras de los sólidos de todo el mapa Create Patches : 1312 base patches Crea los "parches" del mapa Nota: No info sorry , si alguien quiere añadir... 0 opaque faces : Nada que decir, son las caras opacas sin luz alguna 25258 square feet [3637248.00 square inches] Nota: No info sorry , si alguien quiere añadir... 1 direct lights Entidades light, light_enviroment y light_spot del mapa, en mi caso solo una light BuildFacelights: (0.19 seconds) Construye la luz que irradia sobre las caras de los solidos BuildVisLeafs: (0.69 seconds) Construye los Leafs del HLVIS, obviamente si no compilamos con HLVIS no va a hacer esto. visibility matrix : 0.3 megs Determina que pathces pueden ver a los otros, no tengo más info(necesario HLVIS) MakeScales: (0.95 seconds) Uno de los procesos que más memoria requiere, creo que crea la escala de las luces del mapa(necesario HLVIS) SwapTransfers: (0.17 seconds) Transfer Lists : 1378816 : 1.38M transfers -----> Lista de Transferencias Indices : 8576 : 8.38k bytes ----->Indices Data : 5515264 : 5.26M bytes ----->Data(información) Mi proceso favorito, Swap Transfers, el primero que vi y me "enamoré" de el ^^; cambia las transferencias de las luces enviadas a fuera a las luces colectadas dentro. En un mundo ideal, estas luces serían simétricas pero por culpa de los factores son unicamente aproximadas, despues son normalizadas y finalmente serán un poco diferentes GatherLight: (0.25 seconds) Toma las luces le da variable g_patches FinalLightFace: (0.41 seconds) Añade la iluminación indirecta encima de la luz directa y lo guarda en el archivo final del mapa Y con esto acaba mi amado y a la vez odiado HLRAD.EXE y nos vamos a la última parte de este articulo RIPENT Probablemente la mayoría de la gente no lo conozca, poca que lo conozca pero que no lo use y muy poca gente que lo use. Pero, ¿qué es el Ripent? Gran definición por un gran amigo: El Ripent comprueba los limites de todo lo que puede ser colocado en un mapa models, caras, solidos, entidades, luces y demás Seguidamente dejo como es el ripent Object names Objects/Maxobjs Memory / Maxmem Fullness ------------ --------------- --------------- -------- models 1/400 64/25600 ( 0.3) planes 20/32767 400/655340 ( 0.1) vertexes 90/65535 1080/786420 ( 0.1) nodes 6/32767 144/786408 ( 0.0) texinfos 3/32767 120/1310680 ( 0.0) faces 88/65535 1760/1310700 ( 0.1) clipnodes 18/32767 144/262136 ( 0.1) leaves 2/8192 56/229376 ( 0.0) marksurfaces 88/65535 176/131070 ( 0.1) surfedges 352/512000 1408/2048000 ( 0.1) edges 177/256000 708/1024000 ( 0.1) texdata [variable] 48/4194304 ( 0.0) lightdata [variable] 49608/4194304 ( 1.2) visdata [variable] 3/2097152 ( 0.0) entdata [variable] 2343/524288 ( 0.4) 1 textures referenced === Total BSP file data space used: 58062 bytes === Como pueden ver, al usar un mapa casi vacio los niveles son muy bajos, esta herramienta es de gran utilidad y sirve desde para detectar errores, saber si vamos a poder compilar el map y hasta hacernos una idea de como será el peso de nuestro mapa No diré nada más de ella porque es autoexplicativa, si hay alguan duda ya saben Y S34cabó Ripent Notas/Comentarios/Conclusiones /Agradecimientos Esta es un artículo que le había pedido a Emi hace bastante tiempo (1 año al menos) si podía hacerlo, me dijo que lo intentaría pero que le llevaría bastante tiempo pero al final, por olvido, falta de tiempo, ganas o lo que fuera no salió adelante. Ahora, con mi añito y 3 meses de experiencia puedo hacer un humilde articulo que aunque no sea del mismo tema en concreto, puede que tenga la mitad de calidad de los articulos de Emi: -Mapa vs. Mapper -Como progresar en el Mapping Espero que les guste y lo más importante, que aprendan; yo tengo la creencia de que absolutamente nadie puede llegar a ser un buen mapper si conocer el proceso de compilación a fondo y espero que este articulo les ayude, me parece algo extraordinario el saber que está ocurriendo cada vez que hago click en compile en mi Batch Compiler, que es lo que hace el VHE cuando le doy a exportar a .map, etc Nota: Por si a alguien se le da por preguntar si, se puede hacer un mapa a mano con el bloc de notas, pero es muy difícil además de ser una pérdida de tiempo Agradecimientos: -A mi mentor, tutor, amigo, compañero, maestro, definidor del Ripent, el quien aguanta todas mis preguntas y soporta mi pesadez , quien va a ser, Emi claro está -A cierta frutira, que tiene forma de P'erita por hacer la página nº 1 en toda Sudamérica y gracias a él, hoy pueden leer este articulo. Gracias por Aguantar (L) -De este no hablo, solo digo que le doy la tabarra todo el día, más que a Emi, via MSN o Skype de igual, gracias por ayudar a MZ cuando lo necesitaba -NemeS!S....WTF? Este no se qu ehace aqui no pregunten, apoyo moral y un HLDS cuando lo necesito -Resto de usuarios, Incrusser, iLY, sonrisa, varchar(no este está repe ), DmC.Bleacj, valen, Swata, Oxi, ezeh, ezequieel, howard, CHris, Rewolf, SHun, aagguuu, Faqqu & Poola Cumbia Inc, PCCLone, Ciio, El Juanixxx y mogollón de gente de la que me olvido pero que pienso igual en ella Licencia Se autoriza la libre distribución de este articulo siempre y cuando haya mención al autor, yo (S34Qu4K3) y esta maravillosa comunidad que es Mapping-Zone (http://www.mapping-zone.NET) Aun asi, este articulo fue creado para Mapping-Zone usando como fuentes, mi pequeño cerebro, el codigo fuente del ZHLT y la experiencia de Emi Saludos