Houdini Cloud Rendering: guida tecnica approfondita alle simulazioni VFX per Pyro, FLIP, Vellum, distruzione e Crowds

Le scene Houdini hanno il modo di generare output molto prima di produrre frame. Una simulazione FLIP che impiega nove ore per essere salvata in cache localmente, un Pyro plume cotto su 240 frame, un solve di Vellum cloth che riempie un disco scratch da 4 TB — e questo prima che un singolo sample di Karma atterri sulla passata di beauty. Per gli FX TD e gli artisti di lookdev con cui lavoriamo, il collo di bottiglia è raramente il rendering stesso. È la simulazione, la cache e la gestione delle versioni che consuma la settimana — e poi «il render» diventa ciò che deve stare nel pomeriggio del venerdì.

Quel divario — tra la simulazione completata e i frame consegnati — è dove vivono le decisioni sul cloud rendering. Gestiamo Super Renders Farm dal 2017, con il team che esegue rendering distribuito per lavoro di produzione FX intensivo dal 2010. Le domande che sentiamo dagli FX TD di Houdini non sono quasi mai «dovremmo usare il cloud rendering?». Sono: «la mia cache di Pyro sopravviverà al trasferimento?» e «se sposto il mio bake di Vellum sulla farm, i substep rimarranno stabili?». La risposta dipende da ciò che fa la simulazione — ecco perché questo articolo è organizzato per tipo di simulazione anziché per fase del workflow.

Quello che segue è un manuale di ottimizzazione per tipo di simulazione. Per la configurazione completa del workflow — preparazione delle scene, percorsi $HIP e $JOB, risoluzione degli asset USD, fissaggio delle versioni dei plugin — consulta la nostra guida alla configurazione della render farm Houdini. Per un confronto tra fornitori di render farm Houdini gestite in termini di prezzo, hardware e supporto ai renderer, consulta il nostro confronto diretto delle render farm Houdini. Questa guida approfondita presuppone che la scena sia pronta per l'upload e si concentra sui controlli specifici per tipo di simulazione che determinano se la simulazione sopravvive al viaggio verso una flotta di worker, e cosa ritorna da essa.

Perché le simulazioni Houdini stressano una render farm in modo diverso

La maggior parte del contenuto sulle render farm inquadra il carico di lavoro come «frame all'ora» — una scena fissa renderizzata N volte su N worker. Quel modello si adatta a una passata di lookdev statica su Karma o Redshift. Non si adatta a una simulazione Houdini, perché in Houdini la «scena» non è finalizzata finché la cache di simulazione non è finalizzata. Un Pyro plume, un volume FLIP, un pre-roll di Vellum cloth — questi sono stati intermedi, non stato della scena. La farm deve ricevere quello stato intermedio pre-cotto, oppure ricrearlo da un file .hip che il worker ha appena ricevuto, e questi due percorsi hanno profili di costo molto diversi.

Il limite di una singola macchina sulla maggior parte dei solver Houdini è il vincolo operativo. La coerenza dei substep del DOPnet — il requisito che il frame N dipenda dal frame N-1 nello stesso contesto del solver — significa che i solve di Pyro, FLIP, Vellum e RBD per lo più non sono parallelizzabili tra nodi worker a metà simulazione. PDG distribuisce wedge e lavoro SOP indipendente dai frame; il ciclo di solve interno in genere non si ramifica. Implicazione pratica: una simulazione o si adatta a un worker e alla workstation, oppure non gira sulla farm del tutto. La farm vince sul parallelismo lato rendering, non sul parallelismo lato simulazione.

Sulla nostra farm, il lato CPU esegue nodi Dual Intel Xeon E5-2699 V4 con 96–256 GB RAM (oltre 20.000 core totali), che è il tier rilevante per la ricostruzione della cache e le passate di simulazione/rendering CPU; il lato GPU esegue schede RTX 5090 con 32 GB VRAM ciascuna, che è il tier che Karma XPU e Redshift consumano nella fase di rendering. La fase di simulazione e la fase di rendering atterrano su flotte diverse, motivo per cui il prezzo nel lavoro Houdini è quasi sempre una voce a due righe — GHz-ora CPU per la ricostruzione della cache (se necessario), node-ore GPU per il rendering.

I punti di ingresso canonici della riga di comando sono hbatch (esecuzione classica delle scene Houdini) e husk (riferimento alla riga di comando husk — rendering dello stage Solaris/USD). La maggior parte dell'automazione lato farm viene eseguita tramite uno di questi, con il .hip caricato una volta e ri-eseguito per intervallo di frame (hbatch) o renderizzato contro uno stage USD pre-cotto (husk). Per tipo di simulazione, la domanda è: spediamo una cache cotta ed eseguiamo husk, oppure spediamo il .hip e lasciamo che hbatch ricostruisca?

Pyro: cache di fumo, fuoco ed esplosioni su scala cloud

Pyro è il solver di fumo, fuoco ed esplosioni di Houdini — un modello di combustione a sparse grid costruito sul Pyro Solver DOPnet, che scrive volumi .vdb per frame. La combustione produce campi di temperatura, densità, carburante, velocità e divergenza, e la griglia di voxel è il controllo principale sulla dimensione della cache: dimezzare la dimensione dei voxel aumenta approssimativamente di 8 volte il costo di memoria e disco (scalatura cubica). Per il contesto tecnico completo, consulta la documentazione SideFX Pyro.

Strategia di cache. Cuocere quasi sempre in .vdb (OpenVDB sparse) anziché in .bgeo.sc, perché i campi Pyro sono sparse per natura — la maggior parte dei voxel è aria vuota. L'archiviazione narrow-band di OpenVDB elimina i voxel morti dal disco. Il numero di substep conta qui: Pyro si risolve correttamente con 1–2 substep per plume a movimento lento, 4–8 substep per combustione rapida o onde d'urto. Un substep più alto sulla farm significa che il worker consuma più CPU per frame. Fissare il conteggio dei substep nel DOPnet, non affidarsi al comportamento predefinito della farm.

La dimensione del voxel, lo schema di avvezione (Semi-Lagrangian vs. Trilinear vs. MacCormack) e i parametri del modello di combustione stabiliscono insieme la dimensione .vdb per frame. Un Pyro plume di complessità media a dimensione voxel 0,05, 240 frame, si attesta tipicamente nel range 20–60 GB totali. Controllare la dimensione della cache per frame prima dell'upload — la larghezza di banda nell'upload è spesso il collo di bottiglia, non il rendering.

Considerazioni sulla cloud render farm. Pyro renderizza su GPU tramite Karma XPU o il rendering di volumi Redshift, entrambi consumano .vdb in modo nativo. La simulazione stessa è limitata dalla CPU ed è accelerabile da OpenCL, ma l'accelerazione OpenCL aiuta principalmente la velocità di bake sulla workstation, non la simulazione parallela di frame lato farm. Modello pratico: cuocere localmente, caricare la sequenza .vdb, renderizzare sulla flotta GPU.

# Renderizzare un Pyro plume in cache tramite husk su uno stage USD,
# con Karma XPU sul nodo GPU e volume samples aumentati.
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'invocazione di husk contro uno stage USD che fa riferimento alla sequenza .vdb in cache consente al worker GPU di disegnare il volume senza ri-risolvere. Alzare volumesamples dal valore predefinito Karma 4 a 8 riduce il rumore nei plume densi al costo di circa 1,5–2x il tempo di rendering. Usare 16 per gli shot hero, lasciare a 4 per il pre-vis.

FLIP: liquidi, ricostruzione di superficie, narrow-band

FLIP — Fluid Implicit Particle solver — combina rappresentazioni di particelle e griglia per simulare acqua, liquidi viscosi e flusso a superficie libera. L'output è composto da due elementi: una cache di particelle (sequenza packed .bgeo.sc) e, opzionalmente, una mesh di superficie ricostruita (anch'essa .bgeo.sc). Entrambe vanno alla farm, il che significa che FLIP quasi sempre raddoppia la sua impronta su disco rispetto a Pyro a complessità equivalente.

