Houdini Cloud Rendering: guía profunda de simulaciones VFX para Pyro, FLIP, Vellum, destrucción y Crowds

Las escenas de Houdini tienen una forma de generar datos de salida mucho antes de generar frames. Una simulación FLIP que tarda nueve horas en almacenarse en caché localmente, un Pyro plume horneado a lo largo de 240 fotogramas, un solve de Vellum cloth que llena un disco scratch de 4 TB — y eso antes de que un solo sample de Karma aterrice en el pase de beauty. Para los FX TDs y artistas de lookdev con los que trabajamos, el cuello de botella rara vez es el propio renderizado. Es la simulación, la caché y el manejo de versiones lo que consume la semana — y entonces «el render» se convierte en lo que tiene que caber en la tarde del viernes.

Esa brecha — entre la simulación que termina y los fotogramas que se entregan — es donde viven las decisiones de cloud rendering. Llevamos operando Super Renders Farm desde 2017, con el equipo ejecutando renderizado distribuido para trabajo de producción con FX intensivo desde 2010. Las preguntas que escuchamos de los FX TDs de Houdini casi nunca son «¿deberíamos usar cloud rendering?». Son: «¿sobrevivirá mi caché de Pyro al transporte?» y «si muevo mi bake de Vellum a la farm, ¿seguirán siendo estables los subesteps?». La respuesta depende de lo que haga la simulación — por eso este artículo está organizado por tipo de simulación y no por etapa de workflow.

Lo que sigue es un manual de optimización por tipo de simulación. Para la configuración del workflow de principio a fin — preparación de la escena, rutas $HIP y $JOB, resolución de assets USD, fijación de versiones de plugins — consulta nuestra guía de configuración de render farm Houdini. Para una comparación de vendors de farms Houdini gestionadas en términos de precio, hardware y soporte de renderers, consulta nuestra comparación directa de render farms Houdini. Este análisis profundo asume que la escena está lista para subir y se enfoca en los ajustes específicos de cada tipo de simulación que determinan si la simulación sobrevive el viaje a una flota de workers, y qué regresa de ella.

Por qué las simulaciones de Houdini estresan una render farm de manera diferente

La mayoría del contenido sobre render farms enmarca la carga de trabajo como «fotogramas por hora» — una escena fija renderizada N veces a través de N workers. Ese modelo encaja con un pase de lookdev estático en Karma o Redshift. No encaja con una simulación de Houdini, porque en Houdini la «escena» no está finalizada hasta que la caché de simulación está finalizada. Un Pyro plume, un volumen FLIP, un pre-roll de Vellum cloth — estos son estados intermedios, no estado de escena. La farm tiene que recibir ese estado intermedio pre-horneado, o reconstruirlo a partir de un archivo .hip que el worker acaba de recibir, y esas dos rutas tienen perfiles de costo muy diferentes.

El límite de una sola máquina en la mayoría de los solvers de Houdini es la restricción operativa. La coherencia de subesteps del DOPnet — el requisito de que el fotograma N dependa del fotograma N-1 en el mismo contexto del solver — significa que los solves de Pyro, FLIP, Vellum y RBD en su mayoría no son paralelizables entre nodos de workers a mitad de la simulación. PDG distribuye wedges y trabajo SOP independiente de fotogramas; el bucle de solve interno generalmente no se expande. Implicación práctica: una simulación o cabe en un worker y en la workstation, o no se ejecuta en la farm en absoluto. La farm gana en paralelismo del lado del renderizado, no en el lado de la simulación.

En nuestra farm, el lado CPU ejecuta nodos Dual Intel Xeon E5-2699 V4 con 96–256 GB RAM (más de 20.000 núcleos en total), que es el tier relevante para la reconstrucción de caché y los pases de simulación/renderizado CPU; el lado GPU ejecuta tarjetas RTX 5090 con 32 GB VRAM cada una, que es el tier que Karma XPU y Redshift consumen en la fase de renderizado. La fase de simulación y la fase de renderizado aterrizan en flotas diferentes, por lo que el precio en trabajo de Houdini es casi siempre un elemento de dos líneas — CPU GHz-hora para la reconstrucción de caché (si es necesario), GPU node-horas para el renderizado.

