Utility avanzate: Template nodo, Risolvi macchina, Simula percorso, API

Super Renders Farm espone quattro utility avanzate per gli studi che necessitano di più del flusso predefinito di caricamento-invio-download via web: Template nodo di rendering (definire uno stack software riproducibile per i worker che eseguono il rendering del job), Risolvi macchina (avviare una VM di debug accessibile via RDP che corrisponde all'ambiente del nodo di rendering), Simula percorso locale (preservare i percorsi assoluti per i progetti che risolvono gli asset tramite percorso hard-coded), e la superficie di accesso API (attualmente limitata — consultare §Accesso API per la situazione attuale sull'invio programmatico). Questa pagina è il manuale di riferimento per tutte e quattro — quando usare ciascuna, come funziona il meccanismo sottostante sulla nostra render farm, i passaggi esatti per configurare o invocare ciascuna utility, e le modalità di errore che vediamo più spesso nel supporto.

Se si è nuovi alla render farm e si cerca il flusso di caricamento predefinito, la è il punto di partenza giusto. Se si sta effettuando il debug di un job fallito, la pagina copre i pattern di errore più frequenti. Le utility documentate qui sono per i casi in cui il flusso predefinito non si adatta — tipicamente studi di grandi dimensioni con pipeline consolidate, progetti con requisiti insoliti per i percorsi degli asset, o sessioni di debug occasionali in cui è necessario vedere esattamente ciò che vede il worker di rendering.

Quale utility usare — riepilogo decisionale

Una breve orientazione prima delle sezioni per utility:

| Se si ha bisogno di… | Usare | |---|---| | Bloccare quale versione DCC, versioni dei plugin e licenze dei plugin vengono eseguiti sui worker assegnati al job | Template nodo di rendering | | Connettersi a un worker di rendering reale tramite Microsoft Remote Desktop, correggere una scena in loco, quindi inviarla come job reale | Risolvi macchina | | Eseguire il rendering di un progetto che utilizza percorsi assoluti (C:\projects\… o D:\textures\…) e non può essere riconfigurato con percorsi relativi | Simula percorso locale | | Inviare job in modo programmatico da uno script o uno strumento di pipeline | Accesso API (vedere il placeholder — il percorso attuale è Client App o il plugin DCC) |

È possibile combinare queste utility. Un Template nodo di rendering può essere abbinato a Simula percorso locale sullo stesso job. Risolvi macchina rispetta sia il Template nodo di rendering attivo sia qualsiasi configurazione Simula percorso locale, in modo che l'ambiente di debug corrisponda all'ambiente di rendering in produzione. Le quattro utility sono progettate per essere composte.

Template nodo di rendering

Il Template nodo di rendering è la più potente delle quattro utility e la più longeva. Consente di specificare l'esatto ambiente software che i worker di rendering dovrebbero avere prima di prendere in carico il job: quale versione di 3ds Max, quale build di V-Ray, quali plugin sono installati e licenziati, e qualsiasi file di configurazione personalizzato che deve essere in posizione sul worker prima dell'avvio del rendering. Una volta definito, il template è riutilizzabile tra job — ogni invio contrassegnato con quel template viene eseguito su uno stack di worker identico.

Il problema che risolve

Per impostazione predefinita, Super Renders Farm preinstalla uno stack software curato su ogni worker di rendering — versioni DCC recenti e i renderer e plugin più comuni, calibrati per i carichi di lavoro che vediamo più spesso. Per l'80% dei job questo è il valore predefinito giusto; il worker ha già il software di cui la scena ha bisogno. Ma ci sono due situazioni in cui il valore predefinito non è sufficiente:

• Blocco della versione. Lo studio si è standardizzato su 3ds Max 2024 + V-Ray 6.10.05 + una specifica build di Forest Pack, e non ci si può permettere che un worker riceva una versione più recente che introduce differenze di campionamento o di rumore tra frame nella stessa animazione.
• Plugin di nicchia. Si utilizza un plugin (o una versione di plugin) che non è nello stack predefinito della render farm — ad esempio, una release meno comune di Phoenix FD, un bridge Pulze ZBrush, o una build speciale di Corona.

