Si vous avez vu un film à succès au cours des cinq dernières années, vous avez probablement été témoin des effets visuels et du travail d'animation réalisés par les artistes au talent exceptionnel des Method Studios à Melbourne. Notre travail couvre les genres cinématographiques, de «Aquaman" et "Terminator: Dark Fate"Pour"Jumanji: le prochain niveau" et "John Wick: Chapitre 3 - Parabellum, "Et des séries épisodiques, y compris le gagnant d'un Emmy Award"Bataille des Bastards»Épisode de la sixième saison de« Game of Thrones »de HBO. Réflexion sur notre travail, Disney's "Christopher Robin»S'est avéré l'une des entreprises les plus mémorables, étant donné l'exploit de donner vie à Winnie-the-Pooh, la co-star de CG aimant le miel du film. La prise en charge de ce projet a non seulement permis à l'équipe de remporter un Asian Academy Creative Award, mais cela a également marqué le début de notre collaboration avec AWS.
Gagner la candidature pour «Christopher Robin» en 2017 était passionnant, mais intimidant, car rendre un ours en plein CG, souvent présenté dans des plans rapprochés, est un défi. Nous utiliserions Date limite Thinkbox logiciel pour gérer notre ferme de rendu pendant de nombreuses années, avant l'acquisition de Thinkbox Software par AWS. Alors que nous avons commencé à préparer «Christopher Robin», le AWS Thinkbox l'équipe a aidé à mettre en place un workflow de validation de principe pour le rendu en rafale dans le cloud. Avant de commencer, nous avons dû réfléchir à la manière dont nous présenterions nos données aux nœuds de rendu basés sur le cloud, où stocker les données et comment intégrer le calcul basé sur le cloud à notre batterie de serveurs sur site existante.
Nous avons envisagé un certain nombre d'options pour présenter les textures et la géométrie au Cloud Amazon Elastic Compute (Amazon EC2) instances. L'approche la plus simple consistait à présenter notre serveur NFS (Network File System) sur site directement sur notre AWS Direct Connect à la Flotte Spot Amazon EC2 dans la région de Sydney. Cela dit, nous voulions profiter de centaines d'instances qui créeraient des dizaines de gigabits de trafic. Obtenir ce type de débit sur un réseau privé virtuel (VPN) est un défi et un coût prohibitif en termes de trafic de sortie. Au lieu de cela, nous avons opté pour Amazon Elastic File System (Amazon EFS), un service NFS géré basé sur le cloud. La configuration avec Amazon EFS était simple et la configuration par défaut pouvait être réduite pour minimiser les coûts lorsqu'elle n'était pas utilisée. Bien qu'une approche moins automatisée, nous avons fini par utiliser le paramètre de débit provisionné pour des performances plus prévisibles.
Au cours des années qui ont suivi «Christopher Robin», les exigences techniques pour le rendu n'ont fait que devenir plus exigeantes. Nous avons donc continué à affiner notre flux de travail et la façon dont nous utilisons les services AWS. Aujourd'hui, les projets nécessitent le rendu des images à une résolution de 4.5K, où l'accès au calcul basé sur le cloud avec beaucoup de RAM et de cœurs de processeur est payant. Les cadres qui pourraient avoir du mal à être rendus avec du matériel sur site peuvent tirer parti de ces grandes instances Amazon EC2, tous les calculs étant gérés à l'aide de la même instance Deadline. Au fur et à mesure que les travailleurs Amazon EC2 se connectent, ils sont disponibles de manière dynamique dans Moniteur de date limite aux côtés de notre ferme sur place.
L'un des avantages les moins évidents que nous avons trouvés lors de l'explosion dans AWS est un impact réduit sur le stockage sur site. Les exigences d'entrée / sortie (E / S) liées à une activité de rendu intense peuvent avoir un impact significatif sur les artistes, car il est difficile de rester productif lorsque votre stockage ne peut pas suivre. Le transfert de cette lourde charge de travail d'E / S vers EFS a protégé les performances de nos artistes et, par conséquent, a stimulé la productivité et le moral du studio. Parallèlement à EFS, nous avons ajouté un partenaire AWS XNUMX% Flash Qumulo cluster afin d'accélérer les temps de démarrage des applications.
Pour nous assurer que les bonnes données atteignent le cloud pour les rendus et reviennent aux postes de travail des artistes dès qu'une image a terminé le rendu, nous avons construit un système pour générer par programme une liste des actifs dépendants et des logiciels requis pour rendre un plan donné. Notre ensemble d'outils pouvait déjà suivre les dépendances, il n'a donc fallu que deux semaines pour créer l'infrastructure et les logiciels de base. Aujourd'hui, nous utilisons une base de données pour suivre les fichiers de stockage dans le cloud. Avant de transférer des données, nous vérifions par rapport à cette base de données pour voir si un actif doit être synchronisé. Tout ce qui n'est pas déjà dans la base de données est ajouté à la file d'attente, qui alimente une batterie de travailleurs de synchronisation qui déplacent les données vers / depuis le stockage cloud. La date limite capture toutes les erreurs résultant d'actifs manquants, qui envoie ensuite automatiquement une demande de récupération des fichiers manquants. La tâche qui a échoué attend ensuite l'arrivée des données et reprend une fois que les fichiers sont arrivés dans le stockage cloud.
Étant donné que nous utilisons le cloud pour augmenter notre capacité de rendu sur site, nous devions pouvoir évoluer rapidement sans intervention manuelle, et tout aussi facilement réduire afin de ne pas payer pour les ressources une seconde de plus que ce dont nous avons besoin. . Pour y parvenir, nous avons créé des outils pour surveiller la date limite pour les tâches de file d'attente. Désormais, lorsque notre capacité de rendu sur site est épuisée, nous pouvons facilement faire évoluer notre flotte Spot et commencer le rendu dans le cloud en quelques minutes. Dès qu'il n'y a plus de tâches en file d'attente, Deadline arrête les machines inactives, nous ne payons donc que pour le calcul en cours d'utilisation. Nous suivons et surveillons les dépenses à l'aide de tableaux de bord et d'étiquettes de répartition des coûts. De cette façon, nous avons toujours une visibilité sur nos dépenses et une alerte prédéfinie nous avertit si nous dépassons le budget prévu.
Parfois, notre système de synchronisation des actifs ne parvient pas à copier quelque chose dont un rendu a besoin, nous avons donc créé un poste de travail virtuel à l'aide d'un Instance Amazon EC2 G4dn (GPU) qui est configuré exactement comme un poste de travail sur site. Chaque fois que nous avons besoin de dépanner un rendu cassé, nous nous connectons au poste de travail basé sur le cloud et déclenchons une scène comme si nous l'exécutions dans notre studio pour identifier rapidement tout problème. Lorsqu'un rendu se termine sur AWS, l'image ou les données finies sont synchronisées sur site afin que l'artiste puisse les examiner. Pour nous assurer que les rendus se déroulent comme prévu, nous avons créé une application Web qui permet aux artistes de prévisualiser les images pendant leur rendu. Nous profitons de toutes les métriques issues de Amazon Cloud Watch et utilisez les tableaux de bord Grafana pour suivre les métriques Amazon EC2, le stockage, la bande passante, les coûts et tout ce que nous pouvons imaginer.
Aujourd'hui, plus de trois ans après le début de notre aventure dans le cloud, nous avons vu à quel point le rendu intégral sur AWS s'inscrit dans notre stratégie de ferme de rendu. Nous nous sommes éloignés des achats de capex ou de la location d'équipement, et nous nous concentrons maintenant sur le cloud. À ce stade, nous avons automatisé la plupart de la gestion de l'infrastructure AWS et passons beaucoup moins de temps à monter les serveurs, à gérer les mises à jour du micrologiciel et à remplacer le matériel défectueux. Notre objectif est de continuer à réduire le temps nécessaire pour renvoyer un cadre fini aux artistes, afin que nous puissions continuer à élever la barre en termes de qualité et de délai d'exécution pour les clients.
Comment Winnie-the-Pooh a déclenché le voyage de Melbourne vers le rendu dans le cloud, a été publié sur le Blog AWS Media le 20 avril 2021. À propos de l'auteur : Jon Stanley est responsable des systèmes chez Method Studios à Melbourne, poste qu'il occupe depuis 2017. Avec près de 20 ans d'expérience en ingénierie des systèmes pour les VFX et les studios de post-production, il a également passé du temps chez Iloura, Lipsync Post et Framestore.
En savoir plus
De l'animation et de la production à distance à la distribution, Qumulo pour les médias et le divertissement
Échelle illimitée et programmabilité API, Cloud Q pour AWS
Nous contacter
Faites un essai routier. Démo Qumulo dans nos laboratoires interactifs.
Abonnez-vous au blog Qumulo pour les témoignages clients, les informations techniques, les tendances du secteur et les actualités sur les produits