Los puntos de entrada de línea de comandos canónicos son hbatch (ejecución clásica de escenas Houdini) y husk (referencia de línea de comandos husk — renderizado de stage Solaris/USD). La mayoría de la automatización del lado de la farm funciona a través de uno de estos, con el .hip subido una vez y ya sea re-ejecutado por rango de fotogramas (hbatch) o renderizado contra un stage USD pre-horneado (husk). Por tipo de simulación, la pregunta es: ¿enviamos una caché horneada y ejecutamos husk, o enviamos el .hip y dejamos que hbatch reconstruya?

Pyro: cachés de humo, fuego y explosiones a escala cloud

Pyro es el solver de humo, fuego y explosiones de Houdini — un modelo de combustión de sparse grid construido sobre el Pyro Solver DOPnet, que escribe volúmenes .vdb por fotograma. La combustión produce campos de temperatura, densidad, combustible, velocidad y divergencia, y la cuadrícula de vóxeles es el control primario del tamaño de caché: reducir a la mitad el tamaño de vóxel aproximadamente 8x el costo de memoria y disco (escalado cúbico). Para contexto técnico completo, consulta la documentación de SideFX Pyro.

Estrategia de caché. Casi siempre hornear en .vdb (OpenVDB sparse) en lugar de .bgeo.sc, porque los campos de Pyro son sparse por naturaleza — la mayoría de los vóxeles son aire vacío. El almacenamiento de banda estrecha de OpenVDB elimina los vóxeles muertos del disco. La cantidad de subesteps importa aquí: Pyro se resuelve limpiamente con 1–2 subesteps para plumes de movimiento lento, 4–8 subesteps para combustión rápida u ondas de choque. Mayor subestep en la farm significa que el worker gasta más CPU por fotograma; menor subestep significa que el worker gasta menos pero la simulación puede perder coherencia en movimientos rápidos. Fijar la cantidad de subesteps en el DOPnet, no depender del comportamiento predeterminado de la farm.

El tamaño del vóxel, el esquema de advección (Semi-Lagrangian vs. Trilinear vs. MacCormack) y los parámetros del modelo de combustión juntos establecen el tamaño .vdb por fotograma. Un Pyro plume de complejidad media a 0,05 de tamaño de vóxel, 240 fotogramas, típicamente cae en el rango de 20–60 GB en total. Verificar el tamaño de caché por fotograma antes de subir — el ancho de banda en la subida es a menudo el cuello de botella, no el renderizado.

Consideraciones de la cloud render farm. Pyro renderiza en GPU a través de Karma XPU o renderizado de volúmenes Redshift, ambos consumen .vdb de forma nativa. La simulación en sí está limitada por CPU y es acelerada por OpenCL, pero la aceleración OpenCL ayuda principalmente en la velocidad de bake en workstation, no en la simulación paralela de fotogramas del lado de la farm (porque cada fotograma sigue dependiendo del anterior). Patrón práctico: hornear localmente, subir la secuencia .vdb, renderizar en la flota GPU.

# Renderizar un Pyro plume en caché a través de husk en un stage USD,
# con Karma XPU en el nodo GPU y volume samples aumentados.
husk --renderer karma \
     --frame 1 --frame-count 240 --frame-inc 1 \
     --verbose 3a \
     --output "$HIP/render/pyro_plume.\$F4.exr" \
     --settings xpu \
     --override "/Render/rendersettings:karma:volumesamples=8" \
     "$HIP/stage/pyro_plume_volumes.usd"

La invocación de husk contra un stage USD que referencia la secuencia .vdb en caché permite que el worker GPU dibuje el volumen sin re-resolver. Aumentar volumesamples del valor predeterminado de Karma 4 a 8 reduce el ruido en plumes densos al costo de aproximadamente 1,5–2x el tiempo de renderizado. Usar 16 para shots hero, dejarlo en 4 para pre-vis.

FLIP: líquidos, reconstrucción de superficie, banda estrecha

FLIP — el Fluid Implicit Particle solver — combina representaciones de partículas y cuadrículas para simular agua, líquidos viscosos y flujo de superficie libre. La salida son dos cosas: una caché de partículas (secuencia packed .bgeo.sc) y, opcionalmente, una malla de superficie reconstruida (también .bgeo.sc). Ambas van a la farm, lo que significa que FLIP casi siempre duplica su huella de disco en comparación con Pyro en complejidad equivalente.

