Marcadores

27 junho 2011

Desenhando para VÍDEO e desenhando para SWF

Originalmente, alguns dos episódios postados foram produzidos como parte de um trabalho acadêmico. Nesse trabalho estavam previstas algumas possibilidades de interação, o que levou o projeto a ser encarado como um Aplicativo Web (nesse caso, distribuído em SWF), e não como um vídeo propriamente dito. Essa distinção básica traz grandes diferenças na forma de pensar o desenho. Por exemplo: esse é o plano inicial do episódio Uma Novela Mexicana 01-04, parte de um Aplicativo SWF.



Agora, o mesmo plano (em termos de enquadramento, motivo, iluminação, etc.) para o episódio Pavor desenvolvido desde o início para ser distribuído em vídeo (streaming).



É claro que existe a questão de paletas de cores diferentes, mas os detalhes do céu, a presença e desfoque nas montanhas ao fundo, a maior gama de variações de luz e sombra é gritante. Isso acontece porque em SWF temos algumas preocupações semelhantes aquelas de um desenvolvedor de Aplicativos: arquitetura de sistema, peso final do arquivo, memória disponível em tempo de execução, etc. Em vídeo temos outros tipos de preocupações, a Decupagem e a Montagem, por exemplo, são mais importantes aqui do que seriam em um aplicativo animado.
Em termos desenhísticos - se é que essa palavra existe ;) - em vídeo temos maiores liberdades de detalhes, sobreposição de objetos, gradientes, desfoque, canais de alfa, etc. Isso, porque o SWF é mais suscetível a problemas de throughput limitado do que um vídeo em streaming (no youtube, por exemplo).
Essa m3#d@.limita.projetos conhecida como throughput, segundo o pessoal da Adobe, é a quantidade de dados que uma unidade pode processar por segundo. Em termos práticos: é a capacidade, ou não, de executar um vídeos/aplicativo animado em tempo real... Ainda: sabe quando um vídeo (em altíssima resolução ou em um equipamento de baixíssima capacidade) roda mais lento do que deveria, perdendo a sincronia com o áudio? Aquilo, quase sempre, é throughput limitado. Então... em SWF temos mais chances que isso aconteça do que em vídeo.

Tentando limitar esse (d)efeito, desenvolvi alguns hábitos de produção para cada modelo de distribuição. No caso de SWF, tendo a desenhar todos os objetos não animados e suas sombras/brilhos em uma única camada. A simulação de efeitos de iluminação é feita variando o brilho da cor em questão. Nessa imagem, que é um dos cenários do episódio Uma Parábola de Suspense 03-04, as sombras projetadas no gramado atrás do prédio, por exemplo, é apenas o próprio gramado com uma variação mais escura de sua cor. Isso vale para toda a luz e sombra dessa imagem. Aqui não existe nenhuma sobreposição. Tudo está em uma única camada.



Em vídeo, a forma do objeto é desenhada em uma camada e cada sombra e cada brilho em uma camada diferente. Essa sombra/brilho é na verdade uma forma sobreposta, preenchida de preto (para sombras) ou branco (para brilho) variando a porcentagem de seu canal de alfa (transparência). O resultado é visivelmente melhor. É claro, o arquivo é maior, sua execução é mais lenta, mas em caso de vídeos não chega a ser problema.



Outra vantagem é a fácil reedição desses efeitos. Gerando, sobre o mesmo desenho inicial, mudanças como a iluminação das primeiras horas da manhã.



ou ao entardecer.



Ainda, o uso de padrões no fundo de cena. O que seria absurdamente pesado em SWF, mas é irrelevante em vídeo.



Nenhum comentário: