Vai al contenuto
Andrea Marchetto

Alcune considerazioni su V-Ray RT

Recommended Posts

Ciao a tutti, scrivo questo post in parte a carattere informativo, in parte perchè spero di costruire un dibattito che mi sta assillando da qualche giorno. RIngrazio chiunque voglia partecipare attivamente, dando il proprio contributo.

 

In sostanza qualche tempo fa mi sono trovato nella necessità di renderizzare delle scene di interni ed ho voluto mettere alla prova V-Ray RT in "production rendering mode".

 

A primo impatto, ho notato una discrepanza enorme nei valori di noise threshold tra VRay Adv e VRay RT. Dopo svariati tentativi, ricerche online infruttuose e qualche santo sceso dal paradiso ( pace all'anima loro ) ho deciso di fare un test per sottolineare le mie perplessità; qui sotto allego alcune immagini.

 

Le conclusioni dopo il test sono:

 

1. esiste una notevole disparità nel modo in cui i due motori considerano la soglia di noise ( immagine 1 e 2 )

2. per ottenere lo stesso risultato di VRay Adv, VRay RT impiega molto più tempo ( immagine 3 ) infatti la soglia di noise è impostata ad un valore che non credevo neanche si potesse utilizzare!!! e qui infatti si apre un capitolo a se ed un bel dilemma:

 

essenzialmente per VRay Adv utilizzo una vecchia CPU Intel i7 4790K ( 4 core, 8 thread, 4,20Ghz ), mentre per VRay RT utilizzo 1 x GTX1060 6GB + 1 x GTX1070 + 1 x GTX1080. 

 

Pertanto, a conti fatti una vecchia CPU risulta essere più performante di 3 GPU di ultima generazione.

 

3. per curiosità ho effettuato un test con FStorm e, se è pur vero che per ottenere un render paragonabile alla prima immagine, è pur vero che i tempi di rendering si equivalgono. Questo in parte va a smentire la tesi appena sopra. Quindi dove sta la verità? 

 

Certo appare evidente che in uno scontro diretto VRay RT vs FStorm, non ci sia proprio partita. Voi avete esperienza in merito o considerazioni da aggiungere al mio ragionamento?

 

Andrea

 

VRay_0.003.jpg

VRay_RT_0.003.jpg

VRay_RT_0.0001.jpg

FStorm_0.0004.jpg

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
Inviata (modificato)

Il caso vuole che io stessi leggendo in contemporanea le news su vRay next beta 2.. e l'RT CPU sembra verrà rimosso a favore dell'IPR, il cui risultato non è solo ipù veloce ma matcha al 100% i risultati del production renderer.. (solo su 3dsmax, tutti gli altri restano con cpu RT).

p.s.: Tral'altro, secondo le news dirette da uno degli sviluppatori con cui sto discutendo in questo momento, solo 3dsmax ha questo problema con l'RT CPU ed è il motivo per cui lo sostituiscono con l'IPR.


Modificato da Michele Faccoli

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

Ciao Michele, attenzione che io parlavo di RT GPU. Anche se devo dire che RT CPU soffre dello stesso problema ma, a parità di noise threshold, RT CPU sembra ottenere risultati migliori, almeno dai miei test. Sarei curioso anche io di leggere queste news!

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

So che non sarà utile a risolvere il problema, ma ho sempre considerato al momento valida la scelta di Corona o Arnold di non impelagarsi con le gpu, tra rendering ibridi e tutto il resto. 

Poi Magari in futuro ci saranno sviluppi per creare soluzioni prive di differenze nei risultati. 

 

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

Forse in prima istanza ho letto "velocemente" il post e non ho neanche pensato alle considerazioni che venivano fatte.. anche perché alcuni discorsi che magari do per assodati, per altri sono più oscuri.

E' impossibile ottenere gli stessi risultati tra GPU e CPU per tanti motivi: In primis, sono due motori di rendering diversi, Interamente; In secundis, CPU e GPU sfruttano quelle che sono le loro "potenzialità".. la scheda video va di forza bruta, la CPU è meno potente ma più "intelligente". Questo vuol dire che in GPU il calcolo viene effettuato in larga parte come progressive (qualcosa è adaptive, secondo le parole di Blagovest, Lead GPU Developer di chaos group), per la CPU si può andare di Adaptive puro e macinare difetti "più velocemente" in proporzione.

Ciò che rende il rendering GPU più conveniente rispetto a quello CPU è che ad un pc puoi attaccare 4-5-6-7.. a volte anche 11 schede video.. (Sebastian Michalski su youtube). Di processori ne attacchi due e poi t'attacchi tu. A livello di rapporto costo/prestazioni vince la GPU.

L'hybrid in questo è un "terzo caso" ed è GPU+CPU dove la CPU finge di essere una GPU.. e qua hai lo stesso identico risultato in produzione e in "rt" perché Sono la stessa cosa.. e la CPU è solo una spinta in più alle schede video.

Non credo sarà mai possibile ottenere lo stesso risultato usando due tecnologie diverse ma quello che fa vRay è tenere aperte tutte le porte.. ed invito a tenere d'occhio la 4.0 perché la mole di cambiamenti e update è impressionante.

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
Inviata (modificato)

Andrea, posso risponderti precisamente, e assai semplicemente, io.

 

V-Ray GPU è un motore di rendering diverso da V-Ray CPU.

Non lo dico come opinione personale: è la linea ufficiale di ChaosGroup, e determina in maniera consistente le scelte di sviluppo.

 

 

 

Alcune tecnologie sono indubbiamente condivise, alcune identicamente (ad esempio la Light Cache) o tradotte in maniera indistinguibile (per esempio alcuni materiali), altre invece sono per forza (intesa come caratteristiche dell'hardware e delle piattaforme di codice) molto diverse (o lo sono state sinora. poi mi spiego meglio in proposito.).

Non c'è, a mio ultimo controllo, un motore di rendering che sia production-ready, e funzioni dienticamente in versione per pura CPU e per GPU (ibrido o meno.): sulla carta, qualcuno ancora ci prova, ma in pratica, le differenze sono sostanziali, e sempre intorno a quei pezzi di tecnologia di difficile traduzione verso la GPU, che mi lascia sospettare nessuno abbia ancora trovato il sacro graal, al netto delle roboanti press release.

 

Nel tuo caso specifico, il sampler tra le due versioni e' diverso nel modo di valutare il rumore nell'immagine.

Per correggere, semplicemente diminuisci il valore di Noise Threshold in RT, senza preoccuparti di trovare una corrispondenza tra i due motori, che non esiste per scelta progettuale.

Nel senso che con un valore di N.T. più basso, RT è perfettamente in grado di convergere l'immagine a pulizia visuale completa, e quindi tant'è, valore più basso sia: tienilo a mente come valore valido per le tue scene.

Impostarlo a 0.0001 pero', non e' precisamente corretto: RT avra' raggiunto un valore di N.T. gia' al di sotto della visibilita' ben prima, e tutto il resto del tempo e' perso inutilmente.

Questo detto, riparliamone con l'ultima versione, la 3.60.04, che i ragazzi del team GPU non stan fermi un secondo (c'e' ragione particolare per l'affezione verso una versione vecchia di un anno?).

 

Stesso tipo di approccio vale per il resto del setup di una scena: noi consigliamo di scegliere anzitempo quale dei due motori usare, e poi di lavorare nei limiti che ciascuno impone.

Il messaggio è questo da ormai dieci anni, ma in qualche modo non riusciamo a farlo passare a dovere, e quindi creiamo aspettative inesatte negli utenti, che invariabilmente non possiamo soddisfare.

Capisco/capiamo perfettamente la confusione, non sei l'unico ad avere dubbii, e sappiamo anche perchè: è in fondo colpa nostra, ma tant'è, il latte è versato, almeno per la 3.x.

 

Con l'arrivo della versione 4 (O Next, che sia), la distinzione tra i due motori di render sarà più chiara, sia per denominazione che per UI, ma non per licenza, con entrambi sempre distribuiti assieme sotto licenza singola.

D'altro canto sarà ampliato l'accesso alle tecnologie già presenti in CPU e mancanti in GPU (Ad esempio il render di Volumi, etc.), e grazie alla separazione marcata tra i due motori, il team GPU sarà più libero di sviluppare ottimizzazioni che han senso solo in ambito GPU, senza costantemente dover "controllare gli specchietti" per guardare dove sta CPU.

Il tempo, e gli utenti, ci diranno se la scelta è stata quella giusta, o no.

 

Spero di averti risposto esaustivamente, ma in ogni caso leggo le risposte.

 

Lele


Modificato da ChaosLele

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

"A livello di rapporto costo/prestazioni vince la GPU."

 

mmm ne sei così sicuro? Hai messo in conto anche il consumo di energia?

Mettere in un PC 4 1080Ti e farle andare in full load consuma un fottio di corrente, per non parlare del rumore e calore prodotto.

Ora, bisognerebbe tenere in conto anche questo fattore. Mi spiego.

Mettiamo che tu hai un dual Xeon che produce un rendering in 60 minuti consumando1Kwh.

Ora, poniamo il caso, invece, che le tue 4 GPU hanno prodotto lo stesso risultato in 30 minuti. Pero controlla il loro consumo.

Magari hanno consumato 3 KWh. Inoltre produrranno molto più calore che dovrai dissipare (magari accendendo un condizionatore).

Inoltre fanno molto rumore ( a meno di non metterle a liquido)

Questi sono numeri presi a caso, ma è risaputo che le GPU consumano molto, ma molto di più.

 

 

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

La metrica e' tipicamente picojoule/op.

E' saggio avere i numeri reali alla mano, gia' che poi una volta che si parla di programmi complessi, la qualita' del codice entra in gioco in modo  preponderante.

 

A questo mi riferivo nel post sopra: GPU permette approcci da cui la CPU non beneficia affatto, e viceversa.

Esempio banale (e non necessariamente vero.): in GPU e' piu' efficente fare 4+4+4+4, in CPU 4x4.

Per far 16, chi ha usato meno picojoule?

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
Inviata (modificato)

picojoule/op? :P No no, non sono così "avanti"... io in ufficio utilizzo, spesso, un semplice wattometro per capire quanto consumano i vari nodi.

Comunque, non è raro vedere bollette di oltre 1.500 euro/mese per chi usa renderfam fatte da GPU.

Diciamo che le CPU sono più "tranquille" con i consumi.

Nel calcolo costo/prestazioni tra GPU e CPU, spesso si dimenticano anche i costi di gestione.

Anche se Juray (Corona forum) ha detto che il suo ultimo i9 18 core delighted (OC +-5 GHz) consuma 700 Watt :o!

Cioè, quasi tre volte il mio sistema. Vero anche che "viaggia" 6-7 volte più veloce di un i7 970 (00:40min vs 4:30min)

Quindi, a parità di corrente consumata, l'i9 è più efficiente ( e ci credo... stiamo parlando di 2011 vs 2018)

 

 

 


Modificato da cecofuli

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

Un wattmetro purtroppo e' preda del problema di cui parlavo: la dipendenza dalla qualita' del software.

Non puoi fare un confronto tra CPU e GPU, manco se calcoli la "stessa" immagine: le matematiche sono diverse, e di efficienza sconosciuta, ambo le parti.

Metti che la versione che stai provando, in altre parole, ha un problema nella convergenza di uno shader particolare, mentre la CPU no, ed eccoci, hai completamente falsato la misura.

 

Se fosse solo il caso di mettere un kill-a-watt e misurare, credi le GPU potrebbero mai essere cosi' diffuse per il calcolo generico? :)  

Nota che Google (ed altri) hanno gia' in beta, o disponibili, macchine da cloud con GPU a bordo, ed NVidia sta pompando schede video da 10k e piu' sul mercato come non ci fosse un domani.

L'hype si ferma agli utenti individuali, quando c'e' da investire un miliardo di dollari qualcuno i numeri li ha fatti precisamente.

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
Inviata (modificato)

Sarà, ragazzi ma a me dopo l'esperienza di iray e gpu che doveva essere il miracolo ho messo un po il freno ....

visto poi che in italia le bollette di corrente non continuano a scendere ma a salire inesorabili.

Poi ci mancherebbe a qualcuno faranno anche comodo per accelerare i tempi, sono io il primo a dirlo che mi son divertito molto a fare il render in gpu.

Magari per Vray sarà diverso e incontrerà più consensi e me lo auguro. 

Nvidia non saprei che dire... prima era amore a prima vista, ora li vedo come pericolo dietro l'angolo.... se questo gpu era cosi importante, come mai non sono riusciti a imporre i loro motori di render ?  Forse hanno considerato che era più economico vendere gpu a chi era più avanti di loro. 

Iray ad esempio, in substance painter, poteva essere il ponte con Iray in 3ds max, per ottenere un render praticamente identico tra i due programmi e fare la felicità di molti. 

Eppure anche li niente. C'è qualche cosa che non mi torna .... se non la convinzione che è più facile far fare il lavoro di sviluppo a vray piuttosto che octane, per il render gpu, etc etc. 

Scusate la divagazione .. ma sono considerazioni che mi si sono presentate nel panorama variegato dei motori di render.

Magari tra qualche anno sarà tutto più chiaro e ben delineato... me lo auguro.

 

 

 

 

 

 


Modificato da Marcello Pattarin

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

CNon morto, trasfromato.

https://developer.nvidia.com/optix

 

Quel che non ti torna e' quel di cui parlo qui sopra: ci sono differenze *sostanziali* nell'approccio logico-matematico tra CPU e GPU.

Quindi anche un substance painter (che la GPU la usa per una preview a video *assai* semplificata, non per la generazione delle texture, su CPU) quando si cerca il 100% di corrispondenza (nel senso di sperimentazione quantitativa) diventa un passo troppo lungo, anche per NVidia (come per noi: substance e' supportato solo sotto cpu.).

 

Tutti, chi pirma, chi poi (e qualcuno persino ora...), sono stati colpevoli di sovra-promettere, per poi in effetti sotto-consegnare: Noi (se nel 2005...), NVidia, Cebas, Next Limit.

Gli approcci saggi sono in realta' solo due, a fronte della delusione degli utenti: ammettere le differenze sostanziali, e lavorare al meglio di ciascuna delle due tecnologie (Vedi V-Ray, Thea, Arion), o mollarne interamente una in favore dell'altra (fStorm, Optix).

 

Non tutti i ptoblemi hanno soluzione ottimale, e spesso s'ha da scegliere il meno peggio, e di quello far tesoro.

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

Ragazzi che dire, ho scatenato un buon numero di reazioni e questo mi fa decisamente piacere! Evidentemente c'è bisogno di fare chiarezza ad alcuni di noi.

 

@ChaosLele non mi è chiaro quando scrivi che non ha senso impostare una NT così bassa. Ho perso due giorni a cercare soluzioni per togliere via quel noise fastidioso ma non ci sono riuscito in nessun modo. Si, chiaramente a questo punto ha poco senso paragonare due semplici valori numerici, su questo sono d'accordo. Ma allora le possibilità sono due: o io non so usare V-Ray RT oppure non riesce ad ottenere gli stessi risultati della versione CPU ( cosa che prontamente escludo visto che hai espressamente indicato che RT è in grado di convergere ad una soluzione finale più che soddisfacente e del resto mi stupirebbe il contrario ). Resta quindi una sola possibilità...sono ignorante in materia di RT :D

 

Interessante pure il discorso sul consumo totale di un sistema multi GPU rispetto al classico CPU, a cui onestamente io non ho mai pensato.

 

A tal proposito, visto il numero di variabili in gioco, sta ad ognuno farsi i propri conti e capire dove conviene indirizzarsi. Sarà già stato detto un milione di volte...i pro ed i contro ci sono sia in CPU che GPU quindi a maggior ragione, libertà di scelta per ognuno.

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
Inviata (modificato)
Quote

non mi è chiaro quando scrivi che non ha senso impostare una NT così bassa. Ho perso due giorni a cercare soluzioni per togliere via quel noise fastidioso ma non ci sono riuscito in nessun modo.

 

Ti faccio vedere, che si capisce meglio:

In allegato, un render per scelta semplicissimo (una domelight, con un render a 32bit FP di un preetham sun e sky, con disco del sole visibile, come texture, su shader puramente diffuso.).

La semplicita' e' volta all'eliminazione di fattori complicanti (almeno inizialmente, e' saggio. No, e' Metodo Scientifico, mica ho scoperto nulla io.).

Cpu e GPU sono abbastanza simili, e anzi direi che le differenze di tempo di calcolo sono ben corrrelabili con le differenze di costo (al tempo in cui acquistai, un anno e mezzo fa) tra i due oggetti.

La CPU, un i7-6800k che lascio girare a stock, e senza turbo, a 3.4ghz, costo' circa 550 Euro, mentre la GTX 1080, anch'essa lasciata rigorosamente a stock, costo' circa 750Euro.

Puoi considerari entrambi con efficienza termica illimitata (ie. ne' cpu ne' gpu fanno del throttling dovuto a alte temperature, non importa quanto a lungo le tenga sotto carico completo.).

 

Nell'allegato, sulla colonna di sinistra si vedono i due risultati (per comodita' ho scritto i dati nel nome di file: periferica_tempo_noiseThreshold), mentre nella colonna di destra si puo' osservare l'analisi della quantita' di rumore in Nuke.

Nota che nello specifico *non c'e' corrispondenza diretta* con i due valori, quello impostato in V-Ray (GPu o CPU) e quello letto in Nuke: il computo e' diverso.

In nuke, calcolo il rumore assoluto, in V-Ray, e' percentuale.

Dovresti dividere i valori di noise rilevati in nuke per i valori Max corrispondenti, ad esempio per la R del render con GPU, 0.030114/3.1046, che fa 0.00969, o appena meno di 0.01, come impostato nel render.

In ogni caso, la matematica rimane consistente tra le due immagini, tanto che lo strumento lo usiamo quotidianamente sia in RnD che in QA.

 

Al netto dei valori di R, G, e B (comunque in linea tra loro, proporzionalmente), il quarto, V, e' quello interessante.

Nota come sia CPU che GPU abbiano ottenuto virtualmente lo stesso livello di rumore, pur avendo io impostato il valore del N.T. per il render su CPU una volta e mezzo piu' alto (0.015 anziche' 0.01).

