Compositing VFX e rendering cloud: perché il render di compositing è un carico di lavoro diverso dal 3D

Introduzione

La maggior parte dei contenuti sul rendering cloud è scritta per un solo tipo di carico di lavoro: una scena 3D che attraversa un path tracer, bucket per bucket, finché il rumore non si dirada e il frame è completo. Questa impostazione è corretta per un job Redshift o V-Ray, ed è quasi inutile per un render di compositing. Un comp non esegue il sampling di percorsi luminosi. Valuta un grafo di nodi rispetto a footage e pass che esistono già, e ciò che determina la durata e il costo non è quasi mai il numero di sample GPU.

Questa distinzione conta più di quanto sembri in superficie, perché i due carichi di lavoro vengono continuamente confusi nei consigli generici sul "rendering cloud". Un compositor che sposta per la prima volta uno script Nuke o un progetto After Effects su una farm, aspettandosi lo stesso comportamento GPU-bound di un render 3D, finisce per non capire perché un comp senza simulazioni e senza ray tracing sia comunque lento, o perché sia veloce in un modo che non ha nulla a che vedere con il livello di GPU scelto. Questa guida riguarda proprio quel divario: cosa fa realmente un render di compositing su una farm, in cosa differisce meccanicamente da un render 3D, e quando spostare il lavoro di compositing sul cloud ha senso rispetto a una workstation che lavora tutta la notte.

Lavoriamo entrambi i lati di questa pipeline ogni giorno sulla nostra farm di Super Renders Farm, dal render 3D che produce il beauty pass e gli AOV al render di compositing che li assembla in uno shot finale. I due condividono l'hardware ma poco altro in termini di comportamento del render, e capire questa differenza è ciò che rende un job di render di compositing prevedibile invece che un mistero.

Diagramma della pipeline che mostra il flusso di compositing EXR multi-pass: i pass di rendering 3D si combinano in un file EXR multistrato, che passa quindi all'applicazione di compositing per il color grading finale

Il compositing è un carico di lavoro di rendering diverso dal 3D

Un renderer 3D come V-Ray, Redshift o Arnold esegue il trasporto della luce: traccia raggi, campiona i materiali e accumula la riduzione del rumore nel tempo finché un'immagine non converge. Questo lavoro è genuinamente intensivo dal punto di vista computazionale per pixel, motivo per cui il rendering 3D è CPU-intensivo o GPU-intensivo a seconda del motore, e per cui l'accelerazione GPU ha un effetto così grande sui tempi di render 3D.

Un render di compositing non fa nulla di tutto questo. Nuke, After Effects, Fusion e strumenti simili valutano un grafo di nodi: leggono un'immagine, applicano una correzione colore, uniscono due layer, applicano una trasformazione, scrivono il risultato. Non c'è sampling né convergenza. Ogni operazione è un passaggio deterministico e per lo più di algebra lineare sui dati dei pixel, e la maggior parte di queste operazioni (merge, color grading, keyer, trasformazioni, la maggior parte dei filtri) viene eseguita sulla CPU piuttosto che sulla GPU. Un piccolo numero di nodi specifici (retime pesanti, alcune operazioni di denoising, alcuni strumenti di machine learning) è accelerato via GPU, ma sono l'eccezione in un comp tipico, non la regola.

Ciò che determina realmente la durata di un render di compositing è più vicino a un problema di movimento dei dati che a un problema di calcolo:

• Throughput di lettura. Uno script di compositing legge footage e pass di render, spesso più sequenze EXR multistrato contemporaneamente, per ogni frame.
• Threading CPU. Le operazioni di compositing si parallelizzano tra i core CPU all'interno di un singolo frame, e il gestore del rendering parallelizza tra i frame assegnando blocchi dell'intervallo di frame a worker diversi.
• Memoria. Tenere in memoria contemporaneamente più frame a piena risoluzione e multicanale (un beauty pass, alcuni AOV, una matte cryptomatte, forse un deep pass) è molto più esigente in termini di memoria di quanto sembri, e l'esaurimento della RAM a metà frame è una causa più comune di fallimento del render di compositing rispetto alla pura velocità della CPU.
• Throughput di scrittura. Il frame composito finale, o un precomp intermedio, deve essere riscritto, e per i deliverable di pipeline VFX quell'output è di solito un'altra sequenza EXR piuttosto che un singolo file video.

