Rendering di scene Maya con USD su una render farm

Universal Scene Description è passato da un formato interno di Pixar alla struttura portante di molte pipeline Maya. Se lo studio compone le riprese a partire da stage USD stratificati, referenzia asset pubblicati tra i vari reparti e passa il risultato a un renderer attraverso un procedural, è chiaro che USD non è più un esperimento secondario — è la colonna vertebrale della scena. Quello che risulta meno ovvio fino a quando non si avvicina una scadenza è che una scena che esegue il rendering perfettamente su una workstation non garantisce lo stesso risultato su una render farm esterna. La render farm deve disporre della versione corretta di MayaUSD, del supporto USD appropriato per il motore di render e di un modo per risolvere ogni percorso asset a cui lo stage fa riferimento. Quando uno di questi elementi manca, non si ottiene un errore chiaro — si ottengono frame falliti, fallback silenziosi o geometria semplicemente assente.

Gestiamo una render farm gestita e i job Maya con USD sono uno dei workflow per cui vediamo gli studi faticare a lasciare le proprie workstation. Questa guida illustra perché USD è più difficile da renderizzare da remoto rispetto a un file .ma autonomo, cosa deve essere allineato perché funzioni e come viene gestito sul nostro lato — inclusi i dettagli più facili da sbagliare.

Pipeline di rendering Maya USD: stage USD stratificati verso il plugin MayaUSD verso l'Arnold USD procedural verso i frame renderizzati, con risoluzione degli asset e corrispondenza dell'ambiente.

Perché USD è più difficile da renderizzare da remoto rispetto a una scena autonoma

Una scena Maya tradizionale è in gran parte auto-descrittiva: si apre, le mesh e i materiali sono presenti, si punta il renderer su di essa e i frame vengono prodotti. Una scena basata su USD è più simile a una ricetta che a un piatto finito. I file .usd, .usda o .usdc sono un insieme di istruzioni stratificate — sublayer, reference, payload e variant — che si compongono in uno stage finale al momento del caricamento. Questa composizione è potente, ma significa che tre elementi distinti devono essere presenti e compatibili sulla macchina che esegue il rendering.

Il primo è il plugin MayaUSD stesso. MayaUSD è il ponte che consente a Maya di leggere, comporre e passare gli stage USD al rendering. Se la render farm non ha MayaUSD caricato, o dispone di una versione che compone lo stage in modo diverso rispetto a quella usata dagli artisti, la scena non riesce ad aprirsi oppure si apre con le parti provenienti da USD mancanti.

Il secondo è la risoluzione dei percorsi asset. Uno stage USD fa riferimento ad altri file — geometria, texture, layer USD annidati — tramite percorso. Sulla workstation, quei percorsi vengono risolti perché i dati si trovano dove lo stage si aspetta. Su una render farm, a meno che non vengano riprodotte la stessa struttura di directory e lo stesso comportamento del resolver, metà di quei riferimenti non viene risolta. Questo è il motivo più comune per cui una scena USD che "funziona in locale" torna vuota da una render farm: i pixel sono stati renderizzati correttamente, ma i riferimenti non sono stati trovati.

Il terzo è il supporto USD del renderer. Il motore di render deve comprendere i dati USD che Maya gli passa. Per Arnold, tale percorso avviene attraverso l'Arnold USD procedural, che legge il contenuto USD al momento del rendering invece di espandere l'intero stage in Maya in anticipo. Se il procedural non è installato, o la sua versione non corrisponde ai dati, il renderer salta ciò che non riesce a leggere — silenziosamente.

