Houdini Cloud Rendering : guide VFX simulation approfondi pour Pyro, FLIP, Vellum, destruction et foules

Les scènes Houdini ont une façon de générer des données bien avant de produire des images. Une simulation FLIP qui met neuf heures à se mettre en cache localement, une simulation Pyro cuite sur 240 images, une résolution Vellum cloth qui remplit un disque scratch de 4 To — et tout cela avant qu'un seul échantillon Karma n'atterrisse sur la passe de beauté. Pour les FX TDs et les artistes lookdev avec lesquels nous travaillons, le goulot d'étranglement est rarement le rendu lui-même. C'est la simulation, le cache et la gestion des versions qui consomment la semaine — et « le rendu » devient alors la chose qui doit tenir dans l'après-midi du vendredi.

Cet écart — entre la simulation terminée et les images livrées — est là où vivent les décisions de cloud rendering. Nous gérons Super Renders Farm depuis 2017, avec une équipe qui opère du rendu distribué pour des productions FX intensives depuis 2010. Les questions que nous entendons des FX TDs Houdini ne sont presque jamais « devrions-nous passer au cloud rendering ? ». Ce sont plutôt : « est-ce que mon cache Pyro survivra au transfert ? » et « si je déplace mon bake Vellum vers la farm, les sous-étapes resteront-elles stables ? ». La réponse dépend de ce que fait la simulation — c'est pourquoi cet article est organisé par type de simulation plutôt que par étape de workflow.

Ce qui suit est un manuel d'optimisation par type de simulation. Pour la configuration complète du workflow — préparation de la scène, chemins $HIP et $JOB, résolution des assets USD, verrouillage des versions de plugins — consultez notre guide de configuration de render farm Houdini. Pour une comparaison des farms Houdini gérées — prix, matériel et support des moteurs de rendu — consultez notre comparaison des render farms Houdini. Ce guide approfondi suppose que la scène est prête à l'upload et se concentre sur les paramètres spécifiques à chaque type de simulation qui déterminent si la simulation elle-même survit au transfert vers une flotte de workers.

Pourquoi les simulations Houdini sollicitent différemment une render farm

La plupart des contenus sur les render farms cadrent la charge de travail comme « images par heure » — une scène fixe rendue N fois sur N workers. Ce modèle convient à une passe de lookdev statique sous Karma ou Redshift. Il ne convient pas à une simulation Houdini, car dans Houdini la « scène » n'est pas finalisée tant que le cache de simulation ne l'est pas. Un panache Pyro, un volume FLIP, un pré-roulement Vellum cloth — ce sont des états intermédiaires, pas des états de scène finals. La farm doit soit recevoir cet état intermédiaire pré-cuit, soit le reconstruire à partir d'un fichier .hip que le worker vient de recevoir — et ces deux chemins ont des profils de coûts très différents.

La contrainte opérante sur la plupart des solveurs Houdini est la contrainte de machine unique. La cohérence des sous-étapes DOPnet — l'exigence que l'image N dépende de l'image N-1 dans le même contexte de solveur — signifie que les résolutions Pyro, FLIP, Vellum et RBD ne sont généralement pas parallélisables sur plusieurs nodes workers en cours de simulation. PDG distribue les wedges et les travaux SOP indépendants des images ; la boucle de résolution sous-jacente ne se distribue généralement pas. Implication pratique : soit une simulation tient sur un seul worker et sur la station de travail, soit elle ne tourne pas du tout sur la farm. La farm gagne sur le parallélisme côté rendu, pas côté simulation.

Sur notre farm, le côté CPU tourne sur des nodes Dual Intel Xeon E5-2699 V4 avec 96–256 Go de RAM (20 000+ cœurs au total), ce qui est le palier pertinent pour la reconstruction du cache et les passes de simulation/rendu CPU ; le côté GPU tourne sur des cartes RTX 5090 avec 32 Go de VRAM chacune, qui est le palier que Karma XPU et Redshift consomment lors de la phase de rendu. La phase de simulation et la phase de rendu atterrissent sur des flottes différentes — c'est pourquoi la tarification des travaux Houdini représente presque toujours deux lignes : CPU GHz-heures pour la reconstruction du cache (si nécessaire) et GPU node-heures pour le rendu.

