XGen e file .tx si rompono sulla tua render farm? Guida al preflight di Maya

Introduzione

Una scena che viene renderizzata perfettamente su una workstation e torna sbagliata da una render farm è uno dei fallimenti più disorientanti in una pipeline Maya: nel log non c'è nulla che punti a "te", e nel file di scena stesso non c'è nulla di rotto. Due dei colpevoli più comuni sono XGen e le cache di texture .tx. Entrambi funzionano, per progettazione, al di fuori del file di scena principale: XGen memorizza i dati di groom e description in cartelle collections e archives separate, e il plugin MtoA di Arnold può generare silenziosamente una propria cache di texture .tx tiled accanto alle texture sorgente. Nessuno dei due problemi si manifesta quando apri il file .ma o .mb in locale, perché in locale quei file esterni si trovano già dove Maya se li aspetta.

Vediamo questo schema abbastanza spesso nei lavori Maya freelance e nei piccoli studi da renderlo degno di essere messo per iscritto in modo chiaro: i capelli o il pelo che "spariscono" in un render sulla farm, e la texture che genera un errore OpenImageIO inspiegabile a metà frame, quasi mai sono bug del software. Sono problemi di raccolta degli asset e di cache non aggiornata, ed entrambi si possono prevenire con un breve passaggio di preflight prima dell'invio.

Diagramma che mostra i dati di groom e cache risolti correttamente su una workstation locale ma mancanti su un nodo della render farm, causando la scomparsa di capelli o pelo dal render.

Perché XGen si rompe su una render farm (anche quando la scena "sembra" a posto)

XGen non memorizza un groom o una description come geometria cotta ("baked") nel file .ma/.mb. La memorizza come riferimento: un file palette .xgen più, a seconda di come è configurata la description, una cartella collections (dati di groom per singola description) e una cartella archives (dati di point-cache cotti o Alembic, se la description è impostata per il render da archivio anziché per la generazione live). Quando apri la scena in locale, Maya risolve quei riferimenti rispetto a percorsi che esistono già sulla tua macchina o sulla tua condivisione di rete locale. Quando la stessa scena arriva su un nodo della render farm, quegli stessi percorsi spesso non esistono - perché erano assoluti, perché puntavano a una condivisione UNC a cui il nodo della farm non è mappato, o perché è stato caricato solo il file .ma/.mb e la cartella xgen/ accanto ad esso non ha mai fatto il viaggio.

Il risultato raramente è un errore bloccante. In genere XGen non riesce a risolvere la description silenziosamente, e il render si completa - semplicemente senza i capelli, il pelo o le piume che avrebbero dovuto esserci. È proprio questa modalità di fallimento a rendere il debug frustrante: tutto il resto nel frame viene renderizzato correttamente, i drive risultano mappati, e la versione di Maya e XGen sulla farm corrisponde esattamente a quella della workstation - il groom è semplicemente sparito, perché i file che lo generano non sono mai arrivati.

Una seconda causa, correlata: anche quando la cartella xgen/ viene raccolta, l'impostazione della description "genera al momento del render" rispetto a "cached/archived" fa la differenza. Se una description è impostata per attingere da un archivio e quel percorso di archivio è relativo a una struttura di progetto che il nodo della farm non condivide, la description non si risolve in nulla, invece di ripiegare su un groom generato live.

Pannello generico in stile description editor che evidenzia i campi dei percorsi collection e archive, a illustrare dove risiedono, al di fuori del file di scena principale, i riferimenti ai dati di groom di XGen.

Perché i file di texture .tx si rompono su una render farm

.tx è un formato di texture tiled e mipmapped prodotto dallo strumento maketx di OpenImageIO. Arnold legge le texture .tx più velocemente e con un ingombro di memoria inferiore rispetto ai formati sorgente grezzi, motivo per cui MtoA (il plugin Maya di Arnold) offre l'opzione "Auto-Convert Textures to TX Files" - al salvataggio o al render, genera silenziosamente una cache .tx accanto alle texture sorgente.

Questo comportamento di conversione automatica è comodo su una singola workstation con un disco locale e una build di OpenImageIO coerente. È un comportamento molto meno affidabile su una render farm distribuita, per tre motivi distinti:

