Corrija errores de XGen y .tx en un render farm de Maya

Introducción

Una escena que se renderiza perfectamente en una estación de trabajo y vuelve mal desde una render farm es uno de los fallos más desconcertantes de un pipeline de Maya: nada en el log señala hacia «usted», y nada en el propio archivo de la escena está roto. Dos de los culpables más comunes son XGen y las cachés de texturas .tx. Ambos funcionan, por diseño, fuera del archivo de escena principal: XGen almacena los datos de groom y de description en carpetas de collection y archive independientes, y el plugin MtoA de Arnold puede generar silenciosamente su propia caché de texturas .tx en mosaico junto a sus texturas de origen. Ninguno de los dos problemas aparece al abrir el archivo .ma o .mb en local, porque en local esos archivos externos ya están donde Maya los espera.

Vemos este patrón con la frecuencia suficiente en trabajos de Maya freelance y de estudios pequeños como para que merezca la pena documentarlo correctamente: el pelo o la piel que «desaparece» al renderizar en una render farm, y la textura que lanza un error inexplicado de OpenImageIO a mitad de frame, casi nunca son fallos de software. Son problemas de recopilación de assets y de caché obsoleta, y ambos se pueden prevenir con un breve pase de preflight antes de enviar el trabajo.

Diagrama que muestra cómo los datos de groom y caché se resuelven correctamente en una estación de trabajo local, pero faltan en un nodo de una render farm, provocando que el pelo o la piel desaparezcan del render.

Por qué XGen falla en una render farm (incluso cuando la escena «parece» correcta)

XGen no almacena un groom ni una description como geometría integrada en el archivo .ma/.mb. Los almacena como una referencia: un archivo de paleta .xgen más, según cómo esté configurada la description, una carpeta collections (datos de groom por description) y una carpeta archives (datos de point-cache o Alembic ya generados, si la description está configurada para renderizar desde un archive en lugar de generarse en vivo). Al abrir la escena en local, Maya resuelve esas referencias contra rutas que ya existen en su equipo o en su recurso compartido de red local. Cuando esa misma escena llega a un nodo de una render farm, esas mismas rutas a menudo no existen: porque eran absolutas, porque apuntaban a un recurso compartido UNC al que el nodo de la render farm no tiene mapeo, o porque solo se subió el archivo .ma/.mb y la carpeta xgen/ que lo acompaña nunca hizo el viaje.

El resultado rara vez es un error grave. XGen normalmente no logra resolver la description de forma silenciosa, y el render termina, simplemente sin el pelo, la piel o las plumas que deberían haber estado ahí. Ese es el modo de fallo concreto que hace esto tan frustrante de depurar: todo lo demás en el frame se renderiza correctamente, las unidades se reportan como mapeadas, y la versión de Maya y XGen en la render farm coincide exactamente con la de la estación de trabajo; el groom simplemente ha desaparecido, porque los archivos que lo generan nunca llegaron.

Una segunda causa relacionada: incluso cuando la carpeta xgen/ se recopila correctamente, importa el ajuste de la description entre «generar en el momento del render» y «en caché/archivada». Si una description está configurada para tomar los datos de un archive y esa ruta del archive es relativa a una estructura de proyecto que el nodo de la render farm no comparte, la description no resuelve nada, en lugar de recurrir a un groom generado en vivo.

Panel genérico de estilo editor de description que resalta los campos de ruta de collection y archive, ilustrando dónde viven las referencias de los datos de groom de XGen fuera del archivo de escena principal.

Por qué los archivos de textura .tx fallan en una render farm

.tx es un formato de textura en mosaico con mipmaps, generado por la herramienta maketx de OpenImageIO. Arnold lee las texturas .tx más rápido y con un menor consumo de memoria que los formatos de origen sin procesar, motivo por el cual MtoA (el plugin de Arnold para Maya) ofrece la opción «Auto-Convert Textures to TX Files»: al guardar o al renderizar, genera silenciosamente una caché .tx junto a sus texturas de origen.

Ese comportamiento de conversión automática es cómodo en una única estación de trabajo con un solo disco local y una compilación de OpenImageIO coherente. Es un comportamiento mucho menos fiable en una render farm distribuida, por tres razones distintas:

