Configurare Houdini per il rendering cloud \| SuperRenders

Houdini sulla nostra farm è un ambiente multi-renderer costruito attorno alla moderna pipeline USD-first. Karma XPU è il percorso raccomandato da SideFX per i nuovi progetti in Houdini 20.5 ed è il renderer principale presentato nella nostra landing page . Karma CPU e Mantra restano disponibili per i lavori legacy; i renderer di terze parti — Redshift, Arnold, V-Ray for Houdini, Octane — sono supportati per gli studi con pipeline consolidate in questi motori. Questa pagina tratta il packaging del progetto (che in Houdini include HDA e cache di simulazione, non solo texture), il flusso di lavoro con gli asset Solaris/USD, le note specifiche per ogni renderer, il flusso di invio e i problemi di troubleshooting più frequenti che riscontriamo nei ticket di supporto.

Una nota sulle licenze prima di iniziare: gestiamo le installazioni di Houdini sulla farm con una licenza di sola renderizzazione (render-only utilization), che consente di eseguire Houdini sui worker per il rendering offline dei progetti dei clienti. Super Renders Farm non è un partner SideFX — la render-only utilization è il quadro legale che permette il rendering farm delle scene Houdini senza occupare un seat SideFX dal pool di licenze del Suo studio. Lei non trasferisce la Sua licenza Houdini a noi, e il tier del progetto lato artista (Indie, Core, FX) non determina l'accordo di licenza del worker. Il worker attinge dalla licenza della farm dal proprio lato.

Per il posizionamento generale — versioni Houdini supportate, adattamento hardware, esempi di prezzo — la landing page dedicata è il riferimento canonico. La pagina che sta leggendo è il documento di workflow: cosa fare in Houdini prima di fare clic su Submit.

Versioni supportate

Houdini 19.5, 20.0 e 20.5 sono preinstallati su ogni worker della farm. Seguiamo il calendario delle versioni di SideFX e provisioniamo le nuove build principali entro quattro settimane dalla disponibilità pubblica. Le point release (ad esempio Houdini 20.5.410 vs. 20.5.487) vengono monitorate continuamente; se il Suo progetto è vincolato a un numero di build specifico per un problema di compatibilità dei nodi, indichi il numero di build nelle note del job all'invio e abbiniamo il worker alla build richiesta.

Sia i file di scena Houdini FX (il tier di produzione) che Houdini Indie (.hip e .hipnc) vengono caricati sul worker e renderizzati nell'ambito del regime render-only utilization della farm. Il tier lato artista (Indie vs. Core/FX) non si propaga al seat di licenza del worker — il worker utilizza qualsiasi tier che la farm provvede per il rendering. I file Houdini Apprentice vengono renderizzati ma producono output con watermark secondo i termini della licenza non commerciale di SideFX; per lavori di produzione a pagamento, salvare la scena da una licenza non-Apprentice prima dell'invio. Le licenze Education seguono la stessa regola.

Una nota sul ritmo delle versioni di Houdini: SideFX rilascia versioni principali ogni 12–18 mesi e aggiornamenti point più frequentemente. Karma XPU in particolare è migliorato sostanzialmente tra le versioni 19.5, 20.0 e 20.5 — funzionalità che richiedevano il fallback su CPU in 19.5 (volumi densi, certi network di shader) sono native XPU in 20.5. Se il Suo progetto dipende da una funzionalità Karma XPU introdotta in una build specifica, blocchi la build nelle note del job invece di lasciare che il worker scelga l'ultima disponibile.

Packaging del progetto Houdini

Un progetto Houdini è molto più del semplice file di scena .hip (o .hipnc). Include tipicamente: HDA (Houdini Digital Asset — formato .hda o il più vecchio .otl), file di cache di simulazione (.bgeo, .bgeo.sc, .vdb, .abc), layer e riferimenti USD di asset Solaris (.usd, .usda, .usdc), mappe texture e qualsiasi geometria esterna importata tramite File o Alembic SOP. Il rendering cloud ha successo quando ogni dipendenza referenziata dalla scena è presente sul worker; fallisce quando qualcosa si risolve localmente tramite un percorso specifico della workstation ma non ha dove risolversi sulla farm.

Le convenzioni di percorso di Houdini sono basate su variabili d'ambiente — più comunemente $HIP (si risolve nella directory contenente il file .hip), $HIPNAME (il basename del file di scena) e $JOB (la root del progetto, impostata tramite variabile d'ambiente). Per il rendering cloud, la convenzione affidabile è usare percorsi relativi a $HIP ovunque. I passaggi di packaging riportati di seguito applicano questa convenzione end-to-end:

Impostare la cartella del progetto. Quando si salva un nuovo progetto, Houdini imposta $HIP sulla directory contenente il file .hip. Verificare nella shell Python con hou.text.expandString('$HIP') — il percorso deve corrispondere alla posizione del file di scena.
Usare la struttura standard delle sottocartelle. $HIP/cache/ per le simulazioni, $HIP/geo/ per Alembic e geometrie esterne, $HIP/tex/ per le texture, $HIP/hda/ per gli asset digitali, $HIP/usd/ per i layer e riferimenti USD, $HIP/render/ per l'output. Tutti i percorsi nei File SOP, File COP, output ROP e riferimenti texture della scena devono usare $HIP/... invece di percorsi assoluti con lettera di unità.
Verificare che i percorsi si risolvano. File → Refresh All. Houdini segnala eventuali riferimenti a file non risolti nella Console. Dalla shell Python, hou.fileReferences() restituisce l'elenco completo dei riferimenti esterni — scansionare quelli che iniziano con D:\, Y:\, una condivisione UNC come \\server\, o qualsiasi percorso che il worker non può raggiungere.
Bake delle simulazioni su disco. La farm non esegue simulazioni come parte del job di rendering — le simulazioni sono lavoro della workstation, e la farm esegue il rendering contro file di cache pre-baked. Fare il bake di tutte le reti DOP (FLIP fluidi, Pyro, Vellum cloth, RBD Bullet, grani), solver di particelle e qualsiasi altro output di simulazione in file .bgeo.sc o .vdb in $HIP/cache/ prima dell'invio. Il File Cache SOP con "Save to Disk" è il workflow standard.
Integrare o includere gli HDA. Se la scena usa HDA personalizzati da una libreria dello studio, è possibile integrarli nel .hip (Asset menu → Save Operator Type → "Embedded") o includere i file .hda/.otl in $HIP/hda/ in modo che il worker possa caricarli dalla cartella del progetto. Le librerie HDA condivise dello studio su unità di rete non sono raggiungibili dal worker.
Appiattire o raggruppare i layer USD. Se la scena usa Solaris/LOPs, è possibile fare il bake dello stage USD in un singolo file USD composto tramite il USD ROP prima dell'invio, oppure includere l'intera struttura di directory $HIP/usd/ in modo che ogni layer si risolva sul worker. Le regole di risoluzione degli asset USD sono trattate in dettaglio nella sezione successiva.
Archiviare l'intera cartella $HIP. Usare .tar, .tar.gz o .7z. Non accettiamo upload .zip per i progetti Houdini (le convenzioni di naming di Houdini a volte contengono caratteri che si rompono negli archivi .zip Windows sui worker Linux).

Un problema tipico specifico di Houdini: i campi "Pre-Render Script" e "Post-Render Script" sui nodi ROP a volte referenziano script Python specifici della workstation — gli strumenti pipeline dello studio, un percorso di configurazione locale di Houdini, una chiamata hou.ui.displayMessage che apre una finestra di dialogo per cui il worker non ha display. Il rendering cloud fallisce silenziosamente oppure rimane in attesa di un input che non arriverà mai. Controllare qualsiasi callback Python o HScript di pre-rendering prima dell'invio; disabilitare o rendere portabili qualsiasi codice che tocchi percorsi solo locali, chiamate UI, o hou.system() shell-out verso binari della workstation. Preferire il logging con print() rispetto ai callback interattivi.

Solaris, layer USD e risoluzione degli asset

Se la scena è creata in Solaris (la rete LOPs /stage), il layer di risoluzione degli asset USD aggiunge una dimensione extra all'invio cloud non presente nelle scene solo OBJ/SOP. Il resolver USD di Houdini segue le regole standard di risoluzione degli asset USD: i riferimenti in un layer vengono risolti rispetto al percorso identificatore del layer, ai percorsi di ricerca configurati tramite houdini.env o il plugin del resolver di asset, e a qualsiasi arco di composizione usato dallo stage (riferimenti, sublayer, payload).

Per l'invio cloud, due pattern funzionano in modo affidabile:

Appiattire lo stage. Usare il nodo USD ROP con "Save to Disk" e l'opzione "Flatten Stage" abilitata. Il risultato è un singolo file .usd composto (o .usdc per il binario) che contiene l'intero stage con tutti i riferimenti risolti. Questo è il pattern più semplice — il worker legge un file, senza indirizzamento tramite resolver — ma si perde la struttura a layer che rende USD prezioso per la collaborazione.
Raggruppare l'intero albero degli asset. Posizionare tutti i layer USD in $HIP/usd/ e usare riferimenti relativi a $HIP nei sublayer, nei riferimenti e nei payload. Il worker risolve $HIP nella root di upload, quindi i file di layer nella stessa posizione relativa si caricano correttamente.