• Cache obsoleta. Se una texture sorgente viene modificata dopo la generazione del file .tx, e il controllo del timestamp che normalmente dovrebbe innescare una riconversione non scatta (oppure la posizione scrivibile di cui il nodo della farm ha bisogno non è la stessa da cui è stata generata), Arnold può caricare un file .tx non aggiornato senza alcun avviso che sia obsoleto.
• Mismatch di versione. Le versioni di maketx/OpenImageIO differiscono tra le varie release di Arnold e MtoA. Una cache .tx generata con una versione di OIIO può produrre errori di lettura - che di solito emergono come un errore OIIO non specificato che interrompe il frame - quando viene riletta con una versione diversa lato farm.
• Contesa di scrittura su percorsi condivisi o di sola lettura. L'auto-convert presuppone di poter scrivere un file .tx accanto alla texture sorgente. Su una render farm, quella posizione può essere di sola lettura, condivisa tra job concorrenti, o semplicemente non lo stesso percorso fisico usato dalla workstation, per cui la conversione fallisce silenziosamente oppure due nodi entrano in competizione per scrivere lo stesso file di cache.

È un problema abbastanza comune che la documentazione delle render farm in tutto il settore - non solo la nostra - dica di routine agli utenti Maya/Arnold di disabilitare "Auto-Convert Textures to TX Files" proprio per evitarlo, invece di provare a correggere il comportamento dell'auto-convert stesso. Lo schema più affidabile è fare una scelta deliberata: o pre-convertire le texture in .tx con una versione di maketx nota e fissata (pinned) e includere quei file .tx come parte della raccolta degli asset, oppure disattivare completamente l'auto-convert, inviare le texture sorgente grezze e lasciare che sia il renderer della farm a gestire la conversione in modo coerente dal proprio lato.

Diagramma di pipeline che mostra una texture sorgente convertita da maketx in una cache .tx, con un secondo ramo che mostra una cache obsoleta o con mismatch di versione che porta a un errore di lettura della texture.

Cosa l'archivio di scena di Maya non raccoglie per te

L'archiviazione di scena integrata in Maya (Send To / archive project) è costruita attorno al modello di riferimento standard: texture di file collegate tramite i file node nativi di Maya, e geometria che vive all'interno dello scene graph. XGen non rientra del tutto in questo modello, motivo per cui i suoi dati sono uno degli elementi più comunemente dimenticati in una raccolta di asset altrimenti "completa". Prima di inviare una scena XGen a qualsiasi render farm, pianifica di impacchettare esplicitamente:

• Il file palette .xgen stesso
• La cartella xgen/collections/<description>/ per ogni description referenziata nella scena
• La cartella xgen/archives/, se una qualsiasi description è impostata per il render da un archivio cotto
• Eventuali guide curves esterne, density map o length map che un modificatore XGen referenzia al di fuori dei normali file node di texture di Maya - a volte bypassano gli strumenti di archiviazione che intercettano le texture normali
• La versione esatta di Maya e MtoA (Arnold per Maya) con cui è stata costruita la scena, in modo che la render farm carichi la description con una build del plugin corrispondente invece di una simile ma diversa

Nulla di tutto ciò richiede software speciale - richiede di trattare i dati XGen come una parte a pieno titolo della raccolta degli asset, invece che come un effetto collaterale implicito del salvataggio della scena.

Checklist di preflight Maya + Arnold per i lavori XGen e .tx

Problemi comuni e soluzioni

Mockup di una console di render log che mostra un errore di lettura texture a livello warning, a illustrare il tipo di messaggio che una cache .tx obsoleta o con mismatch produce su un nodo di render.

Checklist riassuntiva

• Versioni di Maya e Arnold/MtoA verificate rispetto all'intervallo supportato dalla render farm
• xgen/collections/ e xgen/archives/ incluse esplicitamente nella raccolta degli asset
• Impostazione generate-vs-archive di ogni description XGen verificata, e il suo percorso confermato come accessibile dalla farm
• Un'unica strategia per le texture scelta: .tx pre-convertiti (versione di maketx fissata) oppure texture grezze con auto-convert disattivato - non entrambe
• Tutti i percorsi UNC e con lettera di unità sostituiti con percorsi relativi accessibili dalla farm
• Un frame di test inviato, con il render log controllato per avvisi XGen e texture prima della sequenza completa
• Percorso di render CPU o GPU deciso per gli shot pesanti su XGen o con shader personalizzati

Sulla nostra render farm, le versioni recenti di Maya (2022 e successive) superano automaticamente la corrispondenza di versione al momento dell'invio; le versioni più vecchie nell'intervallo supportato 2014-2027 vengono instradate attraverso un controllo di provisioning e compatibilità prima dell'avvio del render, così un mismatch viene rilevato prima che i frame vengano bruciati, invece che a metà job. Gli elementi relativi a percorsi, cache e impostazioni di archivio restano specifici della scena e vale la pena verificarli indipendentemente dalla render farm a cui viene inviato il job.

