Avvio rapido: dal caricamento al primo rendering

Questa guida accompagna un account nuovo attraverso l'intero percorso dalla registrazione a un rendering completato sul proprio disco locale. L'intero ciclo richiede circa dieci minuti di lavoro attivo più il rendering stesso. Abbiamo mantenuto la guida indipendente dal motore a livello generale — i passaggi universali sono gli stessi per una scena archviz 3ds Max + V-Ray o una simulazione Houdini + Redshift. Le particolarità di packaging specifiche per DCC si trovano nelle documentazioni setting-up-{DCC}, collegate di seguito dove rilevante.

La procedura dettagliata "Hello World" in 10 minuti

Se si legge solo una sezione, si legga questa. Questi otto passaggi coprono il ciclo di vita completo del rendering.

Passaggio 1 — Creare un account. Si registri su superrendersfarm.com con un indirizzo email che si monitora effettivamente. Fatture, notifiche di completamento del rendering e messaggi dell'account vengono inviati lì. I nuovi account includono 25 $ di credito di prova gratuito, così è possibile eseguire un rendering di prova reale senza impegnare budget.

Passaggio 2 — Preparare la scena. Si apra il progetto nel proprio DCC e si esegua il comando di packaging integrato (File → Archive, Collect Files, Save Project with Assets, a seconda dello strumento). L'obiettivo è una singola cartella autonoma in cui ogni texture, proxy, cache e riferimento si risolve tramite un percorso relativo. Si veda §Preparare il progetto di seguito per il principio e le documentazioni specifiche per DCC per i passaggi specifici dello strumento.

Passaggio 3 — Caricare il progetto pacchettizzato. Si trascini la cartella nell'uploader web, si importi da Google Drive o Dropbox utilizzando il connettore, oppure si utilizzi la SuperRenders Client App per un trasferimento ripristinabile per i progetti più grandi. Si veda §Caricare il progetto di seguito per la selezione rapida e /docs/upload-and-download per il riferimento completo.