Estrategia de caché. Separar la caché de partículas y la malla de superficie en dos directorios de caché — las partículas se hornean primero, la malla se reconstruye a partir de las partículas en una red SOP posterior. Esta división permite re-mallar sin re-simular, lo que importa cuando la tensión superficial o la separación de partículas necesita un segundo pase. Una simulación FLIP de complejidad media a 200 fotogramas con separación de partículas de 0,02 a menudo cae en 80–200 GB en el lado de partículas y 20–40 GB en el lado de la malla. FLIP de banda estrecha — donde solo se almacenan a densidad completa las partículas cerca de la superficie — reduce la caché de partículas en un 60–80% en shots donde el volumen profundo no es visible. Activarlo cuando la cámara no mira a través del agua.

La rigidez de viscosidad y las restricciones CFL establecen el recuento de subesteps. Las simulaciones de agua con viscosidad 0 típicamente se ejecutan con 1–2 subesteps; la miel o el metal fundido con alta viscosidad a menudo necesitan 5–10 subesteps para permanecer estables. La violación de CFL produce explosiones de partículas, que en una farm son mucho más costosas que en una workstation porque no las ves hasta que termina el renderizado.

Consideraciones de la cloud render farm. El tiempo de subida de caché es el costo dominante para FLIP en una cloud render farm. Una caché de partículas de 100 GB sobre un uplink de cliente de 100 Mbps toma aproximadamente 2,5 horas antes de que pueda comenzar el primer fotograma de renderizado. Con un uplink de 1 Gbps, la misma caché se sube en ~15 minutos — la diferencia es a menudo lo que decide si el FLIP en cloud es operativo para un shot. Auditar el tamaño de caché antes de subir.

# Sonda Hython — ejecutar desde una workstation o worker para calcular
# el tamaño de caché por fotograma antes de pagar el ancho de banda de subida
# en una simulación FLIP de varios TB. Usar como puerta de pre-vuelo.
import os, hou
cache_dir = hou.expandString("$HIP/cache/flip/v003")
total = 0
frames = 0
for f in sorted(os.listdir(cache_dir)):
    if f.endswith(".bgeo.sc"):
        size = os.path.getsize(os.path.join(cache_dir, f))
        total += size
        frames += 1
print(f"{frames} fotogramas, {total/1e9:.2f} GB total, "
      f"{(total/frames)/1e6:.1f} MB/fotograma promedio")

Si el promedio por fotograma supera los 500 MB y el total supera los 100 GB, ya sea aceptar la ventana de subida o revisar la separación de partículas, la banda estrecha y el umbral de malla de superficie antes de transferir.

Vellum: cloth, soft body, serialización de restricciones

Vellum es el framework de dinámica basada en posiciones de Houdini — cloth, soft body, cabello, granos, fluidos en una formulación de posición restringida. La salida es una caché .bgeo.sc por fotograma, pero a diferencia de Pyro o FLIP, las cachés de Vellum llevan el estado de restricciones además de las posiciones de puntos. El grafo de restricciones (pin, stretch, bend, attach-to-static) debe serializar limpiamente o el worker de la farm re-solverá con restricciones rotas. Consulta la documentación del solver Vellum para la matriz de tipos de restricciones.

Estrategia de caché. Almacenar en caché después del Vellum Solver DOPnet, antes de cualquier limpieza SOP posterior. Usar el Vellum I/O SOP en lugar de un File Cache genérico, porque Vellum I/O conserva los atributos de restricción (__constraintnetwork, restlength, stiffness) que un caché genérico eliminaría. El pre-roll importa: el cloth necesita 20–40 fotogramas de asentamiento antes de que comience el rango de fotogramas de la cámara, y el pre-roll debe estar en la caché o el worker renderizará el fotograma 1 con cloth no asentado. La mayoría de los rigs de producción Vellum hornean el pre-roll en los fotogramas -20 a 0 de la caché.