Caché obsoleta. Si una textura de origen se edita después de generarse el archivo .tx, y la comprobación de marca de tiempo que normalmente activaría una reconversión no se dispara (o la ubicación con permisos de escritura que necesita el nodo de la render farm no es la misma en la que se generó), Arnold puede cargar un archivo .tx desactualizado sin ninguna advertencia de que está obsoleto.
Discrepancia de versión. Las versiones de maketx/OpenImageIO difieren entre las distintas versiones de Arnold y MtoA. Una caché .tx generada por una versión de OIIO puede producir errores de lectura (que normalmente aparecen como un error OIIO no especificado que aborta el frame) al ser leída por una versión distinta en el lado de la render farm.
Contención de escritura en rutas compartidas o de solo lectura. La conversión automática asume que puede escribir un archivo .tx junto a la textura de origen. En una render farm, esa ubicación puede ser de solo lectura, estar compartida entre varios trabajos simultáneos, o simplemente no ser la misma ruta física que usó la estación de trabajo, de modo que la conversión falla en silencio o dos nodos compiten por escribir el mismo archivo de caché.

Esto es lo bastante habitual como para que la documentación de render farms de todo el sector, no solo la nuestra, indique de forma sistemática a los usuarios de Maya/Arnold que desactiven «Auto-Convert Textures to TX Files» específicamente para evitarlo, en lugar de intentar corregir el propio comportamiento de conversión automática. El patrón más fiable es tomar una decisión deliberada: o bien preconvertir las texturas a .tx con una versión de maketx conocida y fijada, y enviar esos archivos .tx como parte de la recopilación de assets, o bien desactivar por completo la conversión automática, enviar las texturas de origen sin procesar y dejar que el renderizador de la render farm gestione la conversión de forma coherente por su cuenta.

Diagrama de pipeline que muestra una textura de origen convertida por maketx en una caché .tx, con una segunda rama que muestra una caché obsoleta o con discrepancia de versión que provoca un error de lectura de textura.

Lo que el Scene Archive de Maya no recopila por usted

El sistema integrado de archivado de escenas de Maya (Send To / archive project) está construido en torno al modelo de referencia estándar: texturas de archivo conectadas a través de los propios nodos file de Maya, y geometría que vive dentro del scene graph. XGen no encaja del todo en ese modelo, motivo por el cual sus datos son una de las piezas que más se olvidan en una recopilación de assets, por lo demás, «completa». Antes de enviar una escena con XGen a cualquier render farm, planifique empaquetar explícitamente:

El propio archivo de paleta .xgen
La carpeta xgen/collections/<description>/ de cada description referenciada en la escena
La carpeta xgen/archives/, si alguna description está configurada para renderizar desde un archive ya generado
Cualquier guide curve externa, mapa de densidad o mapa de longitud que un modificador de XGen referencie fuera de los nodos de textura file estándar de Maya; estos a veces evitan las herramientas de archivado que sí detectan las texturas normales
La versión exacta de Maya y de MtoA (Arnold para Maya) en la que se construyó la escena, para que la render farm cargue la description con una compilación de plugin equivalente, en lugar de una parecida pero distinta

Nada de esto requiere software especial: requiere tratar los datos de XGen como una parte de primer nivel de la recopilación de assets, en lugar de un efecto secundario implícito de guardar la escena.

Lista de preflight de Maya + Arnold para trabajos de XGen y .tx

Paso	Qué comprobar	Por qué importa
1. Coincidencia de versiones	Confirme que el rango de versiones de Maya y Arnold/MtoA compatible con la render farm cubre la versión exacta de su escena	Una discrepancia de versión puede romper la compatibilidad de la description de XGen incluso cuando las rutas de archivo son correctas
2. Recopilar las carpetas de XGen	Empaquete explícitamente `xgen/collections/`, `xgen/archives/` y el archivo `.xgen`; no confíe únicamente en una herramienta genérica de archivado de escenas	Son los archivos que más habitualmente se quedan atrás, provocando que el pelo o la piel desaparezcan en silencio
3. Comprobar el ajuste generar-o-archivar	Confirme si cada description se genera en vivo o se lee desde un archive ya generado, y que la ruta del archive viaje junto con el trabajo	Una ruta de archive que no se resuelve no renderiza nada, y sin ningún error
4. Elegir una única estrategia de texturas	Desactive «Auto-Convert Textures to TX Files» y envíe las texturas sin procesar, o bien preconvierta con una versión fijada de `maketx` e incluya los archivos `.tx`	Dejar activada la conversión automática asume acceso de escritura en el lado de la render farm y una versión de OIIO coincidente, suposiciones que no siempre se cumplen
5. Reescribir las rutas UNC y de letra de unidad	Sustituya cualquier ruta `\\server\share\...` o de letra de unidad local en los nodos de XGen y de texturas por rutas relativas accesibles desde la render farm	Las rutas que se resuelven en local con frecuencia no existen en un nodo de render
6. Ejecutar una prueba de un frame	Envíe un único frame de prueba antes de la secuencia completa, y revise el render log específicamente en busca de advertencias de carga de texturas y de resolución de XGen, no solo la finalización del render	Detecta pelo ausente, texturas ausentes y errores de OIIO antes de que cuesten una secuencia completa
7. Decidir entre CPU y GPU para el plano	Para grooms intensivos en XGen, cobertura densa de pelo o piel y redes de shading personalizadas, planifique usar la ruta de render CPU de Arnold para los frames finales: las escenas con procedurales pesados y shaders personalizados son el tipo de trabajo para el que la propia documentación de Arnold recomienda CPU en la salida final	Tomar la decisión de enrutamiento CPU/GPU antes del envío evita descubrir una limitación de dispositivo a mitad del render

