Benvenuto su Super Renders Farm

Benvenuto nella documentazione di Super Renders Farm. Qui raccogliamo le informazioni pratiche necessarie per eseguire il rendering dei propri progetti sulla nostra render farm — dalla preparazione della scena e l'invio del primo job, alla risoluzione dei problemi di qualità del rendering, alla comprensione del modello di prezzi e alla gestione della quotidianità del rendering cloud.

Questa pagina di benvenuto è la versione sintetica: cosa facciamo, cosa significa rendering cloud nel nostro contesto, l'hardware alla base dei suoi rendering, come è organizzata la documentazione, da dove iniziare in base alle esigenze odierne e come contattarci quando la documentazione non è sufficiente. Se dispone solo di cinque minuti prima di inviare il primo rendering, legga questa pagina e passi alla .

Cosa facciamo

Super Renders Farm è una render farm cloud completamente gestita. L'utente carica la scena, noi la eseguiamo sulla nostra infrastruttura, l'utente scarica il risultato. Operiamo dal 2010 (entità legale dal 2017) e serviamo attualmente clienti in oltre 50 paesi — principalmente studi di archviz, team VFX, case di animazione, freelance di motion design e studi di product visualization.

"Completamente gestita" è la parte che ci distingue dai provider di infrastruttura-come-servizio. Sulla nostra render farm:

• Non ci si connette in remote desktop alle macchine di rendering.
• Non si installano render engine o plugin manualmente.
• Non si gestiscono licenze software in modo autonomo.
• Non si configurano worker node, condivisioni di file o priorità di coda.

Ci occupiamo della configurazione dei worker, del routing delle licenze, della risoluzione dei percorsi degli asset, della pianificazione delle code e del blocco delle versioni del motore. L'interazione con la render farm è: carica → invia → scarica. Per un'analisi approfondita di cosa significhi "completamente gestita" in pratica — e come si confronti con il noleggio di macchine raw su un cloud pubblico — si consulti .

Supportiamo i principali DCC utilizzati nella produzione 3D: 3ds Max, Maya, Cinema 4D, Blender, Houdini, After Effects e NukeX. Supportiamo anche i render engine che girano su di essi — V-Ray, Corona, Arnold, Redshift, Octane e Cycles. Le partnership ufficiali con Maxon (Cinema 4D, Redshift, Red Giant, Universe), Chaos (V-Ray, Corona, Vantage, Phoenix FD) e AXYZ design (animazione folla Anima) forniscono licenze verificate per tali motori sulla nostra farm, quindi non è necessario portare o trasferire i propri seat per i titoli supportati.

Per un riassunto in una riga da incollare in un brief di progetto: "Super Renders Farm esegue la sua scena su nodi CPU e GPU gestiti, con i principali DCC e render engine licenziati a livello di farm — lei carica, noi eseguiamo il rendering, lei scarica."

Cos'è il rendering cloud

Il rendering cloud sposta il lavoro computazionale del rendering di scene 3D dalla workstation locale a macchine remote che operano in parallelo. Invece di una workstation che elabora 5.000 fotogrammi nel corso di un weekend, decine di nodi dividono la coda e completano lo stesso carico di lavoro in poche ore.

Due modelli principali in questo mercato:

• Render farm IaaS — si noleggia la macchina base con fatturazione oraria, si installa il proprio DCC e render engine, si configurano i percorsi degli asset e le licenze, e si orchestra la coda autonomamente. Questo modello offre accesso diretto alla console e il massimo controllo, in cambio di tempo di configurazione e responsabilità operativa (si gestiscono i guasti, si pagano le ore inattive, si portano le licenze).
• Render farm completamente gestite — l'operatore gestisce lo stack software, il routing delle licenze, la pianificazione delle code e la risoluzione dei problemi a livello di nodo. Si inviano i job e si scaricano i risultati. Questo modello è più rapido da avviare e ha meno componenti in movimento dal lato dell'utente, in cambio di un accesso meno diretto all'ambiente di rendering e una struttura dei costi diversa (si paga per il compute consumato, non per le ore macchina noleggiate).

Super Renders Farm è la seconda categoria. I compromessi non sono astratti: se si ha una scadenza ravvicinata, un progetto che necessita di un render engine più tre plugin, e nessun pipeline TD a tempo pieno nello staff, il modello gestito elimina la variabilità di configurazione che spesso assorbe le prime 24 ore della settimana di scadenza. Se si gestisce già un team di pipeline che possiede il versionamento dei DCC, gli script di installazione dei plugin e i server di licenze, una render farm IaaS può offrire più controllo di quanto non si otterrebbe su una farm gestita.

Per un'analisi più approfondita di come funziona effettivamente il rendering cloud, un framework per valutare qualsiasi render farm cloud e un confronto tra i principali provider, la guida dedicata è qui: .

Il nostro hardware

La composizione della nostra flotta è importante perché cambia per quali tipi di job siamo più adatti. Non elenchiamo il numero di macchine (una "macchina" è un'unità inadeguata — un singolo nodo GPU con otto schede RTX non equivale a un singolo nodo CPU). Descriviamo invece la flotta in termini che si mappano direttamente su ciò che utilizzerà il suo job.

• Capacità di rendering CPU: oltre 20.000 core CPU sulla nostra render farm. I worker node eseguono processori dual Intel Xeon E5-2699 V4 con 96–256 GB di RAM per nodo. Questa è la struttura portante della nostra operatività — i job V-Ray, Corona e Arnold CPU costituiscono circa il 70% del nostro volume di rendering. I progetti di archviz interni, i pass di animazione di personaggi e i progetti di motion design a lungo termine atterrano tipicamente qui.
• Capacità di rendering GPU: macchine GPU dedicate con NVIDIA RTX 5090 con 32 GB di VRAM ciascuna. Eseguiamo job Redshift, Octane e V-Ray GPU su questa flotta. Il limite di 32 GB di VRAM è sufficientemente alto per la maggior parte delle scene di produzione (inclusi Forest Pack denso e displacement complesso) ma non illimitato — si consulti la documentazione per la risoluzione dell'overflow di VRAM nel caso in cui si superi tale limite.
• Rete e archiviazione condivisa: tutti i worker node condividono un tier di archiviazione ad alto throughput. La risoluzione dei percorsi degli asset viene gestita al momento dell'invio, quindi i progetti con molti riferimenti collegati (Forest Pack, RailClone, XGen, file IES, configurazioni OCIO, cache tx) funzionano senza debug dei percorsi UNC dal suo lato. Il layer di invio traduce i percorsi locali in percorsi locali della farm automaticamente — questa è una delle parti fondamentali di "completamente gestita".
• Licenze dei render engine: le licenze V-Ray, Corona, Arnold, Redshift, Octane e Cycles sono raggruppate a livello di farm. Il suo job utilizza una licenza disponibile al momento dell'invio. Non trasferisce il proprio seat e non paga le tariffe di licenza in aggiunta ai propri render credit (il prezzo per GHz copre sia il compute che la licenza del motore).

Per un'analisi approfondita delle differenze di prezzo tra GPU e CPU e su come stimare un job prima di inviarlo, si consulti la e gli articoli sui costi collegati da lì.

Come è organizzata questa documentazione

Abbiamo strutturato questa documentazione attorno a quattro punti di ingresso pratici, più un riferimento autonomo. La navigazione a sinistra riflette lo stesso raggruppamento.

• Getting Started — welcome (questa pagina), quick-start-guide e pricing-and-credits. Si legga prima di tutto se è nuovo sulla nostra farm. La guida rapida copre il flusso carica-invia-scarica dall'inizio alla fine; la documentazione sui prezzi spiega come funzionano i render credit, il GHz-Hr e il cost calculator.
• DCC Pipelines — una documentazione per ogni DCC supportato: setting-up-3dsmax, setting-up-maya, setting-up-c4d, setting-up-blender, setting-up-houdini e setting-up-after-effects. Ciascuna copre gli stessi sei argomenti nello stesso ordine: installazione del plugin, convenzioni di packaging del progetto, opzioni di invio (sito web, Client App o plugin DCC), versioni dei render engine supportate, guida al formato di output e note di compatibilità note. Se lavora principalmente in un DCC, aggiunga ai segnalibri la pagina corrispondente.
• Common Issues & Reference — common-errors, troubleshoot-render-quality, upload-and-download, vray-optimization-guide e faq. Queste risorse vanno utilizzate quando qualcosa non ha prodotto il rendering previsto, quando un caricamento è fallito, o quando si vuole approfondire un argomento specifico come la reuse della light cache e della irradiance map di V-Ray.
• Tools — tools-client-app, tools-plugin-installation e tools-utilities. Riferimento per la SuperRenders Client App (incluso il percorso di migrazione Spaces), gli installer dei plugin DCC e le utility ausiliarie (preset di test render, archiver, lettori di log).

Più un riferimento autonomo: legal-and-policies. Questa pagina è la fonte canonica per i Termini di Servizio, la Privacy Policy, la politica di rimborso e gli impegni in materia di trattamento dei dati che si applicano quando si carica un progetto sulla nostra infrastruttura.

Aggiorniamo questa documentazione man mano che la nostra farm cambia — quando viene distribuita una nuova versione di DCC, quando la nostra flotta hardware cambia, quando un render engine che supportiamo riceve una versione principale, quando una funzionalità della Client App come Spaces diventa generalmente disponibile. Ogni documento porta un timbro "ultimo aggiornamento" in cima, così è possibile vedere cosa è corrente.

Da dove iniziare

Se non si è sicuri di quale documento aprire per primo, i due punti di partenza più comuni coprono quasi tutti.

Iniziare per attività — si ha un progetto da rendere subito.

1. Si legga la . Illustra la configurazione dell'account, la preparazione della scena, il caricamento, l'invio, il monitoraggio della coda e il download in un flusso continuo. La procedura dettagliata richiede circa 10 minuti di lettura e 20–40 minuti di pratica, a seconda delle dimensioni del rendering di prova.
2. Si dia una scorsa a prima di inviare un job reale. Il sistema di render credit e l'unità GHz-Hr sono semplici una volta visti; il consente di stimare un job in 30 secondi. Si raccomanda di eseguire prima un piccolo rendering di prova e di utilizzare il suo costo misurato per estrapolare il job completo.
3. Se un rendering fallisce o restituisce output inatteso, si passi a . I 10-15 problemi principali sono documentati lì con le esatte istruzioni di risoluzione.

Iniziare per DCC — si vuole sapere come si comporta il proprio software specifico sulla nostra farm.

1. Si apra la documentazione setting-up-* pertinente per il proprio DCC (3ds Max, Maya, Cinema 4D, Blender, Houdini o After Effects). Ogni documentazione setting-up-* è autonoma — non dovrebbe essere necessario seguire una catena di link incrociati per eseguire il rendering del primo job.
2. Ogni documentazione setting-up-* copre: installazione del plugin, convenzioni di packaging del progetto (cosa includere, cosa escludere), opzioni di invio (caricamento sul sito web, Client App o plugin DCC) e note di compatibilità note per i render engine su quel DCC.
3. Si torni alla per il flusso universale carica-invia-scarica una volta configurato il DCC.

Se il progetto è ibrido (ad esempio, una simulazione Houdini memorizzata nella cache ed eseguita tramite Cinema 4D + Redshift), si legga la pagina del DCC di simulazione per la guida alla memorizzazione nella cache e la pagina del DCC di rendering per l'invio.

Cosa cambia tra un rendering desktop e un rendering su farm

Questa è la sezione che sorprende più spesso i nuovi utenti del rendering cloud, quindi l'abbiamo separata:

• I percorsi devono risolversi sulla farm. Qualsiasi elemento a cui si fa riferimento tramite un percorso assoluto (C:\textures\..., /Users/utente/...) non verrà trovato sulla farm. Si utilizzino percorsi relativi all'interno del progetto pacchettizzato, o ci si affidi alla funzione "package project" del DCC (3ds Max archive, Maya File > Archive Scene, Blender pack external data, Cinema 4D save with assets). Ogni documentazione setting-up-* ha il percorso di menu esatto.
• I plugin devono corrispondere all'elenco supportato. I plugin supportati sono preinstallati su ogni worker node. I plugin non presenti nell'elenco falliranno al momento dell'invio con un errore chiaro. L'elenco dei plugin supportati per DCC è su ogni pagina setting-up-* ed è aggiornato quando aggiunge o rimuove supporto.
• I server delle licenze non sono propri. Non si configurano server di licenze o conteggi di licenze floating. La farm raggruppa le licenze V-Ray, Corona, Arnold, Redshift, Octane e Cycles dal proprio lato. Se si vede un errore di licenza, la causa è quasi sempre una mancata corrispondenza della versione del plugin (non una carenza di seat) — la documentazione ha l'esatta procedura di triage.
• La memoria GPU è finita. Una scena che viene renderizzata sulla scheda locale da 24 GB potrebbe fallire su una scheda da 32 GB della farm se la scheda locale stava utilizzando il fallback alla memoria di sistema. La risoluzione dell'overflow di VRAM è documentata in e nelle pagine di ottimizzazione specifiche per DCC.
• L'ordine della coda è FIFO all'interno del tier di priorità. Il suo job entra in coda al momento dell'invio. Se ha bisogno che un job inizi prima, la Client App ha un'opzione di priorità (trattata in tools-client-app); non offriamo salti manuali della coda via chat.

Quando ha bisogno di assistenza

Tre percorsi di escalation, in ordine di preferenza.

• Cercare prima in questa documentazione. Le domande più comuni sono trattate nelle , nella pagina setting-up-* pertinente per il proprio DCC, o nel riferimento . La casella di ricerca in cima alla documentazione copre tutte le pagine e le lingue.
• Live chat su knowledge.superrendersfarm.com. Per domande relative all'account, alla fatturazione, ai rendering in corso, o per qualsiasi cosa in cui un dialogo sia più rapido di una email, la chat è il canale giusto. Il nostro team risponde durante l'orario di lavoro e in pochi minuti durante i periodi di punta. Il widget di chat è disponibile su ogni pagina della documentazione (in basso a destra).
• Email. Per partnership, pipeline personalizzate, NDA, domande su rimborsi o fatturazione, o qualsiasi cosa che richieda una traccia scritta, si scriva a supportcenter@superrendersfarm.com. Si utilizzino i tag nell'oggetto "Privacy request", "Legal inquiry", "Refund" o "NDA" affinché il messaggio venga instradato alla persona giusta. Per le richieste di NDA in particolare, la spiega cosa possiamo firmare e come funziona il processo.

Una nota su ciò che non facciamo via chat: revisione della qualità del rendering frame per frame, feedback sulla direzione artistica o consulenza sul pipeline di produzione. Siamo operatori dell'infrastruttura di rendering, non il team di produzione del suo progetto. Detto questo, se un risultato di rendering sembra errato in un modo che suggerisce un problema lato farm (artefatto a livello di driver, versione errata del motore, interruzione del server delle licenze), lo porti in chat con un fotogramma e un ID job — questo è esattamente il caso per cui la coda di chat è pensata.

Cosa questa documentazione non coprirà

Per definire le aspettative in modo onesto: questa documentazione copre come utilizzare Super Renders Farm. Non copre:

• Come modellare, illuminare, animare o compositare una scena. Si presume che l'utente operi già nel DCC con cui lavora; copriamo le parti che cambiano quando si sposta il rendering dalla workstation locale.
• La teoria di ottimizzazione per motore oltre le correzioni pratiche che compaiono sulla nostra farm. La vray-optimization-guide copre le impostazioni specifiche di V-Ray che cambiano materialmente il tempo di rendering sulla nostra flotta; la teoria di rendering più approfondita appartiene alla documentazione del fornitore del motore.
• I prezzi per gli impegni personalizzati (contratti annuali per grandi studi, richieste di installazione di plugin personalizzati, distribuzioni mirror on-prem). Queste conversazioni avvengono via email — la documentazione sui prezzi copre il prezzo standard self-serve.

Aggiorniamo questa documentazione man mano che la nostra farm cambia — quando viene distribuita una nuova versione di DCC, quando la nostra flotta hardware cambia, quando un render engine che supportiamo riceve una versione principale. Ogni documento porta un timbro "ultimo aggiornamento" in cima, così è possibile vedere cosa è corrente, e il changelog in fondo alla home della documentazione elenca le modifiche rilevanti negli ultimi 90 giorni.

Benvenuto a bordo. Il percorso più diretto da qui è la .