Strategia di cache. Separare la cache di particelle e la mesh di superficie in due directory di cache distinte — le particelle si cuociono per prime, la mesh si ricostruisce dalle particelle in una rete SOP a valle. Questa suddivisione consente il re-meshing senza ri-simulare, il che conta quando la tensione superficiale o la separazione delle particelle necessita di un secondo passaggio. Una simulazione FLIP di complessità media a 200 frame con separazione delle particelle a 0,02 spesso si attesta tra 80–200 GB sul lato particelle e 20–40 GB sul lato mesh. FLIP narrow-band — dove solo le particelle vicino alla superficie sono archiviate a densità piena — riduce la cache di particelle del 60–80 % negli shot in cui il volume profondo non è visibile. Attivarlo quando la telecamera non guarda attraverso l'acqua.

La rigidità della viscosità e i vincoli CFL stabiliscono il conteggio dei substep. Le simulazioni d'acqua con viscosità 0 di solito girano con 1–2 substep; miele o metallo fuso ad alta viscosità spesso necessitano di 5–10 substep per rimanere stabili. La violazione CFL produce esplosioni di particelle, che su una farm sono molto più costose che su una workstation perché non si vedono finché il rendering non finisce.

Considerazioni sulla cloud render farm. Il tempo di upload della cache è il costo dominante per FLIP su una cloud render farm. Una cache di particelle da 100 GB su un uplink client da 100 Mbps richiede circa 2,5 ore prima che il primo frame di rendering possa iniziare. Con un uplink da 1 Gbps, la stessa cache si carica in ~15 minuti — la differenza è spesso ciò che decide se il FLIP cloud è operativo per uno shot. Verificare le dimensioni della cache prima di caricare.

# Sonda Hython — eseguire da una workstation o worker per calcolare
# la dimensione della cache per frame prima di pagare la larghezza di banda
# di upload per una simulazione FLIP multi-TB. Usare come verifica preliminare.
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} frame, {total/1e9:.2f} GB totali, "
      f"{(total/frames)/1e6:.1f} MB/frame media")

Se la media per frame supera 500 MB e il totale supera 100 GB, accettare la finestra di upload o rivedere la separazione delle particelle, il narrow-band e la soglia della mesh di superficie prima del trasferimento.

Vellum: cloth, soft body, serializzazione dei vincoli

Vellum è il framework di dinamica basata sulla posizione di Houdini — cloth, soft body, capelli, granuli, fluidi in una formulazione a posizione vincolata. L'output è una cache .bgeo.sc per frame, ma a differenza di Pyro o FLIP, le cache Vellum trasportano lo stato dei vincoli oltre alle posizioni dei punti. Il grafo dei vincoli (pin, stretch, bend, attach-to-static) deve serializzarsi correttamente altrimenti il worker della farm ri-risolve con vincoli rotti. Consulta la documentazione del solver Vellum per la matrice dei tipi di vincolo.

Strategia di cache. Salvare in cache dopo il Vellum Solver DOPnet, prima di qualsiasi pulizia SOP a valle. Usare il Vellum I/O SOP anziché un File Cache generico, perché Vellum I/O preserva gli attributi dei vincoli (__constraintnetwork, restlength, stiffness) che una cache generica eliminerebbe. Il pre-roll conta: il cloth necessita di 20–40 frame di assestamento prima che inizi l'intervallo di frame della telecamera, e il pre-roll deve essere nella cache altrimenti il worker renderizzerà il frame 1 con cloth non assestato. La maggior parte dei rig di produzione Vellum cuociono il pre-roll nei frame da -20 a 0 della cache.

