Uma malha gerada ainda exige decisões sobre escala, forma, movimento, carregamento e interação. Comece pelo motor previsto e pela câmera do jogo, preserve o resultado bruto da geração e depois faça as correções em um arquivo editável de criação de conteúdo digital (DCC). Versione a exportação para o runtime separadamente, para que seja possível rastrear o asset distribuído até sua fonte.
Use as etapas abaixo como verificações de aceitação para seu asset, motor e hardware de destino. Defina o briefing antes da limpeza e registre quais verificações foram aprovadas. Uma bela visualização giratória é bem-vinda; ela não revela se um personagem se deforma corretamente ou se uma sala cheia de objetos cabe no orçamento de desempenho.
1. Defina a fonte e os requisitos de execução
Crie um registro do asset com a referência aprovada, a receita de geração, os direitos sobre os dados de entrada e saída, as dimensões esperadas, a função nas interações e o responsável. Salve a malha e as texturas brutas antes da limpeza. Importe uma cópia de trabalho no Blender ou no DCC escolhido e inspecione-a de todos os lados, em wireframe e por canal do material. Examine a parte de trás e a parte inferior com o mesmo cuidado dedicado à prévia frontal do gerador.
Defina as unidades do projeto, a orientação, a origem e as convenções de nomenclatura. Coloque o pivô onde o objeto precisa girar ou se encaixar durante o jogo. Para personagens, combine a pose de repouso e o esqueleto antes do skinning. Mantenha o arquivo de criação junto da exportação que será distribuída, com as correções de escala e pivô registradas na fonte. O código de execução não deve se tornar o único lugar em que essas decisões ficam preservadas.
2. Decida qual geometria merece ser preservada
Analise a silhueta na distância da câmera do jogo. Corrija aberturas inventadas, componentes fundidos, cascas que se intersectam, fragmentos flutuantes e normais voltadas para a direção errada. Procure detalhes pintados que precisam afetar a forma e detalhes geométricos densos que poderiam ser substituídos por um mapa de normais gerado por baking. Mantenha separadas as partes que precisam se mover de forma independente.
Aplique a limpeza automática de forma seletiva. Alguns designs usam intencionalmente superfícies abertas, roupas sobrepostas ou planos poligonais finos; tornar tudo fechado e estanque pode danificá-los. Malhas de colisão e malhas visuais têm requisitos diferentes. Salve uma cópia antes do remeshing, que pode alterar UVs, shape keys e outras informações criadas na produção ao reconstruir a superfície.
3. Escolha entre simplificação e retopologia planejada
Um objeto estático de fundo pode tolerar uma simplificação cuidadosa se sua silhueta, seu sombreamento e suas UVs continuarem adequados. Um personagem que fala ou se deforma com frequência geralmente precisa de uma topologia planejada em torno das articulações e expressões. Crie loops ao redor dos ombros, cotovelos, joelhos, boca e pálpebras onde o briefing exigir e depois teste como eles se deformam. Analise com o mesmo cuidado o resultado de um serviço composto principalmente por quadriláteros.
Mantenha a fonte densa e corrigida para o baking. Aprove a malha menos detalhada separadamente, verificando o que a redução alterou. Tiras finas, alças e contornos curvos precisam de atenção especial. Registre a contagem de faces no DCC e a geometria exportada para o runtime: a exportação pode dividir vértices nos limites de materiais, UVs ou sombreamento.
4. Crie UVs que permitam as edições previstas
Inspecione o layout UV com uma textura quadriculada. Procure esticamentos, densidade de detalhes desigual, ilhas minúsculas e sobreposições acidentais. Posicione as costuras onde você possa corrigi-las e onde a câmera prevista exponha menos artefatos. Ilhas compartilhadas ou espelhadas podem servir para alguns assets; bakes únicos e marcações assimétricas podem precisar de seu próprio espaço de superfície.
Escolha as dimensões das texturas de acordo com as necessidades na tela e o orçamento total de memória da cena. Um rosto em close e uma caixa distante não devem receber automaticamente a mesma alocação. Deixe espaço ao redor das ilhas para a filtragem e os níveis mip inferiores. Se a topologia mudou, refaça o baking ou corrija as texturas com base nas UVs finais. O atlas antigo pode não servir mais.
5. Reconstrua e valide o conjunto de materiais PBR
Separe a cor base da iluminação. Brilhos pintados podem parecer errados sob iluminação dinâmica. Analise os canais de metalicidade, rugosidade e normais sob luz neutra e depois sob a iluminação do jogo. Verifique as convenções do shader para espaço de cor e mapas de normais, o empacotamento de canais e o modo de transparência. Faça essas verificações mesmo quando o gerador anuncia materiais PBR.
Quando for útil, transfira por baking os detalhes da fonte corrigida para a malha aprovada para o runtime. Inspecione costuras, gaiolas de baking, erros de projeção e a silhueta de baixo detalhe; um mapa de normais não consegue recuperar um contorno ausente. Reutilize materiais e atlas compatíveis quando isso beneficiar o conjunto. Conte os slots de material e as draw calls junto com os triângulos e preserve as fontes editáveis das texturas para futuras mudanças de direção de arte.
6. Crie um rig e inspecione o skinning
Para um personagem que se move, crie ou adapte o esqueleto combinado e analise a orientação dos ossos, a hierarquia e a nomenclatura. Faça a mesma inspeção em um rig automático. Ajuste os pesos ao redor dos ombros, quadris, dedos e interseções das roupas e depois teste poses que exagerem o movimento esperado. Verifique novamente o design aprovado do personagem após a deformação: as correções também podem mudar sua aparência.
Verifique os limites do motor para influências de ossos e complexidade do esqueleto. Crie as expressões ou formas corretivas necessárias em vez de presumir que elas vêm com um rosto gerado. Verifique elementos acoplados, como equipamentos e partes de cabelo separadas. Preserve no arquivo-fonte a pose de repouso, as informações de vinculação e os controles do rig necessários para futuros trabalhos de animação.
7. Valide o conjunto real de animações
Teste as animações de repouso, caminhada, giro, alcance com o braço, ato de sentar e as outras ações de jogo exigidas pelo briefing. Verifique o contato com o chão, o deslizamento dos pés, o posicionamento das mãos, as interpenetrações e as mudanças de escala. Decida se o movimento usa root motion ou uma transformação controlada pelo motor e depois teste as transições e os loops com essa mesma configuração.
Ao fazer retargeting, analise o movimento importado nas proporções finais do personagem. A correspondência dos nomes do esqueleto não garante deslocamentos nem contatos corretos. Mantenha uma pequena cena de revisão de animações que revele regressões e teste os clipes que serão distribuídos após a exportação. Compare os quadros nos limites dos loops para identificar saltos que uma prévia rápida pode esconder.
8. Crie LODs e proxies de colisão
Crie variantes de nível de detalhe (LOD) para o uso previsto do asset. Remova detalhes gradualmente, preserve a silhueta e verifique se as transições apresentam mudanças que distraem. Planeje a simplificação de materiais e texturas junto com a redução da geometria. Personagens e objetos repetidos podem precisar de estratégias diferentes; escolha distâncias ou limites de tamanho projetado com base no comportamento medido da cena.
Crie proxies de colisão simples para a interação prevista. Um armário pode usar caixas e algumas formas móveis; um personagem pode usar a forma do controlador de personagem do projeto em vez de cada triângulo visual. Mantenha nomes e posições consistentes para os proxies. Teste a abertura dos componentes, a navegação e a física no motor, especialmente onde a geração deixou superfícies internas inesperadas.
9. Exporte, valide e otimize o asset para o runtime
Para distribuição na web, GLB ou glTF 2.0 é um formato útil para o runtime quando o motor suporta os recursos de que você precisa. Exporte de forma deliberada os materiais, o esqueleto e as animações selecionadas. Confirme que os nós procedurais do DCC foram convertidos em dados de material compatíveis ou texturas geradas por baking. Execute Khronos glTF Validator, analise os erros e avisos e depois compare o resultado importado com a fonte.
Use glTF Transform ou ferramentas equivalentes para inspecionar a exportação, remover conteúdo não utilizado e eliminar duplicatas quando apropriado. Compare as opções de compressão de malhas considerando o suporte do carregador e o custo de decodificação. Use compressão de texturas como KTX2/Basis quando o runtime oferecer suporte. Preserve uma exportação não otimizada e compare novamente a aparência e a animação após a otimização. O tamanho do arquivo é apenas uma parte da aceitação.
10. Teste a cena completa nos dispositivos de destino
Carregue o asset que será distribuído em uma situação de jogo representativa, com a quantidade de instâncias, a iluminação, as sombras e as animações esperadas. Meça separadamente o volume de dados transferidos pela rede, o tempo de decodificação, a memória e o comportamento dos quadros. Teste distâncias de câmera e estados de interação que revelem a parte de trás, as transições de LOD e as suposições sobre colisão. Verifique uma build de lançamento e o comportamento no primeiro carregamento, além da prévia no DCC ou no editor.
Use dispositivos físicos de destino para a aceitação quando o desempenho em dispositivos móveis for importante. A emulação em um navegador de desktop pode revelar problemas de layout e funcionalidades, mas não reproduz o comportamento térmico nem os limites de GPU de um celular específico. Registre o dispositivo, o navegador/OS, a configuração da cena e as medições. Revise ou rejeite um asset cujo consumo de recursos na cena completa exceda o orçamento e depois repita as verificações afetadas pela correção.
11. Prepare o pacote do asset aceito e suas evidências
Entregue o arquivo-fonte, as texturas corrigidas, o registro de direitos, o arquivo otimizado para o runtime, as convenções de nomenclatura e pivô e as evidências da revisão. Informe quais animações, estados de colisão e dispositivos passaram nas verificações e quais ainda não foram testados. Armazene os resultados da aceitação junto com a versão do asset para que uma regeneração posterior não possa substituir silenciosamente uma malha aprovada.
Use as fontes preservadas para estimar o custo de futuras revisões. A limpeza manual pode levar mais tempo que a geração original, principalmente para personagens principais, então registre esse trabalho também. Aceite o asset quando seus requisitos visuais, de movimento, interação e desempenho tiverem sido atendidos em conjunto.
Decisões-chave
- Preserve separadamente o resultado bruto, a fonte editável e a exportação para o runtime.
- Trate retopologia, rigging e skinning como trabalhos de produção distintos.
- Verifique novamente os materiais, a silhueta e a animação após conversões destrutivas.
- Faça o profiling da cena completa nos dispositivos físicos de destino.
- Armazene os resultados da aceitação junto com a versão do asset entregue.
Comunidades externas dedicadas a modelos e sites externos de publicação podem conter material explícito. Os links para as fontes abrem em uma nova aba; este guia não carrega suas prévias.
Fontes e leituras adicionais +
- Fonte: manual de remeshing do Blender ↗
- Referência do exportador glTF do Blender 4.3 ↗
- Referência de baking de renderização do Blender ↗
- CLI do glTF Transform ↗
- Khronos glTF Validator ↗
- Especificação do formato glTF 2.0 ↗
- Visão geral da importação avançada no Godot ↗
Última verificação 5 de outubro de 2026.