Guia prático para quem precisa entender destruidor de mundos na hora do dia
Vocês sabem como é aquela situação em que você entra num projeto e descobre que o sistema de destruição de terrenos não funciona direito. Eu passei por isso semana passada, trabalhando numa simulação de terreno com o destruidor de mundos, e demorei quase três horas só pra descobrir que o problema era no mapeamento de coordenadas, não no código de colisão.
O que destruidor de mundos realmente faz
A ferramenta permite modificar malhas triangulares em tempo real, removendo vértices e reconstruindo topologia onde houver impacto. O processo básico envolve calcular a interseção entre um raio de impacto e a malha do terreno, remover os triângulos dentro de um raio especificado, e então regenerar as arestas expostas criando novos triângulos que fecham o buraco sem gerar artefatos visuais. O detalhe que a maioria dos tutoriais não menciona é que a regeneração da malha precisa respeitar a normal média dos vértices adjacentes. Se você simplesmente reconectar os pontos sem considerar isso, o resultado visual fica com iluminação quebrada, especialmente em áreas onde o terreno tem curvatura suave.
👉 Clique no botão abaixo para saber mais sobre o assunto!
No meu caso, o problema específico aconteceu quando estava trabalhando com uma malha de alta densidade, algo em torno de 50 mil vértices. A cada destruição parcial, o processo de regeneração levava cerca de 400 milissegundos por chamada, o que causava stutter visível no framerate. A solução foi implementar um sistema de chunking: dividir o terreno em blocos de 64x64 vértices e regenerar apenas o chunk afetado, mantendo os chunks vizinhos em cache. Isso reduziu o tempo de regeneração para algo em torno de 12 milissegundos por chunk, praticamente invisível durante a gameplay. Outro ponto que eu não tinha considerado era a questão da física. Quando você remove triângulos, o sistema de física continua usando a malha original como referência até que ela seja atualizada. Se o jogador cair num buraco enquanto a regeneração ainda está acontecendo, ele pode atravessar o terreno temporariamente. A workaround que eu encontrei foi manter uma cópia de leitura da malha atualizada separadamente, usada apenas pelo teste de colisão, enquanto a malha visual é regenerada de forma assíncrona.
Existem limitações importantes que você precisa saber antes de usar essa abordagem. Em malhas com topologia irregular ou com bordas muito complexas, o algoritmo de regeneração pode gerar triângulos degenerados com área próxima de zero. Isso causa problemas de renderização que aparecem como flash(esbranquiçados) na borda do buraco. A solução é implementar um filtro que descarta triângulos com área inferior a 0.001 unidades quadradas e tenta reconectar os vértices de outra forma. Demora um pouco mais, mas evita esses artefatos. Se você precisa de algo mais simples e não quer lidar com regeneração de malha, existe a alternativa de usar voxel-based destruction, onde o terreno é representado como uma grade tridimensional de blocos. Nesse caso, destruir é simplesmente remover blocos da grade, sem necessidade de regenerar topologia. O problema é que voxel-based destruction consome muita memória para terrenos grandes, e a qualidade visual das bordas costuma ficar ruim sem pós-processamento adicional.
Para quem está começando, eu recomendo empezar com uma malha pequena, algo em torno de 10 mil vértices, e implementar o sistema de forma incremental. Primeiro faça a detecção de colisão funcionar, depois a remoção de triângulos, e só então a regeneração. Tentar fazer tudo de uma vez geralmente resulta em bugs difíceis de rastrear.