Nota altresi' come il render su GPU abbia completato il lavoro con certo anticipo rispetto alla CPU, di nuovo sufficientemente in linea con il resto dei risultati di questa tipologia.

 

Attenzione: io non dico che non vi sia differenza tra i due motori, al contrario!

C'e', ci sara' sempre: bisogna solo farci la mano.

Ma da li', a chiedere a un software di effettuare CENTO volte piu' calcoli (per una soglia di rumore dieci volte piu' bassa), e chiamare la comparazione "valida" e' per me uno zic al limite.

Bastava abbassarla di un pochino, ecco tutto.

Non so pero' dirti cosa ci fosse di diverso nelle tue impostazioni di render, nel setup di materiali e luci, e cosi' via (hint: la scena di fStorm ha la luce a sinistra decisamente meno intensa dei due render di V-Ray.): ciascuno dei dettagli di cui sopra puo' influire sul risultato, sia per rumore che per il suo inverso, il tempo di resa.

 

Se invece hai usato una versione craccata (ma la versione che vedo nei render non mi risulta tale...), il banco salta: i rallentamenti incomprensibili e casuali sono parte e parcella di quelle versioni, qualunque sia il crack (non ne esiste uno fatto a modo. E paradossalmente ci fa orribile pubblicita'.).

Molto meglio, nel caso, la demo (le nuove sono versioni full, con licenza a tempo di 30gg, estendibile.), specie per valutazioni quantitative.

Se invece sei correttamente licenziato (o no, a me fa uguale. :) ), che aspetti a passare alla 3.60.04, o meglio ancora a fare un giro su NEXT?

 

GPU_85s_0_HR_01.exr_CS.jpg.9ffcd6aa57a6245885517c2743a9ba2b.jpg


Modificato da ChaosLele

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
Inviata (modificato)
3 ore fa, ChaosLele ha scritto:

CNon morto, trasfromato.

https://developer.nvidia.com/optix

 

Quel che non ti torna e' quel di cui parlo qui sopra: ci sono differenze *sostanziali* nell'approccio logico-matematico tra CPU e GPU.

Quindi anche un substance painter (che la GPU la usa per una preview a video *assai* semplificata, non per la generazione delle texture, su CPU) quando si cerca il 100% di corrispondenza (nel senso di sperimentazione quantitativa) diventa un passo troppo lungo, anche per NVidia (come per noi: substance e' supportato solo sotto cpu.).

 

Si è vero, però a quelli di nvidia cosa costava fare degli export per il render. Io intendevo il render di iray vero e proprio in substance painter, che non sarà tanto diverso dal render di iray di 3ds max o altro.. certo te lo puoi fare tu impostando le esportazioni delle texture .... i preset per vray arnold etc ci sono.... quello per iray mi sembra a memoria che non lo hanno fatto.. magari mi sbaglio ma non mi sembra di averlo visto.... comunque certo, cpu e gpu sono due logiche diverse, di questo me ne ero accorto vedendo i risultati in giro per la rete. 


Modificato da Marcello Pattarin

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

Due cose, @ChaosLele: il rendering CPU sopra che sampling usava? Progressive? Per quella che è stata la mia esperienza ad oggi con 2x2630v4 xeon e 2x1070 (che dovrebbero più o meno equivalersi in quanto a potenza di calcolo parlando molto grossolanamente) è che la CPU permettendo il rendering Adaptive risulti molto pù rapida a macinare scene, il che permette di renderle anche più pulite. Poi, venendo io da MODO e usando vRay for MODO (nelle nightlies siamo praticamente alla 3.6) sono abituato ad un noise 100 volte più alto, quindi non mi pesa troppo la differenza.. però la noto.

La seconda cosa è, mi pare che Vlado abbia detto che chiunque compri vRay da DOPO il lancio della beta della 4.0 (avvenuto ormai parrecchie settimane fa) non dovrà pagare l'aggiornamento a 4.0. Per tutti gli altri ci sarà da pagare l'update (e per chi l'ha comprato 4 anni fa, immagino non sia così grave.. sperando costi meno della licenza intera altrimenti son stato uno scemo a comprarla l'anno scorso xD).

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
Inviata (modificato)
5 hours ago, Michele Faccoli said:

Due cose, @ChaosLele: il rendering CPU sopra che sampling usava? Progressive? Per quella che è stata la mia esperienza ad oggi con 2x2630v4 xeon e 2x1070 (che dovrebbero più o meno equivalersi in quanto a potenza di calcolo parlando molto grossolanamente) è che la CPU permettendo il rendering Adaptive risulti molto pù rapida a macinare scene, il che permette di renderle anche più pulite. Poi, venendo io da MODO e usando vRay for MODO (nelle nightlies siamo praticamente alla 3.6) sono abituato ad un noise 100 volte più alto, quindi non mi pesa troppo la differenza.. però la noto.

La seconda cosa è, mi pare che Vlado abbia detto che chiunque compri vRay da DOPO il lancio della beta della 4.0 (avvenuto ormai parrecchie settimane fa) non dovrà pagare l'aggiornamento a 4.0. Per tutti gli altri ci sarà da pagare l'update (e per chi l'ha comprato 4 anni fa, immagino non sia così grave.. sperando costi meno della licenza intera altrimenti son stato uno scemo a comprarla l'anno scorso xD).

 

Entrambi i motori sono adattivi nel sampling, di default (ma e' un comportamento che si puo' disattivare), tanto che a entrambi ho chiesto di calcolare finche' non avessero raggiunto un dato livello di rumore (noterai che Arnold, ad esempio, non ha un noise threshold. non adattivo.).

Nel nostro caso specifico, GPU ha cambiato registro decisamente solo qualche anno fa, dopo l'arrivo dei componenti dell'odierno GPU team (non e' che si trovino i Messi e i Ronaldo al supermercato...).

La versione originale era un tentativo del 2005 di sfruttare quella che era una tecnologia all'apparenza promettente: non la GPU, ma l'Activeshade (Se non ti sei piantato un palmo di mano in faccia a questa, sei un eroe.).

Il goal era di avere della progressivita' nel calcolo mentre l'utente lavorava, e fine li'.

Prima della 3.3, non consiglierei di provarlo nemmeno (ma la 3.3 e' di quasi tre anni fa.), ma da quella in poi inizio' un lavoro *enorme* di refactoring e i risultati si son ben visti (c'e' sempre modo di rompere una cosa: basta provarci abbastanza. C'e' poi modo di vederne l'utilita', pur entro limiti precisi, e farne buon uso, vedi Dabarti.).

 

E' a questo gruppo di ragazzi che dobbiamo le Adaptive Lights, l'Adaptive Dome, e una serie di intuizioni fulminanti che vedranno la luce con Next.

A giudicare dal responso sui nostri Forum, chi ha provato NEXT s'e' bell'e accorto dei cambiamenti lato GPU.

 

EDIT: Ho avuto conferma di quanto sospettavo: ogni utente corrente di V-Ray beneficiera' di un percorso (piu' economico) di upgrade.

 


Modificato da ChaosLele

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

@ChaosLele ti ringrazio infinitamente per il tempo che stai dedicando a questo argomento!

 

Il pc dal quale ho fatto tutti i test non è il mio quindi non posso far installare la 3.6 se non vogliono..vai a capirli te..io ci ho rinunciato!

 

Devo dire che le mie perplessità sono nate principalmente osservando il reflection pass di una scena su cui ho lavorato. Dal momento che RT non permette di impostare un valore di sample per materiali, riflessioni, luci etc l'unico modo per ridurre il noise dalla reflection è stato quello di sperimentare con valori di NT sempre minori.

Non ottenendo comunque una pulizia accettabile ( a mio parere ma se vuoi ti posto qualche crop e mi dai un tuo parere ) ho estremizzato i valori di NT per vedere se effettivamente RT fosse in grado di "pulire" la scena in modo soddisfacente.

 

Il comportamento che ho osservato in sostanza è che il pass della diffusa è praticamente perfetto, pure lo specular va bene. Il noise sembra concentrarsi esclusivamente sulla componente riflessiva ( ma stiamo parlando di un VRay Mat semplicissimo eh ).

 

Per i test tra CPU e GPU che ho postato qui, ho lasciato tutto invariato, beh altrimenti il test non avrebbe avuto molto senso no? :D

Invece per quanto riguarda FStorm ho semplicemente convertito la scena con il tool proprietario. Le due omni le ho aggiunte io e, per carità, si ci sono delle differenze sicuramente. Lascerei allora da parte questo ultimo test che effettivamente potrebbe risultare fuorviante.

 

Comunque...se effettivamente con la versione 4 si riesce ad utilizzare il denoise su tutti i pass, allora avete fatto bingo!!

 

 

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

Grazie a te per la pazienza, e l'apertura mentale nel leggermi senza traccia di polemica.

 

Indubbiamente nel mio test di cui sopra ho omesso tutto lo shading complesso, appositamente per illustrare il solo punto della soglia di rumore.

Quanto vado dicendo sulle differenze di motore tra le due versioni diventa ancora piu' apparente quando, come dici bene tu, uno incomincia ad aggiungere BRDFs (cioe', riflessioni/speculari), ed effetti piu' complessi (BSSRDF, layers, etc. etc.).

 

Vi e' poi una differenza metodologica tra GPU e CPU: CPU ha il "min. shading rate", ossia quanti raggi secondari tracciare per ciascun raggio primario (o shading vs. AA, effects vs. camera, come credi.), e il default e' di 6 (quindi per ogni passata, 6+1 raggio tracciati), mentre GPU ha il rapporto fisso ad 1:1, quindi il bilanciamento tra AA e shading sara' sempre differente (a meno di non settare CPU con un msr di 1, *caldamente sconsigliato*).

Non e' (ancora? mai?) pratico in termini di performance per GPU avere un MSR diverso da 1, ed al contrario per CPU impostare l'MSR a 1 ammazza le performance.

 

Entrambi i motori sono pero' identici nel chiedere all'utente di concentrarsi sul contenuto, anziche' le impostazioni di materiali e luci.

 

Al netto delle differenze procedurali, e di bug indesiderati (magari nella versione che usi c'era un problema sullo shading delle riflessioni, chissa'. andrebbe ben indagato, ma e' versione vecchia, che rende il tutto piu' complesso.), entrambi sono *interamente* governabili, e garantiti come quasi-ottimali nel rapporto costo/prestazioni, a partire dai default, cambiando esclusivamente noise threshold e min e max subdivs.

 

Dalla versione 3.3, tornare a lavorare impostando luci e materiali individualmente e' ufficialmente sconsigliato, alla luce di benchmark estensivo che io e Vlado abbiamo effettuato su scene d'ogni tipologia, ed i cui risultati abbiamo condiviso sui forum.

 

Ci saranno *sempre* casi ove una azione manuale, da parte di utente esperto, possa portare a risultati marginalmente migliori in termini di rapporto costi/prestazioni.

Supposto anche che l'utente in questione, esperto e quindi infallibile per definizione, sia un razzo, abbia una pipeline che gli permetta di effettuare cambiamenti di massa intelligentemente (300 materiali? 1200 luci? auguri con i metodi tradizionali.), e quindi ci metta "poco", quel tempo sara' invariabilmente ben di piu' che non se avesse lasciato tutto ai default, e premuto "render", per quel dato livello di rumore nell'immagine di output (misurato, non visuale.).

 

Oltre a tutto cio', abbiamo piani di migliorare ancora questo approccio, sia per tecnologie sottese, che per qualita' e semplicita' dell'interfaccia utente, mentre l'approccio ad impostazioni individuali verra' progressivamente dimenticato (e' la nostra speranza, almeno.), perche' obsoleto, e di difficile manutenzione per utenti (abbiamo, ahinoi, le statistiche da Support.) e per quantita' di codice ancillare.

 

Rimango a disposizione,

 

L.

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

Crea un account o accedi per commentare

Devi essere un utente per poter lasciare un commento

Crea un account

Registrati per un nuovo account nella nostra comunità. è facile!

Registra un nuovo account

Accedi

Hai già un account? Accedi qui.

Accedi ora

  • Navigazione recente   0 utenti

    Non ci sono utenti registrati da visualizzare in questa pagina.

×