Configurar Houdini para el renderizado en la nube

Houdini en nuestra render farm es un entorno con múltiples motores de renderizado construido en torno al pipeline moderno centrado en USD. Karma XPU es el camino recomendado por SideFX para proyectos nuevos en Houdini 20.5 y es el renderer principal en nuestra página de destino de . Karma CPU y Mantra siguen disponibles para trabajo heredado; los renderers de terceros — Redshift, Arnold, V-Ray for Houdini, Octane — son compatibles para estudios con pipelines establecidos en esos motores. Esta página cubre el empaquetado de proyectos (que en Houdini implica HDAs y cachés de simulación, no solo texturas), el flujo de trabajo de assets USD/Solaris, notas por renderer, el flujo de envío y la resolución de problemas específicos de Houdini que vemos con mayor frecuencia en los tickets de soporte.

Una nota sobre las licencias antes de comenzar: operamos las instalaciones de Houdini en la render farm bajo uso de renderizado exclusivo, que permite ejecutar Houdini en los workers de renderizado para el renderizado offline de proyectos de clientes. Super Renders Farm no es socio de SideFX — el uso de renderizado exclusivo es el marco legal que permite el renderizado en render farm de escenas de Houdini sin ocupar un puesto de SideFX del pool de licencias de su estudio. No nos transfiere su licencia de Houdini, y los metadatos del nivel de proyecto del lado del artista (Indie, Core, FX) no determinan el acuerdo de licencia del worker. El worker utiliza la licencia de la render farm en su extremo.

Para posicionamiento de alto nivel — versiones de Houdini compatibles, configuración de hardware, ejemplos de precios — la página de destino dedicada en es la referencia canónica. La página que está leyendo es el documento de flujo de trabajo: qué hacer en Houdini antes de hacer clic en Submit Job.

Versiones compatibles

Houdini 19.5, 20.0 y 20.5 están preinstalados en cada worker de la render farm. Rastreamos el calendario de lanzamientos de SideFX y aprovisionamos nuevas compilaciones principales en un plazo de cuatro semanas a partir de la disponibilidad pública. Los lanzamientos de punto (por ejemplo, Houdini 20.5.410 vs. 20.5.487) se rastrean de forma continua; si su proyecto está vinculado a un número de compilación específico debido a un problema de compatibilidad de nodos, indique la compilación en las notas del trabajo al enviar y asignaremos el worker correspondiente.

Tanto los archivos de escena de Houdini FX (el nivel de producción) como los de Houdini Indie (.hip y .hipnc) se cargan en el worker y se renderizan bajo el acuerdo de uso de renderizado exclusivo de la render farm. El nivel del lado del artista (Indie vs. Core/FX) no se propaga al puesto de licencia del worker — el worker utiliza el nivel que la render farm aprovisiona para el renderizado. Los archivos de Houdini Apprentice se renderizan pero producen resultados con marca de agua según los términos de licencia no comercial de SideFX; para trabajo de producción remunerado, guarde la escena desde una licencia que no sea Apprentice antes de enviarla. Las licencias educativas siguen la misma regla.

Una nota sobre el ritmo de lanzamientos de Houdini: SideFX lanza versiones principales cada 12–18 meses y actualizaciones de punto con mayor frecuencia. Karma XPU en particular ha mejorado sustancialmente entre 19.5, 20.0 y 20.5 — funciones que eran de reserva de CPU en 19.5 (volúmenes pesados, ciertas redes de shaders) son nativas de XPU en 20.5. Si su proyecto depende de una función de Karma XPU que se lanzó en una compilación específica, bloquee la compilación en las notas del trabajo en lugar de dejar que el worker elija la última disponible.

Empaquetado del proyecto de Houdini

Un proyecto de Houdini es más que el archivo de escena .hip (o .hipnc). Normalmente también incluye: HDAs (Houdini Digital Assets — .hda o el formato anterior .otl), archivos de caché de simulación (.bgeo, .bgeo.sc, .vdb, .abc), capas y referencias de assets USD (.usd, .usda, .usdc), mapas de texturas y cualquier geometría externa importada desde SOPs de archivo o Alembic. El renderizado en la nube tiene éxito cuando cada dependencia que referencia la escena está presente en el worker; falla cuando algo se resuelve localmente a través de una ruta exclusiva de la estación de trabajo pero no tiene dónde resolverse en la render farm.

Las convenciones de rutas de Houdini se basan en variables de entorno — más comúnmente $HIP (resuelve al directorio que contiene el archivo .hip), $HIPNAME (el nombre base del archivo de escena) y $JOB (la raíz del proyecto, establecida mediante variable de entorno). Para el renderizado en la nube, la convención confiable es rutas relativas a $HIP en todas partes. Los pasos de empaquetado a continuación aplican esa convención de extremo a extremo:

Establezca la carpeta del proyecto. Cuando guarda un nuevo proyecto, Houdini establece $HIP en el directorio que contiene el archivo .hip. Verifique en el shell de Python con hou.text.expandString('$HIP') — la ruta debe coincidir con donde vive su archivo de escena.
Use la estructura de subcarpetas estándar. $HIP/cache/ para simulaciones, $HIP/geo/ para Alembic y geometría externa, $HIP/tex/ para texturas, $HIP/hda/ para assets digitales, $HIP/usd/ para capas y referencias USD, $HIP/render/ para la salida. Todas las rutas en los SOPs de archivo, COPs de archivo, salidas de ROP y referencias de texturas de su escena deben usar $HIP/... en lugar de rutas absolutas con letra de unidad.
Verifique que las rutas se resuelvan. File → Refresh All. Houdini informa cualquier referencia de archivo sin resolver en la consola. Desde el shell de Python, hou.fileReferences() devuelve la lista completa de referencias externas — busque cualquiera que comience con D:\, Y:\, un recurso compartido UNC como \\server\, o cualquier ruta que el worker no pueda alcanzar.
Hornee las simulaciones al disco. La render farm no ejecuta simulaciones como parte del trabajo de renderizado — las simulaciones son trabajo de la estación de trabajo, y la render farm renderiza contra archivos de caché pre-horneados. Hornee todas las redes DOP (fluidos FLIP, Pyro, tela Vellum, RBD Bullet, granos), solucionadores de partículas y cualquier otra salida de simulación a archivos .bgeo.sc o .vdb en $HIP/cache/ antes de enviar. El SOP de caché de archivos con "Save to Disk" es el flujo de trabajo estándar.
Incruste o incluya HDAs. Si su escena usa HDAs personalizados de una biblioteca de estudio, incrústelos en el .hip (menú Asset → Save Operator Type → "Embedded") o incluya los archivos .hda/.otl en $HIP/hda/ para que el worker pueda cargarlos desde la carpeta del proyecto. Las bibliotecas HDA compartidas del estudio en unidades de red no son accesibles desde el worker.
Aplane o agrupe las capas USD. Si su escena usa Solaris/LOPs, hornee el stage USD a un único archivo USD compuesto a través del ROP USD antes de enviar, o incluya todo el árbol de directorios $HIP/usd/ para que cada capa se resuelva en el worker. Las reglas de resolución de assets USD se tratan en detalle en la siguiente sección.
Archive toda la carpeta $HIP. Use .tar, .tar.gz o .7z. No aceptamos archivos .zip para proyectos de Houdini (las convenciones de nombres de archivo de Houdini a veces contienen caracteres que se corrompen dentro de archivos .zip de Windows en workers Linux).

Un problema común específico de Houdini: los campos "Pre-Render Script" y "Post-Render Script" en los nodos ROP a veces hacen referencia a scripts de Python específicos de la estación de trabajo — las herramientas de pipeline de su estudio, una ruta de configuración local de Houdini, una llamada hou.ui.displayMessage que abre un diálogo para el que el worker no tiene pantalla. El renderizado en la nube falla silenciosamente o se queda esperando una entrada que nunca llegará. Audite cualquier devolución de llamada Python o HScript de pre-renderizado antes de enviar; deshabilite o haga portátil cualquier código que acceda a rutas exclusivas locales, llamadas a la UI o salidas de shell de hou.system() a binarios de la estación de trabajo. Prefiera el registro con print() en lugar de devoluciones de llamada interactivas.

Solaris, capas USD y resolución de assets

Si su escena está creada en Solaris (la red LOPs de /stage), la capa de resolución de assets USD añade una dimensión adicional al envío en la nube que no está presente en las escenas de solo OBJ/SOP. El resolvedor USD de Houdini sigue las reglas estándar de resolución de assets USD: las referencias en una capa se resuelven contra la ruta identificadora de la capa, las rutas de búsqueda configuradas mediante houdini.env o el plugin del resolvedor de assets, y cualquier arco de composición que use el stage (referencias, subcapas, cargas útiles).

Para el envío en la nube, dos patrones funcionan de forma confiable:

Aplane el stage. Use el nodo ROP USD con "Save to Disk" y la opción "Flatten Stage" habilitada. El resultado es un único archivo .usd compuesto (o .usdc para binario) que contiene todo el stage con todas las referencias resueltas. Este es el patrón más simple — el worker lee un archivo, sin indirección del resolvedor — pero pierde la estructura en capas que hace valioso a USD para la colaboración.
Agrupe el árbol de assets completo. Coloque todas las capas USD bajo $HIP/usd/ y use referencias relativas a $HIP en sus subcapas, referencias y cargas útiles. El worker resuelve $HIP a la raíz de carga, por lo que los archivos de capa en la misma posición relativa se cargan correctamente.