El recuento de subesteps es la causa más común de fallos de Vellum del lado de la farm. Los subesteps predeterminados del Vellum Solver (5) funcionan para drapeados lentos y cloth básico de personajes, pero el movimiento rápido, las relaciones de estiramiento altas y las redes de pin ajustadas a menudo necesitan 10–20 subesteps para permanecer estables. Fijar el recuento de subesteps explícitamente en el DOPnet — dejar que el worker de la farm use su predeterminado es donde la estabilidad entre fotogramas tiende a romperse, porque las cachés horneadas en la workstation con subestep 10 no coinciden con las cachés reconstruidas por el worker con subestep 5.

Consideraciones de la cloud render farm. Vellum está limitado por CPU, de un solo hilo por solver (con multihilo limitado en la resolución de restricciones), y el tamaño de caché es modesto — generalmente 5–20 GB por shot — por lo que el cuello de botella de subida es menos agudo que FLIP. El costo dominante en una farm es el tiempo de reconstrucción si se envía el .hip en lugar de una caché horneada. Una caché Vellum de 4 GB (disfraz de complejidad media) típicamente tarda 30–90 minutos en hornear en un solo worker E5-2699. Si primero horneas localmente y subes la caché, la farm solo ve el costo de renderizado.

# Hornear por lotes un solve de Vellum cloth a .bgeo.sc con una
# anulación explícita de subesteps. Los recuentos de subesteps predeterminados
# son donde la estabilidad del lado de la farm tiende a romperse en cloth de calidad producción.
hbatch -c "render -f 1 240 -i 1 \
  -v vellum_substeps=10 \
  -v cache_format=bgeo.sc \
  /obj/cloth_sim/dop_cache_OUT" \
  -d "/obj/cloth_sim/dopnet1" \
  "$HIP/scenes/cloth_main_v007.hip"

La anulación -v vellum_substeps=10 fija el recuento de subesteps independientemente de lo que diga el parámetro DOPnet guardado del .hip. Esta es la cobertura más segura contra la deriva de estabilidad de Vellum del lado de la farm.

Destrucción: RBD, Bullet, redes de restricciones

La destrucción en Houdini significa dinámica de cuerpos rígidos — RBD Solver, Bullet y las redes de restricciones que pegan, fijan o rompen la geometría fracturada. El formato de caché es primitivas packed .bgeo.sc, donde cada prim packed representa un fragmento fracturado y la red de restricciones se almacena como un .bgeo.sc separado por fotograma. Fracturar antes de la simulación — hecho en SOPs, no en DOPs — y solo la geometría post-fractura más la red de restricciones va al solver.

Estrategia de caché. Dos cachés importan: la geometría fracturada (estática, un fotograma) y el estado dinámico de transformación por fotograma. Almacenar solo las transformaciones durante la simulación, luego aplicarlas en el tiempo de renderizado a través del workflow de Packed Disk Primitive. Esto separa la geometría pesada (a menudo 5–50 GB de piezas fracturadas) del estado dinámico barato (típicamente 10–50 MB por fotograma). La geometría se sube una vez; la caché dinámica se sube por shot.

La serialización de la red de restricciones es el punto problemático. Las restricciones RBD (glue, hard, soft, cone-twist) llevan un atributo __constraintnetwork que el equivalente Vellum I/O — el RBD I/O SOP — maneja correctamente, pero un File Cache genérico no lo hará. Usar RBD I/O para el lado de restricciones; usar la caché estándar de prim packed para las transformaciones.

Consideraciones de la cloud render farm. Las simulaciones RBD son deterministas si se fijan las semillas aleatorias. El comportamiento predeterminado — semillas controladas por $F, semillas de hora del día, o semillas no establecidas — produce diferentes patrones de fractura en diferentes workers. En una farm donde un worker reconstruye la caché y otro renderiza contra un patrón esperado (por ejemplo, una configuración de composición pre-construida en una caché de workstation), la deriva de semillas produce desajustes visibles que solo aparecen después de que el render aterriza. Fijar cada semilla aleatoria antes del bake.

# Bake determinístico de RBD — fijar RBD_SEED para que dos workers
# renderizando el mismo rango de fotogramas produzcan cachés de fractura idénticos.
# Sin esto, los solves de fractura pueden desincronizarse entre workstation
# y farm, apareciendo como desajustes en el tiempo de composición.
hbatch -c "set -g \$RBD_SEED 42; \
  render -f 1 200 \
  -v packed_prims=1 \
  /obj/destruction/dop_constraint_OUT" \
  "$HIP/scenes/destruction_v012.hipnc"

