Do 3D à pixel art: o guia completo

Desenhar um personagem à mão em oito direções, com ciclos de caminhada, corrida, ataque e morte, são muitos quadros. Para uma equipe pequena, pode ser o maior custo de arte de um jogo. Renderizar esses quadros a partir de um modelo 3D é uma resposta antiga para esse problema. Este guia mostra de onde veio a ideia, por que ela funciona, o que dá errado e como conseguir sprites que parecem pixel art em vez de uma renderização encolhida.

Uma breve história dos sprites pré-renderizados

Em 1994, a Rare lançou Donkey Kong Country no Super Nintendo. Seus personagens e cenários foram modelados e renderizados em estações de trabalho da Silicon Graphics, depois reduzidos aos sprites pequenos e às cores limitadas do console. Não se parecia com nada mais no sistema, e mostrou que um pipeline 3D podia alimentar um jogo 2D.

No fim dos anos noventa, sprites pré-renderizados se tornaram comuns no PC. Diablo (1996), Fallout e Fallout 2, StarCraft e Age of Empires usaram unidades e personagens renderizados a partir de 3D, muitas vezes em várias direções, porque um modelo pode ser girado de graça e um desenho não.

A técnica voltou de outra forma com Dead Cells (2018). A Motion Twin animou seus personagens em 3D e os renderizou como pequenos quadros em pixel art, e descreveu o processo no artigo de 2018 da Gamasutra (hoje Game Developer) “Art Design Deep Dive: Using a 3D pipeline for 2D animation in Dead Cells”. O objetivo era o mesmo de 1994: uma equipe pequena obter animação fluida e consistente sem desenhar cada quadro.

Leia mais em Sprites pré-renderizados.

Por que renderizar a partir de 3D

Três motivos aparecem de novo e de novo.

• Todas as direções. Quando um modelo já existe, um novo lado é só mais uma câmera. Quatro, oito ou dezesseis direções custam o mesmo esforço para configurar.
• Animação consistente. As proporções do personagem continuam iguais em cada quadro e em cada lado. Sprites desenhados à mão vão se desviando; um esqueleto não.
• Mudanças saem baratas. Mude a cor da armadura, o tamanho do sprite ou a paleta e renderize de novo. Com folhas desenhadas à mão, uma mudança tardia significa repintar centenas de quadros.

O preço é que uma renderização simples não parece pixel art. Encolha uma renderização com sombreamento suave e você terá bordas suaves, degradês turvos, centenas de cores quase idênticas e pixels que cintilam de um quadro para outro. O resto deste guia trata de fechar essa distância.

O que faz parecer pixel art

Pixel art tem menos a ver com baixa resolução e mais com controle. Cada pixel é uma decisão. Uma renderização toma milhões de pequenas decisões que você não pediu, então o trabalho é retomar essas decisões.

Uma só escala de pixel

Tudo no jogo deve compartilhar um só tamanho de pixel. Se uma árvore é desenhada numa escala e um personagem com o dobro de detalhe, o descompasso é óbvio. Pixel artists chamam pixels de tamanhos misturados de mixels. Num pipeline 3D, a solução é uma única escala de pixels por metro: um cavaleiro de dois metros tem sempre a mesma altura em pixels, e um caixote ao lado dele fica em proporção. No Pixor, defina um Pixels/m fixo nas câmeras por esse motivo: por padrão, cada câmera ajusta o sprite ao próprio tamanho.

Um pivô fixo

Se os pés do personagem caem num pixel diferente a cada quadro, o sprite treme no jogo mesmo quando a animação é boa. O pivô, normalmente entre os pés, deve ficar no mesmo pixel em todos os quadros e todos os lados. O Pixor prende o pivô a um pixel em todos os quadros e lados.

Paletas limitadas e rampas

Sprites feitos à mão usam poucas cores, organizadas em rampas: uma sequência curta do escuro ao claro para cada material. Poucas cores fazem as formas ficarem legíveis em tamanhos pequenos. Uma renderização precisa ser reduzida a uma paleta, e não só a menos cores escolhidas ao acaso.

Deslocamento de matiz

Boas rampas não só escurecem; elas mudam de matiz no caminho, normalmente mais frias na sombra e mais quentes na luz. Isso é o deslocamento de matiz, e é boa parte do que faz a pixel art parecer pintada em vez de acinzentada.