Una sottigliezza: l'"Asset Reference" LOP di Solaris e il Reference SOP nei contesti /obj serializzano entrambi il percorso di riferimento così com'è scritto. Se si è scritto D:\studio_assets\char_robot.usd in un Reference LOP, il worker non ha D:\ e il riferimento fallisce. Riscrivere il riferimento come $HIP/usd/char_robot.usd (o ${SRF_ASSETS}/char_robot.usd con una mappatura di variabile d'ambiente documentata che la farm riconosce). Più semplice è il percorso, più affidabilmente viaggia.

Una seconda sottigliezza: le librerie di asset USD possono portare il proprio indirizzamento di versioning. Uno stage Solaris che referenzia asset USD compilati contro USD 23.x potrebbe non caricarsi correttamente su un worker con USD 22.x integrato in una build più vecchia di Houdini. La matrice di versioni Houdini-e-USD è importante — se la propria libreria di asset è stata creata per la versione USD di Houdini 20.5, eseguire il rendering su worker Houdini 20.5.

Gestione degli HDA

Gli Houdini Digital Asset (HDA, ancora spesso indicati con la vecchia estensione .otl) sono network di nodi riutilizzabili impacchettati come file di asset autonomi. Sono comuni nelle pipeline di produzione, in particolare per gli asset procedurali — edifici, vegetazione, sistemi di folla, solver personalizzati — creati separatamente dai singoli shot e condivisi tra le scene.

Tre pattern per la gestione degli HDA sulla farm:

Integrare l'HDA nel file .hip. Asset menu → Operator Type Manager → clic destro sull'HDA → "Save to Embedded." L'HDA è ora memorizzato all'interno del .hip e viaggia con la scena. Questo è il pattern più sicuro per job occasionali o per HDA creati specificamente per un singolo shot.
Raggruppare gli HDA in $HIP/hda/. Posizionare tutti i file .hda/.otl in una sottocartella del progetto, poi in Houdini → Edit → Preferences → File Locations, assicurarsi che $HIP/hda/ faccia parte del percorso di ricerca OTL (in alternativa, impostare HOUDINI_OTLSCAN_PATH per includere $HIP/hda/ nel houdini.env). Il worker legge gli HDA da questa posizione al caricamento della scena.
Referenziare HDA da una libreria condivisa dello studio. Se lo studio usa una libreria HDA condivisa su un'unità di rete (ad esempio \\studio-fs\houdini\hda\), quella libreria non è accessibile dal worker. È necessario copiare gli HDA rilevanti in $HIP/hda/ prima dell'invio, oppure integrarli nel .hip.

Prima dell'invio, elencare gli HDA caricati nella scena dalla shell Python:

text

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

Ogni percorso nell'output deve risolversi sotto $HIP o essere un HDA stock SideFX fornito con Houdini stesso (questi sono preinstallati su ogni worker). Qualsiasi HDA di terze parti che si trova fuori da $HIP non verrà trovato.

Gestione dei file di cache

I file di cache sono tipicamente la singola categoria più grande in un upload di progetto Houdini — simulazioni FLIP, cache Pyro, bake Vellum cloth, export Alembic e volumi VDB possono ciascuno raggiungere decine o centinaia di gigabyte. Due pattern riducono i tempi di upload senza compromettere il rendering:

Comprimere le cache al momento del bake. .bgeo.sc (bgeo compresso, compressione blosc) è significativamente più piccolo di .bgeo per la stessa geometria ed è il default moderno per i File Cache SOP. Per i file VDB, il volume è già compresso all'interno del contenitore OpenVDB, ma gli archivi .tar.gz comprimono bene i metadati della directory circostante.
Usare $HIP/cache/ in modo coerente. Il File Cache SOP di Houdini ha come default $HIP/cache/{node_name}/$F4.bgeo.sc, che è il pattern corretto per le scene portabili sulla farm. Evitare percorsi assoluti di cache come D:\sim_cache\ — il worker non ha D:\ e il rendering inizierà, registrerà avvisi "cannot find cache file" e produrrà geometria vuota dove dovrebbe esserci la simulazione.

Per simulazioni molto grandi — cache FLIP o Pyro multiterabyte che superano la capacità di un upload browser — usare SFTP invece del modulo di upload web. Il documento tratta il workflow SFTP, la riprendibilità degli archivi e le soglie pratiche per passare dall'upload web all'SFTP.

Una nota di workflow per gli studi che eseguono il caching sulla workstation ma renderizzano sulla farm: se la directory di cache è su un SSD locale veloce e il file di progetto usa $HIP/cache/, la cache si muove con il progetto all'upload — non è necessaria alcuna rimappatura manuale. Se il pattern della workstation è quello di fare il caching su un'unità di rete condivisa e il .hip referenzia direttamente quell'unità, sarà necessario copiare le cache in $HIP/cache/ e aggiornare i percorsi del File Cache SOP, oppure impostare una variabile d'ambiente $JOB sul worker che rispecchi la condivisione di rete della workstation (meno affidabile; l'approccio con percorsi relativi è preferibile).

Cosa verificare prima dell'invio

Una breve checklist pre-flight per qualsiasi invio Houdini:

Il nodo ROP attivo è impostato correttamente. Output context → Render. Il ROP selezionato al momento dell'invio determina quale renderer il worker invoca. ROP non corrispondenti (ad esempio, selezionare un Karma ROP per una scena la cui illuminazione era creata per Mantra) sono la causa più comune dei ticket "il rendering sembra completamente diverso".
L'intervallo di frame corrisponde alle impostazioni ROP. L'intervallo di frame memorizzato nel ROP (parametri f1, f2, f3) è quello che il worker usa, non l'intervallo di riproduzione della timeline né il frame corrente del viewport. Confermare che l'intervallo di frame del ROP corrisponda a quello che si intende renderizzare.
Il percorso di output usa token relativi a $HIP. $HIP/render/$F4.exr è il default sicuro per EXR multilayer con padding a quattro cifre. Evitare percorsi assoluti con lettera di unità nell'espressione di output del ROP.
Tutti i File SOP e i riferimenti texture si risolvono. File → Refresh All. Correggere eventuali errori "Unable to read" nella Console prima dell'invio — il worker li segnalerà anch'esso, ma al costo di un frame di rendering sprecato.
Gli HDA sono integrati o in $HIP/hda/. Verificare chiudendo completamente la scena e riaprendo da una sessione Houdini diversa; se gli HDA non si caricano localmente, il worker non riuscirà a caricarli neppure.
Le cache sono state bakate. Eseguire un bake manuale della cache su ogni File Cache SOP tramite Render → Save to Disk prima dell'invio. Non fare affidamento su "Auto-Bake on Frame Change" — bakare esplicitamente e confermare che i file di cache esistano ai percorsi $HIP/cache/... attesi.
I layer USD (se Solaris) sono raggruppati o appiattiti. Includere l'intero albero $HIP/usd/ o scrivere un USD composto appiattito tramite il USD ROP.
Nessun script di pre-rendering o post-rendering interattivo. Controllare le callback Python dei ROP e i Pre-Frame Script per eventuali chiamate UI, shell-out o percorsi specifici della workstation.

Note specifiche per renderer

Karma XPU (raccomandato)

Karma XPU è il renderer ibrido CPU+GPU di SideFX, promosso a produzione-ready in Houdini 20.5 e il percorso di riferimento per i nuovi progetti Houdini. È il renderer principale nella nostra landing page Houdini e il percorso che la maggior parte dei nuovi clienti sulla farm adotta.

Note di configurazione:

Tier worker: Funziona sul nostro tier di worker GPU RTX 5090 (32 GB VRAM per scheda) per la porzione GPU del rendering, con fallback su CPU per qualsiasi funzionalità che il code path XPU non supporta ancora.
Vincoli VRAM: 32 GB VRAM per worker. Karma XPU è più efficiente in termini di VRAM rispetto ai renderer GPU puri perché può scaricare porzioni del rendering (in particolare le volumetriche) nella memoria CPU quando la VRAM è limitata — ma le scene USD molto dense con volumi ad alta risoluzione traggono comunque vantaggio dal restare entro il limite di 32 GB.
Integrazione pipeline USD. Karma è il renderer progettato per la pipeline USD basata su Solaris. Se il progetto usa /stage (contesto Solaris LOPs), Karma è la scelta naturale del renderer e il worker risolve i riferimenti agli asset USD allo stesso modo in cui risolve i riferimenti File SOP — i percorsi relativi a $HIP vincono.
AOV. Configurati per render-product nel prim Render Settings dello stage USD. L'EXR multicanale è il formato di output predefinito ed è quello che raccomandiamo per le pipeline VFX (preserva tutti gli AOV in un singolo file per frame).
Sampling. I campioni di path-tracing di Karma sono configurati per prim Render Settings. Calibrare localmente su un singolo frame prima di inviare una sequenza — la convergenza dei campioni XPU è diversa da quella CPU, e la calibrazione si trasferisce direttamente al worker.
Motion blur. Karma XPU supporta il motion blur della geometria e lo shutter-window blur. Confermare che l'impostazione dello shutter del motion-blur sulla camera prim USD corrisponda a ciò che il prim Render Settings si aspetta — la gestione dello shutter Solaris e il sampling del motion-blur Karma non sempre concordano sui principi di base, e il sintomo è "il rendering sembra corretto ma il motion blur è assente o raddoppiato."

Karma CPU

Karma CPU è la variante puramente CPU di Karma. Completo di funzionalità e stabile dalla versione Houdini 19; il fallback naturale per le scene che superano la VRAM GPU o si basano su funzionalità non ancora implementate nel code path XPU.

Note di configurazione:

Tier worker: Tier di worker CPU (nodi Dual Intel Xeon E5-2699 V4, 96–256 GB RAM per nodo, oltre 20.000 core CPU aggregati nell'intera flotta).
Quando usarlo invece di Karma XPU: geometria molto pesante (>50 milioni di poligoni), rendering volumetrico denso che supera i 32 GB VRAM, shader OSL personalizzati che non hanno ancora un equivalente XPU, o progetti che mischiano passaggi di simulazione CPU-intensive nella stessa sessione di invio.
Stessa integrazione Solaris/USD di Karma XPU. La configurazione del render product e degli AOV è identica; cambia solo il backend computazionale.

Mantra (legacy)

Mantra è il renderer pre-Karma di Houdini — il motore micropolygon di SideFX precedente alla pipeline USD-first. SideFX ha indicato che Mantra non è il percorso futuro; Karma lo è. Mantra rimane nella build di Houdini per la compatibilità retroattiva con i progetti creati prima che Karma fosse praticabile.

Note di configurazione:

Tier worker: Tier di worker CPU.
Prestazioni. Mantra è generalmente più lento per frame rispetto a Karma CPU per scene equivalenti e non dispone del percorso di accelerazione GPU che Karma XPU offre. I nuovi progetti dovrebbero usare Karma.
Quando usarlo. Quando il file di progetto è vincolato a Mantra (una produzione in corso iniziata prima che Karma fosse praticabile, una libreria di shader non ancora portata), o quando si ha bisogno di una funzionalità specifica di Mantra (alcuni casi limite del micropolygon di Mantra non hanno un equivalente esatto in Karma). Per nuovi lavori nel 2026, usare Karma come default.

Redshift per Houdini

Redshift per Houdini funziona sul nostro tier di worker GPU RTX 5090. Redshift è la scelta per gli studi con pipeline Redshift consolidate — spesso studi Maya o Cinema 4D che si avvicinano a Houdini per gli FX e vogliono condividere le librerie di shader tra i DCC.

Note di configurazione:

Licenza. Redshift sulla nostra farm funziona con la nostra licenza . Redshift è ora un prodotto Maxon, e la nostra partnership Maxon copre Redshift su tutti i DCC che supportiamo (C4D, Houdini, Maya).
Out-of-core memory. Abilitata per default. Estende la memoria effettiva della scena oltre il limite di 32 GB VRAM per worker, importante per le scene dense che altrimenti andrebbero in OOM sulla GPU.
Funzionalità specifiche di Houdini. Redshift si integra direttamente con i tipi di primitive di volume di Houdini (VDB, cache Pyro) — non è necessario un passaggio di export speciale per il rendering volumetrico. Il Redshift ROP espone parametri nativi di Houdini per ray bias, sampling e configurazione degli AOV.
Version pinning. Redshift viene rilasciato nel proprio ciclo 3.x, indipendente dal calendario di versioni di Houdini. Le versioni principali di Redshift (3.0 → 3.5 → 4.0 quando verrà rilasciata) non garantiscono la compatibilità retroattiva — una scena salvata con Redshift 3.5.18 potrebbe non caricarsi correttamente su un worker che esegue Redshift 3.0.x. Annotare la build Redshift al momento del salvataggio della scena e confermare la compatibilità del worker prima di inviare una sequenza completa.

Arnold per Houdini

Arnold per Houdini (a volte chiamato HtoA, attualmente nel ciclo di versioni Arnold 7.x) funziona sul nostro tier di worker CPU. È la scelta per gli studi con pipeline Arnold condivise Maya/Houdini, dove il lookdev è creato in un DCC e gli FX nell'altro ma il layer di shader e rendering è unificato.

Note di configurazione:

Licenza. Arnold sulla nostra farm funziona con licenze render-node Autodesk.
AOV. Il sistema AOV di Arnold in Houdini funziona allo stesso modo di Maya. Configurare per ROP e scrivere in EXR multicanale o file per AOV; il pattern cross-DCC è coerente.
Version pinning. Le versioni HtoA seguono il calendario di versioni di Arnold (HtoA 6.x per Houdini 19.5/20.0; HtoA 7.x per Houdini 20.5/21.0 quando verrà rilasciato). I salti principali di HtoA (6 → 7) non devono mai essere considerati compatibili — confermare che il worker abbia almeno la versione minore con cui la scena è stata salvata.

V-Ray per Houdini

V-Ray per Houdini funziona sul nostro tier di worker CPU. L'adozione in Houdini è notevolmente inferiore rispetto a 3ds Max o Maya, ma l'integrazione è supportata per gli studi con pipeline V-Ray-centriche.

Note di configurazione:

Licenza. V-Ray sulla nostra farm funziona con la nostra licenza .
Asset VRayProxy. Supportati. Includere i file .vrmesh in $HIP/geo/ in modo che il worker possa risolverli.
Specifiche di Houdini. Il ROP di V-Ray per Houdini espone le stesse impostazioni di rendering di V-Ray in 3ds Max — tipo di sampler, render elements (AOV), formato di output. La mappatura dei parametri cross-DCC è documentata nella documentazione V-Ray for Houdini di Chaos.

Octane per Houdini

Octane per Houdini funziona sul nostro tier di worker GPU RTX 5090. Usato principalmente dagli studi di motion design che collegano Houdini e Cinema 4D per output stilizzati.

Note di configurazione:

Licenza. Licenze render-node Otoy.
Vincoli VRAM. Come Octane per C4D — 32 GB VRAM per worker, con un profilo di memoria più aggressivo rispetto a Redshift (nessun percorso out-of-core). Le scene che si adattano a 24 GB su Redshift potrebbero necessitare di downsampling delle texture o decimazione della geometria per adattarsi a 32 GB su Octane.

Flusso di invio

Tre canali di invio funzionano per i progetti Houdini sulla farm:

Upload web + invio tramite pannello di controllo. Archiviare la cartella $HIP come .tar.gz o .7z, caricarla tramite il sito web, poi configurare il job (renderer, nodo ROP, intervallo di frame, formato di output) e inviarlo. Questo è il percorso più comune per job Houdini occasionali e progetti con una dimensione totale di upload inferiore a ~50 GB.
SFTP per progetti di grandi dimensioni. I progetti Houdini con cache di simulazione multiterabyte devono essere trasferiti tramite SFTP per trasferimenti riprendibili. Vedere per il workflow SFTP, le credenziali e la soglia per passare dall'upload web all'SFTP.
Client App. La Super Renders Farm Client App integra upload, invio e auto-download in un'applicazione desktop. Utile per gli studi con invii ricorrenti dove la stessa struttura di progetto viene re-renderizzata con variazioni ai parametri. Vedere .

Un plugin di invio per Houdini che si integra direttamente con l'interfaccia di Houdini è in sviluppo ma non ancora preinstallato su tutti i worker. Per ora, il flusso di invio tramite la dashboard web è il percorso raccomandato. La procedura guidata di invio cross-DCC — cosa compilare, come impostare l'intervallo di frame, dove trovare i file di output — è nella .

Internamente, il worker invoca i punti di ingresso del rendering batch di Houdini: hbatch per gli invii di file HIP a ROP nel contesto OBJ/SOP (Mantra, Karma CPU, Redshift, Arnold, V-Ray, Octane), e husk per gli invii di stage USD a Karma (CPU o XPU). Generalmente non è necessario conoscere l'invocazione sottostante, ma se si sta eseguendo il debug di un naming dell'output inatteso o di un comportamento dell'intervallo di frame, le impostazioni a livello di ROP sono quelle che il worker passa a hbatch/husk tramite flag a riga di comando.

Troubleshooting degli errori specifici di Houdini

Per il troubleshooting cross-DCC generale (asset mancante, rendering fallito al frame N, problemi comuni con i formati di output), vedere . Pattern di errori specifici di Houdini che vediamo più spesso nei ticket di supporto:

"Unable to find HDA" o HDA non si carica con un placeholder di nodo obsoleto. Il worker non riesce a trovare il file HDA che la scena referenzia. Verificare che gli HDA siano integrati nel .hip (Asset menu → Operator Type Manager → "Save to Embedded") o presenti in $HIP/hda/ con il percorso di ricerca configurato. Se si referenziano HDA da una libreria condivisa dello studio, copiarli nella cartella del progetto prima dell'invio.
File di cache non trovato durante il rendering / geometria di simulazione vuota. Verificare che i file di cache siano stati effettivamente bakati su disco prima dell'invio — aprire ogni File Cache SOP e confermare che la scheda "Output" mostri i file nel percorso visualizzato. Se il percorso usa una lettera di unità assoluta (D:\sim_cache\flip.0001.bgeo.sc), cambiare in $HIP/cache/{node_name}/$F4.bgeo.sc e ri-bakare. Il controllo di 60 secondi prima dell'upload — File → Refresh All, più una scansione manuale dei File Cache SOP — previene la più grande categoria singola di errori di rendering Houdini che vediamo.
Gli output del rendering sono completamente vuoti / frame neri. Controllare il prim "Render Settings" del ROP (per Karma su uno stage Solaris) o il riferimento alla camera (per Mantra, Redshift, Arnold, V-Ray, Octane su ROP nel contesto /obj). La causa più comune è una camera impostata nel viewport ma non referenziata nel ROP — il worker non ha viewport, quindi il riferimento alla camera a livello di ROP è autoritativo.
Karma XPU fallisce immediatamente con "OptiX not available" o "GPU not detected." Raro sulla nostra farm perché la flotta di worker GPU ha copertura CUDA + driver OptiX confermata. Se si verifica, la causa più comune è un worker in aggiornamento o un rollback del driver in corso; ri-inviare dopo 5–10 minuti o contattare il supporto se il problema persiste su più invii.
Lo script Python pre-rendering fallisce sul worker. Disabilitare lo script o renderlo portabile rispetto al percorso. Il Python personalizzato che referenzia percorsi di modulo specifici della workstation (gli strumenti pipeline dello studio), apre finestre di dialogo UI, o esegue shell-out verso binari locali tramite hou.system() non funzionerà su un worker Linux headless.
I riferimenti agli asset Solaris/USD si rompono. I percorsi del resolver degli asset USD devono essere relativi a $HIP, usare un contesto del resolver USD che il worker possa caricare, oppure essere appiattiti in un singolo USD composto tramite il USD ROP prima dell'invio. I percorsi assoluti nei layer di riferimento USD sono il modo di fallire più comune qui.
Mancata corrispondenza di versione del plugin / la scena non si carica. La versione del plugin locale differisce da quella del worker — più spesso salti HtoA 6 → 7 o Redshift 3.0 → 3.5. Controllare la versione del plugin al momento del salvataggio della scena (visibile tramite il testo dell'intestazione del file HIP o il timbro di versione nel menu ROP del plugin) e confermare che il worker abbia almeno quella versione minore. I salti di versione principale non devono mai essere considerati compatibili.
Mancata corrispondenza di versione di Houdini (scena 20.5 su worker 20.0). Il formato del file HIP include metadati di versione; una versione precedente di Houdini non può aprire scene salvate con versioni più recenti. Confermare che il worker abbia Houdini ≥ la versione di salvataggio della scena, o ri-salvare la scena nella versione target se assolutamente necessario.
La simulazione OpenCL non si avvia durante il rendering. Le simulazioni OpenCL avvengono al momento del bake, non al momento del rendering. Fare il bake nella cache prima dell'invio. La farm non esegue simulazioni OpenCL live durante il rendering — questo è per design e si applica a FLIP, Pyro, Vellum e qualsiasi altro solver accelerato da OpenCL.
Deriva della configurazione OCIO tra l'invio e il worker. Se la variabile d'ambiente OCIO locale punta a una configurazione specifica dello studio non presente sul worker, i colori vengono renderizzati con la configurazione default del worker e appaiono diversi. Raggruppare il file di configurazione OCIO con il progetto, impostare OCIO tramite l'override dell'ambiente di invio, o usare la configurazione ACES integrata di Houdini che il worker include anch'esso.
Avviso "missing field" di cache Pyro/FLIP tra versioni di Houdini. Il formato dei file di cache cambia occasionalmente tra le versioni principali di Houdini; una cache più vecchia caricata su una versione più recente di Houdini a volte perde campi. Ri-bakare la simulazione nella versione target di Houdini, o confermare che il worker usi la stessa build di Houdini che ha scritto la cache.

Riferimenti incrociati

— workflow di upload, invio, download (cross-DCC)
— come vengono calcolati i costi dei job Houdini (tier GPU vs CPU)
— guida SFTP, formati di archivio, trasferimenti di grandi progetti
— troubleshooting cross-DCC
— wrapper di invio desktop
— landing page (matrice renderer, hardware, esempi di prezzo)

FAQ

Q: Quali versioni di Houdini supporta la farm? A: Houdini 19.5, 20.0 e 20.5 sono preinstallati su ogni worker. Seguiamo il calendario di versioni di SideFX e provisioniamo le nuove build principali entro quattro settimane dalla disponibilità pubblica. Sono supportati sia i file di scena Houdini FX (.hip) che Houdini Indie (.hipnc). I file Houdini Apprentice vengono renderizzati ma producono output con watermark secondo i termini della licenza non commerciale di SideFX — per lavori di produzione a pagamento, salvare da una licenza non-Apprentice prima dell'invio.

Q: Devo trasferire la mia licenza Houdini per renderizzare sulla farm? A: No. Gestiamo Houdini con una licenza di sola renderizzazione (render-only utilization), che consente di eseguire Houdini sui worker per il rendering offline senza occupare un seat SideFX dal pool di licenze del Suo studio. La Sua licenza Houdini locale rimane con Lei. Super Renders Farm non è un partner SideFX — la render-only utilization è il quadro legale che permette il rendering farm delle scene Houdini.

Q: Dovrei usare Karma XPU, Karma CPU o Mantra per un nuovo progetto? A: Karma XPU per i nuovi progetti nel 2026 — è il percorso futuro raccomandato da SideFX, funziona sul nostro tier GPU RTX 5090, ed è significativamente più veloce di Karma CPU o Mantra per la maggior parte delle scene. Usare Karma CPU per le scene che superano i 32 GB VRAM, si basano su volumetriche pesanti che esauriscono la GPU, o usano shader OSL personalizzati non ancora supportati in XPU. Usare Mantra solo quando il progetto è vincolato a Mantra (una produzione in corso iniziata prima che Karma fosse praticabile, o una funzionalità di shader Mantra-specifica senza equivalente Karma). Per nuovi lavori, usare Karma come default.

Q: La farm può eseguire simulazioni Houdini (Pyro, FLIP, Vellum, RBD)? A: No — le simulazioni sono lavoro della workstation. Bakare tutte le cache di simulazione in file .bgeo.sc o .vdb localmente prima dell'invio. La farm esegue il rendering contro le cache pre-baked; non esegue simulazioni live come parte del job di rendering. Questo è lo stesso pattern dei workflow di simulazione di Blender o Maya sulla maggior parte delle farm cloud gestite.

Q: Il mio progetto usa la pipeline Solaris/USD di Houdini. Verrà renderizzato correttamente? A: Sì, con Karma (CPU o XPU) come renderer. Il percorso progettato per Solaris è Karma — entrambi i renderer consumano lo stage USD nativamente e l'integrazione Solaris/Karma è la pipeline futura raccomandata da SideFX. Per l'invio cloud, appiattire lo stage USD in un singolo file .usd composto tramite il USD ROP, oppure raggruppare l'intera struttura di directory $HIP/usd/ in modo che ogni layer si risolva sul worker. I renderer di terze parti (Redshift, Arnold) possono anche renderizzare scene basate su USD se la loro integrazione con Houdini lo supporta — verificare localmente su un singolo frame prima di inviare una sequenza completa.

Q: La mia scena usa HDA personalizzati dalla libreria condivisa del nostro studio. La farm li troverà? A: La farm non troverà HDA sull'unità di rete condivisa del Suo studio (\\studio-fs\hda\... o equivalente). Integrare gli HDA nel .hip tramite Asset menu → Operator Type Manager → "Save to Embedded," oppure copiare i file .hda/.otl in $HIP/hda/ prima di archiviare il progetto. Verificare con hou.hda.loadedFiles() dalla shell Python che ogni HDA caricato si risolva sotto $HIP o sia un asset stock SideFX.

Q: Come si impacchetta un progetto Houdini che usa cache di simulazione? A: Bakare ogni simulazione in $HIP/cache/{solver_name}/$F4.bgeo.sc (o .vdb per i volumi) localmente prima dell'invio. Verificare che i file di cache esistano ai percorsi attesi tramite File → Refresh All. Archiviare l'intera cartella $HIP — inclusa la sottocartella cache/ — come .tar.gz o .7z. Per le cache superiori a qualche centinaio di gigabyte, caricare tramite SFTP invece del modulo web. La farm esegue il rendering contro le cache bakate; la simulazione stessa viene eseguita sulla workstation, non su un worker node.

Q: Quanto può essere grande un upload di progetto Houdini? A: Non c'è un limite fisso alle dimensioni di upload, ma raccomandiamo di mantenere un singolo upload browser sotto ~50 GB. Oltre quella soglia, passare all'SFTP per trasferimenti riprendibili — vedere . La farm ha gestito rendering di simulazioni Houdini multiterabyte, tutti caricati tramite SFTP con la struttura di directory appropriata preservata.

Q: Il rendering Mantra è molto più lento sulla farm che in locale. È normale? A: La velocità per frame di Mantra sul nostro tier di worker CPU (Dual Xeon E5-2699 V4) è paragonabile a quella di una workstation di fascia alta. Se si riscontrano tempi per frame significativamente più lenti rispetto al locale, le cause più probabili sono: una configurazione di sampling diversa sul worker (Mantra legge i campioni dal ROP — confermare che le impostazioni a livello di ROP corrispondano), oppure l'accelerazione OpenCL locale non attiva sul tier solo-CPU del worker. La soluzione strutturale è la migrazione: Karma XPU sul nostro tier GPU è significativamente più veloce di Mantra per la maggior parte delle scene, e Karma è il percorso che SideFX raccomanda per il futuro.

Q: La farm supporta PDG/TOPs di Houdini per la gestione distribuita dei task? A: PDG è un'orchestrazione lato workstation; la farm usa il proprio sistema di coda e assegnazione dei worker. È possibile usare PDG localmente per creare e bakare asset, poi inviare i job ROP finali alla farm tramite la dashboard web o la Client App. L'invio diretto guidato da PDG a farm esterne è nella nostra roadmap ma non è ancora un workflow di prima classe.

Q: Come viene calcolato il costo del rendering cloud Houdini? A: Il costo di Houdini sulla farm segue il tier di worker del renderer — tariffe GPU per Karma XPU, Redshift e Octane; tariffe CPU per Karma CPU, Mantra, Arnold e V-Ray per Houdini. La complessità per frame (numero di campioni, numero di AOV, risoluzione di output) determina il costo per frame; la scelta del renderer determina la tariffa oraria per nodo. Le simulazioni hanno un costo extra solo se vengono eseguite sulla farm (raccomandiamo il caching locale e l'upload della cache). Per i dettagli sui prezzi, vedere o stimare con il nostro .

---

Configurare Houdini per il rendering cloud