Bullet vs. RBD Solver: Bullet es más rápido para grandes cantidades de piezas (1.000+ fragmentos) y aceptable para destrucción de calidad media; el RBD Solver es más preciso para dinámicas de shot hero, colapso de pilas y configuraciones controladas por restricciones, con un costo de solve por fotograma aproximadamente 3–5x mayor. En una farm, Bullet es el predeterminado práctico a menos que el shot sea hero.

Crowds: agentes, LOD, traspaso de ragdoll

Houdini Crowds es el framework de simulación de agentes — poblaciones de agentes con bibliotecas de clips de movimiento, estados de comportamiento y variantes LOD. La caché es más compleja que otros tipos de simulación: cachés de agentes (clips de movimiento .bclip.sc), cachés de transformación de crowd (.bgeo.sc por fotograma) y referencias packed prim de agentes que se resuelven en el tiempo de renderizado. Cada agente tiene su propia jerarquía LOD, intercambiada en el tiempo de renderizado a través de conjuntos de variantes de Solaris.

Estrategia de caché. Hornear la simulación de crowd en una caché de transformación .bgeo.sc (un archivo por fotograma que contiene la transformación por agente más el índice de clip de movimiento). La geometría del agente — los datos de malla reales — vive en una biblioteca .bclip.sc separada que se referencia, no se hornea por fotograma. Esta división es la razón por la que los renders de crowd son manejables: un shot con mil agentes puede tener una caché de transformación de 200 MB por fotograma pero solo 2 GB de geometría de agente en total, referenciada desde el disco.

El almacenamiento en caché de clips de movimiento importa porque los crowds se animan mezclando clips, no con fotogramas clave por fotograma. La biblioteca de clips tiene que estar en el worker antes de que comience el renderizado. Hornear la biblioteca de clips una vez, subir al almacenamiento persistente del worker, luego las subidas por shot son solo la caché de transformación.

El traspaso de ragdoll — donde un agente pasa de animación controlada por clips a física controlada por RBD — necesita tratamiento especial en la farm. La caché de estado de ragdoll es separada de la caché de transformación de crowd, y el fotograma de traspaso debe ser determinista, lo que significa fijar semillas y fotogramas de inicio de ragdoll explícitamente. De lo contrario, diferentes workers producen diferentes trayectorias de ragdoll.

Consideraciones de la cloud render farm. Los crowds se renderizan en Karma (CPU y XPU) a través de stages de Solaris, con variantes LOD de agentes resueltas en el tiempo de renderizado. El intercambio de LOD en el tiempo de renderizado significa que puedes cambiar el LOD por shot sin re-simular — los agentes de alto LOD se renderizan para shots hero, los de bajo LOD para shots amplios, sin tocar la caché.

# Renderizar un stage de crowd Solaris con LOD de agente seleccionado
# en la invocación de husk. Karma honra las variantes prim de agentes
# para el intercambio de LOD sin reconstruir la simulación de crowd.
husk --renderer karma --settings xpu \
     --frame 1 --frame-count 240 \
     --output "$HIP/render/crowd.\$F4.exr" \
     --override "/World/crowd:variantSet:lodVariant:value=mid" \
     "$HIP/stage/crowd_main.usd"

La anulación lodVariant:value=mid selecciona el conjunto de variantes de agente mid-LOD en el tiempo de renderizado. Cambiar a low para pases de fondo distantes y high para primer plano hero sin volver a ejecutar la simulación de crowd. Este es el mayor ahorro de costo por shot en el renderizado de crowd en cloud — el LOD en tiempo de renderizado permite que una caché sirva a cada shot en una secuencia.

Límites honestos: cuándo la farm no es la herramienta correcta

Una cloud render farm no es la respuesta a cada problema de simulación de Houdini, y ser explícito al respecto evita que los shots terminen en la farm porque nadie hizo la pregunta previa.