Contornos seletivos e traços limpos

Uma linha preta em volta de tudo serve para alguns estilos, mas muitos artistas colorem o contorno a partir da forma que ele envolve, mais escuro no lado da sombra e mais claro ou ausente no lado iluminado. Isso é selout. Os traços devem ter um pixel de largura, sem cantos em “L” dobrados, e partes finas como lâminas de espada e cajados devem continuar como traços limpos de um pixel em vez de se partirem. Mais em Contornos.

Sem pixels soltos e sem tremulação

Pixels isolados que não pertencem a nenhuma forma parecem ruído. Na animação, o problema pior é a tremulação: um pixel ou um traço que aparece num quadro e some no seguinte. Uma renderização produz os dois o tempo todo, porque mudanças minúsculas no modelo empurram valores um pouco acima ou abaixo de um limiar.

Nada de pontilhado por acidente

Pontilhado pode ser um estilo deliberado. Se for usado, o padrão deve ficar fixo na superfície enquanto o modelo se move, e não se arrastar por cima dela como uma porta de tela.

O pipeline, etapa por etapa

Aqui está a cadeia de costume, e onde o Pixor entra em cada etapa.

1. O modelo

Qualquer modelo com rig ou estático serve. O Pixor lê glTF e GLB, FBX (incluindo downloads do Mixamo), OBJ e arquivos .vox do MagicaVoxel. Modelos mais simples, com formas claras e materiais distintos, rendem sprites melhores que modelos muito detalhados; detalhes menores que um pixel se perdem de qualquer jeito.

2. Uma câmera por lado

Cada direção é uma câmera olhando para o modelo. Jogos de rolagem lateral precisam de uma; jogos vistos de cima e isométricos usam anéis de 4 ou 8. A inclinação importa tanto quanto a direção: uma vista lateral, uma vista de três quartos, uma vista isométrica 2:1 e uma vista de cima servem a jogos diferentes. No Pixor cada lado é uma câmera, em anéis de 4, 8 ou 16 ou em qualquer ângulo que você escolher.

3. O G-buffer

Em vez de renderizar uma imagem pronta de uma vez, renderize a informação de que você precisa: a cor chapada de cada pixel, a direção para onde sua superfície aponta (normais), sua distância da câmera (profundidade) e a que parte ou material ele pertence. Isso se chama G-buffer. Cada etapa seguinte trabalha a partir dele, e é isso que torna o resto controlável. As imagens no topo desta página mostram a cor, as normais e a profundidade de um baú, e o sprite final.

4. Luz em faixas

O sombreamento suave vira poucas faixas chapadas: luz, meio-tom, sombra. A pixel art normalmente usa de duas a quatro. A parte difícil é manter as faixas estáveis quando o modelo se move, para que a borda de uma faixa não fique pulando para lá e para cá numa superfície que mal virou. O Pixor sombreia em 1 a 4 faixas e mantém uma faixa até a superfície ter claramente virado.

5. Traços

A partir da profundidade, das normais e dos ids de parte você encontra a silhueta, as arestas internas entre partes e os vincos onde uma superfície se dobra. Cada um pode ser desenhado de um jeito: escuro, colorido ou de jeito nenhum. O Pixor trata traços de silhueta, internos e de vinco como tipos separados, cada um com seu próprio ajuste de contorno seletivo, os desenha com um pixel de largura sem cantos em L e mantém partes finas como linhas de um pixel.

6. Paleta

Cada faixa de cada material é mapeada para uma cor numa rampa. Você pode deixar a ferramenta montar rampas a partir das cores do modelo ou impor uma paleta fixa compartilhada pelo jogo inteiro. O Pixor monta rampas com deslocamento de matiz por material e pode usar uma paleta automática, uma das sete embutidas, um arquivo .hex do Lospec ou .gpl do GIMP, ou uma paleta tirada de uma imagem. Ele grava PNGs indexados e tem modos de console para os limites de cor de Game Boy, NES, PICO-8, TIC-80 e C64.

7. Limpeza

A última passada remove pixels soltos e traços que aparecem por um único quadro. Essa é a diferença entre uma folha que parece feita à mão e uma que parece vídeo. O Pixor faz essa limpeza como um estágio próprio.

8. A folha