Qui emerge anche il divario già reso noto in alcuni servizi di cloud rendering. Il tracker AWS per Deadline Cloud per Maya presenta un problema aperto (aws-deadline/deadline-cloud-for-maya#409) relativo al supporto MayaUSD nel loro submitter, che è esattamente il tipo di infrastruttura che deve essere risolta end-to-end prima che le scene USD vengano renderizzate in modo affidabile. È un chiaro esempio del problema: il rendering USD non è una singola funzionalità da attivare, ma una catena di versioni e percorsi che devono essere tutti coerenti.

Uno stage USD stratificato nel Layer Editor di Maya — sublayer e reference visibili — accanto all'output di Arnold RenderView.

Come eseguiamo il rendering di Maya + USD sulla nostra farm

Il nostro approccio inizia prima che venga accodata un singolo frame: adattiamo l'ambiente alla scena invece di chiedere alla scena di adattarsi a un'immagine farm fissa. Quando uno studio ci invia un job Maya basato su USD, confermiamo la versione di Maya, la build di MayaUSD, il renderer e la versione USD in cui gli asset sono stati creati, quindi prepariamo i nodi di conseguenza. L'obiettivo è che lo stage si componga sui nostri nodi esattamente come si compone sulle macchine degli artisti — stessa versione del plugin, stessa risoluzione, stesso procedural.

Sul lato del rendering, i due componenti che contano di più per Maya USD con Arnold devono entrambi inizializzarsi correttamente: MayaUSD per comporre lo stage all'interno di Maya, e l'Arnold USD procedural per leggere il contenuto USD al momento del rendering. Abbiamo eseguito job Maya in produzione in cui entrambi vengono caricati e funzionano correttamente su tutto il pool di nodi, il che costituisce il test pratico che conta — non "la render farm afferma di supportare USD" ma "questo stage, con questi riferimenti, produce i frame che l'artista si aspetta." Arnold in questo contesto funziona sui nostri nodi CPU, il che si adatta al modo in cui molti studi usano Arnold per il lavoro USD di qualità finale; le stesse scene possono essere eseguite su GPU dove il progetto lo richiede.

Un dettaglio che vale la pena evidenziare, perché trae spesso in inganno: le scene USD che hanno attraversato diverse pipeline spesso contengono riferimenti a plugin residui e attributi di nodi estranei da renderer che il progetto non utilizza più. Riceviamo scene che richiedono ancora un plugin che lo studio ha abbandonato mesi fa, o che contengono attributi da un motore che non è nel percorso di rendering finale. Sui nostri nodi questi residui sono innocui — Maya li ignora e procede con il rendering usando il motore effettivamente in uso. Per log più ordinati è possibile rimuovere le richieste di plugin sconosciuti e i nodi residui in Maya prima di inviare, ma è una questione estetica; non è ciò che blocca un rendering. Sapere distinguere tra un "residuo innocuo" e "ciò che sta effettivamente causando il problema" è la maggior parte di ciò che rende il rendering USD scorrevole.

Un vincolo realistico sulle prestazioni hardware: i nostri nodi GPU sono costruiti su schede RTX 5090 con 32 GB di memoria per GPU, e quella memoria è per scheda — non viene condivisa tra le due schede in una macchina. Per il lavoro Arnold-CPU con USD che la maggior parte degli studi ci porta questo limite raramente si manifesta, ma se si sta eseguendo un percorso GPU su scene con texture molto grandi o volumetrici pesanti, è opportuno verificare in anticipo il footprint di memoria per GPU. Preferiamo chiarirlo con il cliente prima di avviare un job piuttosto che ritrovarsi un frame che non riesce ad adattarsi a metà esecuzione.

Rendering dal filespace esistente, senza rieseguire l'upload

Il problema di risoluzione degli asset descritto in precedenza ha una soluzione efficace quando uno studio conserva già il proprio progetto su un filespace montato. Se gli asset si trovano su LucidLink, possiamo montare quel filespace sui nodi di rendering, in modo che lo stage USD risolva i suoi riferimenti rispetto agli stessi dati che gli artisti vedono — senza rieseguire l'upload di una libreria di asset da diversi gigabyte e senza ricostruire manualmente la struttura delle directory. Lo stage si compone rispetto ai percorsi reali perché i percorsi reali sono montati.

Questo è particolarmente importante per USD rispetto a una scena a file singolo autonoma, proprio perché USD fa affidamento su quei riferimenti esterni. Montare la fonte originale elimina un'intera categoria di errori "reference non trovato", perché non c'è nulla da copiare in modo errato — la render farm legge lo stesso albero di directory che legge lo studio. Per i team che già lavorano nativamente con LucidLink, questo tende a fare la differenza tra un ciclo complicato di upload-e-speranza e un rendering che si risolve semplicemente.

Un filespace LucidLink dello studio montato direttamente sui nodi di rendering, che leggono gli asset in locale — senza rieseguire l'upload.

Cosa è incluso — licenze e DCC, non solo macchine

Quando si noleggia capacità dedicata, le licenze del motore di render e le applicazioni DCC sono incluse. Maya, il renderer — Arnold, V-Ray, Redshift, Octane, Cycles — e i plugin di supporto fanno parte di ciò che viene fornito, invece di essere qualcosa che si deve portare e licenziare per nodo in autonomia. Per un job USD questo significa solitamente che le licenze Arnold sono gestite dal nostro lato come parte dell'esecuzione, senza dover reperire separatamente licenze di rendering per ogni nodo del blocco.

Vale la pena confrontare questo approccio con quello bare-metal o build-your-own, in cui la tariffa per macchina può sembrare inferiore fino a quando non si aggiungono le licenze del motore di render — che costano da qualche centinaio a ben oltre mille dollari per nodo, per anno, per motore su un host bring-your-own. Il bundling è la parte del modello che svolge il lavoro silenzioso: la scena che viene renderizzata è quella in cui Maya, MayaUSD, il procedural e la licenza del motore sono tutti presenti contemporaneamente, e fornirli insieme è il modo in cui si mantiene intatta quella catena.

Una migrazione reale: USD su Maya, via da uno scheduler cloud che non riusciva a gestirlo

Per rendere questo concreto: di recente abbiamo lavorato con uno studio di effetti visivi britannico che si è rivolto a noi perché la loro configurazione con uno scheduler cloud esistente stava fallendo esattamente su questo problema — Maya non riusciva a lavorare con i loro asset USD in quell'ambiente. La loro pipeline era Maya con Arnold, su un filespace LucidLink. Abbiamo montato il loro filespace sui nodi, adattato l'ambiente alla loro scena e confermato nei log che MayaUSD e l'Arnold USD procedural si inizializzavano ed eseguivano correttamente il rendering su tutte le macchine. La scena conteneva alcuni riferimenti residui risalenti a una fase precedente della sua vita; questi sono stati ignorati e i frame sono stati prodotti. Lo studio è passato da "i nostri rendering USD continuano a fallire" a un'esecuzione pulita, e da lì ha ampliato la capacità. Lo studio rimane anonimo, ma il workflow — Maya, USD, Arnold, LucidLink — è sempre più la norma piuttosto che l'eccezione.

Una checklist di preparazione prima di inviare un job USD a qualsiasi render farm

Che si esegua il rendering con noi o altrove, questi sono gli aspetti da verificare in anticipo in modo che una scena USD non riservi sorprese su una render farm:

La maggior parte dei rendering USD falliti è riconducibile a una delle prime tre righe. Il motivo per cui si analizzano prima di avviare un job, e non dopo, è che con USD la differenza tra un'esecuzione pulita e un frame vuoto è solitamente una singola versione non corrispondente o un percorso non risolto — ed è molto meno costoso individuarlo su un frame di test che sul frame 480 di una scadenza.

Proprio per questo, il modo in cui iniziamo tipicamente un ingaggio Maya USD è con un frame rappresentativo: ne eseguiamo uno prima del blocco completo in modo che lo studio possa vedere lo stage comporsi e i frame arrivare sui nostri nodi, e confermare la pipeline end-to-end prima di qualsiasi impegno maggiore. Con USD, dimostrare la catena su un solo frame vale più di qualsiasi elenco di funzionalità.

Per un quadro più ampio su come funziona il rendering Maya su una render farm al di là di USD in modo specifico, la nostra guida al cloud rendering con Maya copre il workflow generale, e la nostra panoramica sulla scelta di una render farm per Maya illustra come valutarne una. Il noleggio di nodi dedicati su cui viene eseguito questo lavoro USD è descritto nella nostra pagina di noleggio render farm. Per il formato stesso, la documentazione OpenUSD di Pixar è il riferimento canonico su come si compongono gli stage.

FAQ

Q: La vostra render farm supporta le scene Maya che utilizzano USD? A: Sì. Vengono eseguiti job Maya che utilizzano USD adattando la build di MayaUSD e il supporto USD del renderer alla scena. Nelle esecuzioni in produzione è stato confermato nei log che MayaUSD e l'Arnold USD procedural si inizializzano ed eseguono correttamente il rendering su tutto il pool di nodi. L'elemento chiave è che la stessa build di MayaUSD, la stessa versione USD e gli stessi percorsi asset utilizzati dagli artisti vengano riprodotti sul lato rendering.

Q: Quali versioni di Maya e USD supportate? A: Invece di essere vincolati a un'immagine fissa, si adatta la versione di Maya, la build di MayaUSD e la versione USD in cui gli asset sono stati creati. La composizione USD è sensibile alle differenze di versione nel modo in cui si risolvono layer, reference e variant, quindi la corrispondenza con l'ambiente di creazione è ciò che garantisce che lo stage si componga nello stesso modo in cui si compone sulle workstation.

Q: Supportate l'Arnold USD procedural? A: Sì — per Maya con Arnold, l'Arnold USD procedural è il percorso che legge il contenuto USD al momento del rendering, e viene fornito insieme ad Arnold. Deve essere presente e compatibile con i dati in termini di versione, altrimenti il renderer salta ciò che non riesce a leggere. Ne viene confermata l'inizializzazione prima di eseguire un blocco completo.

Q: È necessario portare la propria licenza Arnold? A: No. Le licenze del motore di render, incluso Arnold, fanno parte della capacità dedicata che viene fornita — sono incluse invece di essere qualcosa che si deve licenziare per nodo in autonomia. In una configurazione bring-your-own-host quelle licenze andrebbero aggiunte al costo della macchina; il bundling fa parte del modo in cui si mantiene intatta la catena di rendering.

Q: È possibile montare il nostro filespace LucidLink per non dover rieseguire l'upload degli asset? A: Sì. Se il progetto risiede su LucidLink, è possibile montare quel filespace sui nodi di rendering in modo che lo stage USD risolva i suoi riferimenti rispetto agli stessi dati degli artisti. Per USD in modo specifico questo elimina una comune modalità di errore, perché la render farm legge lo stesso albero di asset dello studio invece di una copia che potrebbe avere una struttura diversa.

Q: Utilizziamo uno scheduler cloud che non riesce a eseguire le nostre scene Maya USD. È possibile effettuare la migrazione? A: È uno dei motivi più comuni per cui gli studi si rivolgono a noi. Si adatta l'ambiente alla scena, si monta il filespace se disponibile e si verifica su un frame rappresentativo che lo stage USD si componga e venga renderizzato prima di impegnarsi in un'esecuzione completa. La migrazione consiste principalmente nel riprodurre fedelmente l'ambiente di creazione sul lato rendering.

Q: La nostra scena contiene riferimenti residui da un renderer che non utilizziamo più — è un problema? A: Di solito no. Le scene USD che hanno attraversato diverse pipeline spesso contengono richieste di plugin estranee e attributi di nodi residui. Sui nostri nodi Maya li ignora e procede con il rendering usando il motore effettivamente in uso. È possibile rimuoverli in Maya per log più ordinati, ma è una questione estetica — i residui raramente sono la causa del fallimento di un rendering.

Q: Conviene eseguire il rendering di Maya USD su CPU o GPU? A: Entrambe le opzioni sono disponibili e la risposta giusta dipende dal renderer e dalla scena. Molti studi eseguono Arnold per il lavoro USD di qualità finale su CPU, per cui i nostri nodi CPU sono predisposti. GPU è disponibile dove il progetto lo richiede — occorre tenere presente che le nostre schede GPU hanno 32 GB di memoria ciascuna, non condivisa, quindi per scene GPU molto pesanti è opportuno verificare prima il footprint di memoria per GPU.