La simulación distribuida es en gran medida inviable. Los solvers de Pyro, FLIP, Vellum y RBD están en su mayoría limitados a una sola máquina por la coherencia de subesteps del DOPnet. PDG puede distribuir wedges y trabajo SOP independiente de fotogramas, pero el bucle de solve interno generalmente no puede expandirse entre nodos de workers a mitad de la simulación. Si tu simulación no cabe en una máquina — y el worker de la farm es típicamente un Dual Xeon E5-2699 V4 con 96–256 GB RAM, no radicalmente diferente de una workstation de gama alta — moverla a la farm no resuelve el problema.

Matemáticas del ancho de banda de subida de caché. Una caché FLIP de 100 GB sobre un uplink de cliente de 100 Mbps toma aproximadamente 2,5 horas antes de que comience el primer fotograma de renderizado. Las subidas de caché son tiempo de reloj de pared que pagas antes de que ocurra cualquier renderizado. El uplink gigabit ayuda; el ancho de banda de la workstation del cliente a menudo no.

El trade-off GPU vs. CPU en simulación está resuelto, pero no de la manera que los usuarios esperan. Pyro y FLIP tienen rutas OpenCL que aceleran los solves de subesteps en la workstation. La ventaja del lado de la farm es el renderizado paralelo de fotogramas de la simulación en caché, no la simulación paralela de fotogramas. Reformular: GPU en la farm equivale a aceleración de renderizado a través de Karma XPU o Redshift; CPU en la farm equivale a reconstrucción de caché si envías un .hip en lugar de una caché.

Latencia de iteración en el ajuste de simulación del lado cloud. Si ajustas un parámetro de densidad de Pyro y necesitas re-simular, vuelves a subir el .hip modificado, re-almacenas en caché en el worker y luego renderizas. El ciclo en la farm es a menudo 4–8x el ciclo local para trabajo intensivo en simulación. Almacenar en caché en la workstation si la workstation puede mantener la resolución; la farm gana en el lado del renderizado, no en el lado de la iteración.

Disponibilidad de tokens de licencia para Houdini Engine. La utilización de solo renderizado en una farm gestionada cubre los workers de renderizado de Houdini, pero las licencias de Houdini Engine (para pipelines procedurales con HDA intensivos, workflows de assets de juegos) son un tipo de seat separado. Confirmar con la farm si los tokens de Engine están agrupados y cómo se maneja la concurrencia antes de enviar escenas dependientes de Engine. Cuando la farm es la herramienta correcta pero la pregunta se convierte en cuál farm, nuestra comparación directa de render farms Houdini cubre cinco proveedores gestionados según criterios específicos de Houdini.

Resumen de recomendaciones de workflow

Por tipo de simulación, la decisión de almacenar en caché localmente vs. hornear en la farm generalmente se presenta así. Pyro: hornear localmente, subir .vdb, renderizar GPU. FLIP: hornear localmente si el uplink admite el tamaño de caché, de lo contrario considerar la reconstrucción de hbatch en el worker. Vellum: casi siempre hornear localmente — las cachés son pequeñas, los tiempos de reconstrucción no son triviales. Destrucción: hornear localmente con semillas fijadas, subir la caché de transformación (no la geometría completa por fotograma). Crowds: hornear la caché de transformación localmente, subir una vez con la biblioteca de agentes, renderizar con variantes LOD por shot.

El árbol de decisiones por el que guiamos a los nuevos clientes de Houdini en nuestra página de Houdini cloud render farm cubre la matriz de renderers a nivel de comprador; este artículo cubrió los ajustes de nivel FX-TD debajo. El precio de CPU en nuestra tarifa publicada es $0,004/GHz-hora — relevante al dimensionar una reconstrucción de caché de varios días frente a una alternativa de workstation. La matriz de renderers en nuestra farm admite Karma XPU y Karma CPU, Mantra, Redshift, Arnold, V-Ray para Houdini y Octane.

FAQ

Q: ¿Cuál es la mejor configuración de compresión .bgeo.sc para el ancho de banda de subida a cloud? A: Para las cachés de partículas FLIP, el .bgeo.sc estándar (compresión sparse packed) ya es casi óptimo para la subida — el formato está diseñado para ello. La mayor ganancia individual de ancho de banda está antes: activar FLIP de banda estrecha cuando la cámara no mira a través del volumen profundo, lo que puede reducir el tamaño de la caché de partículas en un 60–80% antes de que la compresión siquiera se ejecute. Para las cachés de Vellum y RBD, .bgeo.sc también es ya óptimo; las ganancias provienen de almacenar en caché solo lo que cambia (transformaciones, no geometría completa por fotograma), no de cambiar el formato.