Per la configurazione generale del rendering cloud di Maya al di là di XGen e delle texture nello specifico, consulta la nostra guida al rendering cloud di Maya e la nostra guida completa al renderer Arnold. Per gli intervalli di supporto software alla base della corrispondenza di versione sulla farm, consulta le nostre pagine Maya render farm e Arnold render farm. Sul fronte texture, la documentazione di maketx di OpenImageIO stessa è il riferimento tecnico più chiaro su cosa fa realmente la conversione .tx e quali flag controllano il comportamento di mipmap e tiling.

FAQ

Q: Perché i capelli o il pelo XGen spariscono quando renderizzo su una cloud render farm ma funzionano bene in locale? A: Di solito significa che le cartelle collections e archives di XGen non sono state raccolte insieme al resto della scena. XGen legge i dati di groom e description da questi file esterni al momento del render - se viene caricato solo il file .ma o .mb, il nodo di render non ha nulla da cui generare i capelli o il pelo, e il render risulta calvo invece di generare un errore evidente.

Q: Cos'è un file .tx e perché Arnold ne ha bisogno? A: Un file .tx è una texture tiled e mipmapped creata dallo strumento maketx di OpenImageIO. Arnold e MtoA usano le texture .tx invece dei formati sorgente grezzi perché i mipmap tiled si caricano più velocemente e usano meno memoria durante il rendering, un aspetto che conta ancora di più su scala farm rispetto a una singola workstation.

Q: Devo lasciare attivata l'opzione "Auto-Convert Textures to TX Files" quando invio a una render farm? A: Lasciarla attivata è una causa comune di errori di texture lato farm. Funziona bene su una singola workstation con un solo disco, ma su una farm distribuita può produrre una cache .tx obsoleta o con mismatch di versione, oppure incontrare una differenza di permessi di scrittura sul nodo di render. Pre-convertire con una versione nota di maketx e includere i file .tx, oppure disattivare l'auto-convert e inviare le texture grezze, evita entrambe le modalità di fallimento.

Q: Le mie versioni di Maya e Arnold corrispondono già a quelle della farm - perché il render continua a mancare di texture? A: La corrispondenza di versione previene i fallimenti a livello di plugin, ma la maggior parte degli errori XGen e .tx sulle farm deriva dai percorsi dei file, non dalle versioni. Se XGen referenzia un percorso UNC o una lettera di unità locale che non esiste sul nodo di render, oppure la cache .tx è stata generata rispetto a una posizione di texture che la farm non può raggiungere, il render fallisce anche con versioni software corrispondenti.

Q: Come faccio a sapere quali versioni di Maya e Arnold supporta una render farm? A: Controlla l'intervallo di versioni Maya e Arnold/MtoA supportate dalla farm prima dell'invio - versioni corrispondenti eliminano un'intera classe di errori di render. La nostra render farm supporta Maya 2014-2027: le versioni 2022 e successive superano automaticamente la corrispondenza di versione al momento dell'invio, mentre le versioni più vecchie vengono instradate attraverso un controllo di compatibilità prima del render.

Q: Gli shot XGen devono essere renderizzati con il percorso CPU o GPU di Arnold? A: Gli shot con un uso intenso di XGen, copertura fitta di capelli o pelo e network di shading personalizzati appartengono al percorso CPU di Arnold per l'output finale - è la classe di lavoro verso cui le stesse linee guida di Arnold indirizzano l'uso della CPU. Qualunque percorso usi uno shot, prendi la decisione sul device al momento dell'invio, come parte del preflight, invece di scoprire un vincolo a metà render.

Q: Cosa devo controllare prima di inviare a una render farm una scena Maya con XGen? A: Esegui un breve preflight: verifica la corrispondenza delle versioni Maya/MtoA, impacchetta esplicitamente le cartelle xgen/collections e xgen/archives, scegli un'unica strategia per le texture (.tx pre-convertiti oppure grezzi con auto-convert disattivato), correggi eventuali riferimenti UNC o con unità locale, e invia un test su un solo frame prima della sequenza completa.

Q: È un problema esclusivo di XGen, o si presenta anche con altri DCC? A: Lo stesso schema di fondo - dati che vivono al di fuori del file di scena principale, più dati di texture in cache che diventano obsoleti - si presenta anche altrove. Gli utenti di 3ds Max incontrano un problema correlato ma distinto con i bitmap node mancanti in Arnold quando i percorsi delle texture non si risolvono sul nodo di render; consulta la nostra guida ai bitmap mancanti di Arnold in 3ds Max per quella versione del problema.