Il Template nodo di rendering consente di dichiarare lo stack in modo esplicito. La render farm instrada quindi il job su worker che già corrispondono al template dichiarato, oppure predispone nuovi worker in modo che corrispondano prima di assegnare il job. In entrambi i casi, la garanzia di blocco della versione è end-to-end.

Come funziona sulla nostra render farm

Un Template nodo di rendering è un record di configurazione denominato collegato al Suo account. Contiene:

• Il DCC e la versione — ad esempio 3ds Max 2024.2.2.
• Il renderer e la versione — ad esempio V-Ray 6.10.05.
• Un elenco di plugin con versioni — ad esempio Forest Pack Pro 8.4.2, RailClone Pro 6.3, Phoenix FD 5.10.
• Un canale di licenza — quali licenze (Chaos, Maxon, Otoy, AXYZ Design) dovrebbero essere disponibili per il worker tramite la nostra infrastruttura di licenze ombrello. La maggior parte dei plugin è coperta di default; se il template fa riferimento a un plugin che non ospitiamo ancora, il supporto lo segnala e sarà necessario fornire il proprio file di licenza.
• Payload di file opzionali — file di configurazione, preset o librerie di shader che devono essere posizionati in un percorso noto sul worker prima dell'avvio del rendering.

Quando si invia un job e lo si contrassegna con un template, lo scheduler della render farm abbina il template al pool di worker corrente. Se i worker corrispondenti sono inattivi, il job viene inviato immediatamente. Se nessun worker corrispondente è disponibile, lo scheduler predispone un worker nuovo in base al template — questo richiede in genere alcuni minuti in più rispetto a un job con stack predefinito, il che è il compromesso principale.

Creazione di un Template nodo di rendering

L'editor del template è accessibile dal pannello di controllo del Suo account nella sezione "Render Node Templates" (o simile — l'etichetta esatta dell'interfaccia può cambiare tra le release del pannello di controllo; se la voce non è visibile, contattare il supporto e la renderemo disponibile per il Suo account).

Passaggi:

1. Accedere a superrendersfarm.com e aprire la sezione Render Node Templates del pannello di controllo.
2. Creare un nuovo template e assegnargli un nome descrittivo — tipicamente un codice di progetto o un'etichetta standard dello studio come studio-archviz-2024-vray6. Il nome è a Sua discrezione; la render farm lo utilizza solo per l'abbinamento.
3. Scegliere il DCC e la versione. Il menu a discesa elenca ogni versione DCC che ospitiamo attualmente. Se la versione richiesta non è elencata, il template non può essere creato senza una conversazione con il supporto — alcune versioni legacy sono state deprecate.
4. Scegliere il renderer e la versione. Stesso vincolo — il menu a discesa riflette lo stack attuale della render farm.
5. Aggiungere i plugin uno alla volta. Per ogni plugin: selezionare il nome del plugin dal catalogo, scegliere la versione e confermare il canale di licenza. I plugin fuori dal nostro catalogo richiedono una conversazione con il supporto per essere aggiunti — tipicamente un impegno una tantum se il plugin è abbastanza comune da poter ospitare la licenza.
6. Allegare eventuali payload di file. Caricare i file di configurazione o preset necessari sul worker. La render farm li conserva insieme al template e li copia nella directory di lavoro del worker prima dell'avvio del rendering.
7. Salvare e validare. Il pannello di controllo esegue un passaggio di validazione rispetto al pool di worker corrente e riporta "worker corrispondenti disponibili" (invio immediato al primo job) o "nessuna corrispondenza attuale — i worker verranno predisposti al primo utilizzo" (leggero ritardo di avvio al primo job).

Il template è ora disponibile per la selezione in qualsiasi invio successivo di job.

Utilizzo di un template al momento dell'invio

Quando si invia un job di rendering — tramite caricamento web, Client App o plugin di invio DCC — il modulo di invio include un menu a discesa "Render Node Template". Selezionare il template creato. Il job eredita l'intera dichiarazione dello stack; non è necessario specificare nuovamente il DCC, il renderer o le versioni dei plugin nel modulo di invio stesso.

Due note operative:

• Template + priorità Express si compongono. È possibile inviare un job con template con priorità Express. Lo scheduler cerca un worker inattivo che corrisponda a entrambi i vincoli; se nessuno è disponibile, ne predispone uno. I job Express con template hanno in genere una finestra di invio leggermente più lunga rispetto ai job Express con stack predefinito, ma la differenza di prezzo è la stessa.
• Template + Simula percorso locale si compongono. Se il progetto richiede anche percorsi assoluti, configurare Simula percorso locale sull'invio normalmente (vedere §Simula percorso locale). Il template controlla l'ambiente software; Simula percorso locale controlla il layout del file system. Sono preoccupazioni ortogonali.

Modifica e versionamento dei template

Un template è modificabile — è possibile modificare il blocco della versione, aggiungere o rimuovere plugin, o sostituire i payload di file. Ma la modifica di un template influisce su tutti i job futuri che lo utilizzano; i job in esecuzione già inviati continuano con la versione del template acquisita al momento dell'invio.

Per gli studi che necessitano di un rigoroso controllo delle versioni tra le revisioni del template, un pattern comune è clona-poi-modifica: quando si ha bisogno di aggiornare le versioni dei plugin, clonare il template esistente in studio-archviz-2024-vray6-r2, apportare lì le modifiche e aggiornare gli script di invio del progetto affinché puntino al nuovo template. Il vecchio template rimane invariato per qualsiasi progetto in corso che dipende dal suo stack esatto.

Modalità di errore comuni

• "Nessun worker corrispondente — il provisioning richiede 5-10 minuti." Non si tratta di un errore, solo di un avviso. Il primo job con template dopo una modifica dello stack predispone nuovi worker. I job successivi sullo stesso template vengono inviati immediatamente perché i worker sono già attivi.
• "Licenza plugin non disponibile per il template." Il plugin specificato non è nel catalogo delle licenze ospitate. Contattare il supporto — per i plugin mainstream in genere aggiungiamo le licenze ospitate entro pochi giorni lavorativi; per i plugin di nicchia possiamo sia integrare la licenza sia accettare che si fornisca un file di licenza con l'invio.
• "Versione renderer non più supportata." Le versioni DCC o renderer più vecchie vengono periodicamente ritirate dallo stack attivo. L'editor del template lo segnala al salvataggio; la correzione consiste nell'aggiornare il template a una versione supportata o nel clona-poi-modifica verso una build corrente.
• "Job inviato ma lo stack del worker non corrisponde al template." Raro, ma vale la pena sapere. Se accade, il job fallisce il controllo di sanità pre-rendering e la render farm lo rimette in coda automaticamente su un worker con corrispondenza confermata. Non si paga per il tentativo di invio fallito.

Risolvi macchina

Risolvi macchina è la controparte diagnostica al percorso di rendering in produzione. Invece di inviare un job reale e aspettare che fallisca con un messaggio di errore, si avvia una Risolvi macchina — una VM Windows che corrisponde allo stack software del nodo di rendering — e ci si connette tramite Microsoft Remote Desktop Connection. Si vede esattamente quello che vedrebbe il worker di rendering, è possibile aprire il file della scena, identificare cosa sta fallendo, correggerlo in loco, salvare la scena corretta nello storage e quindi inviare un job di produzione reale con fiducia.

Il problema che risolve