Nulla di tutto questo è una critica al compositing. È un tipo di carico di lavoro diverso, costruito attorno allo spostamento e alla combinazione di dati immagine già esistenti piuttosto che alla loro generazione da zero, e una render farm che tratta un job di compositing come un render 3D, allocando una forte capacità GPU e lesinando su RAM e throughput di storage, avrà prestazioni scarse esattamente sulle macchine che dovrebbero gestire bene il lavoro.

Cosa legge e scrive realmente un render di compositing

La forma di input e output di un job di compositing è dove la differenza rispetto al rendering 3D si manifesta più concretamente.

File EXR multistrato e multi-pass in ingresso. Un comp tipicamente apre uno o più file OpenEXR per frame che già contengono molti canali: un beauty render, pass separati di diffuse e specular, AOV di illuminazione, un pass di Z-depth, vettori di movimento e matte cryptomatte per l'isolamento di oggetti, materiali e asset ID, tutti in un unico file letto tramite un nodo Read e separati con nodi Shuffle per il lavoro per singolo pass. Leggere quel file non è un piccolo accesso singolo; significa estrarre ogni canale che il frame contiene, anche se un dato comp ne usa solo alcuni, motivo per cui la larghezza di banda di lettura dello storage è un vero collo di bottiglia sui nodi farm orientati al compositing, in un modo che raramente accade per un render 3D, che scrive, non legge, la maggior parte dei suoi dati EXR.

Cryptomatte come input, non come output. I dati cryptomatte (matte ID generate proceduralmente che permettono a un compositor di isolare singoli oggetti, materiali o istanze di asset a posteriori, senza dover ri-renderizzare) vengono scritti dal render 3D e consumati dal comp. Ciò significa che un job di compositing su farm eredita qualunque canale cryptomatte prodotto dal render 3D a monte, e un comp che si appoggia all'isolamento cryptomatte legge più canali per frame rispetto a uno che non lo fa. La nostra guida a EXR-IO e cryptomatte illustra come sono strutturati questi dati e come lavorarci in modo efficiente, ed è utile leggerla prima di inviare a qualsiasi farm un comp che fa ampio uso di cryptomatte.

Un numero ridotto di output, ad alta profondità di bit. Mentre un render 3D scrive spesso diversi pass per frame, un render di compositing riduce tipicamente quei pass a uno solo, o a un piccolo gruppo, di output compositi finali, di solito EXR 16-bit half-float per i deliverable HDR lineari destinati a proseguire lungo una pipeline VFX, occasionalmente 32-bit per i pass di dati che richiedono piena precisione. La scrittura è più contenuta in numero di canali rispetto alla lettura, ma resta comunque un frame a piena risoluzione, e per un job di deep compositing (che tiene più campioni di profondità per pixel per risolvere gli holdout senza ri-renderizzare la scena 3D) sia la lettura sia la scrittura diventano considerevolmente più pesanti.

Gli encode video sono un passaggio separato, non il render stesso. Quando il deliverable finale è H.264 o HEVC anziché una sequenza di immagini, quell'encode avviene generalmente come passaggio distinto dopo il render frame-per-frame di compositing, non come parte di esso, perché i codec video non sono suddivisibili in modo pulito tra worker come lo è una sequenza di immagini indipendente. La nostra guida al confronto tra encoding H.264 e H.265 approfondisce i compromessi di questo passaggio finale.

Sei pass di rendering (beauty, diffuse, specular, cryptomatte, depth, ambient occlusion) che convergono in un unico file EXR multistrato

Come i render di compositing si distribuiscono su una cloud farm

Il modello di distribuzione per il lavoro di compositing è più vicino a quello di Nuke che a quello di un renderer 3D, ed è utile essere precisi sul perché.

Un renderer 3D può suddividere un singolo frame spazialmente: bucket o tile assegnati a thread o macchine diverse, perché i pixel di una regione genuinamente non dipendono dai pixel di un'altra. Un comp generalmente non può essere suddiviso in questo modo. Il valore di un pixel al frame N dipende dagli input di quel frame che attraversano l'intero albero di nodi, il che rende la maggior parte del lavoro di compositing parallelizzabile in modo quasi imbarazzante per frame, non per regione dell'immagine. Un gestore del rendering non suddivide un frame di compositing; suddivide l'intervallo di frame, assegnando blocchi di frame a worker diversi, ciascuno dei quali esegue la propria istanza dell'applicazione di compositing in modalità headless (senza interfaccia grafica) per la propria porzione.

