Mapeando no hammer.
Antes de iniciar qualquer trabalho no hammer você deve ter o conhecimento básico de como os mapas são compilados, parece um absurdo começar falando o final, mas fazer uma caixa com paredes luzes texturas e relativamente fácil, e você vai encontrar n! Tutoriais sobre isso ,e infelizmente quem fica só no básico acaba fazendo aqueles mapas orange que deveriam ter alto fps, mas são em sua maioria completamente equivocados.
Recentemente descompilei o mapa dod_orange_paradise e fiquei apavorado, com a falta de técnica do mapper, ignorando técnicas básicas de otimização, mostrando que a única preocupação era meramente estética acreditando que texturas “dev_” aumentarão o FPS. deve ter demorado uma fabula para compilar do jeito que estava.
Em primeiro lugar existem os brush as brush entity e as point entity. Os brushes
são os blocos e as entidades são espíritos são os objetos, que podem ser feitos a partir de blocos (brush entity) e as entidades verdadeiras, são as point entity.
A primeira etapa da compilação é basicamente geométrica transformando todos os objetos em coordenadas e aplicando as texturas nos planos, verificando se não existem superfícies coplanares e se o todo mapa é uma ambiente matematicamente fechado, se não aparece a mensagem leak ( vazamento) e a compilação para no primeiro processo, deixando o mapa pesado com a iluminação “chapada” e no local do vazamento o clássico Hall of mirrors em que as imagens se refletem infinitamente.
O seguinte passo se chama Vis, é a etapa que divide o mapa em áreas de visibilidade, ou seja aonde o a engine vai criar áreas que serão renderizadas pelos clientes e as que são as adjacentes a sua areá visível evitando que o cliente enxergue o mapa todo de uma vez, o velho problema dos mapas abertos..em que praticamente tudo e visível (para a maquina, ou se você estiver usando algum cheater) para isso o vis divide o mapa em diversas aéreas baseados unicamente nos brushes (blocos) ou algumas outras brush entity feitas para isso, dividindo o mapa em áreas menores cortando o mapa paralelamente a cada lado de todo bloco “brush”, por exemplo se nesta grande caixa você colocar um cubo bem no meio ( sem encostar nas paredes) vai dividir em o mapa em 27 áreas !.
A medida que você vai adicionado blocos ao seu mapa mais o vis vai dividir o mapa, aumentado consideravelmente o tempo de compilação e o “peso” do mapa.
O ultimo passo se chama rad, ou radiosity calculator, este processo da compilação é a grade responsável pela beleza do mapa, colocando as luzes e as sombras em cada área criada pelo vis, ou seja ele vai colocar os efeitos de luz e sombra em cada parede para dar a sensação de luz.
Um dos maiores erros é fazer uma grande caixa com a textura sky (menos no fundo) mas ainda é o começo mais fácil quando se esta criando, não impedindo que as as areas que não irao ser usadas sejam eliminadas e ate transformadas em 3d sky futuramente.
Fiquemos com a caixa para facilitar, comece inicialmente com a textura nodraw sempre, após use a ferramenta apply texture para pintar os blocos somente na superfície que é visível para o jogador, (explicarei as ferramentas de textura em outra ocasião).
A textura nodraw , como o nome já diz avisa a engine para não desenhar o bloco com esta textura como se fosse uma pintura invisível de desenho animado! Economizando recursos do pc do cliente, mas elas devem ser mantidas longe dos olhos dos jogadores senão vão aparecer com bugs e com certeza usados por para trapacear, você já deve ter visto “bugs” assim como no mapa dod_anzio na escada próxima aponte em que foi esquecido de texturar um bloco.
Para diminuir o tempo de compilaçao do viz e em conseqüência do rad, deve se imaginar que quanto menos ele for dividido aonde não interessa melhor, para isso existe uma ferramenta essencial chamada “Tie to entity” (Ctrl T) que transforma blocos em entidade ou brushes entity, os detalhes que não devem atrapalhar o vis, no caso a entidade mais “leve” é a Func_detail.
Cantos curvos detalhes complexos cortes em ângulo tudo o que efetivamente não cria áreas uteis para a engine deve ser transformado em func_detail, de uma olhada no dod_flash que já vem como exemplo dentro do hammer, em auto deixe apenas os nodraw e word geometry e de uma conferida, as func_detail ao contrario dos tutoriais que já vi na net possuem caixa de colisao e não precisam de nenhum no_clip para se comportar como blocos.
Para facilitar deve-se começar o trabalho no hammer com uma grade (grid) no maior tamanho possível, porque torna mais fácil alinhar as paredes, verificar leaks e se for necessário fazer alguma alteração de posição de um objeto os encaixes serão mais fáceis, use as medidas padrão para portas e altura de teto (tutorial I), use o nodraw sempre.
Organize o seu mapa, no lado direito do hammer existe uma caixa chamada VisGroups, em auto voce vai encontrar uma arvore de entidade que vai permitir visualizar melhor algumas caraterísticas do mapa que você está hackeando trabalhando podendo eliminar elementos que só poluem as vistas ortogonais, alem disso é muito fácil criar novos grupos, e so selecionar todos os objetos que você quer que faça parte do grupo ir em propriedades alt+enter e na ultima aba criar um novo grupo, no exemplo criei um grupo só para os coqueiros, não esqueça de selecionar todos antes de compilar senão seu mapa vai ficar incompleto e cheio de erros..
Só para exemplificar No dod_orange_paradise usando essas regras consegui aumentar o fps em 50%! (mapa vazio) isso sem colocar as Func_area_portal, hint_brushes e outras.
Quando ele estiver totalmente melhorado vou disponibiliza-lo para comparações e quem sabe para a Orange Cup