Il conteggio dei substep è la causa più comune di errori Vellum lato farm. I substep predefiniti del Vellum Solver (5) funzionano per drappeggi lenti e cloth base dei personaggi, ma movimenti veloci, rapporti di stiramento elevati e reti di pin strette spesso necessitano di 10–20 substep per rimanere stabili. Fissare il conteggio dei substep esplicitamente nel DOPnet — lasciare che il worker della farm usi il suo predefinito è il punto in cui la stabilità tra i frame tende a rompersi, perché le cache cotte sulla workstation con substep 10 non corrispondono alle cache ricostruite dal worker con substep 5.

Considerazioni sulla cloud render farm. Vellum è limitato dalla CPU, single-threaded per solver (con multi-thread limitato nella risoluzione dei vincoli), e la dimensione della cache è modesta — di solito 5–20 GB per shot — quindi il collo di bottiglia dell'upload è meno acuto rispetto a FLIP. Il costo dominante su una farm è il tempo di ricostruzione se il .hip viene inviato anziché una cache cotta. Una cache Vellum da 4 GB (costume di media complessità) impiega tipicamente 30–90 minuti per cuocersi su un singolo worker E5-2699. Cuocendo localmente prima e caricando la cache, la farm vede solo il costo di rendering.

# Cuocere in batch un solve di Vellum cloth in .bgeo.sc con una
# sostituzione esplicita dei substep. I conteggi predefiniti dei substep
# sono il punto in cui la stabilità lato farm tende a rompersi sul cloth di qualità produzione.
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 sostituzione -v vellum_substeps=10 fissa il conteggio dei substep indipendentemente da ciò che dice il parametro DOPnet salvato del .hip. Questo è il singolo hedge più sicuro contro la deriva di stabilità Vellum lato farm.

Distruzione: RBD, Bullet, reti di vincoli

La distruzione in Houdini significa dinamica dei corpi rigidi — RBD Solver, Bullet e le reti di vincoli che incollano, fissano o rompono la geometria fratturata. Il formato della cache è primitivi packed .bgeo.sc, dove ogni prim packed rappresenta un frammento fratturato e la rete di vincoli è archiviata come un .bgeo.sc separato per frame. Fraturare prima della simulazione — fatto nei SOP, non nei DOP — e solo la geometria post-frattura più la rete di vincoli va al solver.

Strategia di cache. Due cache contano: la geometria fratturata (statica, un frame) e lo stato dinamico di trasformazione per frame. Salvare in cache solo le trasformazioni durante la simulazione, poi applicarle al momento del rendering tramite il workflow Packed Disk Primitive. Questo separa la geometria pesante (spesso 5–50 GB di pezzi fratturati) dallo stato dinamico economico (tipicamente 10–50 MB per frame). La geometria si carica una volta; la cache dinamica si carica per shot.

La serializzazione della rete di vincoli è l'insidia. I vincoli RBD (glue, hard, soft, cone-twist) trasportano un attributo __constraintnetwork che l'equivalente Vellum I/O — il RBD I/O SOP — gestisce correttamente, ma un File Cache generico no. Usare RBD I/O per il lato vincoli; usare la cache standard di prim packed per le trasformazioni.

Considerazioni sulla cloud render farm. Le simulazioni RBD sono deterministiche se i seed casuali sono fissati. Il comportamento predefinito — seed controllati da $F, seed dell'ora del giorno, o seed non impostati — produce diversi pattern di frattura su worker diversi. Su una farm dove un worker ricostruisce la cache e un altro renderizza contro un pattern atteso (ad es., una configurazione di compositing pre-costruita su una cache di workstation), la deriva dei seed produce discrepanze visibili che emergono solo dopo che il render arriva. Fissare ogni seed casuale prima del bake.

# Bake deterministico di RBD — fissare RBD_SEED in modo che due worker
# che renderizzano lo stesso intervallo di frame producano cache di frattura identiche.
# Senza questo, i solve di frattura possono desincronizzarsi tra workstation
# e farm, emergendo come discrepanze nel 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 è più veloce per grandi conteggi di pezzi (1.000+ frammenti) e accettabile per distruzione di media qualità; il RBD Solver è più preciso per dinamiche di shot hero, crollo di pile e configurazioni controllate da vincoli, con un costo di solve per frame circa 3–5x maggiore. Su una farm, Bullet è il predefinito pratico a meno che lo shot non sia hero.