Questo è il modello che la nostra guida al cloud render farm per Nuke illustra nel dettaglio specificamente per Nuke, inclusi i flag da riga di comando esatti e la meccanica delle licenze. After Effects si comporta in modo simile per la maggior parte dei comp di produzione (sigle, motion graphics, reveal di archviz), ma con un'avvertenza da segnalare qui: le composizioni AE che dipendono da uno stato temporale tra i frame (motion blur con sampling cross-frame, simulazioni di particelle che si accumulano, alcune operazioni di tracking) non sono nettamente frame-parallele, e suddividerle ingenuamente tra worker diversi può produrre giunture visibili ai confini dei blocchi. La nostra guida alla configurazione del rendering cloud per After Effects illustra quali workflow AE si parallelizzano in modo pulito e quali richiedono invece un passaggio a worker singolo.

La forma pratica di un job di render di compositing su una farm è questa: lo script o il progetto, insieme a tutto ciò a cui fa riferimento, viene caricato come pacchetto autosufficiente; il gestore del rendering suddivide l'intervallo totale di frame in blocchi; ogni worker preleva il proprio blocco, risolve gli stessi percorsi footage, la stessa configurazione colore, gli stessi font e le stesse dipendenze plugin presenti sulla macchina dell'artista, e renderizza in modalità headless; i frame completati arrivano nello storage condiviso o cloud man mano che ogni blocco termina, così una sequenza lunga può iniziare a restituire output utilizzabile molto prima che l'ultimo worker abbia finito.

Problemi comuni nel compositing cloud

La stragrande maggioranza dei render di compositing che falliscono o tornano indietro sbagliati su una farm non sono problemi di matematica del compositing. Sono problemi di dipendenze e di ambiente che una workstation locale mascherava silenziosamente.

Nulla di tutto ciò è specifico di una singola applicazione. È la forma generale di ciò che si rompe quando uno script di compositing lascia la macchina su cui è stato creato, ed è per questo che "testare piccole porzioni prima di lanciare l'intera sequenza" (renderizzare qualche frame e confrontarlo con il risultato locale) è un passaggio assicurativo a basso costo che vale la pena adottare per qualsiasi render di compositing, su qualsiasi farm.

Quando il rendering cloud aiuta davvero una pipeline di compositing

Non ogni comp ha bisogno di una farm. Una sequenza breve che si renderizza localmente in pochi minuti guadagna poco dall'overhead di upload e coda dello spostamento sul cloud. Il compositing cloud ripaga in una serie specifica di situazioni:

Picchi guidati da scadenze. Un deliverable dovuto in ore, non giorni, dove il numero e la complessità dei frame terrebbero occupata una workstation più a lungo di quanto la scadenza permetta. Distribuire una sequenza di 1.000 fotogrammi su decine di worker trasforma un render notturno in qualcosa che può tornare in un'ora o due, perché il throughput scala in modo quasi lineare con il numero di worker disponibili.

Lavoro batch notturno che altrimenti bloccherebbe un artista. Anche senza una scadenza pressante, un comp che occuperebbe la macchina di un artista per diverse ore è tempo in cui quell'artista non può iterare, rivedere o lavorare sullo shot successivo. Inviarlo a una farm libera immediatamente la workstation invece di attendere che un render locale si liberi.

Sequenze grandi con dati pesanti per frame. Il deep compositing, EXR multicanale 4K e oltre, e i comp che fanno ampio uso di cryptomatte sono esattamente i carichi di lavoro in cui il tempo di render per frame si accumula maggiormente, e dove distribuire su molti worker CPU-intensivi ripaga più di quanto farebbe per un comp leggero con pochi canali.

Pipeline miste 3D e compositing che usano già una farm. Se il render 3D di uno shot gira già su una farm cloud, mantenere la fase di compositing sulla stessa infrastruttura evita un percorso di andata e ritorno verso una macchina locale tra le due fasi, e mantiene i pass (beauty, AOV, cryptomatte) vicini al punto in cui il comp li leggerà.

