Cuando compilamos un mapa con el VHE, usamos siempre las ZHLT (Zoner´s Half-Life Tools), ya sean versiones mas viejas o mas nuevas. Sea cual sea la version que descarguemos, siempre va a tener las cuatro herramientas principales : HLCSG, HLBSP, HLVIS, y HLRAD. Estas herramientas son las encargadas de construir e iluminar un mapa y todas se usan generalmente cada vez que compilamos un mapa (a menos claro que solo hagamos compilaciones parciales despues de una compilacion completa inicial).
HLCSG
Hace cálculos de geometría del espacio constructivos al mapa, con eficacia rompiendo brushes complejos en polígonos más simples, y hace 4 archivos de casco para HLBSP para usar.
HLBSP
Genera las ramas BSP para el mapa y crea un BSP jugable.
HLVIS
Genera la matriz de visibilidad (especifica cuales polígonos el jugador no puede o podría ser capaz de ver) para el mapa y ayuda a acelerar su interpretación.
HLRAD
Genera y aplica todos los efectos de luz para el mapa, como entidades ligeras y el cielo, y lo hace ver bien. Este es por lo general el más lento de los cuatro instrumentos para correr.
Posibles problemas de estas herramientas :
El HLRAD tarda mucho/se traba en makescales
El HLRAD requiere cantidades grandes de memoria para correr de manera eficiente para todos incluso para los mapas mas triviales.
El vismatrix HLRAD mientras corre, necesita tomar exponencialmente más RAM mientras el vismatrix crece. La fórmula es "el número de parches" al cuadrado, luego dividida por 16. Este número es cuantos bytes esto consumirá. El máximo es 65535 parches, entonces el máximo vismatrix es 256MB de RAM.
Además, la cantidad de memoria que emplea el vismatrix no es toda la memoria que el HLRAD tiene que correr. Dependiendo la visibilidad del mapa, el cache de "escalas' consume cantidades grandes de memoria también. Para la mayor parte de mapas, esta cantidad de memoria está cerca de 1/2 del tamaño del vismatrix. Esto generalmente se compara con un máximo de 128MB, o un total del sistema de 384MB para controlar el peor caso (65535 parches).
La fase de makescales tiene una tendencia de correr rápido inmediatamente hasta que se quede sin sin la memoria física y tenga que comenzar a confiar en el swapfile.Esto siempre es causado por estar quedándose sin memoria física, y el último 10 % requiere el empleo pesado del swapfile.Si se añade mas arquitectura al mapa, esto comenzará a tomar exponencialmente más tiempo para compilar, hasta que la RAM sea mejorada.
El HLVIS tarda mucho
Para la mayoria de los mapas bien diseñados, el VIS tendria que tardar como mucho, un tiempo de mas o menos 45 minutos en una sola computadora de clase P2-300. Si tarda mas, entonces el mapa problablemente necesite bloqueadores de VIS. Muchas cosas pueden hacer que el VIS tarde mas :
- Primero que nada, si el mapa esta dentro de una "caja" de textura SKY, el VIS tiene que trabajar en las paredes exteriores, es decir que tarda mas tiempo en paredes que normalmente no existen en un mapa sin "caja".
- En segundo lugar, la arquitectura que conecta "areas" puede ser un poco dificil de entender para el VIS. Es algo dificil de explicar, pero algunos ejemplos serian: pasillos que carecen de una pared que no este directamente en el plano XZ o YZ; pasillos que intersectan cuartos en otro plano que XZ o YZ; cuanrtos largos con paredes que no son verticales; pasillos que conectan dos areas pero las areas pueden verse unas a otras a traves del pasillo; muchos brushes chiquititos en una area (especialmente en areas grandes), que no son una entidad.
- Tercero, la velocidad del VIS se alentece cuando el mapa tiene areas exteriores grandes que no son construidas con sumo cuidad para no ver mucho de la parte "interior"
- Y finalmente, usando una version vieja de gensurf que no tengan brushes HINT.
Es muy aconsejable experimentar mucho con mapas de prueba con arquitectura de ejemplo, usando el modo de video SOFTWARE, r_drawflat 1, y r_draworder 1, para ver como trabaja el VIS.
-----------------------------------------------------
Espero que les sirva de algo. Me parecio util asi que pense que capaz le interesaba a alguien aprender que hace cada herramienta. Si consigo mas info del tema la resumo y agrego.
Si alguien ve que algo esta mal o encuentra una forma mejor/mas facil de explicar lo que dice alguna parte.
Fuente :zhlt.info
Guia sacada de zhlt.info y traducida por Santi para Mapping-Zone, como Santi está ocupado con la escuela aquí estoy yo para subirla...
HLCSG
Hace cálculos de geometría del espacio constructivos al mapa, con eficacia rompiendo brushes complejos en polígonos más simples, y hace 4 archivos de casco para HLBSP para usar.
HLBSP
Genera las ramas BSP para el mapa y crea un BSP jugable.
HLVIS
Genera la matriz de visibilidad (especifica cuales polígonos el jugador no puede o podría ser capaz de ver) para el mapa y ayuda a acelerar su interpretación.
HLRAD
Genera y aplica todos los efectos de luz para el mapa, como entidades ligeras y el cielo, y lo hace ver bien. Este es por lo general el más lento de los cuatro instrumentos para correr.
Posibles problemas de estas herramientas :
El HLRAD tarda mucho/se traba en makescales
El HLRAD requiere cantidades grandes de memoria para correr de manera eficiente para todos incluso para los mapas mas triviales.
El vismatrix HLRAD mientras corre, necesita tomar exponencialmente más RAM mientras el vismatrix crece. La fórmula es "el número de parches" al cuadrado, luego dividida por 16. Este número es cuantos bytes esto consumirá. El máximo es 65535 parches, entonces el máximo vismatrix es 256MB de RAM.
Además, la cantidad de memoria que emplea el vismatrix no es toda la memoria que el HLRAD tiene que correr. Dependiendo la visibilidad del mapa, el cache de "escalas' consume cantidades grandes de memoria también. Para la mayor parte de mapas, esta cantidad de memoria está cerca de 1/2 del tamaño del vismatrix. Esto generalmente se compara con un máximo de 128MB, o un total del sistema de 384MB para controlar el peor caso (65535 parches).
La fase de makescales tiene una tendencia de correr rápido inmediatamente hasta que se quede sin sin la memoria física y tenga que comenzar a confiar en el swapfile.Esto siempre es causado por estar quedándose sin memoria física, y el último 10 % requiere el empleo pesado del swapfile.Si se añade mas arquitectura al mapa, esto comenzará a tomar exponencialmente más tiempo para compilar, hasta que la RAM sea mejorada.
El HLVIS tarda mucho
Para la mayoria de los mapas bien diseñados, el VIS tendria que tardar como mucho, un tiempo de mas o menos 45 minutos en una sola computadora de clase P2-300. Si tarda mas, entonces el mapa problablemente necesite bloqueadores de VIS. Muchas cosas pueden hacer que el VIS tarde mas :
- Primero que nada, si el mapa esta dentro de una "caja" de textura SKY, el VIS tiene que trabajar en las paredes exteriores, es decir que tarda mas tiempo en paredes que normalmente no existen en un mapa sin "caja".
- En segundo lugar, la arquitectura que conecta "areas" puede ser un poco dificil de entender para el VIS. Es algo dificil de explicar, pero algunos ejemplos serian: pasillos que carecen de una pared que no este directamente en el plano XZ o YZ; pasillos que intersectan cuartos en otro plano que XZ o YZ; cuanrtos largos con paredes que no son verticales; pasillos que conectan dos areas pero las areas pueden verse unas a otras a traves del pasillo; muchos brushes chiquititos en una area (especialmente en areas grandes), que no son una entidad.
- Tercero, la velocidad del VIS se alentece cuando el mapa tiene areas exteriores grandes que no son construidas con sumo cuidad para no ver mucho de la parte "interior"
- Y finalmente, usando una version vieja de gensurf que no tengan brushes HINT.
Es muy aconsejable experimentar mucho con mapas de prueba con arquitectura de ejemplo, usando el modo de video SOFTWARE, r_drawflat 1, y r_draworder 1, para ver como trabaja el VIS.
-----------------------------------------------------
Espero que les sirva de algo. Me parecio util asi que pense que capaz le interesaba a alguien aprender que hace cada herramienta. Si consigo mas info del tema la resumo y agrego.
Si alguien ve que algo esta mal o encuentra una forma mejor/mas facil de explicar lo que dice alguna parte.
Fuente :zhlt.info
Guia sacada de zhlt.info y traducida por Santi para Mapping-Zone, como Santi está ocupado con la escuela aquí estoy yo para subirla...