La maggior parte degli errori di rendering rientra in due categorie: problemi a livello di scena (un plugin mancante, un riferimento a un asset corrotto, un'impostazione del renderer incompatibile con la versione sul worker) e problemi a livello di ambiente (una licenza non disponibile, un plugin che non si carica, un percorso non corrispondente). Entrambi sono difficili da diagnosticare in remoto — l'unico segnale che si ottiene da un job di produzione fallito è il log di rendering, che è spesso conciso.

Risolvi macchina riduce il ciclo diagnostico. Invece di inviare → fallire → leggere il log → supporre → reinviare → fallire → supporre → reinviare, si avvia una Risolvi macchina, si vede l'errore reale nell'interfaccia GUI del DCC, lo si corregge una volta e si invia un job reale che funziona.

Come funziona sulla nostra render farm

Quando si richiede una Risolvi macchina, la render farm predispone una nuova VM Windows che corrisponde allo stack del nodo di rendering corrente per il DCC specificato (e qualsiasi Template nodo di rendering attivo, se presente). La VM monta lo storage SRF Spaces come unità S: — quindi i file del progetto già caricati appaiono esattamente come apparirebbero su un worker di rendering in produzione. Ci si connette tramite RDP dalla workstation locale.

La VM ha un budget di tempo — tipicamente misurato in minuti, fatturato rispetto ai crediti di rendering a un tasso documentato (controllare il pannello di controllo per il tasso attuale; questo cambia occasionalmente). Al termine, ci si disconnette e si invia un job di produzione dallo stesso progetto oppure si rilascia la VM.

Avvio di una sessione Risolvi macchina

Passaggi:

1. Dal pannello di controllo, navigare su "Troubleshoot Machine" (o la voce equivalente del pannello — la denominazione può variare tra le release).
2. Selezionare il DCC che corrisponde al progetto. La VM verrà predisposta con quel DCC preinstallato e corrispondente al Template nodo di rendering dichiarato, se presente.
3. Confermare il budget di tempo. Il pannello di controllo mostra il costo in crediti al minuto; ci si impegna per una durata massima della sessione e la si può estendere durante la sessione se necessario.
4. Attendere il provisioning. Questo richiede in genere alcuni minuti — viene preparata una nuova VM con lo stack software.
5. Ricevere i dettagli di connessione RDP. Il pannello di controllo fornisce un hostname, un nome utente e una password (o un file RDP scaricabile). Su Windows, fare doppio clic sul file RDP per connettersi; su macOS, usare Microsoft Remote Desktop dall'App Store.
6. Connettersi. Ci si trova ora sul worker. L'unità S: contiene i file del progetto SRF Spaces.

Utilizzo della sessione

Una volta connessi, il flusso di lavoro è lo stesso di quando si lavora direttamente sul worker di rendering:

• Aprire il file della scena da S:. Il DCC si avvia nella versione specificata dal template o nel valore predefinito della render farm per quel DCC.
• Riprodurre il fallimento. Qualsiasi cosa stesse fallendo in produzione — un'anteprima di rendering, un errore di script, un riferimento a un asset — dovrebbe riprodursi qui. Investigare usando gli strumenti diagnostici del DCC.
• Correggere la scena. Ricollegare gli asset mancanti, modificare le impostazioni di rendering, riparare i riferimenti ai plugin, o qualsiasi cosa richieda la diagnosi.
• Salvare in S:. Salvare la scena corretta in S:\SuperRendersOutput\ o in un'altra cartella in SRF Spaces. Il salvataggio è persistente — quando si termina la sessione Risolvi macchina, la scena corretta rimane nello storage.
• (Facoltativo) Inviare un job reale dall'interno della VM. Il plugin di invio SuperRenders del DCC è installato all'interno di Risolvi macchina; è possibile inviare un job di rendering in produzione dall'interno della VM, quindi disconnettersi e lasciare che la render farm esegua il rendering normalmente.

Al termine, disconnettersi da RDP e terminare la sessione dal pannello di controllo. La VM viene distrutta; tutti i file salvati in S: rimangono in SRF Spaces.

Modalità di errore comuni

• "Impossibile connettersi a RDP — connessione scaduta." Verificare che la rete locale o VPN consenta il traffico RDP in uscita (porta 3389). Alcune reti aziendali bloccano il traffico RDP in uscita. In tal caso, chiedere al team IT di inserire nella whitelist l'hostname di Risolvi macchina.
• "Credenziali RDP rifiutate." Riscaricare il file RDP dal pannello di controllo — le credenziali sono specifiche della sessione e possono scadere se la sessione viene messa in pausa troppo a lungo.
• "L'unità S: è vuota o mancano file." L'unità si mappa su SRF Spaces — se i file non compaiono, o il caricamento su SRF Spaces non era ancora completo quando la VM è stata predisposta, o si sta guardando nella cartella sbagliata. Il mount predefinito è tipicamente S:\<account-id>\.
• "La correzione ha funzionato in Risolvi macchina ma il job in produzione fallisce ancora." Nella maggior parte dei casi ciò avviene perché il job in produzione è stato inviato con un Template nodo di rendering diverso (o stack predefinito) rispetto a quello utilizzato dalla sessione Risolvi macchina. Verificare che la selezione del template nell'invio in produzione corrisponda alla configurazione di Risolvi macchina.

Simula percorso locale

Simula percorso locale è la più semplice delle quattro utility per portata, ma quella che risolve la più grande singola categoria di progetti "non renderizzabili nel cloud". Alcune scene DCC risolvono gli asset tramite percorso assoluto hard-coded — ad esempio C:\projects\studio\my-scene\textures\wood_01.tx — anziché tramite percorso relativo. Quando quella scena viene caricata su una render farm, il renderer non riesce a trovare le texture perché il percorso assoluto non esiste sul worker. Simula percorso locale fa esistere il percorso assoluto.

Il problema che risolve

La soluzione semplice per questa categoria di problemi è ripathing della scena prima dell'invio — passare ogni riferimento a un asset da assoluto a relativo — ma per alcuni flussi di lavoro ciò non è pratico:

• Scene Anima (il plugin di persone animate di AXYZ Design) scrivono percorsi assoluti ai file di cache dei personaggi al momento del salvataggio della scena; il ripathing manuale rompe il binding della cache.
• Il rendering cache 4K di Corona Image Editor scrive percorsi assoluti che il renderer si aspetta di trovare allo stesso percorso al momento del rendering.
• I flussi di lavoro di esportazione Substance / Substance Painter possono incorporare percorsi assoluti alle sorgenti delle texture.
• I riferimenti ad asset Alembic a volte scrivono percorsi assoluti a seconda delle impostazioni di esportazione del DCC.
• Vecchi progetti di archivio in cui il ripathing di ogni riferimento a un asset è impraticabile e lo studio vuole semplicemente che il progetto venga renderizzato così com'è.

Per questi casi, Simula percorso locale dice alla render farm: quando questo job viene eseguito, ricrea il percorso assoluto sul worker in modo che il renderer trovi i suoi asset dove la scena se li aspetta.

Come funziona sulla nostra render farm

Quando si carica un progetto con Simula percorso locale abilitata, SuperRenders Client App (o il caricamento web, con l'impostazione giusta) preserva la struttura del percorso assoluto originale nel caricamento. Sul worker di rendering, la render farm crea il corrispondente albero di directory allo stesso percorso assoluto prima dell'avvio del rendering — quindi se il file della scena fa riferimento a D:\studio-2024\project-x\textures\wood.tx, il worker ha un vero D:\studio-2024\project-x\textures\wood.tx al momento del rendering e la scena si risolve correttamente.

Il meccanismo è più affidabile quando abbinato all'opzione "Auto keep local path" di SuperRenders Client App, che preserva automaticamente il percorso assoluto al caricamento. Per il caricamento web, si imposta la struttura dei percorsi manualmente nella struttura delle cartelle SRF Spaces prima di caricare i file.

Configurazione di Simula percorso locale

Ci sono due percorsi per accedere a questa funzionalità:

Tramite SuperRenders Client App (consigliato):

1. In Client App, prima di aggiungere file a un caricamento, aprire le impostazioni di caricamento.
2. Abilitare "Auto keep local path" (l'etichetta esatta può cambiare leggermente tra le versioni di Client App — cercare la casella di controllo per la preservazione del percorso).
3. Aggiungere i file del progetto. Client App legge il percorso assoluto di ogni file man mano che viene aggiunto e lo preserva nell'albero del caricamento.
4. Confermare l'albero dei percorsi nell'anteprima del caricamento. Dovrebbe essere visibile la struttura del percorso assoluto completa specchiata in SRF Spaces.
5. Caricare normalmente. La struttura dei percorsi si trasferisce insieme ai file.
6. Al momento dell'invio, abilitare "Simulate Local Path" sul job — il pannello di controllo o il modulo di invio di Client App ha una casella di controllo o un menu a discesa per questo. La render farm ricreerà il percorso assoluto sul worker.

Tramite caricamento web (manuale):

1. In SRF Spaces (il browser di file web all'interno del pannello di controllo del Suo account), usare il pulsante "Crea cartella" per ricreare manualmente la struttura del percorso assoluto. Ad esempio, se il progetto fa riferimento a D:\studio-2024\project-x\, creare una cartella D: (letteralmente, come nome della cartella), quindi una sottocartella studio-2024, poi project-x, e così via.
2. Caricare i file nell'albero dei percorsi ricreato. Ogni file finisce nel percorso assoluto corrispondente all'interno di SRF Spaces.
3. Al momento dell'invio, abilitare "Simulate Local Path" sul job. La render farm leggerà la struttura dei percorsi da SRF Spaces e la replicherà sul worker.

Il percorso di caricamento web è più manuale ma funziona correttamente se configurato. Client App è più veloce e meno soggetto a errori per gli studi che lo fanno regolarmente.

Note operative

• Lettere di unità. Sul worker di rendering, l'unità simulata (ad es. D: se il progetto usa D:\…) è un mount logico, non un'unità fisica. Il mount viene creato all'avvio del job e rimosso al termine del job; non è persistente.
• Limiti di lunghezza del percorso. Windows ha limiti storici sulla lunghezza del percorso (circa 260 caratteri per le applicazioni legacy). Se i percorsi assoluti sono molto lunghi, alcuni DCC potrebbero non riuscire a caricare i file anche dopo la configurazione di Simula percorso locale. La correzione consiste nel abbreviare i percorsi a livello di progetto o nell'abilitare il supporto ai percorsi lunghi nel DCC, supportato dalla maggior parte delle versioni correnti.
• Composizione tra DCC. Simula percorso locale può essere combinata con un Template nodo di rendering e con Risolvi macchina — l'albero dei percorsi simulato appare in modo identico in tutti e tre i contesti.

Modalità di errore comuni

• "Asset ancora mancante dopo l'abilitazione di Simula percorso locale." La causa più comune è che il caricamento non ha effettivamente preservato il percorso. Aprire SRF Spaces nel pannello di controllo web e confermare che la struttura del percorso assoluto esista lì. Se non esiste, ricaricare con "Auto keep local path" abilitata in Client App.
• "Il rendering inizia ma viene caricata la texture sbagliata." A volte una scena ha più asset con lo stesso nome file in percorsi diversi; se la simulazione del percorso è incompleta, il renderer può ricorrere a un file diverso con lo stesso nome. Verificare che la struttura completa del percorso sia preservata in SRF Spaces.
• "Il renderer segnala accesso negato al percorso simulato." Questo di solito significa che il percorso coinvolge un nome di directory riservato da Windows (con, aux, prn, ecc.) che non può essere creato come cartella normale. Ripathing del progetto per evitare il nome riservato.

Accesso API

L'accesso programmatico all'invio di Super Renders Farm è nella roadmap. È in fase di progettazione una REST API pubblica per l'invio di job, il polling dello stato e il recupero dell'output; al momento non sono disponibili endpoint API pubblici per l'integrazione diretta.

Per le attuali esigenze di invio programmatico, i percorsi supportati sono:

• SuperRenders Client App — Client App desktop () può essere controllata da script su Windows e macOS tramite la sua superficie da riga di comando (dove disponibile) o tramite automazione file-drop sulla directory di caricamento. Per gli studi con strumenti di automazione della pipeline consolidati, Client App è l'attuale punto di integrazione best-practice.
• Il plugin di invio DCC — il plugin per DCC (3ds Max, Maya, Cinema 4D) si integra con l'ambiente di scripting del DCC (MAXScript, Python, ecc.) e può essere controllato da script di pipeline che già vengono eseguiti all'interno del DCC.

Quando la REST API pubblica sarà disponibile, questa sezione verrà sostituita con il riferimento API completo (autenticazione, endpoint, limiti di frequenza, esempi SDK). Per gli studi bloccati su una API pubblica per l'integrazione della loro pipeline, contattare il supporto per condividere il caso d'uso — la roadmap è informata da requisiti reali di pipeline.

Riferimenti incrociati

• — flusso predefinito di caricamento-invio-download senza queste utility
• — installazione e utilizzo dell'applicazione desktop
• — flusso di invio basato su browser
• — pattern di trasferimento per progetti di grandi dimensioni
• — come vengono fatturati i crediti di rendering, inclusi i prezzi delle sessioni Risolvi macchina
• — riferimento per la risoluzione dei problemi tra DCC
• — confronto dei metodi di caricamento
• , , — configurazione dell'invio per DCC che si abbina a queste utility

FAQ

Q: Devo usare un Template nodo di rendering per ogni job? A: No. La maggior parte dei job viene eseguita correttamente sullo stack software predefinito della render farm — le versioni DCC e renderer più comuni con i plugin più comuni. Un Template nodo di rendering è per i casi in cui si necessita del blocco della versione su un progetto a lungo termine, o dove si utilizza un plugin non nel catalogo predefinito. Se non si è sicuri di averne bisogno, lo stack predefinito è quasi sempre la scelta iniziale giusta.

Q: Quanto costa una sessione Risolvi macchina? A: Le sessioni Risolvi macchina vengono fatturate rispetto ai crediti di rendering a un tasso al minuto mostrato nel pannello di controllo all'inizio della sessione. Il tasso cambia occasionalmente man mano che aggiorniamo l'infrastruttura VM sottostante; il pannello di controllo è sempre autorevole. Per una tipica sessione diagnostica di 30 minuti, ci si aspetti una piccola frazione del costo di un singolo job di rendering completo.

Q: Posso usare Simula percorso locale se il mio progetto è su macOS o Linux? A: L'ambiente di rendering del worker è Windows, quindi i percorsi assoluti sono simulati come percorsi Windows (forma D:\…). Se il progetto è creato su macOS o Linux con percorsi assoluti nella forma /Users/… o /home/…, la simulazione del percorso può ancora funzionare — la render farm crea un mount logico Windows che corrisponde alla stringa del percorso che la scena si aspetta — ma in pratica i progetti creati su mac/Linux di solito usano percorsi relativi e non hanno bisogno di questa utility.

Q: Il Template nodo di rendering aumenta il tempo di rendering? A: Il primo job inviato con un nuovo template può richiedere alcuni minuti in più per essere inviato mentre la render farm predispone worker corrispondenti. I job successivi sullo stesso template vengono inviati alla velocità dello stack predefinito perché i worker corrispondenti sono già attivi. Il tempo per job una volta che il template è attivo è lo stesso dello stack predefinito.

Q: Posso modificare un Template nodo di rendering mentre un job è in esecuzione? A: Sì, ma il job in esecuzione continua con la versione del template acquisita al momento dell'invio. La modifica influisce solo sugli invii futuri. Per i progetti che necessitano di un controllo delle versioni più rigoroso, clonare il template con un nuovo nome e aggiornare gli script di invio affinché puntino al nuovo clone anziché modificare il template esistente.

Q: La versione del mio DCC non è nel menu a discesa del Template nodo di rendering. Cosa fare? A: Contattare il supporto e condividere la versione necessaria. Per i DCC mainstream in genere ospitiamo le versioni correnti più alcune versioni precedenti; le versioni molto vecchie potrebbero essere state ritirate dallo stack attivo. Di solito riusciamo a integrare una versione precedente con qualche giorno di anticipo, o a guidare verso la versione supportata più vicina compatibile con la scena.

Q: Esiste una REST API pubblica per inviare job dalla mia pipeline? A: Non ancora. Una REST API pubblica è nella roadmap. Oggi il percorso raccomandato per l'invio programmatico è SuperRenders Client App (controllata da script) o il plugin di invio per DCC (controllato dall'ambiente di scripting nativo del DCC). Se il caso d'uso di automazione della pipeline è bloccato specificamente su una REST API pubblica, contattare il supporto — la roadmap è informata da requisiti reali di pipeline, e il feedback aiuta a stabilire le priorità.

Q: Posso eseguire una Risolvi macchina con un Template nodo di rendering? A: Sì — e questo è il pattern raccomandato quando si effettua il debug di un job con template. La sessione Risolvi macchina legge il Template nodo di rendering attivo al momento del provisioning e predispone la VM con lo stack software corrispondente. Si vede esattamente quello che vedrebbe il worker in produzione, incluse le versioni dei plugin con template.

---