Les points d'entrée en ligne de commande canoniques sont hbatch (exécution classique de scène Houdini) et husk (référence de la commande husk — rendu de stage Solaris/USD). La plupart des automatisations côté farm passent par l'un ou l'autre, le fichier .hip étant uploadé une fois et soit ré-exécuté par plage d'images (hbatch), soit rendu contre un stage USD pré-cuit (husk). Par type de simulation, la question est : livrons-nous un cache cuit et lançons-nous husk, ou livrons-nous le .hip et laissons-nous hbatch reconstruire ?

Pyro : caches de fumée, feu et explosion à l'échelle cloud

Pyro est le solveur de fumée, feu et explosion de Houdini — un modèle de combustion sur grille creuse construit sur le Pyro Solver DOPnet, écrivant des volumes .vdb par image. La combustion produit des champs de température, densité, carburant, vélocité et divergence, et la grille voxel est le principal levier sur la taille du cache : diviser la taille des voxels par deux multiplie environ par 8 la mémoire et le coût disque (mise à l'échelle cubique). Pour le contexte technique complet, consultez la documentation Pyro SideFX.

Stratégie de cache. Mettez presque toujours en cache au format .vdb (OpenVDB creux) plutôt qu'en .bgeo.sc, car les champs Pyro sont creux par nature — la plupart des voxels sont de l'air vide. Le stockage en bande étroite d'OpenVDB élimine les voxels morts du disque. Le nombre de sous-étapes compte ici : les résolutions Pyro s'effectuent proprement à 1–2 sous-étapes pour les panaches lents, 4–8 sous-étapes pour une combustion rapide ou des ondes de choc. Plus de sous-étapes sur la farm signifie que le worker dépense plus de CPU par image ; moins de sous-étapes signifie moins de dépense mais la simulation peut perdre sa cohérence sur des mouvements rapides. Verrouillez le nombre de sous-étapes dans le DOPnet — ne comptez pas sur le comportement par défaut de la farm.

La taille de voxel, le schéma d'advection (Semi-Lagrangian vs Trilinéaire vs MacCormack) et les paramètres du modèle de combustion définissent ensemble la taille des fichiers .vdb par image. Un panache Pyro de complexité moyenne à une taille de voxel de 0,05, sur 240 images, atterrit généralement dans une plage de 20–60 Go au total. Vérifiez la taille du cache par image avant l'upload — la bande passante lors du téléversement est souvent le goulot d'étranglement, pas le rendu.

Considérations pour la render farm. Pyro se rend sur GPU via Karma XPU ou le rendu de volumes Redshift, les deux consommant nativement les fichiers .vdb. La simulation elle-même est limitée par le CPU et accélérée par OpenCL, mais l'accélération OpenCL aide principalement la vitesse de bake en local, pas la simulation parallèle d'images côté farm (parce que chaque image dépend encore de la précédente). Schéma pratique : bake en local, uploadez la séquence .vdb, rendez sur la flotte GPU.

# Rendu d'un panache Pyro en cache via husk sur un stage USD,
# avec Karma XPU sur le node GPU et les samples de volumes augmentés.
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"

L'invocation husk contre un stage USD qui référence la séquence .vdb en cache permet au worker GPU de dessiner le volume sans ré-résoudre. Augmenter volumesamples du défaut Karma de 4 à 8 réduit le bruit sur les panaches denses au prix d'environ 1,5 à 2 fois le temps de rendu. Utilisez 16 pour les plans héros, laissez à 4 pour le pré-vis.

FLIP : liquides, reconstruction de surface, bande étroite

FLIP — le solveur Fluid Implicit Particle — combine des représentations particulaires et de grille pour simuler l'eau, les liquides visqueux et les écoulements à surface libre. La sortie se compose de deux éléments : un cache de particules (séquence compressée .bgeo.sc) et, optionnellement, un maillage de surface reconstruit (aussi en .bgeo.sc). Les deux vont vers la farm, ce qui signifie que FLIP double presque toujours son empreinte disque par rapport à Pyro pour une complexité équivalente.

Stratégie de cache. Séparez le cache de particules et le maillage de surface dans deux répertoires — les particules se cachent en premier, le maillage se reconstruit à partir des particules dans un réseau SOP en aval. Cette séparation permet de re-mailler sans re-simuler, ce qui compte lorsque la tension de surface ou la séparation des particules nécessite un second passage. Une simulation FLIP de complexité moyenne sur 200 images à une séparation de particules de 0,02 atterrit souvent à 80–200 Go côté particules et 20–40 Go côté maillage. La FLIP en bande étroite — où seules les particules proches de la surface sont stockées à pleine densité — réduit le cache de particules de 60–80 % sur les plans où la caméra ne regarde pas à travers l'eau. Activez-la quand la caméra n'est pas plongée dans le volume.

La rigidité de la viscosité et les contraintes CFL définissent le nombre de sous-étapes. Les simulations d'eau à viscosité 0 tournent typiquement à 1–2 sous-étapes ; le miel ou le métal en fusion à haute viscosité nécessite souvent 5–10 sous-étapes pour rester stable. Une violation CFL produit des explosions de particules — sur une farm, celles-ci sont beaucoup plus coûteuses que sur une station de travail car vous ne les voyez pas avant la fin du rendu.

Considérations pour la render farm. Le temps d'upload du cache est le coût dominant pour FLIP sur une render farm. Un cache de particules de 100 Go sur un lien montant client de 100 Mbps prend environ 2,5 heures avant que la première image puisse commencer à se rendre. Sur un lien à 1 Gbps, le même cache s'uploade en ~15 minutes — la différence est souvent ce qui détermine si le cloud FLIP est opérationnel pour un plan. Vérifiez la taille du cache avant l'upload.

# Sonde Hython — à exécuter depuis une station de travail ou un worker
# pour calculer la taille du cache par image avant de payer la
# bande passante d'upload sur une simulation FLIP multi-To.
# À utiliser comme porte de pré-vol.
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} images, {total/1e9:.2f} Go total, "
      f"{(total/frames)/1e6:.1f} Mo/image en moyenne")

Si la moyenne par image dépasse 500 Mo et le total dépasse 100 Go, acceptez la fenêtre d'upload ou revisitez la séparation des particules, la bande étroite et le seuil du maillage de surface avant le transfert.

Vellum : cloth, corps mous, sérialisation des contraintes

Vellum est le framework de dynamique à base de positions de Houdini — cloth, corps mous, cheveux, grains, fluides sur une formulation de positions contraintes. La sortie est un cache .bgeo.sc par image, mais contrairement à Pyro ou FLIP, les caches Vellum portent l'état des contraintes en plus des positions des points. Le graphe de contraintes (épingle, étirement, courbure, attachement au statique) doit se sérialiser proprement ou le worker de la farm ré-résoudra avec des contraintes brisées. Consultez la documentation du solveur Vellum pour la matrice des types de contraintes.

Stratégie de cache. Mettez en cache après le Vellum Solver DOPnet, avant tout nettoyage SOP en aval. Utilisez le SOP Vellum I/O plutôt qu'un File Cache générique, car Vellum I/O préserve les attributs de contraintes (__constraintnetwork, restlength, stiffness) qu'un cache générique supprimera. Le pré-roulement compte : le cloth a besoin de 20–40 images de stabilisation avant que la plage d'images caméra ne commence, et le pré-roulement doit être dans le cache sinon le worker rendra l'image 1 avec un cloth non stabilisé. La plupart des rigs de production Vellum cuisent le pré-roulement dans les images -20 à 0 du cache.

Le nombre de sous-étapes est la cause la plus fréquente d'échecs Vellum côté farm. Les sous-étapes par défaut du Vellum Solver (5) fonctionnent pour des drapés lents et du cloth de personnage basique, mais les mouvements rapides, les forts taux d'étirement et les réseaux d'épingles serrés nécessitent souvent 10–20 sous-étapes pour rester stables. Verrouillez le nombre de sous-étapes explicitement dans le DOPnet — laisser le worker de la farm utiliser sa valeur par défaut est là où la stabilité inter-images tend à se briser, car les caches baked en local à substep 10 ne correspondent pas aux caches reconstruits par le worker à substep 5.

Considérations pour la render farm. Vellum est limité par le CPU, mono-thread par solveur (avec un multi-thread limité sur la résolution des contraintes), et la taille du cache est modeste — généralement 5–20 Go par plan — donc le goulot d'upload est moins aigu que pour FLIP. Le coût dominant sur une farm est le temps de reconstruction si le .hip est livré plutôt qu'un cache cuit. Un cache Vellum de 4 Go (costume de complexité moyenne) prend typiquement 30–90 minutes à cuire sur un seul worker E5-2699. Si vous cuisez en local d'abord et uploadez le cache, la farm ne voit que le coût de rendu.

# Bake par lot d'une résolution Vellum cloth en .bgeo.sc avec
# substitution explicite des sous-étapes. Les comptes par défaut
# de sous-étapes sont là où la stabilité côté farm tend à se briser
# sur du cloth de qualité production.
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 substitution -v vellum_substeps=10 verrouille le nombre de sous-étapes quel que soit ce que le paramètre DOPnet sauvegardé dans le .hip indique. C'est la protection la plus sûre contre la dérive de stabilité Vellum côté farm.

Destruction : RBD, Bullet, réseaux de contraintes

La destruction dans Houdini signifie de la dynamique de corps rigides — RBD Solver, Bullet, et les réseaux de contraintes qui collent, épinglent ou brisent la géométrie fracturée. Le format de cache est des primitives compressées .bgeo.sc, chaque prim compressée représentant un morceau fracturé et le réseau de contraintes stocké comme un .bgeo.sc séparé par image. Fracturez en amont de la simulation — dans les SOPs, pas dans les DOPs — et seule la géométrie post-fracture plus le réseau de contraintes va vers le solveur.

Stratégie de cache. Deux caches comptent : la géométrie fracturée (statique, une image) et l'état de transformation par image dynamique. Mettez en cache uniquement les transformations durant la simulation, puis appliquez-les au moment du rendu via le workflow Packed Disk Primitive. Cela sépare la géométrie lourde (souvent 5–50 Go de pièces fracturées) de l'état dynamique léger (typiquement 10–50 Mo par image). La géométrie s'uploade une fois ; le cache dynamique s'uploade par plan.

La sérialisation du réseau de contraintes est le piège. Les contraintes RBD (glue, hard, soft, cone-twist) portent un attribut __constraintnetwork que l'équivalent Vellum I/O — le RBD I/O SOP — gère correctement, mais qu'un File Cache générique ne gérera pas. Utilisez RBD I/O pour le côté contraintes ; utilisez le cache de prim compressée standard pour les transformations.

Considérations pour la render farm. Les simulations RBD sont déterministes si les graines aléatoires sont verrouillées. Le comportement par défaut — graines basées sur $F, graines basées sur l'heure du jour ou graines non définies — produit des schémas de fracture différents sur des workers différents. Sur une farm où un worker reconstruit le cache et un autre rend contre un schéma attendu (par exemple, un setup de compositing pré-construit sur un cache de station de travail), la dérive des graines produit des décalages visibles qui ne se révèlent qu'après le retour du rendu. Verrouillez toutes les graines aléatoires avant le bake.

# Bake RBD déterministe — verrouillage de RBD_SEED pour que deux
# workers rendant la même plage d'images produisent des caches
# de fracture identiques.
# Sans cela, les résolutions de fracture peuvent se désynchroniser
# entre la station de travail et la farm, créant des décalages
# au moment du compositing.
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 est plus rapide pour les grands nombres de pièces (1 000+ morceaux) et acceptable pour les destructions de qualité moyenne ; le RBD Solver est plus précis pour les dynamiques de plans héros, les effondrements de structures et les setups à contraintes, à environ 3–5 fois le coût de résolution par image. Sur une farm, Bullet est la valeur par défaut pratique sauf si le plan est un héros.

Foules : agents, LOD, transfert ragdoll

Houdini Crowds est le framework de simulation d'agents — populations d'agents avec des bibliothèques de clips de mouvement, des états comportementaux et des variantes LOD. Le cache est plus complexe que pour les autres types de simulation : caches d'agents (clips de mouvement .bclip.sc), caches de transformations de foule (.bgeo.sc par image) et références de prims compressées d'agents qui se résolvent au moment du rendu. Chaque agent possède sa propre hiérarchie LOD, échangée au moment du rendu via des ensembles de variantes Solaris.

Stratégie de cache. Cuisez la simulation de foule en un cache de transformations .bgeo.sc (un fichier par image, contenant la transformation par agent plus l'index de clip de mouvement). La géométrie de l'agent — les données de maillage réelles — réside dans une bibliothèque .bclip.sc séparée qui est référencée, non cuite par image. Cette séparation est la raison entière pour laquelle les rendus de foule sont tractables : un plan à mille agents peut avoir un cache de transformations de 200 Mo par image mais seulement 2 Go de géométrie d'agent au total, référencée depuis le disque.

La mise en cache des clips de mouvement compte parce que les foules s'animent par mélange de clips, pas par images-clés par image. La bibliothèque de clips doit être sur le worker avant que le rendu commence. Cuisez la bibliothèque de clips une fois, uploadez-la vers le stockage persistant du worker, puis les uploads par plan ne concernent que le cache de transformations.

Le transfert ragdoll — où un agent passe de l'animation par clips à la physique pilotée par RBD — nécessite un traitement spécial sur la farm. Le cache d'état ragdoll est séparé du cache de transformations de foule, et l'image de transfert doit être déterministe, ce qui signifie verrouiller explicitement les graines et les images de démarrage ragdoll. Sinon, des workers différents produisent des trajectoires ragdoll différentes.

Considérations pour la render farm. Les foules se rendent sous Karma (CPU et XPU) via des stages Solaris, avec les variantes LOD d'agents résolues au moment du rendu. L'échange LOD au moment du rendu signifie que vous pouvez changer le LOD par plan sans re-simuler — les agents haute résolution se rendent pour les plans héros, les agents basse résolution pour les plans larges, sans toucher au cache.

# Rendu d'un stage Solaris de foule avec LOD d'agent sélectionné
# à l'invocation de husk. Karma honore les variantes de prims
# d'agents pour l'échange LOD sans reconstruire la simulation
# de foule.
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 substitution lodVariant:value=mid sélectionne l'ensemble de variantes d'agents LOD moyen au moment du rendu. Passez à low pour les passes d'arrière-plan distantes et high pour les héros au premier plan sans re-lancer la simulation de foule. C'est le plus grand économiseur de coûts par plan dans le cloud rendering de foules — le LOD au moment du rendu permet à un seul cache de servir chaque plan d'une séquence.

Limites honnêtes : quand la farm n'est pas le bon outil

Une render farm n'est pas la réponse à chaque problème de simulation Houdini, et être explicite à ce sujet empêche des plans de finir sur la farm parce que personne n'a posé la question en amont.

La simulation distribuée est en grande partie infaisable. Les solveurs Pyro, FLIP, Vellum et RBD sont principalement limités à une seule machine par la cohérence des sous-étapes DOPnet. PDG peut distribuer les wedges et les travaux SOP indépendants des images, mais la boucle de résolution interne ne peut généralement pas se distribuer sur des nodes workers en cours de simulation. Si votre simulation ne tient pas sur une seule machine — et le worker de la farm est typiquement un Dual Xeon E5-2699 V4 avec 96–256 Go de RAM, pas radicalement différent d'une station de travail haut de gamme — la déplacer vers la farm ne résout pas le problème.

Calcul de la bande passante pour l'upload du cache. Un cache FLIP de 100 Go sur un lien montant client de 100 Mbps prend environ 2,5 heures avant que la première image commence à se rendre. Les uploads de cache sont du temps d'horloge murale que vous payez avant que tout rendu n'ait lieu. Un lien Gigabit aide ; la bande passante de la station de travail côté client souvent pas.

Le compromis GPU vs CPU pour la simulation est établi, mais pas comme les utilisateurs l'attendent. Pyro et FLIP ont des chemins OpenCL qui accélèrent les résolutions de sous-étapes sur la station de travail. Le gain côté farm est le rendu parallèle par image du cache de simulation, pas la simulation parallèle par image. Pour reformuler : GPU sur la farm équivaut à accélération de rendu via Karma XPU ou Redshift ; CPU sur la farm équivaut à reconstruction du cache si vous livrez un .hip plutôt qu'un cache.

Latence d'itération sur les ajustements de simulation côté cloud. Si vous modifiez un paramètre de densité Pyro et avez besoin de re-simuler, vous ré-uploadez le .hip modifié, re-mettez en cache sur le worker, puis rendez. Le cycle sur la farm est souvent 4 à 8 fois le cycle local pour les travaux lourds en simulation. Mettez en cache sur la station de travail si elle peut tenir la résolution ; la farm gagne sur le côté rendu, pas sur le côté itération.

Disponibilité des tokens de licence pour Houdini Engine. L'utilisation en rendu seul sur une farm gérée couvre les workers de rendu Houdini, mais les licences Houdini Engine (pour les pipelines procéduraux lourds en HDA, les workflows d'assets de jeux) sont un type de siège séparé. Confirmez avec la farm si les tokens Engine sont mutualisés et comment la simultanéité est gérée avant de soumettre des scènes dépendant d'Engine. Quand la farm est le bon outil mais que la question devient laquelle, notre comparaison des render farms Houdini couvre cinq fournisseurs gérés selon des critères spécifiques à Houdini.

Récapitulatif des recommandations de workflow

Par type de simulation, la décision cache-en-local versus bake-sur-la-farm se décide généralement ainsi. Pyro : bake en local, uploadez .vdb, rendez en GPU. FLIP : bake en local si le lien montant supporte la taille du cache, sinon envisagez la reconstruction hbatch sur le worker. Vellum : bake presque toujours en local — les caches sont petits, les temps de reconstruction sont non négligeables. Destruction : bake en local avec les graines verrouillées, uploadez le cache de transformations (pas la géométrie complète par image). Foules : bake le cache de transformations en local, uploadez-le une fois avec la bibliothèque d'agents, rendez avec les variantes LOD par plan.

L'arbre de décision que nous présentons aux nouveaux clients Houdini sur notre page d'accueil Houdini cloud render farm couvre la matrice de moteurs de rendu au niveau acheteur ; cet article a couvert les paramètres d'optimisation au niveau FX TD en dessous. La tarification CPU sur notre grille publiée est de 0,004 $/GHz-Hr — utile pour évaluer la reconstruction d'un cache multi-journées face à une alternative sur station de travail. La matrice de moteurs de rendu sur notre farm supporte Karma XPU et Karma CPU, Mantra, Redshift, Arnold, V-Ray for Houdini et Octane.

FAQ

Q: Quel est le meilleur réglage de compression .bgeo.sc pour la bande passante d'upload vers le cloud ? A: Pour les caches de particules FLIP, le .bgeo.sc par défaut (compression creuse compressée) est déjà quasi optimal pour l'upload — le format est conçu pour cela. Le plus grand gain de bande passante se situe en amont : activez la FLIP en bande étroite quand la caméra ne regarde pas à travers le volume profond, ce qui peut réduire la taille du cache de particules de 60–80 % avant même que la compression ne s'exécute. Pour les caches Vellum et RBD, le .bgeo.sc est également déjà optimal ; les gains viennent de ne mettre en cache que ce qui change (transformations, pas la géométrie complète par image), pas du changement de format.

Q: Puis-je lancer des simulations Pyro ou FLIP distribuées sur plusieurs workers cloud ? A: Non, pas pour la boucle de résolution interne. Pyro, FLIP, Vellum et RBD reposent tous sur la cohérence des sous-étapes DOPnet — l'image N dépend de l'image N-1 dans le même contexte de solveur — donc la résolution ne peut pas se distribuer sur des nodes workers en cours de simulation. PDG peut distribuer les wedges (balayages de paramètres) et les travaux SOP indépendants des images, mais le solveur réel tourne sur une seule machine. Le gain de la farm sur les travaux de simulation est le rendu parallèle par image du cache cuit, pas la simulation parallèle.

Q: Dois-je mettre en cache Vellum sur la station de travail ou sur la farm ? A: Presque toujours sur la station de travail. Les caches Vellum sont modestes (typiquement 5–20 Go par plan), les temps de bake sur la station de travail sont gérables (30–90 minutes pour un costume de complexité moyenne sur un seul CPU) et le cache s'uploade bon marché. Laisser le worker de la farm reconstruire un cache Vellum depuis le .hip signifie payer des GHz-heures CPU côté worker que vous auriez dépensés localement gratuitement. L'exception : les scénarios de révision de plan où vous modifiez le .hip et le changement de sous-étapes invalide le cache ; dans ces cas, la reconstruction sur la farm est raisonnable.

Q: Karma XPU supporte-t-il le rendu de volumes de fichiers Pyro .vdb en cache sur un worker cloud ? A: Oui. Karma XPU consomme les volumes OpenVDB nativement via des stages Solaris, et une invocation husk contre un stage USD qui référence la séquence .vdb en cache rend le volume sans re-résoudre. Le worker GPU dessine le volume directement ; la simulation n'a pas besoin d'être présente sur le worker. Augmentez karma:volumesamples du défaut 4 à 8 pour des volumes de qualité production, 16 pour les plans héros — le coût est d'environ 1,5 à 2 fois le temps de rendu par doublement.

Q: Comment maintenir les simulations de destruction RBD déterministes sur les workers cloud ? A: Verrouillez toutes les graines aléatoires dans le DOPnet avant le bake — RBD_SEED, les graines de fracture et toutes les graines basées sur $F ou l'heure du jour. Sans verrouillage des graines, la même scène RBD bakée sur deux workers différents produit des schémas de fracture différents, ce qui se manifeste comme des décalages au moment du compositing quand une référence rendue sur station de travail et un final rendu sur farm ne correspondent pas. Définissez la graine comme variable globale dans l'invocation hbatch (set -g $RBD_SEED 42) et vérifiez que le DOPnet la lit.

Q: Ai-je besoin de licences Houdini Engine pour rendre des simulations de foule sur une render farm ? A: Cela dépend de la construction du pipeline de foule. Une simulation de foule qui se cuit en un cache de transformations .bgeo.sc et se rend via Karma contre le cache n'a pas besoin d'Engine — le palier de licence rendu seul le gère. Une simulation de foule qui exécute des HDA au moment du rendu (génération procédurale d'agents, assets procéduraux instanciés) peut nécessiter des sièges Engine. Confirmez avec la farm si les tokens Engine sont mutualisés et comment la simultanéité est gérée. Sur notre farm, le modèle de licence rendu seul nous permet de rendre Karma XPU sur la flotte GPU et les moteurs de rendu CPU sur la flotte CPU sans contrainte de sièges Engine ; les pipelines de foule lourds en HDA doivent être discutés lors de la configuration du plan.

Lectures complémentaires

• Houdini Cloud Render Farm
• Guide de configuration d'une render farm Houdini pour 2026
• Comparaison des render farms Houdini 2026
• Guide du coût de rendu par image

Ressources externes

• Documentation SideFX Houdini
• Documentation SideFX Pyro
• Documentation SideFX Vellum
• Référence de la commande husk