Renderizado de escenas de Maya con USD en una render farm

Universal Scene Description ha pasado de ser un formato interno de Pixar a convertirse en la columna vertebral de muchos pipelines de Maya. Si su estudio compone planos a partir de stages USD por capas, referencia activos publicados entre departamentos y entrega el resultado a un renderizador a través de un procedural, ya sabe que USD ya no es un experimento secundario: es el eje central de la escena. Lo que resulta menos evidente hasta que se acerca una fecha límite es que una escena que se renderiza perfectamente en una estación de trabajo no garantiza que se renderice en la render farm de otra persona. La render farm debe contar con la compilación correcta de MayaUSD, el soporte correcto de USD en el motor de renderizado y una forma de resolver cada ruta de activos a la que apunta el stage. Cuando falta alguno de estos elementos, no se obtiene un error claro: se obtienen fotogramas fallidos, retrocesos silenciosos o geometría que simplemente no está.

Gestionamos una render farm, y los trabajos de Maya con USD son uno de los flujos de trabajo que vemos que los estudios tienen más dificultades para mover fuera de sus estaciones de trabajo. Esta guía explica por qué USD es más difícil de renderizar de forma remota que un archivo .ma autocontenido, qué debe coincidir exactamente para que funcione y cómo lo gestionamos por nuestra parte, incluidas las partes que son fáciles de hacer mal.

Pipeline de renderizado Maya USD: stages USD por capas al plugin MayaUSD, al procedural Arnold USD, a los fotogramas renderizados, con resolución de activos y correspondencia de entornos.

Por qué USD es más difícil de renderizar de forma remota que una escena autocontenida

Una escena de Maya tradicional es en gran medida autodescriptiva: ábrala, las mallas y los materiales están ahí, apunte el renderizador hacia ella y los fotogramas salen. Una escena impulsada por USD se parece más a una receta que a un plato terminado. Los archivos .usd, .usda o .usdc son un conjunto de instrucciones por capas —sublayers, referencias, payloads y variantes— que se componen en un stage final en el momento de la carga. Esa composición es poderosa, pero significa que tres elementos distintos deben estar presentes y ser compatibles en la máquina que los renderiza.

El primero es el plugin MayaUSD en sí. MayaUSD es el puente que permite a Maya leer, componer y pasar stages USD al renderizador. Si la render farm no tiene MayaUSD cargado en Maya, o tiene una versión que compone el stage de forma diferente a la que utilizaron sus artistas para crearlo, la escena no se abre o se abre sin las partes que entraron a través de USD.

El segundo es la resolución de rutas de activos. Un stage USD hace referencia a otros archivos —geometría, texturas, capas USD anidadas— por ruta. En su estación de trabajo, esas rutas se resuelven porque los datos están donde el stage los espera. En una render farm, a menos que se reproduzcan la misma estructura de directorios y el mismo comportamiento del resolvedor, la mitad de esas referencias no se resuelven en nada. Esta es la razón más común por la que una escena USD que "funciona en casa" vuelve vacía desde una render farm: los píxeles se renderizaron bien, las referencias simplemente no se encontraron.

El tercero es el soporte USD del renderizador. El motor de renderizado debe entender los datos USD que Maya le entrega. Para Arnold, esa ruta pasa por el procedural Arnold USD, que lee el contenido USD en el momento del renderizado en lugar de expandir todo el stage en Maya primero. Si el procedural no está instalado, o su versión no coincide con los datos, el renderizador omite lo que no puede leer, en silencio.