Problemas comunes y soluciones

Síntoma	Causa probable	Solución
Falta el pelo o la piel en el render de la render farm, pero está presente en local	No se recopiló la carpeta `collections`/`archives` de XGen, o la ruta no es accesible desde la render farm	Empaquete explícitamente las carpetas de XGen y reescriba cualquier referencia UNC o de letra de unidad
El render se aborta con un error OpenImageIO no especificado a mitad de frame	Caché `.tx` obsoleta o con discrepancia de versión	Regenere el `.tx` con una versión fijada de `maketx`, o desactive la conversión automática y envíe las texturas sin procesar
La textura o el bitmap no se resuelven en el nodo de render (también se observa en pipelines de Arnold en 3ds Max, una clase de fallo relacionada pero distinta; consulte nuestra guía de bitmaps ausentes de Arnold en 3ds Max)	La ruta de la textura no se puede resolver desde el nodo de render	Confirme rutas relativas y accesibles desde la render farm antes del envío
El trabajo se renderiza correctamente al reenviarlo, pero falló la primera vez	La conversión automática escribió la caché `.tx` a mitad del render en el primer pase; el segundo pase leyó la caché ya completa	Preconvierta los archivos `.tx` antes del envío, o desactive por completo la conversión automática
Errores del plugin de Arnold o MtoA al cargar	La versión de MtoA en la render farm no coincide con la versión en la que se creó la escena	Confirme el rango de versiones de Maya/Arnold objetivo antes del envío

Simulación de consola de render log que muestra un error de lectura de textura de nivel de advertencia, ilustrando el tipo de mensaje que produce una caché .tx obsoleta o con discrepancia de versión en un nodo de render.

Lista de verificación resumen

Versiones de Maya y Arnold/MtoA confirmadas contra el rango compatible de la render farm
xgen/collections/ y xgen/archives/ incluidas explícitamente en la recopilación de assets
Ajuste generar-o-archivar de cada description de XGen comprobado, y su ruta verificada como accesible desde la render farm
Una única estrategia de texturas elegida: .tx preconvertido (versión fijada de maketx) o texturas sin procesar con la conversión automática desactivada, no ambas
Todas las rutas UNC y de letra de unidad sustituidas por rutas relativas accesibles desde la render farm
Un frame de prueba enviado y su render log revisado en busca de advertencias de XGen y de texturas antes de la secuencia completa
Ruta de render CPU frente a GPU decidida para planos intensivos en XGen o con shaders personalizados

En nuestra render farm, las versiones recientes de Maya (2022 y posteriores) superan la coincidencia de versiones automáticamente en el envío; las versiones anteriores dentro del rango compatible 2014-2027 se dirigen a través de una comprobación de aprovisionamiento y compatibilidad antes de que empiece el render, de modo que una discrepancia se detecta antes de quemar frames, en lugar de a mitad del trabajo. Los elementos de rutas, caché y ajustes de archive siguen siendo específicos de cada escena, y merece la pena comprobarlos independientemente de a qué render farm se envíe un trabajo.

