Si ha visto una película de gran éxito en los últimos cinco años, probablemente haya sido testigo de los efectos visuales y el trabajo de animación realizado por los artistas excepcionalmente talentosos en Method Studios en Melbourne. Nuestro trabajo abarca géneros cinematográficos, desde "Aquaman y Terminator: Dark Fate" a "Jumanji: El siguiente nivel y John Wick: Capítulo 3 - Parabellum, "Y series episódicas, incluida la ganadora del premio Emmy"Batalla de los Bastardos"Episodio de la sexta temporada de" Game of Thrones "de HBO. Reflexionando sobre nuestro trabajo, Disney's "Christopher Robin”Resultó ser una de las empresas más memorables, dada la gran hazaña de dar vida a la coprotagonista generada por computadora, amante de la miel, Winnie-the-Pooh, de la película. Asumir este proyecto no solo resultó en la obtención del Premio Creativo de la Academia Asiática para el equipo, sino que también marcó el comienzo de nuestra colaboración con AWS.
Ganar la licitación por "Christopher Robin" en 2017 fue emocionante, pero intimidante, ya que representar un oso en CG completo, que a menudo aparece en tomas de primer plano, es un desafío. Nosotros usamos Fecha límite de Thinkbox para administrar nuestra granja de procesamiento durante muchos años, antes de que AWS adquiriera Thinkbox Software. Cuando comenzamos a prepararnos para "Christopher Robin", el AWS Thinkbox El equipo ayudó a configurar un flujo de trabajo de prueba de concepto para la renderización en ráfagas en la nube. Antes de comenzar, tuvimos que pensar en cómo presentaríamos nuestros datos a los nodos de renderización basados en la nube, dónde almacenar los datos y cómo integrar la computación basada en la nube con nuestra granja local existente.
Consideramos una serie de opciones sobre cómo presentar texturas y geometría al Nube informática elástica de Amazon (Amazon EC2) instancias. El enfoque más simple fue presentar nuestro servidor de Sistema de archivos de red (NFS) local directamente sobre nuestro AWS Direct Connect En el correo electrónico “Su Cuenta de Usuario en su Nuevo Sistema XNUMXCX”. Flota de spot de Amazon EC2 en la región de Sydney. Dicho esto, queríamos aprovechar cientos de instancias que crearían decenas de gigabits de tráfico. Obtener ese tipo de rendimiento a través de una red privada virtual (VPN) es un desafío y un costo prohibitivo en términos de tráfico de salida. En su lugar, optamos por Amazon Elastic File System (Amazon EFS), un servicio NFS administrado y basado en la nube. La configuración con Amazon EFS fue simple y la configuración predeterminada se podía reducir para minimizar los costos cuando no se usaba. Aunque fue un enfoque menos automatizado, terminamos usando la configuración de rendimiento aprovisionado para un rendimiento más predecible.
En los años transcurridos desde "Christopher Robin", los requisitos técnicos para la renderización se han vuelto más exigentes, por lo que hemos seguido perfeccionando nuestro flujo de trabajo y la forma en que usamos los servicios de AWS. Hoy en día, los proyectos requieren que los fotogramas se procesen a una resolución de 4.5K, que es donde el acceso a la computación basado en la nube con mucha RAM y núcleos de CPU vale la pena. Los marcos que pueden tener dificultades para renderizarse con hardware local pueden aprovechar esas grandes instancias de Amazon EC2, con todo el proceso administrado mediante la misma instancia de Deadline. A medida que los trabajadores de Amazon EC2 se conectan, están disponibles dinámicamente en Monitor de fecha límite junto con nuestra granja en las instalaciones.
Una de las ventajas menos obvias que encontramos al irrumpir en AWS es un impacto reducido en el almacenamiento local. Los requisitos de entrada / salida (E / S) de una intensa actividad de renderizado pueden afectar a los artistas de manera significativa, ya que es difícil mantenerse productivo cuando su almacenamiento no puede mantenerse al día. Trasladar esa pesada carga de trabajo de IO a EFS ha protegido el rendimiento de nuestros artistas y, como resultado, ha aumentado la productividad y la moral en el estudio. Junto con EFS, hemos agregado un socio de AWS totalmente flash Qumulo clúster para acelerar los tiempos de inicio de la aplicación.
Para garantizar que los datos correctos lleguen a la nube para los renderizados y regresen a las estaciones de trabajo de los artistas tan pronto como un fotograma termine de renderizarse, creamos un sistema para generar mediante programación una lista de activos dependientes y software necesarios para renderizar cualquier toma. Nuestro conjunto de herramientas ya podía rastrear dependencias, por lo que solo tomó dos semanas construir la infraestructura y el software básicos. Hoy, usamos una base de datos para rastrear archivos de almacenamiento en la nube. Antes de transferir datos, comparamos esa base de datos para ver si es necesario sincronizar un activo. Todo lo que no esté en la base de datos se agrega a la cola, lo que alimenta una granja de trabajadores de sincronización que mueven datos hacia / desde el almacenamiento en la nube. La fecha límite captura cualquier error resultante de los activos faltantes, que luego envía automáticamente una solicitud para recuperar los archivos faltantes. Luego, la tarea fallida espera a que lleguen los datos y se reanuda una vez que los archivos han llegado al almacenamiento en la nube.
Dado que estamos usando la nube para aumentar nuestra capacidad de renderizado local, necesitábamos poder escalar horizontalmente rápidamente sin intervención manual y con la misma facilidad escalar hacia abajo para no pagar por los recursos un segundo más de lo que los necesitamos . Para lograr esto, creamos herramientas para ver Deadline para tareas en cola. Ahora, cuando nuestra capacidad de renderización local se agote, podemos escalar fácilmente nuestra flota de spot y comenzar a renderizar en la nube en cuestión de minutos. Tan pronto como no haya más tareas en cola, Deadline apaga las máquinas inactivas, por lo que solo pagamos por la computación en uso. Realizamos un seguimiento y seguimiento de los gastos mediante paneles y etiquetas de asignación de costes. De esta manera, siempre tenemos visibilidad de nuestro gasto y una alerta preestablecida nos advierte si estamos excediendo el presupuesto previsto.
Ocasionalmente, nuestro sistema de sincronización de activos puede fallar al copiar algo que un renderizado necesita, por lo que creamos una estación de trabajo virtual usando un Instancia de Amazon EC2 G4dn (GPU) que se configura exactamente como una estación de trabajo local. Cada vez que necesitamos solucionar un render roto, nos conectamos a la estación de trabajo basada en la nube y activamos una escena como si la estuviéramos ejecutando en nuestro estudio para identificar rápidamente cualquier problema. Cuando se completa un renderizado en AWS, el fotograma o los datos terminados se sincronizan de nuevo en las instalaciones para que el artista pueda revisarlos. Para asegurarnos de que los renderizados tengan el resultado esperado, creamos una aplicación web que permite a los artistas obtener una vista previa de los fotogramas mientras renderizan. Aprovechamos todas las métricas que salen de Reloj en la nube de Amazon y utilice los paneles de Grafana para realizar un seguimiento de las métricas, el almacenamiento, el ancho de banda, los costos y cualquier otra cosa que podamos imaginar de Amazon EC2.
Ahora, más de tres años después de nuestro viaje en la nube, hemos visto cuán integral es el renderizado en AWS para nuestra estrategia de granja de renderizado. Hemos cambiado el enfoque de las compras de inversión o la contratación de equipos, y ahora estamos enfocados en la nube. En este punto, hemos automatizado la mayor parte de la administración de la infraestructura de AWS y dedicamos mucho menos tiempo a almacenar servidores, administrar actualizaciones de firmware y reemplazar hardware roto. Nuestro objetivo es seguir reduciendo el tiempo que se tarda en devolver un fotograma terminado a los artistas, de modo que podamos seguir elevando el listón en términos de calidad y tiempo de respuesta para los clientes.
Cómo Winnie-the-Pooh impulsó el método Melbourne's Journey to Cloud Rendering, se publicó en el Blog de medios de AWS el 20 de abril de 2021. Sobre el autor: Jon Stanley es Jefe de Sistemas en Method Studios en Melbourne, cargo que ocupa desde 2017. Con casi 20 años de experiencia en ingeniería de sistemas para estudios de postproducción y efectos visuales, también ha trabajado en Iloura, Lipsync Post y Framestore.
Más información
Desde la animación y la producción remota hasta la distribución, Qumulo para medios y entretenimiento
Escala ilimitada y programabilidad API, Cloud Q para AWS
Comunícate con nosotros
Haz una prueba de manejo. Haga una demostración de Qumulo en nuestros laboratorios prácticos interactivos.
Suscríbete al blog de Qumulo para historias de clientes, conocimientos técnicos, tendencias de la industria y noticias de productos.