Una sutileza: el LOP de "Asset Reference" de Solaris y el SOP de referencia en contextos de /obj serializan la ruta de referencia tal como está escrita. Si escribió D:\studio_assets\char_robot.usd en un LOP de referencia, el worker no tiene D:\ y la referencia falla. Reescriba la referencia como $HIP/usd/char_robot.usd (o ${SRF_ASSETS}/char_robot.usd con un mapeo de variable de entorno documentado que la render farm respete). Cuanto más simple sea la ruta, más confiablemente viajará.

Una segunda sutileza: las bibliotecas de assets USD pueden llevar su propia indirección de versiones. Un stage de Solaris que referencia assets USD compilados contra USD 23.x puede no cargarse correctamente en un worker con USD 22.x incluido en una compilación más antigua de Houdini. La matriz de versiones de Houdini-y-USD es importante — si su biblioteca de assets se creó para la versión USD de Houdini 20.5, renderice en workers de Houdini 20.5.

Gestión de HDAs

Los Houdini Digital Assets (HDAs, a veces todavía con la extensión anterior .otl) son redes de nodos reutilizables empaquetados como archivos de assets independientes. Son comunes en los pipelines de producción, particularmente para assets procedurales — edificios, vegetación, sistemas de multitud, solucionadores personalizados — que se crean por separado de los planos individuales y se comparten entre escenas.

Tres patrones para el manejo de HDAs en la render farm:

Incruste el HDA en el archivo .hip. Menú Asset → Operator Type Manager → clic derecho en el HDA → "Save to Embedded." El HDA ahora se almacena dentro del .hip y viaja con la escena. Este es el patrón más seguro para trabajos individuales o para HDAs que crea específicamente para un plano determinado.
Agrupe HDAs en $HIP/hda/. Coloque todos los archivos .hda/.otl en una subcarpeta de su proyecto, luego en Houdini → Edit → Preferences → File Locations, asegúrese de que $HIP/hda/ sea parte de la ruta de búsqueda de OTL (o bien, establezca HOUDINI_OTLSCAN_PATH para incluir $HIP/hda/ en su houdini.env). El worker lee HDAs desde esta ubicación al cargar la escena.
Haga referencia a HDAs desde una biblioteca compartida del estudio. Si su estudio usa una biblioteca HDA compartida en una unidad de red (por ejemplo, \\studio-fs\houdini\hda\), esa biblioteca no es accesible desde el worker. Copie los HDAs relevantes en $HIP/hda/ antes de enviar, o incrústelos en el .hip.

Antes de enviar, liste los HDAs cargados en la escena desde el shell de Python:

text

for hda in hou.hda.loadedFiles():
    print(hda)

Cada ruta en la salida debe resolverse bajo $HIP o ser un HDA de SideFX enviado con Houdini (esos están preinstalados en cada worker). Cualquier HDA de terceros que viva fuera de $HIP no se encontrará.

Gestión de archivos de caché

Los archivos de caché son típicamente la categoría individual más grande en una carga de proyecto de Houdini — simulaciones FLIP, cachés de Pyro, horneos de tela Vellum, exportaciones Alembic y volúmenes VDB pueden alcanzar decenas o cientos de gigabytes cada uno. Dos patrones reducen el tiempo de carga sin comprometer el renderizado:

Comprima los cachés en el momento del horneado. .bgeo.sc (bgeo comprimido, compresión blosc) es significativamente más pequeño que .bgeo para la misma geometría y es el predeterminado moderno para los SOPs de caché de archivos. Para archivos VDB, el volumen ya está comprimido dentro del contenedor OpenVDB, pero los archivos .tar.gz comprimen bien los metadatos del directorio circundante.
Use $HIP/cache/ de forma consistente. El SOP de caché de archivos de Houdini predetermina a $HIP/cache/{node_name}/$F4.bgeo.sc, que es el patrón correcto para escenas portátiles en la render farm. Evite rutas de caché absolutas como D:\sim_cache\ — el worker no tiene D:\ y el renderizado comenzará, registrará advertencias de "no se puede encontrar el archivo de caché" y producirá geometría vacía donde debería estar la simulación.

Para simulaciones muy grandes — cachés FLIP o Pyro de varios terabytes que superan una carga del navegador — use SFTP en lugar del formulario de carga web. El documento de cubre el flujo de trabajo de SFTP, la reanudabilidad de archivos y los umbrales prácticos para cambiar de la carga web a SFTP.

Qué verificar antes del envío

Una lista de verificación previa al vuelo breve para cualquier envío de Houdini:

El nodo ROP activo está configurado correctamente. Contexto de salida → Render. El ROP que seleccione en el momento del envío determina qué renderer invoca el worker. Los ROPs incompatibles (por ejemplo, seleccionar un ROP de Karma para una escena cuya iluminación fue creada para Mantra) son la causa más común de los tickets de "el renderizado se ve completamente diferente".
El rango de fotogramas coincide con la configuración del ROP. El rango de fotogramas almacenado en el ROP (parámetros f1, f2, f3) es lo que usa el worker, no el rango de reproducción de la línea de tiempo ni el fotograma actual del viewport. Confirme que el rango de fotogramas del ROP sea el que pretende renderizar.
La ruta de salida usa tokens relativos a $HIP. $HIP/render/$F4.exr es el predeterminado seguro para EXR multicapa con relleno de cuatro dígitos. Evite rutas absolutas con letra de unidad en la expresión de salida del ROP.
Todos los SOPs de archivo y referencias de texturas se resuelven. File → Refresh All. Corrija cualquier error de "Unable to read" en la consola antes de enviar — el worker también los reportará, pero al costo de un fotograma de renderizado desperdiciado.
Los HDAs están incrustados o en $HIP/hda/. Verifique cerrando completamente la escena y reabiéndola desde una sesión diferente de Houdini; si los HDAs no se cargan localmente, el worker tampoco podrá cargarlos.
Los cachés están horneados. Ejecute un horneado manual de caché en cada SOP de caché de archivos a través de Render → Save to Disk antes de enviar. No confíe en "Auto-Bake on Frame Change" — hornee explícitamente y confirme que los archivos de caché existen en las rutas $HIP/cache/... esperadas.
Las capas USD (si es Solaris) están agrupadas o aplanadas. Ya sea que incluya el árbol $HIP/usd/ completo o escriba un USD compuesto aplanado a través del ROP USD.
Sin scripts interactivos de pre-renderizado o post-renderizado. Audite las devoluciones de llamada Python de ROP y los pre-frame scripts para detectar llamadas a la UI, salidas de shell o rutas específicas de la estación de trabajo.

Notas específicas por renderer

Karma XPU (recomendado)

Karma XPU es el renderer híbrido CPU+GPU de SideFX, promovido a estado listo para producción en Houdini 20.5 y el camino predeterminado para nuevos proyectos de Houdini. Es el renderer principal en nuestra página de destino de Houdini y el camino que la mayoría de los nuevos clientes en la render farm adoptan.

Notas de configuración:

Nivel de worker: Se ejecuta en nuestro nivel de workers GPU RTX 5090 (32 GB VRAM por tarjeta) para la parte GPU del renderizado, con reserva de CPU para cualquier función que la ruta de código XPU aún no soporte.
Restricciones de VRAM: 32 GB VRAM por worker. Karma XPU es más eficiente en VRAM que los renderers puramente GPU porque puede descargar partes del renderizado (los volúmenes en particular) a la memoria de CPU cuando la VRAM está restringida — pero las escenas USD muy densas con volúmenes de alta resolución todavía se benefician de mantenerse dentro del límite de 32 GB.
Integración del pipeline USD. Karma es el renderer diseñado para el pipeline USD basado en Solaris. Si su proyecto usa /stage (contexto LOPs de Solaris), Karma es la elección natural de renderer y el worker resuelve las referencias de assets USD de la misma manera que resuelve las referencias de SOPs de archivo — las rutas relativas a $HIP ganan.
AOVs. Configurados por producto de renderizado en el prim de Render Settings en el stage USD. El EXR multicanal es el formato de salida predeterminado y es lo que recomendamos para los pipelines de efectos visuales (preserva todos los AOVs en un solo archivo por fotograma).
Muestreo. Las muestras de trazado de rayos de Karma se configuran por prim de Render Settings. Calibre localmente en un solo fotograma antes de enviar una secuencia — la convergencia de muestras de XPU es diferente de la CPU, y la calibración se traslada directamente al worker.
Desenfoque de movimiento. Karma XPU admite desenfoque de movimiento de geometría y desenfoque de ventana de obturador. Confirme que la configuración del obturador de desenfoque de movimiento en el prim de la cámara USD coincide con lo que espera el prim de Render Settings — el manejo del obturador de Solaris y el muestreo de desenfoque de movimiento de Karma no siempre coinciden en los principios básicos, y el síntoma es "el renderizado se ve bien pero falta el desenfoque de movimiento o está duplicado".

Karma CPU

Karma CPU es la variante puramente de CPU de Karma. Completo en funciones y estable desde Houdini 19; la reserva natural para escenas que superan la VRAM de GPU o dependen de funciones aún no implementadas en la ruta de código XPU.

Notas de configuración:

Nivel de worker: Nivel de worker CPU (nodos Intel Xeon E5-2699 V4 dual, 96–256 GB RAM por nodo, más de 20,000 núcleos CPU agregados en toda la flota).
Cuándo usarlo en lugar de Karma XPU: geometría muy pesada (>50M polígonos), renderizado volumétrico denso que supera los 32 GB de VRAM, shaders OSL personalizados que aún no tienen un equivalente XPU, o proyectos que mezclan pasadas de simulación con uso intensivo de CPU en el mismo envío.
La misma integración Solaris/USD que Karma XPU. La configuración del producto de renderizado y AOV es idéntica; solo difiere el backend de cómputo.

Mantra (heredado)