Passaggio 4 — Scegliere come inviare. Sono disponibili tre metodi di invio: il sito web (modulo browser, nessuna installazione), la SuperRenders Client App (app desktop, compatibile con le code) o un plugin DCC (invio dall'interno di 3ds Max, Maya, Cinema 4D o Houdini). La tabella decisionale di seguito spiega quale si adatta al proprio flusso di lavoro.

Passaggio 5 — Configurare il job. Nel modulo di invio, confermare il file di scena, il percorso di output, l'intervallo di fotogrammi, il render engine, il formato di output e la risoluzione. Il pannello di controllo mostra un costo stimato in crediti prima di confermare.

Passaggio 6 — Eseguire prima un fotogramma di prova. Prima di inviare una sequenza di 1.500 fotogrammi, inviare un singolo fotogramma rappresentativo come job di prova. Questo rileva asset mancanti, percorsi di output errati e mancate corrispondenze delle versioni del motore al costo di pochi centesimi invece del costo di una sequenza completa. La sezione §Eseguire prima un rendering di prova copre cosa verificare.

Passaggio 7 — Monitorare il job. Si apra il pannello di controllo e si osservi l'avanzamento del job. I fotogrammi vengono completati uno per uno, il tempo di rendering per fotogramma viene registrato e il contatore dei costi si aggiorna man mano che vengono spesi crediti. Se un fotogramma fallisce, il pannello di controllo mostra il log degli errori per fotogramma. La maggior parte degli errori del primo job è trattata in /docs/common-errors.

Passaggio 8 — Scaricare e confermare i crediti. Al termine del job, scaricare i fotogrammi renderizzati dal pannello di controllo (archivio singolo per job piccoli, URL per fotogramma per sequenze più grandi). Si verifichi il registro dei crediti — il costo visualizzato dovrebbe corrispondere alla stima pre-invio entro pochi punti percentuali. La fattura per quel job compare nella cronologia di fatturazione.

Dal passaggio 8 si è pronti a inviare il job successivo con un costo reale ed empirico per fotogramma invece di una stima.

Tabella decisionale: quale metodo di invio è adatto?

Supportiamo tre metodi di invio. Nessuno di essi è sbagliato — si adattano a diversi stili di lavoro.

| Metodo | Ideale per | Compromesso | |---|---|---| | Modulo web | Job occasionali, utenti alle prime armi, workstation condivise, impossibilità di installare | Compilazione manuale del modulo per ogni invio; non ideale per chi invia con alta frequenza | | SuperRenders Client App | Chi invia quotidianamente, progetti grandi (>20 GB), batch di più job, chi ha bisogno di upload ripristinabili | Installazione e login una tantum sulla workstation | | Plugin DCC (3ds Max, Maya, Cinema 4D, Houdini) | Lavoro su shot iterativo, invio dall'interno dell'app host, invii consapevoli del contesto della scena | Installazione del plugin per DCC; non tutti i DCC hanno ancora copertura del plugin |

Il sito web funziona per tutti e non richiede nulla sulla propria macchina. La Client App è la risposta giusta una volta che si carica più di una volta alla settimana. Il plugin DCC si adatta bene quando l'invio deve sembrare un pulsante di rendering su disco all'interno dello strumento esistente.

Per una copertura più approfondita: /docs/tools-client-app illustra l'installazione, il login e il comportamento dell'albero di progetto della Client App. /docs/tools-web-submit copre il flusso di invio tramite browser in profondità.

Inviare un job di rendering

Questa sezione è il riferimento per il flusso di invio tramite sito web. I flussi della Client App e del plugin DCC condividono gli stessi campi concettuali — ciò che differisce è l'interfaccia circostante.

Account e login. Si acceda al pannello SuperRenders. La home dell'account mostra il saldo crediti corrente, i job recenti, le fatture e un punto di accesso "invia nuovo job". Il credito di prova da 25 $ è già sul saldo, quindi non è necessario un ricarico prima del primo rendering di prova.

Il caricamento avviene prima. Un job di rendering è sempre collegato a un progetto già esistente nell'archiviazione progetti di SuperRenders, quindi il passaggio di caricamento (vedi §Caricare il progetto di seguito) avviene prima dell'invio. Facendo clic su invia senza un progetto caricato si viene reindirizzati al flusso di caricamento.

File di scena. Il modulo di invio elenca i file all'interno della cartella del progetto caricato. Si scelga il file di scena principale — .max, .ma o .mb, .c4d, .blend, .hip o .hipnc, .aep, .nk. Se il progetto contiene asset referenziati, si confermi che sia selezionata la scena principale, non una sotto-scena referenziata.

Render engine. Si scelga il motore per cui è configurata la scena — V-Ray, Corona, Arnold, Redshift, Octane o Cycles. Il pannello di controllo rileva automaticamente il motore nella maggior parte dei casi; verificare prima di inviare. Inviare una scena V-Ray come Corona, o viceversa, fallirà sul worker.

Intervallo di fotogrammi e output. Si configurino i fotogrammi di inizio/fine/passo (es. 1-1500 passo 1, o 1001-1100 passo 2 per ogni altro fotogramma). Il formato di output predefinito è quello dell'impostazione della scena; sovrascrivere al momento dell'invio se necessario. Il pattern del nome del file di output accetta token standard come <scene>_<frame>.exr.

Override di risoluzione e qualità. La maggior parte degli utenti lascia questi valori alle impostazioni predefinite della scena. Sovrascrivere solo quando c'è un motivo chiaro — ridurre la scala per proxy, aumentarla per la consegna. I parametri di campionamento, denoising e illuminazione rimangono generalmente nel file di scena.

Stima dei costi. Prima dell'invio definitivo, il pannello di controllo mostra un costo stimato in render credit e in dollari. La stima utilizza un tempo medio per fotogramma moltiplicato per il conteggio dei fotogrammi e il prezzo per GHz per il proprio motore. La si tratti come un numero di pianificazione, non un contratto — il costo effettivo dipende dalla complessità per fotogramma. Per il modello di prezzi GHz·hour, si veda /docs/pricing-and-credits.

Inviare. Una volta inviato, il job entra in coda. La maggior parte dei job inizia entro un minuto durante il carico normale; i grandi burst possono accodarsi brevemente. L'URL del pannello di controllo del job diventa la propria vista di monitoraggio.

Preparare il progetto

La maggior parte dei job di rendering falliti che vediamo non sono bug del motore — sono lacune nel packaging. Una scena che si renderizza correttamente sulla workstation dell'artista può fallire su un worker nuovo perché il percorso di alcuni asset punta a un'unità solo locale, o perché una sotto-scena referenziata non è mai stata inclusa nel caricamento.

Il principio di packaging è semplice: tutto ciò di cui la scena ha bisogno per renderizzarsi deve essere all'interno di una cartella, e ogni riferimento all'interno della scena deve risolversi come percorso relativo all'interno di quella cartella.

La maggior parte dei DCC include un comando integrato per questo:

• 3ds Max — File → Archive raggruppa la scena e tutti gli asset referenziati.
• Maya — File → Archive Scene produce un archivio .ma o .mb autonomo.
• Cinema 4D — File → Save Project with Assets.
• Blender — File → External Data → Pack All Into .blend, oppure Make All Paths Relative e poi copiare la cartella del progetto.
• Houdini — il workflow di archiviazione del progetto più File → Pack Geometry gestiscono .hip e le cache.
• After Effects — File → Dependencies → Collect Files.
• NukeX — Export Selected Nodes → Archive Project.

Dopo il packaging, si effettui una verifica. Si apra il progetto pacchettizzato su una macchina diversa o su un account utente nuovo e si confermi che si apre senza avvisi di asset mancanti. Per i DCC con un elenco di asset (3ds Max Asset Tracker, Maya File Path Editor, Cinema 4D Project Asset Inspector, Blender External Data), si confermi che ogni voce si risolve all'interno della cartella del pacchetto. Se il progetto utilizza plugin di terze parti (Forest Pack, RailClone, Anima, X-Particles e simili), si confermi che siano elencati nella copertura dei plugin della documentazione setting-up-{DCC} pertinente.

Nota sul formato di archivio: accettiamo tar, tar.gz e 7z. Non accettiamo .zip — si ripackettizzi come .tar.gz, oppure si salti l'archiviazione e si utilizzi SFTP o la Client App.

Eseguire prima un rendering di prova

Prima di inviare un'animazione da 1.500 fotogrammi come primo job, inviare un singolo fotogramma dal mezzo della sequenza. È l'assicurazione a costo più basso che si possa acquistare su un job di rendering.

Un fotogramma di prova rivela problemi che la stima dei costi non può — percorsi di asset mancanti, mancate corrispondenze delle versioni dei plugin, errori lato motore. Una sequenza completa fallita costa tempo di coda più eventuali addebiti per fotogramma riusciti prima che la coda si interrompesse. Un fotogramma di prova fallito costa pochi centesimi.

Cosa testare:

• Un singolo fotogramma dal mezzo della sequenza (non il fotogramma 1, che spesso ha uno stato di configurazione unico).
• Le stesse impostazioni di rendering, risoluzione e formato di output che si utilizzeranno per la sequenza completa.
• Se il progetto ha più telecamere o shot, testare un fotogramma per telecamera o shot.

Cosa cercare:

• Il fotogramma renderizzato corrisponde visivamente al viewport locale o all'IPR?
• Sono presenti tutte le luci, le ombre, il GI, gli AOV e gli effetti post-processing previsti?
• Il tempo di rendering per fotogramma ha corrisposto al benchmark locale? Se il worker ha impiegato notevolmente più tempo, c'è qualcosa di sbagliato — una texture mancante è ricaduta su un valore predefinito, il displacement ha suddiviso in modo inatteso, o un AOV sta scrivendo dati non validi.
• Si controlli il log per avvisi. "Missing texture", "license fallback" o "plugin not loaded" segnalano problemi reali.

Se il fotogramma di prova è errato, si corregga la scena localmente, si ripackettizzi, si ricarichi e si reinvii. Non si promuova un test non funzionante a un invio di sequenza completa — il debug di 1.500 fotogrammi dopo il fatto è doloroso.

Tour del pannello di controllo

Il pannello di controllo è il centro operativo per tutto ciò che si fa sulla nostra farm. Le viste principali:

Home dell'account. Riepilogo del saldo crediti, job in corso, fatture recenti e il punto di accesso "invia nuovo job". Il saldo si aggiorna ogni pochi secondi durante il rendering di un job, così è possibile osservare il contatore dei costi.

Elenco job. Elenco in ordine cronologico inverso di ogni invio. Ogni riga mostra nome del job, file di scena, motore, intervallo di fotogrammi, stato, tempo trascorso e costo attuale. Si faccia clic su una riga per i dettagli per job.

Vista dettaglio per job. Una griglia di stato per fotogramma (celle codificate a colori per stato), file di log per fotogramma, il registro dei costi e il pannello di download. I fotogrammi falliti possono essere reinviati individualmente senza rieseguire l'intero job.

Archiviazione progetti. Elenca i propri progetti caricati. Si sfoglia l'albero degli asset, si eliminano i progetti vecchi o si riutilizza un progetto esistente come sorgente per un nuovo invio. L'output del rendering viene conservato per 45 giorni dopo il completamento del job — si scarichi tempestivamente o si configuri la Client App per il download automatico nell'archiviazione locale.

Fatturazione e fatture. Cronologia degli acquisti di crediti, addebiti di rendering per job e fatture scaricabili. La fattura per un job completato appare entro un minuto. I render credit non scadono.

Impostazioni. Token API (per autenticazione Client App e plugin), preferenze di notifica email, percorsi di output predefiniti e impostazioni predefinite a livello di account.

Un'abitudine utile per i nuovi utenti: lasciare la vista dettaglio per job aperta in una scheda del browser durante i primi rendering. Osservare i fotogrammi completarsi in tempo reale sviluppa l'intuizione su quali scene sono veloci, quali sono lente e dove nel progetto va effettivamente il tempo di rendering.

Caricare il progetto

Il flusso di invio richiede che il progetto pacchettizzato sia già nell'archiviazione progetti di SuperRenders. Tre percorsi di caricamento coprono i casi comuni.

Caricamento web. Trascina e rilascia nel pannello di controllo. Funziona bene per progetti fino a qualche decina di GB. Si mantenga qualsiasi singolo caricamento web al di sotto di 300 GB; al di sopra, SFTP o la Client App sono più sicuri perché sono ripristinabili e parallelizzabili. Adatto a caricamenti occasionali dove l'installazione non è desiderata.

Connettore Google Drive o Dropbox. Se il progetto pacchettizzato è già in un account di cloud storage, si colleghi il connettore nelle impostazioni del pannello di controllo, poi si indirizzi SuperRenders alla cartella sorgente. Il trasferimento è da server a server, il che è più veloce che scaricare nuovamente sul laptop e ricaricare. Questo è solo per l'importazione — i rendering completati non vengono inviati a Google Drive o Dropbox; si scaricano dal pannello di controllo, tramite SFTP o con il download automatico della Client App.

SuperRenders Client App. Per chi invia con alta frequenza o per progetti di grandi dimensioni, la Client App suddivide il caricamento in blocchi, lo riprende in caso di interruzioni di rete e deduplica i file già caricati nei progetti precedenti. Installazione e autenticazione sono trattate in /docs/tools-client-app.

Questa pagina copre i percorsi di caricamento a livello di riferimento rapido. Per la copertura completa — aspettative di velocità, quote di archiviazione account, restrizioni sui tipi di file e percorsi di download per i rendering completati — si veda /docs/upload-and-download.

Cosa leggere successivamente

Il flusso universale è ora chiaro. Le letture successive naturali:

• Domande sui costi → /docs/pricing-and-credits per il sistema di crediti, i prezzi per GHz e la stima pre-invio.
• Packaging specifico per DCC → la documentazione /docs/setting-up-{DCC} pertinente per il proprio software.
• Approfondimento sul caricamento → /docs/upload-and-download per trasferimenti ripristinabili, pattern di sincronizzazione e opzioni di download.
• Qualcosa è fallito → /docs/common-errors copre le modalità di fallimento del primo job più frequenti.
• Strumento di stima dei costi → il fornisce una stima per motore e per risoluzione.
• Riferimento prezzi → per le tariffe correnti per GHz e i prezzi dei pacchetti di crediti.
• Lettura di approfondimento → spiega il modello e come si confronta con le render farm IaaS.
• Torna all'inizio → .

Questa pagina viene aggiornata quando il flusso di invio cambia, viene distribuita una nuova versione di DCC o il feedback dei nuovi clienti evidenzia un passaggio non spiegato sufficientemente. Se qualcosa qui non corrispondeva a quanto visto nel pannello di controllo, la live chat su knowledge.superrendersfarm.com è il canale giusto — il nostro team utilizza quel feedback per mantenere la documentazione aggiornata.