Dove il compositing cloud ripaga meno: un gruppo di comp brevi e semplici, senza pressione di scadenza, dove il tempo di render locale è già ben al di sotto del tempo necessario a preparare e caricare un pacchetto di progetto autosufficiente. L'overhead di upload e di audit delle dipendenze è reale, e per un job piccolo può superare il tempo risparmiato.

Costi: quanto costa realmente un job di render di compositing

Poiché il compositing è un carico di lavoro legato a CPU e memoria per la grande maggioranza dei nodi in un comp tipico, è la tariffa CPU a governare di norma il costo, con la tariffa GPU applicata solo ai nodi specifici (retime pesanti, alcuni denoising, strumenti di machine learning) che effettivamente usano l'accelerazione GPU.

Sulla nostra farm, il calcolo CPU viene fatturato per GHz-hr, con una tariffa base di $0,004/GHz-hr (i livelli di priorità vanno da $0,004 a $0,016/GHz-hr a seconda della priorità in coda), e il calcolo GPU viene fatturato per OctaneBench-hour (OBh) a una base di $0,003/OBh, con una scheda RTX 5090 (32 GB VRAM) a circa $5,2 all'ora per scheda a piena utilizzazione. I render credit non scadono, e non esiste un minimo di noleggio macchina, quindi un job di compositing viene fatturato per il calcolo effettivamente consumato piuttosto che per un blocco di tempo riservato.

Per rendere concreto questo concetto con un esempio illustrativo (non un dato di benchmark, poiché il tempo di render effettivo per frame varia enormemente in base a risoluzione, numero di canali e complessità dei nodi): un batch di compositing che consuma 5.000 GHz-hr aggregati di calcolo CPU, un ordine di grandezza plausibile per una sequenza 4K di diverse migliaia di frame distribuita su decine di worker durante la notte, costa circa $20 di calcolo alla tariffa base, prima di qualsiasi moltiplicatore per livello di priorità. Se una parte dello stesso job si appoggia a nodi accelerati via GPU, quella porzione viene fatturata separatamente alla tariffa OBh anziché a quella GHz-hr. Il meccanismo che conta ai fini del budget è semplice anche quando i numeri esatti variano da job a job: il costo segue il calcolo totale consumato, non il tempo di render in tempo reale, quindi distribuire un job su più worker per finire più in fretta non ne cambia di per sé il costo.

Compositing vs rendering 3D: confronto diretto

Dove si colloca il compositing in una pipeline di rendering cloud più ampia

Il compositing è di solito l'ultima fase di una catena che inizia con un render 3D, e trattare le due fasi con le stesse assunzioni su hardware e colli di bottiglia è l'errore più comune che vediamo nei ticket di supporto dei team nuovi al compositing cloud. Se la pipeline è interamente sul lato 3D e non è ancora stato definito il modello di servizio più ampio, la nostra guida su cos'è una cloud render farm e la nostra guida al rendering cloud per VFX e visualizzazione di prodotto coprono questo terreno. Per la fase di compositing in particolare, la guida al rendering cloud per Nuke e la guida alla configurazione del rendering cloud per After Effects coprono la meccanica specifica dell'applicazione (licenze, flag di invio, matrici plugin) che questo articolo ha deliberatamente lasciato generale. Sul lato After Effects, la nostra pagina After Effects cloud render farm copre direttamente il workflow supportato e i prezzi.

Per il riferimento canonico sul formato file alla base della maggior parte delle pipeline di compositing VFX, il progetto OpenEXR documenta il formato multicanale e multi-part che la maggior parte dei render di compositing legge e scrive, e la specifica Cryptomatte documenta come i dati delle matte ID vengono codificati in quei file.

FAQ

Q: Il render di compositing è la stessa cosa del rendering 3D su una cloud farm? A: No. Un render 3D esegue il trasporto della luce, campionando e tracciando raggi finché un'immagine non converge, e quel lavoro è genuinamente intensivo dal punto di vista computazionale per pixel. Un render di compositing valuta un grafo di nodi su dati immagine che esistono già (footage, pass di render) ed è dominato dal threading CPU, dalla capacità di memoria e dall'I/O di storage piuttosto che dal sampling. I due carichi di lavoro condividono l'hardware della farm ma hanno colli di bottiglia e modalità di fallimento diversi.