Mantra es el renderer anterior a Karma de Houdini — el motor de micropolígonos de SideFX que precede al pipeline centrado en USD. SideFX ha indicado que Mantra no es el camino a seguir; Karma lo es. Mantra permanece en la compilación de Houdini para compatibilidad con versiones anteriores de proyectos creados antes de que Karma fuera viable.

Notas de configuración:

Nivel de worker: Nivel de worker CPU.
Rendimiento. Mantra es generalmente más lento por fotograma que Karma CPU para escenas equivalentes y carece de la ruta de aceleración GPU que proporciona Karma XPU. Los nuevos proyectos deben usar Karma.
Cuándo usarlo. Cuando su archivo de proyecto está vinculado a Mantra (una producción de larga duración que comenzó antes de que Karma fuera viable, una biblioteca de shaders que no ha sido portada), o cuando necesita una función específica de Mantra (algunos casos extremos de micropolígonos de Mantra aún no tienen un equivalente exacto en Karma). Para trabajo nuevo en 2026, use Karma como predeterminado.

Redshift para Houdini

Redshift para Houdini se ejecuta en nuestro nivel de workers GPU RTX 5090. Redshift es la elección para estudios con pipelines de Redshift establecidos — a menudo estudios de Maya o Cinema 4D que se ramifican hacia Houdini para FX y desean compartir bibliotecas de shaders entre DCCs.

Notas de configuración:

Marco de licencias. Redshift en nuestra render farm se ejecuta bajo nuestra licencia de . Redshift es ahora un producto de Maxon, y nuestra asociación con Maxon cubre Redshift en todos los DCCs que soportamos (C4D, Houdini, Maya).
Memoria fuera del núcleo. Habilitada de forma predeterminada. Extiende la memoria de escena efectiva más allá del límite de 32 GB de VRAM por worker, importante para escenas densas que de otro modo causarían OOM en la GPU.
Características específicas de Houdini. Redshift se integra directamente con los tipos de primitivas de volumen de Houdini (VDB, cachés Pyro) — no se necesita ningún paso de exportación especial para el renderizado de volúmenes. El ROP de Redshift expone parámetros nativos de Houdini para sesgo de rayos, muestreo y configuración de AOV.
Vinculación de versiones. Redshift lanza en su propio ciclo 3.x, independiente del cadencia de lanzamiento de Houdini. Las versiones principales de Redshift (3.0 → 3.5 → 4.0 cuando se lance) no garantizan compatibilidad con versiones anteriores — una escena guardada con Redshift 3.5.18 puede no cargarse correctamente en un worker con Redshift 3.0.x. Anote la compilación de Redshift en el momento de guardar la escena y confirme la compatibilidad del worker antes de enviar una secuencia completa.

Arnold para Houdini

Arnold para Houdini (a veces llamado HtoA, actualmente en el ciclo de lanzamiento Arnold 7.x) se ejecuta en nuestro nivel de workers CPU. Es la elección para estudios con pipelines Arnold compartidos de Maya/Houdini, donde el lookdev se crea en un DCC y los FX en el otro, pero la capa de shaders y renderizado está unificada.

Notas de configuración:

Marco de licencias. Arnold en nuestra render farm se ejecuta bajo licencias de nodo de renderizado de Autodesk.
AOVs. El sistema de AOV de Arnold en Houdini funciona igual que en Maya. Configúrelos por ROP y escriba en EXR multicanal o en archivos por AOV; el patrón entre DCCs es consistente.
Vinculación de versiones. Las versiones de HtoA rastrean el cadencia de lanzamiento de Arnold (HtoA 6.x para Houdini 19.5/20.0; HtoA 7.x para Houdini 20.5/21.0 cuando se lance). Los saltos principales de HtoA (6 → 7) nunca deben asumir compatibilidad — confirme que el worker tiene al menos la versión menor con la que se guardó su escena.

V-Ray para Houdini

V-Ray para Houdini se ejecuta en nuestro nivel de workers CPU. La adopción en Houdini es notablemente menor que en 3ds Max o Maya, pero la integración es compatible para estudios con pipelines centrados en V-Ray.

Notas de configuración:

Marco de licencias. V-Ray en nuestra render farm se ejecuta bajo nuestra licencia de .
Assets VRayProxy. Compatibles. Incluya archivos .vrmesh en $HIP/geo/ para que el worker pueda resolverlos.
Especificaciones de Houdini. El ROP de V-Ray para Houdini expone los mismos parámetros de renderizado que V-Ray en 3ds Max — tipo de muestreador, elementos de renderizado (AOVs), formato de salida. La documentación de referencia de V-Ray para Houdini de Chaos documenta la asignación de parámetros entre DCCs.

Octane para Houdini

Octane para Houdini se ejecuta en nuestro nivel de workers GPU RTX 5090. Utilizado principalmente por estudios de diseño en movimiento que combinan Houdini y Cinema 4D para salidas estilizadas.