Q: ¿Puedo ejecutar simulaciones distribuidas de Pyro o FLIP en múltiples workers cloud? A: No, no para el bucle de solve interno. Pyro, FLIP, Vellum y RBD dependen todos de la coherencia de subesteps del DOPnet — el fotograma N depende del fotograma N-1 en el mismo contexto del solver — por lo que el solve no puede expandirse entre nodos de workers a mitad de la simulación. PDG puede distribuir wedges (barridos de parámetros) y trabajo SOP independiente de fotogramas, pero el solver real se ejecuta en una máquina. La ventaja de la farm en el trabajo de simulación es el renderizado paralelo de fotogramas de la caché horneada, no la simulación paralela de fotogramas.

Q: ¿Debo almacenar en caché Vellum en la workstation o en la farm? A: Casi siempre en la workstation. Las cachés de Vellum son modestas (típicamente 5–20 GB por shot), los tiempos de bake en workstation son manejables (30–90 minutos para un disfraz de complejidad media en una sola CPU), y la caché se sube barato. Dejar que el worker de la farm reconstruya una caché de Vellum desde el .hip significa pagar GHz-hora de CPU en el lado del worker que habrías gastado localmente gratis. La excepción: escenarios de revisión de shot donde ajustas el .hip y el cambio de subestep invalida la caché; en esos casos, la reconstrucción en la farm es razonable.

Q: ¿Karma XPU admite el renderizado de volúmenes de archivos Pyro .vdb en caché en un worker cloud? A: Sí. Karma XPU consume volúmenes OpenVDB de forma nativa a través de stages de Solaris, y una invocación de husk contra un stage USD que referencia la secuencia .vdb en caché renderiza el volumen sin re-resolver. El worker GPU dibuja el volumen directamente; la simulación no tiene que estar presente en el worker. Aumentar karma:volumesamples del valor predeterminado 4 a 8 para volúmenes de calidad de producción, 16 para shots hero — el costo es aproximadamente 1,5–2x el tiempo de renderizado por duplicación.

Q: ¿Cómo mantengo las simulaciones de destrucción RBD deterministas en los workers cloud? A: Fijar cada semilla aleatoria en el DOPnet antes del bake — RBD_SEED, semillas de fractura y cualquier semilla controlada por $F o de hora del día. Sin el fijado de semillas, la misma escena RBD horneada en dos workers diferentes produce diferentes patrones de fractura, lo que aparece como desajustes en el tiempo de composición cuando una referencia renderizada en workstation y un final renderizado en farm no coinciden. Establecer la semilla como una variable global en la invocación de hbatch (set -g $RBD_SEED 42) y verificar que el DOPnet la lee.

Q: ¿Necesito licencias de Houdini Engine para renderizar simulaciones de crowd en una cloud render farm? A: Depende de cómo esté construida la pipeline de crowd. Una simulación de crowd que hornea en una caché de transformación .bgeo.sc y renderiza a través de Karma contra la caché no necesita Engine — el tier de licencia de solo renderizado lo maneja. Una simulación de crowd que ejecuta HDAs en el tiempo de renderizado (generación procedural de agentes, assets procedurales instanciados) puede necesitar seats de Engine. Confirmar con la farm si los tokens de Engine están agrupados y cómo se maneja la concurrencia. En nuestra farm, el modelo de licencia de solo renderizado nos permite renderizar Karma XPU en la flota GPU y renderers CPU en la flota CPU sin restricciones de seat de Engine; las pipelines de crowd con HDA intensivos deben discutirse durante la configuración del shot.

Lecturas relacionadas

• Houdini Cloud Render Farm
• Guía de configuración de Houdini Cloud Render Farm para 2026
• Comparación directa de Houdini render farms 2026
• Guía de costo de render farm por fotograma

Recursos externos

• Documentación de SideFX Houdini
• Documentación de SideFX Pyro
• Documentación de SideFX Vellum
• Referencia de línea de comandos Husk