Wenn Sie in den letzten fünf Jahren einen Blockbuster gesehen haben, sind Ihnen wahrscheinlich die visuellen Effekte und Animationen aufgefallen, die von den außergewöhnlich talentierten Künstlern bei Method Studios in Melbourne geschaffen wurden. Unsere Arbeit erstreckt sich über verschiedene Filmgenres, von „Aquaman“ und „Terminator: Dark Fate“ zu „Jumanji: Die nächste Stufe“ und „John Wick: Kapitel 3 – Parabellum “ sowie Serien, darunter die mit einem Emmy Award ausgezeichnete „Die Schlacht der Bastarde„…“ – eine Folge aus der sechsten Staffel der HBO-Serie „Game of Thrones“. Im Rückblick auf unsere Arbeit, Disneys „Christopher Robin„…“ erwies sich als eines der denkwürdigsten Projekte, allein schon wegen der enormen Herausforderung, den honigliebenden CG-Co-Star des Films, Winnie-the-Pooh, zum Leben zu erwecken. Die Arbeit an diesem Projekt brachte dem Team nicht nur einen Asian Academy Creative Award ein, sondern markierte auch den Beginn unserer Zusammenarbeit mit AWS.
Den Zuschlag für „Christopher Robin“ im Jahr 2017 zu erhalten, war aufregend, aber auch einschüchternd, da die Darstellung eines vollständig computergenerierten Bären, der oft in Nahaufnahmen zu sehen ist, eine große Herausforderung darstellt. Wir hatten bisher Thinkbox-Frist Software zur Verwaltung unserer Renderfarm, die wir bereits seit vielen Jahren einsetzten, bevor Thinkbox Software von AWS übernommen wurde. Als wir mit den Vorbereitungen für „Christopher Robin“ begannen, war die AWS Thinkbox Das Team half bei der Einrichtung eines Proof-of-Concept-Workflows für das Burst-Rendering in die Cloud. Bevor wir loslegen konnten, mussten wir uns genau überlegen, wie wir unsere Daten den cloudbasierten Renderknoten bereitstellen würden, wo die Daten gespeichert werden sollten und wie wir die cloudbasierte Rechenleistung in unsere bestehende lokale Farm integrieren könnten.
Wir haben verschiedene Möglichkeiten geprüft, wie Texturen und Geometrie dem Amazon Elastic Compute Cloud (Amazon EC2) Fälle. Der einfachste Ansatz bestand darin, unseren lokalen Network File System (NFS)-Server direkt über unser AWS Direct Connect an den Amazon EC2 Spot Fleet in der Region Sydney. Allerdings wollten wir die Vorteile von Hunderten von Instanzen nutzen, die einen Datenverkehr im Umfang von mehreren zehn Gigabit erzeugen würden. Einen solchen Durchsatz über ein virtuelles privates Netzwerk (VPN) zu erreichen, ist schwierig und hinsichtlich des ausgehenden Datenverkehrs mit unerschwinglichen Kosten verbunden. Stattdessen entschieden wir uns für Amazon Elastic File System (Amazon EFS), einen cloudbasierten, verwalteten NFS-Dienst. Die Einrichtung mit Amazon EFS war einfach, und die Standardkonfiguration ließ sich zur Kostenminimierung bei Nichtnutzung zurückfahren. Obwohl dies ein weniger automatisierter Ansatz war, entschieden wir uns letztendlich für die Einstellung „Provisioned Throughput“, um eine besser vorhersehbare Leistung zu erzielen.
In den Jahren seit „Christopher Robin“ sind die technischen Anforderungen an das Rendering immer anspruchsvoller geworden, weshalb wir unseren Workflow und den Einsatz von AWS-Diensten kontinuierlich weiterentwickelt haben. Heutzutage erfordern Projekte das Rendern von Einzelbildern in einer Auflösung von 4,5K – und genau hier zahlt sich der Zugriff auf cloudbasierte Rechenleistung mit viel RAM und vielen CPU-Kernen aus. Einzelbilder, deren Rendering mit lokaler Hardware Schwierigkeiten bereiten könnte, können die Vorteile dieser großen Amazon EC2-Instanzen nutzen, wobei die gesamte Rechenleistung über dieselbe Deadline-Instanz verwaltet wird. Sobald Amazon EC2-Worker online gehen, stehen sie dynamisch zur Verfügung in Fristenüberwachung neben unserer lokalen Farm.
Einer der weniger offensichtlichen Vorteile, den wir bei unserem Einstieg in AWS festgestellt haben, ist die geringere Belastung des lokalen Speichers. Die Ein-/Ausgabeanforderungen (I/O) durch intensive Rendering-Aktivitäten können die Arbeit der Grafiker erheblich beeinträchtigen, da es schwierig ist, produktiv zu bleiben, wenn der Speicher nicht mithalten kann. Die Verlagerung dieser hohen I/O-Auslastung auf EFS hat die Leistung für unsere Grafiker gesichert und infolgedessen die Produktivität und Arbeitsmoral im gesamten Studio gesteigert. Neben EFS haben wir ein All-Flash-System eines AWS-Partners hinzugefügt Qumulo Cluster, um die Startzeiten der Anwendungen zu verkürzen.
Um sicherzustellen, dass die richtigen Daten für das Rendering in die Cloud gelangen und an die Arbeitsplätze der Künstler zurückgesendet werden, sobald ein Frame gerendert ist, haben wir ein System entwickelt, das programmgesteuert eine Liste der abhängigen Assets und der für das Rendering einer bestimmten Einstellung erforderlichen Software erstellt. Da unser Toolset bereits in der Lage war, Abhängigkeiten zu verfolgen, dauerte der Aufbau der grundlegenden Infrastruktur und Software nur zwei Wochen. Heute nutzen wir eine Datenbank, um Dateien im Cloud-Speicher zu verfolgen. Vor der Datenübertragung prüfen wir anhand dieser Datenbank, ob ein Asset synchronisiert werden muss. Alles, was noch nicht in der Datenbank vorhanden ist, wird der Warteschlange hinzugefügt, die eine Gruppe von Synchronisierungs-Workern versorgt, welche Daten zum bzw. vom Cloud-Speicher übertragen. Deadline erfasst alle Fehler, die durch fehlende Assets entstehen, und sendet daraufhin automatisch eine Anfrage zum Abrufen der fehlenden Dateien. Die fehlgeschlagene Aufgabe wartet dann auf den Eintreffen der Daten und wird fortgesetzt, sobald die Dateien im Cloud-Speicher angekommen sind.
Da wir die Cloud nutzen, um unsere lokale Renderkapazität zu erweitern, mussten wir in der Lage sein, die Kapazität schnell und ohne manuellen Eingriff zu erhöhen und ebenso einfach wieder zu reduzieren, damit wir keine Sekunde länger für Ressourcen bezahlen, als wir sie benötigen. Um dies zu erreichen, haben wir Tools entwickelt, die Deadline auf Aufgaben in der Warteschlange überwachen. Wenn nun unsere Renderkapazitäten vor Ort erschöpft sind, können wir unsere Spot Fleet problemlos erweitern und innerhalb weniger Minuten mit dem Rendern in der Cloud beginnen. Sobald keine Aufgaben mehr in der Warteschlange stehen, fährt Deadline nicht ausgelastete Maschinen herunter, sodass wir nur für tatsächlich genutzte Rechenleistung bezahlen. Wir verfolgen und überwachen die Ausgaben mithilfe von Dashboards und Kostenverrechnungs-Tags. Auf diese Weise haben wir stets den Überblick über unsere Ausgaben, und eine voreingestellte Warnmeldung informiert uns, wenn wir das prognostizierte Budget überschreiten.
Gelegentlich kann es vorkommen, dass unser System zur Synchronisierung von Assets etwas nicht kopiert, das für einen Rendervorgang benötigt wird. Deshalb haben wir eine virtuelle Workstation mithilfe eines Amazon EC2 G4dn (GPU)-Instanz die genau wie eine lokale Workstation eingerichtet ist. Wann immer wir ein Problem bei einem fehlgeschlagenen Rendering beheben müssen, stellen wir eine Verbindung zur cloudbasierten Workstation her und starten eine Szene, als würden wir sie in unserem Studio ausführen, um eventuelle Probleme schnell zu identifizieren. Wenn ein Rendering auf AWS abgeschlossen ist, werden die fertigen Frames oder Daten zurück in die lokale Umgebung synchronisiert, damit der Grafiker sie überprüfen kann. Um sicherzustellen, dass die Renderings wie erwartet ausfallen, haben wir eine Webanwendung entwickelt, mit der Grafiker bereits während des Renderings eine Vorschau der Frames anzeigen können. Wir nutzen alle Metriken, die aus Amazon CloudWatch und nutzen Grafana-Dashboards, um Amazon EC2-Metriken, Speicherplatz, Bandbreite, Kosten und alles andere, was uns sonst noch einfällt, zu überwachen.
Nach nun mehr als drei Jahren auf unserem Weg in die Cloud haben wir erkannt, wie unverzichtbar das Rendern auf AWS für unsere Renderfarm-Strategie ist. Wir haben unseren Fokus von Investitionen in Sachanlagen oder der Anmietung von Geräten weg verlagert und konzentrieren uns nun auf die Cloud. Mittlerweile haben wir den Großteil der AWS-Infrastrukturverwaltung automatisiert und verbringen deutlich weniger Zeit damit, Server einzuräumen, Firmware-Updates zu verwalten und defekte Hardware zu ersetzen. Unser Ziel ist es, die Zeit bis zur Rückgabe eines fertigen Frames an die Künstler weiter zu verkürzen, damit wir die Messlatte in Bezug auf Qualität und Bearbeitungszeit für unsere Kunden immer höher legen können.
„Wie Winnie-the-Pooh den Weg von Method Melbourne zum Cloud-Rendering ebnete“ wurde am AWS Media-Blog am 20. April 2021. Über den Autor: Jon Stanley ist Leiter der Systemabteilung bei Method Studios in Melbourne, eine Position, die er seit 2017 innehat. Mit fast 20 Jahren Erfahrung im Bereich Systemengineering für VFX- und Postproduktionsstudios war er unter anderem auch bei Iloura, Lipsync Post und Framestore tätig.
Mehr erfahren
Von der Animation über die Fernproduktion bis hin zum Vertrieb, Qumulo für Medien und Unterhaltung
Unbegrenzte Skalierbarkeit und API-Programmierbarkeit, Cloud Q für AWS
Kontaktieren Sie uns
Machen Sie eine Probefahrt. Testen Sie Qumulo in unseren interaktiven Hands-On-Labors.
Den Qumulo-Blog abonnieren für Kundenberichte, technische Einblicke, Branchentrends und Produktneuheiten.