Para la configuración general de render en la nube de Maya más allá de XGen y las texturas específicamente, consulte nuestra guía de render en la nube de Maya y nuestra guía completa del renderizador Arnold. Para conocer los rangos de compatibilidad de software detrás de la coincidencia de versiones de la render farm, consulte nuestras páginas de render farm de Maya y de render farm de Arnold. En el lado de las texturas, la propia documentación de maketx de OpenImageIO es la referencia técnica más clara sobre lo que realmente hace la conversión .tx y qué flags controlan el comportamiento de mipmap y tiling.

FAQ

Q: ¿Por qué desaparece el pelo o la piel de XGen al renderizar en una render farm en la nube, pero funciona bien en local? A: Normalmente significa que las carpetas collections y archives de XGen no se recopilaron junto con el resto de la escena. XGen lee los datos de groom y de description de estos archivos externos en el momento del render; si solo se sube el archivo .ma o .mb, el nodo de render no tiene nada a partir de lo cual generar el pelo o la piel, y renderiza «calvo» en lugar de lanzar un error evidente.

Q: ¿Qué es un archivo .tx y por qué lo necesita Arnold? A: Un archivo .tx es una textura en mosaico con mipmaps creada por la herramienta maketx de OpenImageIO. Arnold y MtoA usan texturas .tx en lugar de los formatos de origen sin procesar porque los mipmaps en mosaico se cargan más rápido y usan menos memoria durante el render, algo que importa más a escala de render farm que en una única estación de trabajo.

Q: ¿Debo dejar activada la opción «Auto-Convert Textures to TX Files» al enviar a una render farm? A: Dejarla activada es una fuente habitual de errores de textura en el lado de la render farm. Funciona bien en una única estación de trabajo con un solo disco, pero en una render farm distribuida puede producir una caché .tx obsoleta o con discrepancia de versión, o toparse con una diferencia de permisos de escritura en el nodo de render. Preconvertir con una versión de maketx conocida y enviar los archivos .tx, o bien desactivar la conversión automática y enviar las texturas sin procesar, evita ambos modos de fallo.

Q: Mis versiones de Maya y Arnold ya coinciden con las de la render farm: ¿por qué al render le siguen faltando texturas? A: La coincidencia de versiones evita fallos a nivel de plugin, pero la mayoría de los errores de XGen y .tx en las render farms provienen de las rutas de archivo, no de las versiones. Si XGen hace referencia a una ruta UNC o a una letra de unidad local que no existe en el nodo de render, o si la caché .tx se generó contra una ubicación de textura a la que la render farm no puede acceder, el render falla incluso con versiones de software coincidentes.

Q: ¿Cómo sé qué versiones de Maya y Arnold son compatibles con una render farm? A: Compruebe el rango de versiones de Maya y Arnold/MtoA compatible con la render farm antes de enviar el trabajo; hacer coincidir las versiones elimina toda una clase de errores de render. Nuestra render farm es compatible con Maya 2014-2027: las versiones 2022 y posteriores superan la coincidencia de versiones automáticamente en el envío, y las versiones anteriores se dirigen a través de una comprobación de compatibilidad antes del render.

Q: ¿Los planos con XGen deben renderizarse en la ruta CPU o GPU de Arnold? A: Los planos intensivos en XGen, con cobertura densa de pelo o piel y redes de shading personalizadas, pertenecen a la ruta CPU de Arnold para la salida final; ese es el tipo de trabajo para el que la propia documentación de Arnold recomienda CPU. Sea cual sea la ruta que use un plano, tome la decisión de dispositivo en el momento del envío como parte del preflight, en lugar de descubrir una limitación a mitad del render.

Q: ¿Qué debo comprobar antes de enviar una escena de Maya con XGen a una render farm? A: Ejecute un breve preflight: confirme la coincidencia de versiones de Maya/MtoA, empaquete explícitamente las carpetas xgen/collections y xgen/archives, elija una única estrategia de texturas (.tx preconvertido o sin procesar con la conversión automática desactivada), reescriba cualquier referencia UNC o de unidad local, y envíe una prueba de un frame antes de la secuencia completa.

Q: ¿Es este un problema exclusivo de XGen, o también aparece con otros DCC? A: El mismo patrón subyacente (datos que viven fuera del archivo de escena principal, más datos de textura en caché que se quedan obsoletos) también aparece en otros sitios. Los usuarios de 3ds Max se topan con un problema relacionado pero distinto, con nodos de bitmap ausentes en Arnold cuando las rutas de textura no se resuelven en el nodo de render; consulte nuestra guía de bitmaps ausentes de Arnold en 3ds Max para esa versión del problema.