Voltar ao blog
ViewState10 min05 de maio de 2026

ViewState: como acabar com o projeto_FINAL_v2.max

Salvar como nova versão é o jeito errado certo de preservar uma cena que funcionou. O ViewState resolve o problema dentro do próprio .max — câmera, luz, render settings e visibilidade, em snapshots nomeados.

Abre o diretório de qualquer projeto de archviz que rodou mais de um mês e você encontra o mesmo padrão: projeto.max, projeto_v01.max, projeto_v02_cliente_A.max, projeto_FINAL.max, projeto_FINAL_v2.max, projeto_FINAL_v2_REAL.max. É um meme da profissão por uma razão — todo mundo faz, todo mundo sabe que tem custo, e ninguém tem uma alternativa óbvia.

A boa notícia é que o problema tem solução técnica simples. A má notícia é que ela exige sair da inércia. Este artigo descreve por que o ritual do _FINAL_v2 existe, o que ele custa de verdade, e como o ViewState resolve sem te pedir pra mudar nada do seu workflow exceto a parte que estava te machucando.

O ritual do _FINAL_v2

O padrão tem causa legítima. Você terminou a câmera 01 com iluminação ajustada, render settings calibrados, layers visíveis configurados, plano de fundo certo. Vai começar a câmera 02 que precisa de luz diferente, render mais leve pra preview, alguns objetos visíveis que estavam escondidos. Se você mexer na cena, perde o estado da câmera 01.

Salvar uma nova versão preserva tudo. É o caminho mais óbvio. Sem ferramenta dedicada pra isso, é também o único caminho seguro. O custo é diluído ao longo das semanas e parece pequeno por isso.

A solução vira hábito. Em três meses você tem oito versões. Em seis, quinze. No final do projeto: 23GB de duplicatas pra preservar diferenças que cabem em alguns kilobytes.

O custo real (que não aparece na fatura)

O custo óbvio é armazenamento e backup. Em SSD interno isso ainda é tolerável. Em backup na nuvem ou em servidor de equipe, multiplica. Multiplica de novo quando você usa controle de versão por trás (Git LFS, Dropbox histórico). Multiplica ainda quando vários projetos sofrem do mesmo padrão.

O custo escondido é maior: erro de versão. Aquele momento em que você abre projeto_FINAL.max, ajusta uma textura, manda render, e descobre depois que devia ter aberto projeto_FINAL_v2_REAL.max. Em projeto bem prazoso isso é uma noite perdida. Em prazo apertado é deadline perdido.

O terceiro custo é fricção mental. Toda vez que você precisa retomar um projeto, precisa decidir qual arquivo é o atual. Toda vez que entrega pro cliente, precisa lembrar qual versão tem qual câmera ajustada. Toda vez que outro membro do time pega o projeto, precisa explicar a convenção. É imposto cognitivo invisível mas constante.

A solução: snapshots dentro do .max

A ideia do ViewState é trivial de descrever mas custosa de implementar à mão: registrar o estado completo da cena num momento dado, dar um nome a ele, e poder voltar a esse estado depois sem perder o que veio antes.

Em termos práticos: você ajustou a câmera 01 da forma que ficou boa, com a iluminação e os render settings que funcionaram. Você cria um ViewState chamado "Câmera 01 — versão cliente A". Aí mexe na cena livremente. Quando precisa voltar pra câmera 01, restaura o estado e a cena volta exatamente como estava.

Diferentemente de salvar nova versão, todos os estados ficam dentro do mesmo arquivo .max. Sem duplicação. Sem ambiguidade sobre qual arquivo abrir. Sem custo de backup proporcional ao número de estados.

O que cada snapshot guarda

Um ViewState completo registra: o estado de cada câmera (posição, target, lens, clipping, depth of field, exposição), a configuração de cada luz ativa (intensidade, cor, samples, ligado/desligado), a visibilidade e isolamento de layers, os modificadores de objetos relevantes, a configuração atual do Render Setup (resolução, samples, output path, elementos), o ambiente (cor de fundo, HDRI ativo, parâmetros de exposição global), e o estado do environment effects (volumetric, fog, etc).