Q: Perché il compositing è più legato all'I/O rispetto al rendering 3D? A: Un comp legge tipicamente uno o più file EXR multistrato e multi-pass per frame, estraendo ogni canale che il file contiene (beauty, AOV, matte cryptomatte, depth), e tiene in memoria contemporaneamente diversi di questi frame a piena risoluzione mentre valuta il grafo di nodi. Quel volume di lettura, combinato con la riscrittura del frame composito, rende il throughput di storage e la capacità di RAM un fattore più determinante nel tempo di render di compositing rispetto alla pura velocità di calcolo, per la maggior parte dei nodi in un comp tipico.

Q: Una render farm per compositing ha bisogno di nodi GPU? A: Per la maggior parte dei comp, no. La maggioranza delle operazioni di compositing (merge, color grading, keyer, trasformazioni, la maggior parte dei filtri) viene eseguita sulla CPU. Un sottoinsieme specifico e più ridotto di nodi (retime pesanti, alcune operazioni di denoising, strumenti di machine learning) è accelerato via GPU, e i comp che si appoggiano molto a quei nodi beneficiano della capacità GPU. Per un comp tipico dominato da merge e color grading, i core CPU e la RAM contano più del livello di GPU.

Q: Cos'è cryptomatte e perché conta per il compositing cloud? A: Cryptomatte è un dato di matte ID generato proceduralmente, scritto da un render 3D, che permette a un compositor di isolare singoli oggetti, materiali o istanze di asset a posteriori senza dover ri-renderizzare la scena 3D. Per un job di compositing cloud, i dati cryptomatte sono un input che il comp legge, non qualcosa che il render di compositing genera, e i comp che fanno ampio uso di cryptomatte leggono più canali per frame, aumentando il carico di I/O e memoria sul nodo di render.

Q: Nuke e After Effects possono renderizzare entrambi sulla stessa cloud farm? A: Sì, su una farm che supporta entrambe le applicazioni, anche se il modello di distribuzione differisce leggermente. I comp Nuke sono quasi sempre frame-paralleli per progettazione (ogni frame è completamente autosufficiente). I comp After Effects sono frame-paralleli nella maggior parte dei casi di produzione, ma le composizioni che dipendono da uno stato temporale tra i frame, come certe configurazioni di motion blur o simulazioni di particelle, richiedono il rendering a worker singolo invece della distribuzione per intervallo di frame per evitare giunture. Le nostre guide per Nuke e After Effects coprono la meccanica specifica delle applicazioni.

Q: Quando ha senso inviare un job di compositing a una cloud farm invece di renderizzare localmente? A: Il compositing cloud ripaga di più in picchi guidati da scadenze, lavoro batch notturno che altrimenti terrebbe occupata la workstation di un artista, e sequenze grandi o con dati pesanti per frame (deep compositing, EXR multicanale 4K e oltre, comp che fanno ampio uso di cryptomatte). Ripaga meno su un gruppo di comp brevi e semplici senza pressione di scadenza, dove il tempo di render locale è già più breve del tempo necessario a preparare un pacchetto di progetto autosufficiente da caricare.

Q: Come viene fatturato il render di compositing su una cloud farm? A: Sulla nostra farm, il calcolo CPU (che governa il costo per la maggior parte del lavoro di compositing) viene fatturato per GHz-hr a una tariffa base di $0,004/GHz-hr, con livelli di priorità fino a $0,016/GHz-hr. I nodi accelerati via GPU vengono fatturati separatamente per OctaneBench-hour a una base di $0,003/OBh. Il costo segue il calcolo totale consumato piuttosto che il tempo in tempo reale, quindi distribuire un job su più worker per finire più in fretta non ne cambia di per sé il costo totale.

Q: Quali formati file gestisce tipicamente una render farm per compositing? A: OpenEXR multistrato e multi-part è lo standard per input e output di pipeline VFX, e trasporta beauty pass, AOV, matte cryptomatte e dati di depth a 16-bit half-float (o 32-bit per i pass di dati che richiedono piena precisione). Quando il deliverable finale è un file video (H.264, HEVC, ProRes) anziché una sequenza di immagini, quell'encode viene tipicamente eseguito come passaggio separato dopo il render frame-per-frame di compositing, poiché i codec video generalmente non sono suddivisibili tra worker come lo è una sequenza di immagini indipendente. La nostra guida H.264 vs H.265 copre questo passaggio finale di encoding.