Aquí es también donde aparece la brecha bien conocida en algunos servicios de renderizado en la nube. El propio rastreador de Deadline Cloud de AWS para Maya tiene un problema abierto (aws-deadline/deadline-cloud-for-maya#409) que cubre el soporte de MayaUSD en su submitter, que es exactamente el tipo de canalización que debe resolverse de extremo a extremo antes de que las escenas USD se rendericen de forma fiable. Es una ilustración justa del problema: el renderizado USD no es una función que se activa, es una cadena de versiones y rutas que deben coincidir.

Un stage USD por capas en el editor de capas USD de Maya —sublayers y referencias visibles— junto a la salida de Arnold RenderView.

Cómo renderizamos Maya + USD en nuestra render farm

Nuestro enfoque comienza antes de que se ponga en cola un solo fotograma: hacemos coincidir el entorno con su escena en lugar de pedir a su escena que se adapte a una imagen fija de la render farm. Cuando un estudio nos envía un trabajo de Maya basado en USD, confirmamos la versión de Maya, la compilación de MayaUSD, el renderizador y la versión de USD en la que se crearon los activos, y luego ponemos en marcha los nodos para que coincidan. El objetivo es que el stage se componga en nuestros nodos exactamente como se compone en las máquinas de sus artistas: mismo comportamiento del plugin, misma resolución, mismo procedural.

En cuanto al renderizado, los dos elementos que más importan para Maya USD con Arnold deben inicializarse correctamente: MayaUSD para componer el stage dentro de Maya, y el procedural Arnold USD para leer el contenido USD en el momento del renderizado. Hemos renderizado trabajos de producción de Maya en los que ambos se cargan y ejecutan correctamente en el conjunto de nodos, que es la prueba práctica que importa: no si la render farm "afirma tener soporte USD", sino si este stage, con estas referencias, produce los fotogramas que el artista espera. Arnold aquí se ejecuta en nuestros nodos de CPU, lo que se adapta a la forma en que muchos estudios utilizan Arnold para el trabajo USD de calidad final; las mismas escenas pueden ejecutarse en GPU cuando el proyecto lo requiere.

Un detalle que vale la pena mencionar, porque suele confundir a la gente: las escenas USD que han pasado por varios pipelines a menudo llevan referencias de plugins sobrantes y atributos de nodos residuales de renderizadores que el proyecto ya no utiliza. Vemos escenas que siguen solicitando un plugin que el estudio abandonó hace meses, o que llevan atributos de un motor que no está en la ruta de renderizado final. En nuestros nodos, esos residuos son inofensivos: Maya los carga sin problemas y renderiza con el motor que usted está usando realmente. Si desea registros limpios, puede eliminar las solicitudes de plugins desconocidos y los nodos sobrantes en Maya antes de enviar, pero es cosmético; no es lo que impide un renderizado. Saber la diferencia entre un "residuo inofensivo" y "lo que está fallando realmente" es la mayor parte de lo que hace que un renderizado USD transcurra sin problemas.

Una restricción honesta sobre el hardware, para establecer expectativas: nuestros nodos de GPU están construidos con tarjetas RTX 5090 con 32 GB de memoria por GPU, y esa memoria es por tarjeta: no se agrupa entre las dos tarjetas de una máquina. Para el trabajo de Arnold USD en CPU que la mayoría de los estudios nos trae, ese límite rara vez aparece, pero si usted está ejecutando una ruta de GPU en escenas con texturas muy grandes o volumetría pesada, vale la pena verificar la huella de memoria por GPU de antemano. Preferimos calificarlo con usted antes de un trabajo a que un fotograma no quepa a mitad de la ejecución.

Renderice desde su espacio de archivos existente, sin volver a cargar

El problema de resolución de activos descrito anteriormente tiene una solución limpia cuando un estudio ya mantiene su proyecto en un espacio de archivos montado. Si sus activos viven en LucidLink, podemos montar ese mismo espacio de archivos en los nodos de renderizado, de modo que el stage USD resuelva sus referencias contra los datos exactos que ven sus artistas: sin volver a cargar una biblioteca de activos de varios gigabytes y sin reconstruir la estructura de directorios a mano. El stage se compone contra las rutas reales porque las rutas reales están montadas.

Esto importa más para USD que para una escena de archivo único empaquetada precisamente porque USD se apoya en esas referencias externas. Montar la fuente de verdad elimina toda una clase de fallos de "referencia no encontrada", porque no hay nada que copiar incorrectamente: la render farm lee el mismo árbol que lee el estudio. Para los equipos que ya trabajan con LucidLink de forma nativa, esto suele ser la diferencia entre un ciclo complicado de carga y esperanza y un renderizado que simplemente se resuelve.

Un espacio de archivos LucidLink de un estudio montado en vivo en los nodos de renderizado, que leen los activos en su lugar, sin necesidad de volver a cargarlos.

Qué se incluye: licencias y DCC, no solo máquinas

Cuando alquila capacidad dedicada con nosotros, las licencias del motor de renderizado y las aplicaciones DCC vienen incluidas. Maya, el renderizador —Arnold, V-Ray, Redshift, Octane, Cycles— y los plugins de soporte forman parte de lo que aprovisionamos, en lugar de ser algo que usted trae y licencia por nodo por su cuenta. Para un trabajo USD, esto generalmente significa que la licencia de Arnold se gestiona por nuestra parte como parte de la ejecución, de modo que usted no tiene que obtener licencias de renderizado por separado para cada nodo del bloque.

Vale la pena tenerlo en cuenta frente a un enfoque de bare-metal o construcción propia, donde la tarifa por máquina puede parecer más baja hasta que se suman las licencias del motor de renderizado: esas pueden alcanzar desde varios cientos hasta más de mil dólares por nodo, por año, por motor en un host de tipo bring-your-own. Incluirlas es la parte del modelo que hace el trabajo silencioso: la escena que se renderiza es aquella en la que Maya, MayaUSD, el procedural y la licencia del motor están todos presentes a la vez, y aprovisionarlos juntos es la forma de mantener esa cadena intacta.

Una migración real: USD en Maya, fuera de un planificador en la nube que no podía ejecutarlo

Para ser más concretos: recientemente trabajamos con un estudio de efectos visuales del Reino Unido que acudió a nosotros porque su configuración existente con un planificador en la nube estaba fallando exactamente en este problema: Maya no podía trabajar con sus activos USD en ese entorno. Su pipeline era Maya con Arnold, en un espacio de archivos LucidLink. Montamos su espacio de archivos en los nodos, hicimos coincidir el entorno con su escena y confirmamos en los registros que MayaUSD y el procedural Arnold USD se inicializaron y renderizaron correctamente en todas las máquinas. La escena llevaba algunas referencias sobrantes de etapas anteriores de su vida; esas se cargaron sin problemas y los fotogramas salieron. El estudio pasó de "nuestros renders USD siguen fallando" a una ejecución limpia, y escaló desde allí. Mantenemos el anonimato del estudio, pero el flujo de trabajo —Maya, USD, Arnold, LucidLink— es cada vez más la norma que la excepción.

Lista de verificación previa al envío de un trabajo USD a cualquier render farm

Ya sea que renderice con nosotros o con cualquier otra render farm, estas son las cosas que vale la pena confirmar de antemano para que una escena USD no le dé sorpresas en la render farm:

La mayoría de los renderizados USD fallidos se remontan a una de las primeras tres filas. La razón por la que las revisamos antes de un trabajo y no después es que, con USD, la diferencia entre una ejecución limpia y un fotograma vacío suele ser una sola versión desajustada o una ruta no resuelta, y es mucho más económico detectar eso en un fotograma de prueba que en el fotograma 480 de una fecha límite.

Por esa razón exacta, la forma en que normalmente iniciamos un trabajo de Maya USD es con un fotograma representativo: ejecutamos uno antes del bloque completo para que el estudio pueda ver cómo se compone el stage y los fotogramas llegan a nuestros nodos, y confirmar el pipeline de extremo a extremo antes de cualquier compromiso mayor. Con USD, demostrar la cadena en un fotograma vale más que cualquier lista de funciones.

Si desea obtener una visión más amplia de cómo funciona el renderizado de Maya en una render farm más allá de USD específicamente, nuestra guía de renderizado en la nube de Maya cubre el flujo de trabajo general, y nuestra descripción general de cómo elegir una render farm para Maya explica cómo evaluar una. El alquiler de nodos dedicados en el que se ejecuta este trabajo USD se describe en nuestra página de alquiler de render farm. En cuanto al formato en sí, la documentación de OpenUSD de Pixar es la referencia canónica sobre cómo se componen los stages.

FAQ

Q: ¿Su render farm admite escenas de Maya que utilizan USD? A: Sí. Renderizamos trabajos de Maya que utilizan USD haciendo coincidir la compilación de MayaUSD y el soporte USD del renderizador con su escena. En ejecuciones de producción hemos confirmado en los registros que MayaUSD y el procedural Arnold USD se inicializan y renderizan correctamente en el conjunto de nodos. La clave es que la misma compilación de MayaUSD, la misma versión de USD y las mismas rutas de activos que utilizaron sus artistas se reproduzcan en el lado del renderizado.

Q: ¿Qué versiones de Maya y USD admiten? A: En lugar de fijarle a una imagen fija, hacemos coincidir la versión de Maya, la compilación de MayaUSD y la versión de USD en la que se crearon sus activos. La composición de USD es sensible a las diferencias de versión en la forma en que se resuelven capas, referencias y variantes, por lo que hacer coincidir el entorno de creación es lo que mantiene el stage componiéndose de la misma manera que en sus estaciones de trabajo.

Q: ¿Admiten el procedural Arnold USD? A: Sí. Para Maya más Arnold, el procedural Arnold USD es la ruta que lee el contenido USD en el momento del renderizado, y lo aprovisionamos junto con Arnold. Debe estar presente y ser compatible en versión con sus datos; de lo contrario, el renderizador omite lo que no puede leer. Confirmamos que se inicializa antes de ejecutar un bloque completo.

Q: ¿Necesito traer mi propia licencia de Arnold? A: No. Las licencias del motor de renderizado, incluido Arnold, forman parte de la capacidad dedicada que aprovisionamos: están incluidas en lugar de ser algo que usted licencia por nodo por su cuenta. En una configuración de bring-your-own-host, usted añadiría esas licencias sobre el costo de la máquina; incluirlas es parte de cómo mantenemos la cadena de renderizado intacta.

Q: ¿Pueden montar nuestro espacio de archivos LucidLink para que no tengamos que volver a cargar los activos? A: Sí. Si su proyecto vive en LucidLink, podemos montar ese espacio de archivos en los nodos de renderizado para que el stage USD resuelva sus referencias contra los datos exactos que ven sus artistas. Para USD específicamente, esto elimina un modo de fallo común, porque la render farm lee el mismo árbol de activos que usted, en lugar de una copia que podría tener una estructura diferente.

Q: Usamos un planificador en la nube que no puede ejecutar nuestras escenas de Maya USD. ¿Podemos migrar? A: Esa es una razón común por la que los estudios se mueven hacia nosotros. Hacemos coincidir el entorno con su escena, montamos su espacio de archivos si utiliza uno, y verificamos en un fotograma representativo que el stage USD se compone y renderiza antes de comprometerse con una ejecución completa. La migración consiste principalmente en reproducir su entorno de creación fielmente en el lado del renderizado.

Q: Nuestra escena tiene referencias sobrantes de un renderizador que ya no usamos. ¿Es eso un problema? A: Generalmente no. Las escenas USD que han pasado por varios pipelines a menudo llevan solicitudes de plugins residuales y atributos de nodos sobrantes. En nuestros nodos, Maya los carga sin problemas y renderiza con el motor que usted está usando realmente. Puede eliminarlos en Maya para obtener registros limpios, pero es cosmético: los residuos rara vez son lo que impide un renderizado.

Q: ¿Deberíamos renderizar Maya USD en CPU o GPU? A: Ambas opciones están disponibles, y la respuesta correcta depende de su renderizador y escena. Muchos estudios ejecutan Arnold para el trabajo USD de calidad final en CPU, para lo cual están diseñados nuestros nodos de CPU. La GPU está disponible cuando el proyecto lo requiere; solo tenga en cuenta que nuestras tarjetas de GPU tienen 32 GB de memoria cada una, sin agrupación, de modo que para escenas de GPU muy pesadas vale la pena verificar la huella de memoria por GPU de antemano.