Notas de configuración:

Marco de licencias. Licencias de nodo de renderizado de Otoy.
Restricciones de VRAM. Las mismas que Octane para C4D — 32 GB VRAM por worker, con un perfil de memoria más agresivo que Redshift (sin ruta fuera del núcleo). Las escenas que caben en 24 GB en Redshift pueden necesitar reducción de resolución de texturas o decimación de geometría para caber en 32 GB en Octane.

Flujo de envío

Tres canales de envío funcionan para proyectos de Houdini en la render farm:

Carga web + envío mediante el panel. Archive la carpeta $HIP como .tar.gz o .7z, cárguela a través del sitio web, luego configure el trabajo (renderer, nodo ROP, rango de fotogramas, formato de salida) y envíe. Este es el camino más común para trabajos individuales de Houdini y proyectos con un tamaño total de carga inferior a ~50 GB.
SFTP para proyectos grandes. Los proyectos de Houdini con cachés de simulación de varios terabytes deben enviarse mediante SFTP para transferencias reanudables. Consulte para el flujo de trabajo de SFTP, las credenciales y el umbral para cambiar de la carga web a SFTP.
Client App. La Client App de Super Renders Farm envuelve la carga, el envío y la descarga automática en una aplicación de escritorio. Útil para estudios con envíos recurrentes donde la misma estructura de proyecto se vuelve a renderizar con cambios de parámetros. Consulte .

Un plugin de envío para Houdini que se integra directamente con la UI de Houdini está en desarrollo pero aún no está preinstalado en todos los workers. Por ahora, el flujo de envío del panel web es el camino recomendado. El recorrido de envío entre DCCs — qué completar, cómo establecer el rango de fotogramas, dónde encontrar los archivos de salida — está en la .

Bajo el capó, el worker invoca los puntos de entrada de renderizado por lotes de Houdini: hbatch para envíos de archivos HIP a ROPs de contexto OBJ/SOP (Mantra, Karma CPU, Redshift, Arnold, V-Ray, Octane), y husk para envíos de stage USD a Karma (CPU o XPU). En general no necesita conocer la invocación subyacente, pero si está depurando comportamiento inesperado en los nombres de salida o el rango de fotogramas, la configuración a nivel de ROP es lo que el worker pasa a hbatch/husk mediante indicadores de línea de comandos.

Resolución de problemas específicos de Houdini

Para la resolución de problemas genérica entre DCCs (asset faltante, renderizado fallido en el fotograma N, problemas comunes de formato de salida), consulte . Los patrones de fallo específicos de Houdini que vemos con mayor frecuencia en los tickets de soporte:

"Unable to find HDA" o el HDA falla al cargar con un marcador de posición de nodo obsoleto. El worker no puede localizar el archivo HDA que referencia la escena. Verifique que los HDAs estén incrustados en el .hip (menú Asset → Operator Type Manager → "Save to Embedded") o presentes en $HIP/hda/ con la ruta de búsqueda configurada. Si referencia HDAs desde una biblioteca compartida del estudio, cópielos en la carpeta del proyecto antes de enviar.
Archivo de caché no encontrado al renderizar / geometría de simulación vacía. Verifique que los archivos de caché realmente se hayan horneado al disco antes del envío — abra cada SOP de caché de archivos y confirme que la pestaña "Output" muestra archivos en la ruta indicada. Si la ruta usa una letra de unidad absoluta (D:\sim_cache\flip.0001.bgeo.sc), cambie a $HIP/cache/{node_name}/$F4.bgeo.sc y vuelva a hornear. La verificación de 60 segundos antes de cargar — File → Refresh All, más un análisis manual de los SOPs de caché de archivos — previene la categoría individual más grande de fallos de renderizado de Houdini que vemos.
Las salidas del renderizado están completamente vacías / fotogramas en negro. Verifique el prim "Render Settings" del ROP (para Karma en un stage de Solaris) o la referencia de la cámara (para Mantra, Redshift, Arnold, V-Ray, Octane en ROPs de contexto /obj). La causa más común es una cámara establecida en el viewport pero no referenciada en el ROP — el worker no tiene viewport, por lo que la referencia de cámara a nivel de ROP es la autoridad.
Karma XPU falla inmediatamente con "OptiX not available" o "GPU not detected". Poco frecuente en nuestra render farm porque la flota de workers GPU tiene cobertura confirmada de CUDA + controlador OptiX. Si ocurre, la causa más común es un worker en actualización o una reversión del controlador en curso; vuelva a enviar 5–10 minutos después o contacte con el soporte si el problema persiste en múltiples envíos.
El script Python de pre-renderizado falla en el worker. Deshabilite el script o hágalo portable en cuanto a rutas. El Python personalizado que referencia rutas de módulos específicas de la estación de trabajo (las herramientas de pipeline de su estudio), abre diálogos de UI o realiza salidas de shell a binarios locales mediante hou.system() no se ejecutará en un worker Linux sin cabecera.
Las referencias de assets de Solaris / USD se rompen. Las rutas del resolvedor de assets USD deben ser relativas a $HIP, usar un contexto de resolvedor USD que el worker pueda cargar, o estar aplanadas en un único USD compuesto mediante el ROP USD antes del envío. Las rutas absolutas en las capas de referencia USD son el modo de fallo más común aquí.
Incompatibilidad de versión de plugin / la escena no se carga. La versión del plugin local difiere de la del worker — más comúnmente saltos de HtoA 6 → 7 o Redshift 3.0 → 3.5. Verifique la versión del plugin en el momento de guardar la escena (visible en el encabezado de texto del archivo HIP o en el sello de versión del menú ROP del plugin) y confirme que el worker tiene al menos esa versión menor. Los saltos de versiones principales nunca deben asumir compatibilidad.
Incompatibilidad de versión de Houdini (escena de 20.5 en worker 20.0). El formato de archivo HIP incluye metadatos de versión; una versión anterior de Houdini no puede abrir escenas guardadas con una versión más reciente. Confirme que el worker tiene Houdini ≥ la versión de guardado de la escena, o vuelva a guardar la escena en la versión de destino si es absolutamente necesario.
La simulación OpenCL falla al renderizar. Las simulaciones OpenCL son de tiempo de horneado, no de tiempo de renderizado. Hornee en caché antes del envío. La render farm no ejecuta simulaciones OpenCL en vivo durante el renderizado — esto es por diseño y se aplica a FLIP, Pyro, Vellum y cualquier otro solucionador acelerado por OpenCL.
Deriva de configuración de OCIO entre el envío y el worker. Si su variable de entorno OCIO local apunta a una configuración específica del estudio que no está presente en el worker, los colores se renderizan bajo la configuración predeterminada del worker y se ven diferentes. Agrupe el archivo de configuración OCIO con el proyecto, establezca OCIO mediante la anulación de entorno de envío, o use la configuración ACES integrada de Houdini que el worker también incluye.
Advertencia de "campo faltante" en caché Pyro/FLIP entre versiones de Houdini. El formato de archivo de caché cambia ocasionalmente entre versiones principales de Houdini; un caché más antiguo cargado en una versión más nueva de Houdini a veces pierde campos. Vuelva a almacenar en caché la simulación en la versión de Houdini de destino, o confirme que el worker usa la misma compilación de Houdini que escribió el caché.

Referencias cruzadas

— flujo de trabajo de carga, envío y descarga (entre DCCs)
— cómo se calculan los costos de los trabajos de Houdini (niveles GPU vs CPU)
— guía de SFTP, formatos de archivo, transferencias de proyectos grandes
— resolución de problemas entre DCCs
— envoltorio de escritorio para envíos
— página de destino (matriz de renderers, hardware, ejemplos de precios)

FAQ

Q: ¿Qué versiones de Houdini admite la render farm? A: Houdini 19.5, 20.0 y 20.5 están preinstalados en cada worker. Rastreamos el calendario de lanzamientos de SideFX y aprovisionamos nuevas compilaciones principales en un plazo de cuatro semanas a partir de la disponibilidad pública. Se admiten tanto los archivos de escena de Houdini FX (.hip) como los de Houdini Indie (.hipnc). Los archivos de Houdini Apprentice se renderizan pero producen salidas con marca de agua según los términos de licencia no comercial de SideFX — para trabajo de producción remunerado, guarde desde una licencia que no sea Apprentice antes del envío.

Q: ¿Necesito transferir mi licencia de Houdini para renderizar en la render farm? A: No. Operamos Houdini bajo uso de renderizado exclusivo, que permite ejecutar Houdini en los workers de renderizado para renderizado offline sin ocupar un puesto de SideFX del pool de licencias de su estudio. Su licencia local de Houdini permanece con usted. Super Renders Farm no es socio de SideFX — el uso de renderizado exclusivo es el marco legal que permite el renderizado en render farm de escenas de Houdini.

Q: ¿Debo usar Karma XPU, Karma CPU o Mantra para un nuevo proyecto? A: Karma XPU para proyectos nuevos en 2026 — es el camino adelante recomendado por SideFX, se ejecuta en nuestro nivel GPU RTX 5090 y es significativamente más rápido que Karma CPU o Mantra para la mayoría de las escenas. Use Karma CPU para escenas que superen los 32 GB de VRAM, dependan de volúmenes pesados que desborden la GPU, o usen shaders OSL personalizados aún no compatibles con XPU. Use Mantra solo cuando su proyecto esté vinculado a Mantra (una producción de larga duración iniciada antes de que Karma fuera viable, o una función de shader específica de Mantra sin equivalente en Karma). Para trabajo nuevo, use Karma como predeterminado.

