Crie um storyboard consistente de seis painéis com Nano Banana 2.1
Transforme um elenco de três personagens em um storyboard de seis painéis com Nano Banana 2.1 e corrija personagens duplicados e rótulos indesejados nos painéis.
Um personagem pode parecer perfeito em uma imagem e ainda assim variar assim que a câmera, a pose e o cenário mudam. Um storyboard útil precisa cumprir duas funções ao mesmo tempo: avançar a história enquanto preserva os rostos, proporções, cores, roupas e detalhes marcantes do elenco.
Testamos um fluxo de trabalho de duas etapas com Nano Banana 2.1 e três personagens originais. Primeiro, criamos um elenco de referência limpo. Em seguida, reutilizamos essa imagem como a única referência para uma aventura de seis painéis. A folha final manteve os três personagens reconhecíveis em vistas traseiras, aproximadas, de ação e de interior — mas chegar a esse resultado também revelou um limite útil: pedir que um personagem se transforme pode gerar uma duplicata, mesmo quando o prompt especifica uma contagem exata.
Fluxo de trabalho testado
Um elenco de três personagens se tornou um storyboard 3×2. Três execuções mostram como as âncoras de referência preservaram a identidade — e por que reescrever uma ação ambígua funcionou melhor do que adicionar mais regras de contagem.
Por que um elenco de personagens limpo vem primeiro
Criamos um elenco com silhuetas e âncoras de cor deliberadamente diferentes:
- Reia: uma entregadora panda-vermelha cor de ferrugem, com capa azul-petróleo com capuz, bolsa tiracolo bege e bússola de latão.
- Nimbo: um espírito de nuvem azul-claro com cachecol amarelo e presilha de cabelo em forma de estrela.
- Tique: um robô pássaro de latão com olho azul-cobalto e chave de corda.
A primeira geração não foi uma cena da história. Foi um elenco neutro de corpo inteiro, com bastante espaço entre os personagens e sem rótulos ou acessórios extras. Isso oferece ao modelo um contrato visual simples antes que ele precise resolver seis cenários e ações de uma só vez.
| Configuração | Elenco de personagens | Storyboard |
|---|---|---|
| Ferramenta | WeShop Nano Banana | WeShop Nano Banana |
| Modelo | Nano Banana 2.1 | Nano Banana 2.1 |
| Entrada | Prompt de texto | Uma imagem do elenco + prompt |
| Proporção | 16:9 | 16:9 |
| Tamanho da imagem | 2K | 2K |
| Quantidade | 1 | 1 |
| Dimensões entregues | 2752 × 1536 | 2752 × 1536 |
O Google descreve o Gemini Nano Banana 2.1 como um modelo de geração de imagens e edição conversacional com melhor adesão a prompts e consistência de personagens em múltiplas interações. Seu cartão de modelo do DeepMind inclui consistência de personagens únicos e múltiplos na cobertura de avaliação, mas também alerta que a consistência dos personagens nem sempre é perfeita. Este teste se concentra em um fluxo de trabalho prático, e não em uma análise ampla do modelo.
Etapa 1: gere uma imagem de referência auditável
Use um fundo simples, peça vistas frontais de corpo inteiro e dê a cada personagem dois ou três detalhes que possam ser verificados depois. Evite ação narrativa nesta etapa; ela adiciona variáveis antes que os designs estejam estáveis.
Antes de continuar, verifique o elenco como se fosse uma folha de modelo. Conte os personagens, confira os acessórios nomeados e rejeite qualquer rótulo extra ou objeto solto. Um erro aqui pode se propagar por todos os painéis.
Etapa 2: combine travas de identidade com uma lista ordenada de tomadas
Envie o elenco como imagem de referência. No próximo prompt, primeiro declare que a imagem enviada é a referência exata de design e, em seguida, repita as âncoras de identidade. Descreva os painéis na ordem de leitura e finalize com regras de layout e exclusão.
Nossa história envia o trio por uma ponte quebrada para entregar uma carta brilhante a uma biblioteca flutuante no céu. O primeiro prompt pedia que Nimbo se transformasse em uma plataforma de nuvem no painel 4. Essa formulação se tornou a parte mais importante do teste.
Primeira tentativa: identidade forte, duas falhas estruturais
A primeira folha contou a história na ordem correta e preservou as principais âncoras de identidade. Ela também ignorou duas restrições explícitas:
- Os espaços brancos continham os números de 1 a 6, apesar da regra de não haver texto.
- O painel 4 mostrava tanto o pequeno Nimbo quanto uma segunda plataforma de nuvem maior com rosto.
Isso não é apenas um erro de contagem. A frase “Nimbo se expande e se transforma em uma plataforma de nuvem macia” pede ao modelo que represente uma identidade em dois estados visuais dentro de um painel. O gerador de imagens manteve o personagem original e adicionou o estado transformado.
Segunda tentativa: uma contagem mais rigorosa corrigiu os rótulos, não a duplicata
O próximo prompt deixou os espaços entre painéis “completamente em branco”, proibiu números nos painéis e exigiu exatamente 18 aparições de personagens nos seis painéis. Ele também dizia para não mostrar um Nimbo pequeno ao lado da plataforma grande.
A instrução de espaços em branco funcionou. A duplicata não. Adicionar aritmética não resolveu a ambiguidade semântica, que é a lição mais útil: quando um momento visual contém duas formas de um personagem, uma frase de contagem exata pode perder para a transformação solicitada.
Tentativa final: reescreva a ação em vez de acumular restrições
Na terceira execução, removemos a transformação. O painel 4 agora pede aos mesmos três personagens que saltem pela lacuna usando tábuas de madeira flutuantes, com Nimbo soprando uma rajada de vento. Também proibimos duplicar, transformar, fundir ou substituir um personagem.
O resultado final resolveu a duplicata e manteve os espaços entre painéis em branco. Cada painel contém uma instância de cada personagem. A capa e a bolsa de Reia, o cachecol e a estrela de Nimbo, e o corpo de latão e olho azul de Tique permanecem identificáveis em diferentes poses e pontos de vista.
Uma variação menor permanece: a chave de corda de Tique não fica visível em todos os ângulos, e as três tábuas aparecem como parte da travessia em vez de haver uma plataforma sob cada personagem. Essas mudanças não quebram a identidade nem a ordem da história, mas mostram por que a folha final ainda precisa de uma revisão painel por painel.
Use esta lista de verificação antes de aprovar um storyboard
| Verificação | O que verificar | Resultado na tentativa final |
|---|---|---|
| Contagem do elenco | Uma instância de cada personagem obrigatório por painel | Aprovado nos seis painéis |
| Identidade | Rosto, material do corpo, cores principais, roupas | Preservada |
| Âncoras marcantes | Capa, bolsa, bússola, cachecol, estrela, olho azul | Preservadas; a chave de corda depende do ângulo |
| Ordem da história | Cada painel avança o momento planejado | Preservada |
| Layout | Seis painéis, leitura clara da esquerda para a direita, espaços em branco | Preservado |
| Texto extra | Sem rótulos, legendas, logotipos ou marca-d'água | Nada visível |
| Detalhe da ação | Encenação e acessórios solicitados | Em grande parte preservados; o posicionamento das tábuas varia |
Se um painel falhar, altere uma fonte de ambiguidade em vez de adicionar uma longa pilha de regras negativas. Reescrever a ação frequentemente oferece ao modelo um problema visual mais claro do que repetir “exatamente um” várias vezes.
A conclusão prática
Nano Banana 2.1 transformou um elenco de três personagens em uma narrativa coerente de seis painéis, mantendo o elenco reconhecível apesar de mudanças de local, pose, escala e câmera. Isso torna o fluxo de trabalho útil para rascunhos de storyboard, pré-produção de animação, planejamento de quadrinhos e conteúdo para redes sociais centrado em personagens.
O principal risco não é apenas a variação visual; é a lógica dos objetos. Uma transformação de personagem pode ser interpretada como dois estados desenháveis, produzindo uma duplicata mesmo quando a contagem é explícita. Primeiro fixe os designs, descreva os painéis em ordem, audite cada instância e substitua transformações ambíguas por ações que mantenham cada personagem separado.
Experimente o fluxo de trabalho no gerador WeShop Nano Banana: crie primeiro o elenco, reutilize-o como referência e trate o primeiro storyboard como evidência para refinar — não como o recurso final.







