Si vous avez vu un film à grand 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 exceptionnellement talentueux de Method Studios à Melbourne. Notre travail couvre tous les genres de films, de "Aquaman" et "Terminator : Dark Fate" à "Jumanji : Le niveau suivant" et "John Wick : Chapitre 3 - Parabellum et des séries épisodiques, notamment "La bataille des bâtards"dans la sixième saison de la série "Game of Thrones" de HBO En réfléchissant à notre travail, Disney's "Christopher Robin"s'est avéré être l'une des entreprises les plus mémorables, étant donné l'exploit de donner vie à Winnie l'ourson, la co-star en images de synthèse du film qui aime le miel. Ce projet a non seulement permis à l'équipe de remporter un Asian Academy Creative Award, mais il a également marqué le début de notre collaboration avec AWS.
Remporter l'appel d'offres pour "Christopher Robin" en 2017 était à la fois excitant et intimidant, car le rendu d'un ours full-CG, qui apparaît souvent en gros plan, est un véritable défi. Nous avions utilisé Délai du Thinkbox pour gérer notre ferme de rendu pendant de nombreuses années, avant que Thinkbox Software ne soit racheté par AWS. Alors que nous commencions à préparer le film "Christopher Robin", l'équipe de Thinkbox Software s'est mise à l'œuvre Boîte à idées AWS nous a aidés à mettre en place un flux de travail de démonstration pour le rendu en rafale dans le nuage. Avant de commencer, nous avons dû réfléchir à la manière dont nous allions présenter nos données aux nœuds de rendu basés sur le cloud, à l'endroit où nous allions stocker les données et à la manière dont nous allions intégrer l'informatique basée sur le cloud à notre ferme existante sur site.
Nous avons envisagé un certain nombre d'options pour la présentation des textures et de la géométrie à l'écran Amazon Elastic Compute Cloud (Amazon EC2) les instances de l'UE. L'approche la plus simple consistait à présenter notre serveur Network File System (NFS) sur site directement sur notre serveur AWS Direct Connect à la Amazon EC2 Spot Fleet 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 un tel débit sur un réseau privé virtuel (VPN) est un défi et un coût prohibitif en termes de trafic de sortie. Nous avons donc opté pour Amazon Elastic File System (Amazon EFS), un service NFS géré dans le nuage. L'installation d'Amazon EFS était simple et la configuration par défaut pouvait être réduite pour minimiser les coûts en cas d'inutilisation. Bien qu'il s'agisse d'une approche moins automatisée, nous avons fini par utiliser le paramètre de débit provisionné pour obtenir des performances plus prévisibles.
Depuis "Christopher Robin", les exigences techniques en matière de rendu n'ont cessé de croître. Nous avons donc continué à affiner notre flux de travail et la manière dont nous utilisons les services AWS. Aujourd'hui, les projets exigent que les images soient rendues à une résolution de 4,5K, et c'est là que l'accès à l'informatique en nuage avec beaucoup de RAM et de cœurs d'unité centrale s'avère payant. Les images dont le rendu serait difficile à obtenir 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 d'Amazon EC2 sont mis en ligne, ils sont dynamiquement disponibles dans l'instance Deadline Moniteur de délais à côté de notre ferme sur place.
L'un des avantages les moins évidents que nous avons découverts en nous lançant dans AWS est la réduction de l'impact sur le stockage sur site. Les exigences en matière d'entrées/sorties (E/S) liées à une activité de rendu intense peuvent avoir un impact considérable sur les artistes, car il est difficile de rester productif lorsque le stockage ne peut pas suivre. Le transfert de cette lourde charge d'E/S vers EFS a permis de protéger les performances de nos artistes et, par conséquent, de stimuler la productivité et le moral dans le studio. En plus de l'EFS, nous avons ajouté un système de stockage tout-flash AWS Partner Qumulo afin d'accélérer le démarrage des applications.
Pour s'assurer que les bonnes données atteignent le nuage pour les rendus et reviennent sur les postes de travail des artistes dès que le rendu d'une image est terminé, nous avons construit un système pour générer de manière programmatique une liste de ressources et de logiciels dépendants nécessaires au rendu d'une prise de vue donnée. Notre ensemble d'outils permettait déjà de suivre les dépendances, et il n'a donc fallu que deux semaines pour mettre en place l'infrastructure et le logiciel de base. Aujourd'hui, nous utilisons une base de données pour suivre les fichiers de stockage sur le cloud. Avant de transférer des données, nous vérifions dans cette base de données si un élément doit être synchronisé. Tout ce qui ne figure pas encore dans la base de données est ajouté à la file d'attente, qui alimente une ferme de travailleurs de synchronisation qui déplacent les données vers/depuis le stockage en nuage. Deadline capture toutes les erreurs résultant d'actifs manquants, ce qui permet d'envoyer automatiquement une demande de récupération des fichiers manquants. La tâche défaillante attend alors l'arrivée des données et reprend une fois que les fichiers sont arrivés dans le stockage en nuage.
Comme nous utilisons le cloud pour augmenter notre capacité de rendu sur site, nous devions être en mesure d'augmenter rapidement notre capacité sans intervention manuelle, et de la réduire tout aussi facilement afin de ne pas payer pour des ressources une seconde de plus que ce dont nous avons besoin. Pour ce faire, nous avons créé des outils pour surveiller les tâches de la file d'attente de Deadline. Désormais, lorsque notre capacité de rendu sur site est épuisée, nous pouvons facilement augmenter notre Spot Fleet et commencer le rendu dans le nuage en quelques minutes. Dès qu'il n'y a plus de tâches en file d'attente, Deadline arrête les machines inactives, de sorte que nous ne payons que pour le calcul en cours d'utilisation. Nous suivons et contrôlons les dépenses à l'aide de tableaux de bord et d'étiquettes de répartition des coûts. Ainsi, nous avons toujours une visibilité sur nos dépenses, et une alerte prédéfinie nous prévient si nous dépassons le budget prévu.
Il peut arriver que notre système de synchronisation des actifs ne parvienne pas à copier un élément nécessaire à un rendu, c'est pourquoi nous avons créé un poste de travail virtuel en utilisant un fichier Instance Amazon EC2 G4dn (GPU) qui est configuré exactement comme une station de travail sur site. Chaque fois que nous avons besoin de dépanner un rendu défectueux, nous nous connectons à la station de travail basée dans le nuage et lançons une scène comme si nous l'exécutions dans notre studio afin d'identifier rapidement les problèmes. Lorsqu'un rendu est terminé sur AWS, l'image ou les données finies sont synchronisées sur site pour 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 en cours de rendu. Nous tirons parti de toutes les mesures provenant de Amazon CloudWatch et utiliser les tableaux de bord Grafana pour suivre les métriques Amazon EC2, le stockage, la bande passante, les coûts et tout ce que l'on peut imaginer.
Après plus de trois ans d'expérience dans le cloud, nous avons constaté que le rendu sur AWS fait partie intégrante de notre stratégie en matière de fermes de rendu. Nous nous sommes détournés de l'achat de capital ou de la location d'équipement pour nous concentrer sur le cloud. À ce stade, nous avons automatisé la majeure partie de la gestion de l'infrastructure AWS et nous passons beaucoup moins de temps à installer des 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 rendre 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 l'ourson a déclenché le voyage de Method Melbourne vers le rendu en nuage (Cloud Rendering), a été posté sur le site web Blog médias AWS le 20 avril 2021. A propos de l'auteur : Jon Stanley est responsable des systèmes à Studios de méthodes à Melbourne un rôle qu'il occupe depuis 2017. Avec près de 20 ans d'expérience dans l'ingénierie des systèmes pour les studios VFX et de post-production, il a également passé du temps chez Iloura, Lipsync Post et Framestore.
En savoir plus
De l'animation à la distribution en passant par la téléproduction qumulo pour les médias et le divertissement
Échelle illimitée et programmabilité de l'API, Cloud Q pour AWS
Contactez nous
Faire un essai routier. Démonstration de Qumulo dans nos laboratoires interactifs.
S'abonner au blog de Qumulo pour des témoignages de clients, des informations techniques, des tendances industrielles et des informations sur les produits.