Finalmente, dopo mesi di lavoro, test, debug e sistemazioni hanno Cycles come motore supportato. Otterranno la potenza di Cycles attraverso il rendering su CPU sul loro grid, con una serie di funzionalità supportate. Per essere in grado di uplodare le sessioni di Cycles dovete essere sicuri di avere l'ultima versione dell'uploader, che potete trovare nel Blender bf-extensions SVN. Posizionatelo nella vostra directory di Blender, in 2.62/scripts/addons/.
Mentre i cicli di rendering permette di rendere facilmente con le parti, assicuratevi di non fare compositing post elaborazione con l'editor del nodo, come per le vecchie restrizioni che esistono ancora.
Mentre il renderer Cycles consente di renderizzare facilmente le parti, assicuratevi di non eseguire il post-processo di composizione con il node editor, così come le vecchie restrizioni sono ancora presenti.
Finché Cycles lavorerà diversamente da Blender Internal possono dividere il carico di lavoro in due modi, prima di ricombinare tutto nel rendering finale. Con Blender Internal, nella migliore delle ipotesi potrebbero dividere il lavoro di un frame in sezioni più piccole di quel frame. Queste parti sarebbero poi cucite insieme nel frame finale. Alcune funzionalità del rendered di Blender Internal rendono molto difficile dividere in parti più piccole, soprattutto perché la loro rete non è costruita su una un'unica architettura di CPU e sistema operativo.
Oltre al taglio di un frame in parti fisiche, possono anche dividere il carico di lavoro di calcolo dei campioni. Diciamo che abbiano una sessione che vogliono renderizzarla con 100 campioni. Possono dividere il carico di lavoro su 4 workunit ognuna delle quali si tradurrà in un rendering di 25 campioni.
Facendo in modo che ogni parte sia renderizzata con un seme diverso possono assicurare che non ottengano 4 volte lo stesso risultato, ma di ottenere ciò che vogliono. Questi sottocampioni risultanti possono sommarli e mediarli in modo che alla fine siano stati renderizzati i 100 campioni del frame.
La cosa bella è che possono dividere il lavoro di calcolo in entrambi i modi ed allo stesso tempo. Così possono dividere il frame in 4 parti e ogni parte in 4 workunit. La cucitrice si prenderà cura di porre le parti risultanti nel fotogramma finale e mediarle come necessario.
Ciò significa che ora possono anche fare, per sempre, dei render ad alta definizione dei campioni, dal momento che il carico di lavoro può essere diviso su molti client. Per un campione di 10'000, potrebbero dividere il carico di lavoro in 100 workunits, ciascuna delle quali copre 100 campioni. Per renderer enormi, probabilmente li divideranno ulteriormente in parti, giusto per assicurarsi che le workunits non siano troppo lunghe.
Quando Cycles supporterà correttamente le GPU attraverso OpenCL, anche per le schede AMD / ATI, indagheranno con quanta facilità le potranno far rullare. Detto questo, è ovvio che il rendering CPU permetterà loro di eseguire le scene molto più grandi, in quanto la ram GPU è ancora un bene molto scarso.
Come nota finale, il supporto CPU è limitato al "set di funzionalità supportate", cosa da tenere a mente durante la preparazione e l'invio delle sessioni per il rendering al loro sito.