Se você assistiu a algum filme de grande sucesso nos últimos cinco anos, provavelmente já viu os efeitos visuais e o trabalho de animação realizados pelos artistas excepcionalmente talentosos da Method Studios, em Melbourne. Nosso trabalho abrange diversos gêneros cinematográficos, desde “Aquaman” e “O Exterminador do Futuro: Destino Sombrio” para “Jumanji: O Próximo Nível” e “John Wick: Capítulo 3 – Parabellum ”, e séries episódicas, incluindo a vencedora do Emmy “A Batalha dos Bastardos” da sexta temporada da série “Game of Thrones”, da HBO. Refletindo sobre nosso trabalho, a série “Christopher Robin” revelou-se um dos projetos mais memoráveis, dada a enorme dificuldade de dar vida ao co-protagonista em CG do filme, o Winnie-the-Pooh, que adora mel. Assumir esse projeto não só rendeu à equipe um prêmio da Asian Academy Creative Award, como também marcou o início de nossa colaboração com a AWS.
Ganhar a licitação para “Christopher Robin” em 2017 foi emocionante, mas também intimidador, já que criar um urso totalmente em CG, que frequentemente aparece em planos de close, é um desafio. Nós vínhamos usando Prazo da Thinkbox software para gerenciar nossa fazenda de renderização por muitos anos, antes de a Thinkbox Software ser adquirida pela AWS. Quando começamos a nos preparar para “Christopher Robin”, o AWS Thinkbox A equipe ajudou a configurar um fluxo de trabalho de prova de conceito para renderização em massa na nuvem. Antes de começar, tivemos que refletir sobre como apresentaríamos nossos dados aos nós de renderização baseados na nuvem, onde armazená-los e como integrar a computação na nuvem ao nosso parque de servidores local já existente.
Consideramos várias opções sobre como apresentar texturas e geometria ao Amazon Elastic Compute Cloud (Amazon EC2) casos. A abordagem mais simples foi disponibilizar nosso servidor local do Sistema de Arquivos em Rede (NFS) diretamente por meio da nossa AWS Direct Connect para o Amazon EC2 Spot Fleet na região de Sydney. Dito isso, queríamos aproveitar centenas de instâncias que gerariam dezenas de gigabits de tráfego. Obter esse nível de taxa de transferência por meio de uma rede privada virtual (VPN) é desafiador e tem um custo proibitivo em termos de tráfego de saída. Em vez disso, optamos pelo Amazon Elastic File System (Amazon EFS), um serviço NFS gerenciado e baseado em nuvem. A configuração do Amazon EFS foi simples, e a configuração padrão podia ser reduzida para minimizar os custos quando não estivesse em uso. Embora tenha sido uma abordagem menos automatizada, acabamos usando a configuração de taxa de transferência provisionada para obter um desempenho mais previsível.
Nos anos que se passaram desde “Christopher Robin”, os requisitos técnicos para a renderização só se tornaram mais exigentes; por isso, continuamos a aprimorar nosso fluxo de trabalho e a forma como utilizamos os serviços da AWS. Hoje, os projetos exigem que os quadros sejam renderizados em resolução de 4,5K, e é aí que o acesso a recursos de computação na nuvem, com grande quantidade de RAM e núcleos de CPU, faz toda a diferença. Quadros que poderiam apresentar dificuldades para serem renderizados com hardware local podem aproveitar essas grandes instâncias do Amazon EC2, com toda a computação gerenciada por meio da mesma instância do Deadline. À medida que os workers do Amazon EC2 ficam online, eles ficam dinamicamente disponíveis em Monitor de Prazos juntamente com nosso ambiente local.
Uma das vantagens menos óbvias que descobrimos ao migrar para a AWS é a redução do impacto no armazenamento local. Os requisitos de entrada/saída (E/S) decorrentes de atividades intensas de renderização podem afetar significativamente os artistas, já que é difícil manter a produtividade quando o armazenamento não consegue acompanhar o ritmo. Transferir essa carga de trabalho pesada de E/S para o EFS garantiu o desempenho para nossos artistas e, como resultado, aumentou a produtividade e o ânimo em todo o estúdio. Juntamente com o EFS, adicionamos um parceiro da AWS com solução totalmente em flash Qumulo cluster, a fim de acelerar o tempo de inicialização dos aplicativos.
Para garantir que os dados corretos cheguem à nuvem para renderização e retornem às estações de trabalho dos artistas assim que um quadro terminar de ser renderizado, criamos um sistema para gerar programaticamente uma lista de recursos dependentes e softwares necessários para renderizar qualquer tomada. Nosso conjunto de ferramentas já era capaz de rastrear dependências, por isso levamos apenas duas semanas para construir a infraestrutura e o software básicos. Hoje, usamos um banco de dados para rastrear arquivos no armazenamento em nuvem. Antes de transferir dados, verificamos nesse banco de dados se um recurso precisa ser sincronizado. Tudo o que ainda não estiver no banco de dados é adicionado à fila, que alimenta um conjunto de processos de sincronização que transferem dados de e para o armazenamento na nuvem. O Deadline captura quaisquer erros resultantes de ativos ausentes e, em seguida, envia automaticamente uma solicitação para recuperar os arquivos que faltam. A tarefa com falha aguarda a chegada dos dados e é retomada assim que os arquivos chegam ao armazenamento na nuvem.
Como estamos usando a nuvem para ampliar nossa capacidade de renderização local, precisávamos ser capazes de expandir rapidamente sem intervenção manual e, com a mesma facilidade, reduzir a escala para não pagarmos por recursos nem que seja por um segundo a mais do que o necessário. Para isso, criamos ferramentas para monitorar o Deadline em busca de tarefas na fila. Agora, quando nossa capacidade de renderização local se esgota, podemos facilmente ampliar nossa Spot Fleet e começar a renderizar na nuvem em questão de minutos. Assim que não há mais tarefas na fila, o Deadline desliga as máquinas ociosas, de modo que pagamos apenas pela computação em uso. Acompanhamos e monitoramos os gastos usando painéis e tags de alocação de custos. Dessa forma, sempre temos visibilidade sobre nossos gastos, e um alerta pré-configurado nos avisa se estivermos excedendo o orçamento previsto.
Às vezes, nosso sistema de sincronização de ativos pode deixar de copiar algum elemento necessário para uma renderização; por isso, criamos uma estação de trabalho virtual usando um Instância Amazon EC2 G4dn (GPU) que está configurada exatamente como uma estação de trabalho local. Sempre que precisamos solucionar um problema em uma renderização com falha, nos conectamos à estação de trabalho baseada na nuvem e iniciamos uma cena como se estivéssemos executando-a em nosso estúdio, para identificar rapidamente quaisquer problemas. Quando uma renderização é concluída na AWS, o quadro finalizado ou os dados são sincronizados de volta para o ambiente local, para que o artista possa revisá-los. Para garantir que as renderizações estejam saindo conforme o esperado, criamos um aplicativo web que permite aos artistas visualizar os quadros enquanto eles estão sendo renderizados. Aproveitamos todas as métricas geradas por Amazon CloudWatch e usar os painéis do Grafana para monitorar métricas do Amazon EC2, armazenamento, largura de banda, custos e tudo o mais que pudermos imaginar.
Já se passaram mais de três anos desde o início de nossa jornada na nuvem, e pudemos constatar o quanto a renderização na AWS é essencial para nossa estratégia de farm de renderização. Deixamos de lado as aquisições de ativos fixos ou a locação de equipamentos e agora estamos focados na nuvem. Atualmente, automatizamos a maior parte do gerenciamento da infraestrutura da AWS e gastamos muito menos tempo instalando servidores, gerenciando atualizações de firmware e substituindo hardware com defeito. Nosso objetivo é continuar reduzindo o tempo necessário para entregar um quadro finalizado aos artistas, para que possamos elevar cada vez mais o padrão em termos de qualidade e prazo de entrega para os clientes.
“Como o Ursinho Pooh inspirou a jornada da Method Melbourne rumo à renderização em nuvem” foi publicado no Blog de Mídia da AWS em 20 de abril de 2021. Sobre o autor: Jon Stanley é chefe de sistemas na Method Studios, em Melbourne, cargo que ocupa desde 2017. Com quase 20 anos de experiência em engenharia de sistemas para estúdios de efeitos visuais e pós-produção, ele também trabalhou na Iloura, na Lipsync Post e na Framestore.
Saiba mais
Da animação e produção remota até a distribuição, Qumulo para mídia e entretenimento
Escalabilidade ilimitada e programabilidade via API, Cloud Q para AWS
Entre em contato conosco
Faça um test drive. Experimente o Qumulo em nossos laboratórios práticos interativos.
Inscreva-se no blog da Qumulo para conhecer histórias de clientes, informações técnicas, tendências do setor e novidades sobre produtos.