A escolha desses estados é deliberada: cobre tudo o que normalmente leva alguém a salvar nova versão. Não cobre geometria — porque alterações de modelagem geralmente são intencionalmente irreversíveis. Se você precisa preservar um estado de modelagem específico, isso continua sendo um caso pra salvar versão. Pra todo o resto, ViewState basta.

Cada snapshot é nomeado e datado. Você pode ter quantos quiser por cena (não há limite imposto). Pode restaurar com um clique, comparar dois lado a lado, ou exportar pra outra cena se quiser reaproveitar uma configuração de luz que ficou boa.

Comparativo com versionamento manual

Salvar versões manualmente preserva tudo: cena, geometria, snapshots — funciona até pra reverter uma modelagem que deu errado. Custa duplicação de arquivo e ambiguidade.

ViewState preserva apenas o que muda entre passes (câmera, luz, render, visibilidade). Não cobre alteração de geometria. Custa próximo de zero em espaço — alguns kilobytes por snapshot.

A combinação dos dois é o ideal: ViewStates pra todo o trabalho diário (alternar entre câmeras, testar variações de luz, comparar render settings); versões manuais reservadas pra marcos do projeto (entrega cliente, fim de fase, antes de refatoração maior de modelagem). Você sai de 15 versões pra 3, e cada versão tem dentro de si todos os estados úteis que antes exigiam arquivos separados.

Workflow real: dia a dia com ViewState

Cena nova: configure a primeira câmera com iluminação e render settings na forma que funciona. Crie um ViewState chamado "Câmera 01 — base". Esse é seu ponto de retorno seguro.

Variações: ajuste a luz pra testar uma versão noturna. Quando ficou boa, ViewState "Câmera 01 — noturno". Aí teste uma versão mais quente. ViewState "Câmera 01 — golden hour". Em vez de três arquivos, você tem três estados no mesmo arquivo, cada um restaurável em um clique.

Múltiplas câmeras: cada câmera recebe seus próprios ViewStates. "Câmera 02 — base", "Câmera 02 — preview rápido" (com render settings leves pra teste). Você nunca mais perde tempo reajustando render settings ao alternar entre câmeras.

Entrega: na hora de mandar o cliente, você tem todos os estados nomeados dentro de um único .max. Se o cliente pede pra voltar à versão da semana passada, você restaura o ViewState. Sem caçar arquivo no histórico.

Onde o ViewState não substitui versão

Refatoração de modelagem grande: continue salvando versão antes. Se você vai unir vinte meshes, redistribuir UVs, ou desmontar uma estrutura, esse é um momento pra ter o estado anterior em arquivo separado, no caso de precisar voltar.

Marcos contratuais: muitas vezes é exigido pela documentação do projeto manter um snapshot do arquivo em cada entrega. Isso continua válido. ViewState não substitui esse uso legítimo de versão.

Colaboração paralela: se duas pessoas precisam trabalhar simultaneamente na mesma cena com mudanças que vão divergir, versionamento ou solução de branching ainda é necessário. ViewState resolve o caso de uma pessoa preservando estados que ela mesma criou — não o de várias pessoas conciliando trabalhos.

Como começar

O ViewState é plugin de 3ds Max — instala como qualquer outro plugin, aparece como painel/dock na interface. Suporta 3ds Max 2020+ em Windows 10/11. Funciona com qualquer renderer (V-Ray, Corona, Arnold, Scanline) porque captura os estados via API nativa do Max em vez de salvar formatos próprios de cada engine.

Pra começar, instale, abra uma cena existente que tenha um estado bom (câmera + luz + render config). Crie o primeiro ViewState com nome descritivo. Mexa na cena. Restaure. A primeira vez que você restaurar e a cena voltar exatamente como estava é o momento em que o produto se prova.

A licença Individual cobre 1 pessoa em até 2 máquinas. A licença Team cobre até 5 pessoas. Garantia de 7 dias. Os estados criados ficam dentro do arquivo .max, então projetos antigos que receberem ViewStates não precisam de migração e nem deixam de abrir em máquinas sem o plugin (os estados ficam disponíveis quando o plugin estiver instalado novamente).