Os quadros são empacotados numa folha, normalmente uma linha por ação e lado, com dados que dizem à engine onde cada quadro está.

No Pixor, cada um desses estágios é um nó no grafo de Estilo, então você pode ver e mudar qualquer um deles. Um visual de que você gosta pode ser salvo como kit e reutilizado num projeto. As predefinições embutidas (clean, selout, retro4, flat e wireframe) são pontos de partida.

Escolhendo tamanhos e direções

O tamanho é antes de tudo uma escolha de design. Um sprite menor é mais fácil de ler numa multidão e mais barato de retocar; um maior mostra mais personalidade. Como guia aproximado:

• 16 px serve para tiles, itens e personagens bem pequenos.
• 32 px é uma altura de personagem comum em jogos top-down e de plataforma.
• De 48 a 64 px dá espaço para rostos, equipamento e animação expressiva.

Escolha uma escala de pixels por metro que dê ao seu personagem principal a altura que você quer e deixe todo o resto acompanhar. Exiba o jogo em múltiplos inteiros (2×, 3×, 4×) para que cada pixel da arte vire um quadrado limpo na tela. Tamanhos de sprite entra nisso em mais detalhes.

Quanto às direções: um lado para jogos de rolagem lateral (espelhe-o para o outro sentido), quatro para jogos simples vistos de cima, oito para a maioria dos jogos de ação e estratégia, dezesseis para coisas que giram suavemente, como veículos.

Animação

Uma animação 3D tem uma pose para cada instante. A animação em pixel art tem um punhado de quadros, e os quadros são escolhidos, não amostrados por igual.

Extremos de pose e retenções

Os quadros que mais importam são os extremos: a pose de contato de uma caminhada, o topo de um pulo, o momento em que uma espada acerta. Uma boa animação de sprite mantém esses e os segura um pouco mais, e descarta os intermediários que nada acrescentam em tamanhos pequenos. Quadros igualmente espaçados tendem a parecer flutuantes. Os quadros inteligentes do Pixor escolhem os extremos das poses e os retêm.

Menos quadros, quadros mais limpos

Uma caminhada de seis ou oito quadros é mais que suficiente a 32 pixels. Mais quadros significam mais chances de tremulação e mais trabalho de retoque. O Pixor mede a tremulação ao longo de uma animação.

Obtendo animação

Você pode animar o modelo você mesmo, usar clipes que vieram com ele (ou em arquivos de clipe separados) ou redirecionar clipes de outro rig. O Pixor também tem uma biblioteca de movimentos com ações simples (idle, caminhar, correr, pular, atacar, receber golpe, morrer) e movimentos de objeto (girar, flutuar, balançar, pulsar) para objetos de cena e itens coletáveis.

Retocando à mão

Uma renderização dá quadros consistentes. Não dá o julgamento de um artista. A maioria dos bons resultados vem de renderizar uma base limpa e depois corrigir os quadros que importam: um rosto mais claro, uma silhueta mais forte no quadro de ataque, um brilho na lâmina.

O Aseprite é a ferramenta habitual para isso. O Pixor exporta arquivos .aseprite com uma tag para cada ação e lado. Quando você muda o modelo ou os ajustes e renderiza de novo, as camadas pintadas à mão ficam nos seus quadros, então os retoques não se perdem numa nova geração. Veja Aseprite.

Exportar para engines

As engines querem quadros mais metadados. Destinos comuns:

• Folhas de sprites em PNG com um arquivo JSON que lista quadros, ações e lados.
• SpriteFrames do Godot para projetos Godot.
• GIF ou APNG para prévias, páginas de loja e posts em redes sociais.
• Mapas de normais e de profundidade se a sua engine ilumina sprites 2D.

O Pixor exporta tudo isso. Como a renderização é determinística, o mesmo modelo e os mesmos ajustes sempre dão os mesmos pixels, então as folhas podem ser refeitas a qualquer momento, sem surpresas. Veja Exportações e o manual de exportação.

Experimente

O Pixor é um app para desktop, para Windows e Linux, que faz cada etapa acima, offline e sem conta. Ele não contém IA generativa: renderiza o seu modelo com os ajustes que você escolhe. Custa $19.99 uma vez, com todas as atualizações grátis. Comece por Como funciona, explore a biblioteca para ver sprites renderizados assim ou leia o manual para ver todos os ajustes.