Q: ¿Puede la render farm ejecutar simulaciones de Houdini (Pyro, FLIP, Vellum, RBD)? A: No — las simulaciones son trabajo de la estación de trabajo. Hornee todos los cachés de simulación a archivos .bgeo.sc o .vdb localmente antes del envío. La render farm renderiza contra cachés pre-horneados; no ejecuta simulaciones en vivo como parte del trabajo de renderizado. Este es el mismo patrón que los flujos de trabajo de simulación de Blender o Maya en la mayoría de las render farms en la nube gestionadas.

Q: Mi proyecto usa el pipeline Solaris/USD de Houdini. ¿Se renderizará correctamente? A: Sí, con Karma (CPU o XPU) como renderer. El camino diseñado para Solaris es Karma — ambos renderers consumen el stage USD de forma nativa y la integración Solaris/Karma es el pipeline adelante recomendado por SideFX. Para el envío en la nube, aplane el stage USD a un único archivo .usd compuesto mediante el ROP USD, o agrupe el árbol de directorios $HIP/usd/ completo para que cada capa se resuelva en el worker. Los renderers de terceros (Redshift, Arnold) también pueden renderizar escenas basadas en USD si su integración con Houdini lo admite — verifique localmente en un solo fotograma antes de enviar una secuencia completa.

Q: Mi escena usa HDAs personalizados de la biblioteca compartida de nuestro estudio. ¿Los encontrará la render farm? A: La render farm no encontrará HDAs en la unidad de red compartida de su estudio (\\studio-fs\hda\... o equivalente). Incruste los HDAs en el .hip mediante el menú Asset → Operator Type Manager → "Save to Embedded", o copie los archivos .hda/.otl en $HIP/hda/ antes de archivar el proyecto. Verifique con hou.hda.loadedFiles() desde el shell de Python que cada HDA cargado se resuelve bajo $HIP o es un asset de SideFX de serie.

Q: ¿Cómo empaqueto un proyecto de Houdini que usa cachés de simulación? A: Hornee cada simulación a $HIP/cache/{solver_name}/$F4.bgeo.sc (o .vdb para volúmenes) localmente antes del envío. Verifique que los archivos de caché existen en las rutas esperadas mediante File → Refresh All. Archive toda la carpeta $HIP — incluyendo la subcarpeta cache/ — como .tar.gz o .7z. Para cachés de varios cientos de gigabytes, cargue mediante SFTP en lugar del formulario web. La render farm renderiza contra los cachés horneados; la simulación en sí se ejecuta en su estación de trabajo, no en un nodo worker.

Q: ¿Qué tan grande puede ser una carga de proyecto de Houdini? A: No hay límite de tamaño de carga estricto, pero recomendamos mantener una sola carga del navegador por debajo de ~50 GB. Por encima de eso, cambie a SFTP para transferencias reanudables — consulte . La render farm ha gestionado renders de simulaciones de Houdini de varios terabytes, todos cargados mediante SFTP con la estructura de directorios adecuada preservada.

Q: Mi render de Mantra es mucho más lento en la render farm que localmente. ¿Es esto esperado? A: La velocidad por fotograma de Mantra en nuestro nivel de workers CPU (Dual Xeon E5-2699 V4) es comparable a una estación de trabajo de gama alta. Si ve tiempos por fotograma significativamente más lentos que localmente, las causas más probables son: una configuración de muestreo diferente en el worker (Mantra lee las muestras del ROP — confirme que la configuración a nivel de ROP coincide), o aceleración OpenCL local que no está activa en el nivel exclusivo de CPU del worker. La solución estructural es la migración: Karma XPU en nuestro nivel GPU es significativamente más rápido que Mantra para la mayoría de las escenas, y Karma es el camino que SideFX recomienda seguir.

Q: ¿Admite la render farm PDG/TOPs de Houdini para la gestión distribuida de tareas? A: PDG es orquestación del lado de la estación de trabajo; la render farm utiliza su propio sistema de cola y asignación de workers. Puede usar PDG localmente para crear y hornear assets, luego enviar los trabajos de ROP finales a la render farm mediante el panel web o la Client App. El envío directo impulsado por PDG a render farms externas está en nuestra hoja de ruta pero aún no es un flujo de trabajo de primera clase.

Q: ¿Cómo se calcula el costo para el renderizado en la nube con Houdini? A: El costo de Houdini en la render farm sigue el nivel de worker del renderer — tarifas GPU para Karma XPU, Redshift y Octane; tarifas CPU para Karma CPU, Mantra, Arnold y V-Ray para Houdini. La complejidad por fotograma (recuento de muestras, recuento de AOV, resolución de salida) impulsa el costo por fotograma; la elección del renderer impulsa la tarifa por hora de nodo. Las simulaciones tienen costo adicional solo si las ejecuta en la render farm (recomendamos almacenar en caché localmente y cargar el caché). Para detalles de precios, consulte o realice una estimación en nuestra .

---

Configurar Houdini para el renderizado en la nube