Crowds: agenti, LOD, handoff ragdoll

Houdini Crowds è il framework di simulazione degli agenti — popolazioni di agenti con librerie di clip di movimento, stati comportamentali e varianti LOD. La cache è più complessa rispetto ad altri tipi di simulazione: cache degli agenti (clip di movimento .bclip.sc), cache di trasformazione del crowd (.bgeo.sc per frame) e riferimenti packed prim degli agenti che si risolvono al momento del rendering. Ogni agente ha la propria gerarchia LOD, scambiata al momento del rendering tramite set di varianti Solaris.

Strategia di cache. Cuocere la simulazione crowd in una cache di trasformazione .bgeo.sc (un file per frame, contenente la trasformazione per agente più l'indice del clip di movimento). La geometria dell'agente — i dati effettivi della mesh — vive in una libreria .bclip.sc separata che è referenziata, non cotta per frame. Questa suddivisione è l'intera ragione per cui i render crowd sono trattabili: uno shot con mille agenti potrebbe avere una cache di trasformazione da 200 MB per frame ma solo 2 GB di geometria degli agenti in totale, referenziata dal disco.

Il caching dei clip di movimento conta perché i crowd animano mescolando clip, non con keyframe per frame. La libreria dei clip deve essere sul worker prima che inizi il rendering. Cuocere la libreria dei clip una volta, caricarla nello storage persistente del worker, poi gli upload per shot sono solo la cache di trasformazione.

L'handoff del ragdoll — dove un agente passa dall'animazione controllata dai clip alla fisica controllata da RBD — necessita di trattamento speciale sulla farm. La cache dello stato del ragdoll è separata dalla cache di trasformazione del crowd, e il frame di handoff deve essere deterministico, il che significa fissare seed e frame di inizio del ragdoll esplicitamente. Altrimenti worker diversi producono traiettorie di ragdoll diverse.

Considerazioni sulla cloud render farm. I crowd renderizzano su Karma (CPU e XPU) tramite stage Solaris, con varianti LOD degli agenti risolte al momento del rendering. Lo scambio LOD al momento del rendering significa che è possibile cambiare il LOD per shot senza ri-simulare — gli agenti ad alto LOD renderizzano per gli shot hero, quelli a basso LOD per gli shot ampi, senza toccare la cache.

# Renderizzare uno stage crowd Solaris con LOD agente selezionato
# all'invocazione di husk. Karma rispetta le varianti prim degli agenti
# per lo scambio LOD senza ricostruire la simulazione 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 sostituzione lodVariant:value=mid seleziona il set di varianti agente mid-LOD al momento del rendering. Passare a low per le passate di sfondo distanti e a high per il primo piano hero senza ri-eseguire la simulazione crowd. Questo è il maggiore risparmio sui costi per shot nel rendering cloud crowd — il LOD al momento del rendering consente a una cache di servire ogni shot in una sequenza.

Limiti onesti: quando la farm non è lo strumento giusto

Una cloud render farm non è la risposta a ogni problema di simulazione Houdini, ed essere espliciti su questo impedisce che gli shot finiscano sulla farm perché nessuno ha posto la domanda a monte.

La simulazione distribuita è in larga misura irrealizzabile. I solver Pyro, FLIP, Vellum e RBD sono per lo più vincolati a una singola macchina dalla coerenza dei substep del DOPnet. PDG può distribuire wedge e lavoro SOP indipendente dai frame, ma il ciclo di solve interno in genere non può ramificarsi tra nodi worker a metà simulazione. Se la simulazione non si adatta a una macchina — e il worker della farm è tipicamente un Dual Xeon E5-2699 V4 con 96–256 GB RAM, non radicalmente diverso da una workstation di fascia alta — spostarla sulla farm non risolve il problema.

Calcolo della larghezza di banda di upload della cache. Una cache FLIP da 100 GB su un uplink client da 100 Mbps richiede circa 2,5 ore prima che inizi il primo frame di rendering. Gli upload della cache sono tempo di orologio da parete che si paga prima che avvenga qualsiasi rendering. L'uplink Gigabit aiuta; la larghezza di banda della workstation client spesso no.

Il trade-off GPU vs. CPU nella simulazione è risolto, ma non nel modo in cui gli utenti si aspettano. Pyro e FLIP hanno percorsi OpenCL che accelerano i solve dei substep sulla workstation. Il vantaggio lato farm è il rendering parallelo dei frame della simulazione in cache, non la simulazione parallela dei frame. Riformulare: GPU sulla farm equivale ad accelerazione del rendering tramite Karma XPU o Redshift; CPU sulla farm equivale a ricostruzione della cache se si invia un .hip anziché una cache.

Latenza di iterazione nell'aggiustamento della simulazione lato cloud. Se si modifica un parametro di densità di Pyro e si ha bisogno di ri-simulare, si carica nuovamente il .hip modificato, si ri-crea la cache sul worker e poi si renderizza. Il ciclo sulla farm è spesso 4–8x il ciclo locale per lavoro intensivo di simulazione. Salvare in cache sulla workstation se questa riesce a gestire la risoluzione; la farm vince sul lato del rendering, non sul lato dell'iterazione.

Disponibilità di token di licenza per Houdini Engine. L'utilizzo render-only su una farm gestita copre i worker di rendering Houdini, ma le licenze di Houdini Engine (per pipeline procedurali con HDA intensivi, workflow di asset di gioco) sono un tipo di seat separato. Confermare con la farm se i token Engine sono in pool e come viene gestita la concorrenza prima di inviare scene dipendenti da Engine. Quando la farm è lo strumento giusto ma la domanda diventa quale farm, il nostro confronto diretto delle render farm Houdini copre cinque fornitori gestiti in base a criteri specifici per Houdini.

Riepilogo delle raccomandazioni per il workflow

Per tipo di simulazione, la decisione di salvare in cache localmente vs. cuocere sulla farm di solito ricade così. Pyro: cuocere localmente, caricare .vdb, renderizzare GPU. FLIP: cuocere localmente se l'uplink supporta la dimensione della cache, altrimenti considerare la ricostruzione hbatch sul worker. Vellum: quasi sempre cuocere localmente — le cache sono piccole, i tempi di ricostruzione non sono banali. Distruzione: cuocere localmente con seed fissati, caricare la cache di trasformazione (non la geometria completa per frame). Crowds: cuocere la cache di trasformazione localmente, caricare una volta con la libreria degli agenti, renderizzare con varianti LOD per shot.

L'albero decisionale attraverso cui guidiamo i nuovi clienti Houdini sulla nostra pagina Houdini cloud render farm copre la matrice dei renderer al livello del compratore; questo articolo ha coperto i controlli di ottimizzazione a livello FX-TD sottostanti. Il prezzo CPU nella nostra tariffa pubblicata è $0,004/GHz-ora — rilevante quando si dimensiona una ricostruzione della cache di più giorni rispetto a un'alternativa con workstation. La matrice dei renderer sulla nostra farm supporta Karma XPU e Karma CPU, Mantra, Redshift, Arnold, V-Ray per Houdini e Octane.

FAQ

Q: Qual è la migliore impostazione di compressione .bgeo.sc per la larghezza di banda di upload cloud? A: Per le cache di particelle FLIP, il .bgeo.sc predefinito (compressione packed sparse) è già quasi ottimale per l'upload — il formato è progettato per questo. Il singolo maggiore guadagno di larghezza di banda è a monte: attivare FLIP narrow-band quando la telecamera non guarda attraverso il volume profondo, il che può ridurre la dimensione della cache di particelle del 60–80 % prima ancora che la compressione venga eseguita. Per le cache Vellum e RBD, il .bgeo.sc è analogamente già ottimale; i guadagni derivano dal salvare in cache solo ciò che cambia (trasformazioni, non geometria completa per frame), non dal cambiare il formato.

Q: Posso eseguire simulazioni Pyro o FLIP distribuite su più worker cloud? A: No, non per il ciclo di solve interno. Pyro, FLIP, Vellum e RBD si basano tutti sulla coerenza dei substep del DOPnet — il frame N dipende dal frame N-1 nello stesso contesto del solver — quindi il solve non può ramificarsi tra nodi worker a metà simulazione. PDG può distribuire wedge (sweep di parametri) e lavoro SOP indipendente dai frame, ma il solver effettivo gira su una macchina. Il vantaggio della farm nel lavoro di simulazione è il rendering parallelo dei frame della cache cotta, non la simulazione parallela dei frame.

Q: Devo salvare Vellum in cache sulla workstation o sulla farm? A: Quasi sempre sulla workstation. Le cache Vellum sono modeste (tipicamente 5–20 GB per shot), i tempi di bake sulla workstation sono gestibili (30–90 minuti per un costume di media complessità su una singola CPU), e la cache si carica in modo economico. Lasciare che il worker della farm ricostruisca una cache Vellum dal .hip significa pagare GHz-ore CPU lato worker che si sarebbero spese localmente gratuitamente. L'eccezione: scenari di revisione dello shot dove si modifica il .hip e il cambio di substep invalida la cache; in quei casi, la ricostruzione sulla farm è ragionevole.

Q: Karma XPU supporta il rendering volumetrico di file Pyro .vdb in cache su un worker cloud? A: Sì. Karma XPU consuma volumi OpenVDB in modo nativo tramite stage Solaris, e un'invocazione husk contro uno stage USD che fa riferimento alla sequenza .vdb in cache renderizza il volume senza ri-risolvere. Il worker GPU disegna il volume direttamente; la simulazione non deve essere presente sul worker. Alzare karma:volumesamples dal valore predefinito 4 a 8 per volumi di qualità produzione, 16 per shot hero — il costo è circa 1,5–2x il tempo di rendering per raddoppio.

Q: Come mantengo le simulazioni di distruzione RBD deterministiche su worker cloud? A: Fissare ogni seed casuale nel DOPnet prima del bake — RBD_SEED, seed di frattura e qualsiasi seed controllato da $F o dall'ora del giorno. Senza il fissaggio dei seed, la stessa scena RBD cotta su due worker diversi produce diversi pattern di frattura, il che emerge come discrepanze nel compositing quando un riferimento renderizzato sulla workstation e un finale renderizzato sulla farm non corrispondono. Impostare il seed come variabile globale nell'invocazione hbatch (set -g $RBD_SEED 42) e verificare che il DOPnet lo legga.

Q: Ho bisogno di licenze Houdini Engine per renderizzare simulazioni crowd su una cloud render farm? A: Dipende da come è costruita la pipeline crowd. Una simulazione crowd che cuoce in una cache di trasformazione .bgeo.sc e renderizza tramite Karma contro la cache non ha bisogno di Engine — il tier di licenza render-only lo gestisce. Una simulazione crowd che esegue HDA al momento del rendering (generazione procedurale di agenti, asset procedurali istanziati) potrebbe aver bisogno di seat Engine. Confermare con la farm se i token Engine sono in pool e come viene gestita la concorrenza. Sulla nostra farm, il modello di licenza render-only ci consente di renderizzare Karma XPU sulla flotta GPU e renderer CPU sulla flotta CPU senza vincoli di seat Engine; le pipeline crowd con HDA intensivi devono essere discusse durante la configurazione dello shot.

Lettura correlata

• Houdini Cloud Render Farm
• Guida alla configurazione di Houdini Cloud Render Farm per il 2026
• Confronto diretto delle render farm Houdini 2026
• Guida al costo per frame della render farm

Risorse esterne

• Documentazione SideFX Houdini
• Documentazione SideFX Pyro
• Documentazione SideFX Vellum
• Riferimento alla riga di comando Husk