Test di velocità

[Fire]

Ciao Fire,
mi conforta sapare che con l'attuale 1.6.1 non sia stato ancora portato avanti un test simile. Avevo addirittura paura di arrivare in ritardo e inserirlo con la nuova release di Maxwell già in giro.
Ovviamente se pensi che possa essere apprezzato anche dalla comunità "maxwellrender dot it", ben venga!...

Per apprezzato lo sarà senz'altro, ci mancherebbe. Piuttosto per la verità, ultimamente sono "più di quà che di là" , per cui non vorrei mi fosse sfuggito, ma non credo, ad ogni modo vedrò di linkare i tuoi test per aver maggior riscontro.

...Di tutti questi test che ho fatto, la cosa che mi è apparsa più rilevante è la possibilità di poter calcolare il tempo che impiegherà il rendering ad arrivare ad un certo S.L. (ma come giustamente dici, Maxwell è più imprevedibile di quanto si pensi)...

Senti Lab... non vorrei darti una delusione, anche perchè tu non crederai quanto io apprezzi i tuoi sforzi in questo senso, (che comunque rimane valido da un punto di vista didattico), ma a questo punto credo che sia anche giusto metterti a conoscenza di una paio di cose. Già esisteva un programmino, "Sampling calculator", quando ancora il SW non ti diceva quanto sarebbe occorso a raggiungere un determinato campione, ora (diciamo anche già da un bel pò), ...ci pensa MW nel parametro "Time Left"! Vi spiego come. Nell' MXCL avete sulla barra di stato delle info, normalmente quando impostate tempo di rendering e campioni da raggiungere avete di fatto impostato due condizioni da raggiungere. Ora se anche solo una di queste viene soddisfatta, il rendering si considera concluso. Bene, provate ad assegnare ad una scena un valore come tempo disponibile estremamente alto (mi raccomando, in minuti) e un valore di Sampling Level sicuramente più basso, nel senso che se per un immagine assegno 60h di rendering e imposto 10SL, a meno di non renderizzare l'impossibile, certamente il calcolo raggiungerà di certo i campioni richiesti nel tempo utile (con un HW anche minimale). In questo modo nella barra di stato potrete leggere anticipatamente la stima precisa del tempo necessario a raggiungere quel dato campione. Così, insieme al parametro "Benchmark", in questo modo, saprete sempre anticipatamente se state procedendo bene o meno. Il discorso è banale credo, ma non so se son riuscito a spiegarmi.

...Per poligoni:
come vedete la curva dei tempi è esponenziale e tende all'infinito, quindi meglio cercare di ottenere una buona immagine senza dover per forza raggiungere il S.L. 23 (per la precisione ci sono arrivato solo una volta fin li).
Scrivendo che il settagio delle luci è essenziale intendi dire che bisogna illuminare bene la scena? diffondere le luci casomai con dei pannelli Emitter?...

Certo non all'infinito ma sicuramente ad un tempo molto alto. Non so se ricordi le immagini del museo o quelle altre postate nello stesso topic, quando non credevi che avessero quel SL senza post-produzione, è proprio a quello che mi rierisco. Il livello di campionamento non è un valore di qualità assoluto, ma relativo, non mi stancherò mai di ripeterlo. Non necessariamente occorre raggiungere i 20SL per avere un'immagine "pulita", ...la luce in questo caso è tutto. Si, quando dico che "il settagio delle luci è essenziale" intendo proprio dire che bisogna illuminare bene la scena, è solo su quello che si basa la fotografia ed è solo su quello che si basa MW, se non vi riesce o non vi soddisfa una ripresa, con buona probabilità avrete cannato qualcosa nell'illuminazione, per cui occhio anche ai settaggi di camera, oltre che al set di luci.

...Per luce:
Sky Dome, Physical Sky + Sun, None + Emitter
Anch'io avrei detto che il Cielo Fisico fosse quello che aumentava maggiormente i tempi di resa, invece l'aggiunta di un solo poligono Emitter mi ha fatto cambiare idea; ma se hai dei dubbi, posso portare avanti qualche altro test di conferma...
Ehm, non ho capito cosa sia l'HDR via MXI. Io ho fattto solo una prova con una immagine HDRI e ho notato che i tempi coincidevano con lo Sky Dome, quindi ho tralasciato il grafico....

Bhè si, qualche altro test, magari con qualche scena anche un tantino più complessa si può sicuramente fare. Ad ogni modo mi sembra strano che con un'immagine HDR (o MXI) tu abbia gli stessi tempi, posso dirti per certo che qualcosa non quadra, (un sospetto ...non è che hai convertito una LDR in HDR?)

..Con multilight:
Anch'io avrei detto con certezza che l'attivazione avrebbe influenzato significativamente i tempi di rendering. Forse, come tu dici, è colpa della scena molto semplice...
La mia riflessione invece è stata differente (ipotizzo). Visto che impiego lo stesso tempo a renderizzare una scena con un solo Emitter ed una con 22, e da quest'ultima posso ricavare un'infinità di soluzioni differenti combinando i miei ipotetici 22 livelli; mi viene da pensare che la qualità del singolo livello sia molto inferiore alla qaulità dell'immagine renderizzata con un solo Emitter. O meglio, la somma di tutte e 22 i livelli Emitter ripropone la stessa qualità del rendering fatto con un solo Emitter; quindi, in teoria, se spengo tutte le luci e ne mantengo solo una attiva, questa avrà una qualità 1/22 rispetto alla versione fatta senza MultiLight....

Posso confermarti che la qualità assolutamente non varia da prove fatte in passato, come per i poligoni anche la quantità delle fonti di luce influiscono ma non molto, questo però dipende molto dalla scena, ...sarebbe bello se fosse sempre così. Ad ogni modo il ML rimane un'opzione estremamente utilizzabile nella stragrande maggioranza dei lavori!

..Con displacement:
la cosa che più mi è dispiaciuta è stato nel vedere i tempi crescere drasticamente; la mia speranza era quella di apprezzare un calcolo maggiore solo in fase iniziale (per calcolare le micro suddivisioni).
A rigor di logica, al momento, conviene renderizzare un oggetto con milioni di poligoni piuttosto ch uno semplice con applicato il displacement.....

Come detto il Microdisplacement non è molto ottimizzato, e in NL lo sanno, ...ma essendo megalomani (), non potevano accontentarsi d'un normalissimo displacement, per cui loro sono comunque convinti d'aver intrapreso la "strada giusta", anche se questo vorrà dire avere bisogno ancora di molte relise "d'affinamento". Per cui nel frattempo, se avete bisogno di un banale displacement, applicatelo in LW e poi passate la geometria a MW già "deformata".

..Con cloni e istanze:
sapresti spiegarmi come mai non sono riuscito a lanciare il rendering con 119 cloni, ma con 119 istanze si?
Comunque, il concetto di istanze in un software dove non conta il peso poligonale è veramente molto strano. Non trovi?....

Probabilmente m'è sfuggito qualcosa e non ho compreso esattamente ciò che intendi, ...ma ovviamente con le Istanze ti parte perchè il sistema alloca molta meno memoria.

..Immagini ribaltate:
confermi il fatto che il formato di default dalla versione 1.6 è il BMP?
il problema del "cappottamento" lo trovo solo con ACDsee, potrebbe essere un discorso collegato ai metafile creati con l'immagine?....

Guarda, se apri le "Options" di MW nella plugin, nel requester vuoto noterai che di default a differenza del passato ora c'è sia per l'immagine che per l' MXI una stringa di default che si chiama appunto "default.tga" e "default.mxi". Poi anche io utilizzo ACDsee, ma in versione 3.1 ti confermo che a me non ribalta le immagini.

Comunque hai un pò anticipato molti argomenti che ho trattato nell'articolo che sarà pubblicato nel prox numero (02) del Maxwell Magazine, che non dovrebbe tardare ancora molto.

Fabio.

[Lab2]

Ciao Fire,
grazie dell'attenzione.

Rispondo in breve ai tuoi quesiti poi mi ributto sul lavoro.

- Linka pure!
- Il discorso di impostare un S.L. limite o un tenmpo limite mi è chiaro; anche se tendo a inserire valori estremi per decidere manualmente quando fermare. Ed ora posso calcolarmi le tempistiche dei vari passaggi.
Non sapevo esistesse una programmino che calcolasse le tempistiche; interessante.
- In poche parole, bisogna conoscere la fotografia! Qualche link utile...
- Riproverò il test con l'HDR! non so cosa sia una LDR.
- Per studiare la scena, parto sempre con molte luci in MultiLight. Poi Mantengo solo le principali. Comunque, rimane una delle funzioni più potenti del software, a mio parere.
- Il Displacement è molto peso e andrebbe evitato, ma per fare un'immagine come quella che ho allegato (la mappa del mondo applicata come texture di displacement), in LW non saprei proprio da dove partire.
- Quindi il senso delle istanze di Maxwell sta tutto nell'alleggerire la memoria allocata.
- Non parlavo dell'immagine di Default el'MXI che vengono salvati automaticamente (una manna dal cielo ), ma piuttosto del salvataggio delle immagini da Maxwell Render una volta che si è stoppato il rendering. Facendo Save Image, di default l'immagine viene salvata in BMP. Prova.

[Fire]

- Il discorso di impostare un S.L. limite o un tenmpo limite mi è chiaro; anche se tendo a inserire valori estremi per decidere manualmente quando fermare. Ed ora posso calcolarmi le tempistiche dei vari passaggi.
Non sapevo esistesse una programmino che calcolasse le tempistiche; interessante.

Lab, il programmino a cui mi riferivo, (MXC - Maxwell Render Calculator) , ormai non serve più, ...anch'io tendo a inserire valori "overdose" per lo stesso motivo, ...ma se comunque voglio sapere quanto ci metterà la mia scena a raggiungere i 25SL, inserisco un bel 9600 (per il tempo) ed in genere ho il risultato che voglio in "Time Left"! ...Non serve calcolare le tempistiche!


- Di link utili in fotografia è piena la rete, ti passo i primi che mi capitano,anche se forse già li conoscete:

Calcolatore per il DoF: http://www.dofmaster.com/dofjs.html
Calcolatore per l'esposizione: http://www.robert-barrett.com/photo/...alculator.html
Concetti base (solo i primi sono gratis): http://www.abc-fotografia.com/corba/index.htm
Corso base Canon per chi inizia: http://web.canon.jp/imaging/enjoydslr/index.html
Corso base di Fotografia Digitale Nikon1: http://www.nital.it/corso_foto_digitale/index.php
Corso base di Fotografia Digitale Nikon2: http://www.nital.it/corso_foto/index.php
Corso gratuito di Fotografia Digitale: http://www.3megapixel.it/introduzione.html

- Le LDR sono le immagini "normali", a volte per poter utilizzare delle immagini nell'enviroment di MW, si convertono immagini normali (o LDR) in MXI (quindi HDR). Mentre per tutti gli altri canali il discorso tutto sommato è fattibile, lo stesso non si può dire quando la mappa dev'essere utilizzata per illuminare, pur essendo stata convertita nel formato "giusto", l'immagine è priva naturalmente delle informazioni sulla radianza che sono invece presenti nelle HDR. Tutto quà, ...era solo un sospetto...

- Concordo sul ML

- Guarda ci credo, figurati, è solo che quando ho salvato qualche immagine da MXCL, ho sempre specificato il formato, ...per cui non me ne son accorto...

[desegno]

che fantastici link!!!
alcuni li conoscevo altri assolutamente no!!!
thank's

[davhub]

Ciao Ragazzi, al solito fire e Lab2 ci mettono del loro.

La mia esperienza (vedi cavallo ed il tempio distrutto) dice che il multilight influenza poco i tempi. influisce molto il microdisplace. mi dice anche che il rumore aumenta più sono puntinati e poligonati gli emitters.
(come è ovvio che sia). aumentando il rumore ho bisogno di più tempo per raggiungere gli SL idonei alla pulizia.

Certo che il discorso su 1/22° di Lab2 non regge... il multilight io l'ho quasi semrpe attivo apporta per avere l'effetto luci dove e come voglio. anche con una sola luce la qualità non ne risente. io credo che sia una "magia" algoritmica del motore HDR interno. tanto lui CALCOLA tutte le soluzioni possibili sfruttando la virgola mobile, no? quindi è un calcolo già pesante di suo e no ncredo che le relazioni siano di semplice somma di tempi e complessità... ma qui si esula dalla mia competenza di programmatore neofita.

@Lab2.. le istanze servono apputno a questo... il tema del contest multiply va a fagiolo.. c'è anche un post architetturtale di NIco ( ) che ne parla . i files 3D sono ELENCHI formattati di testo.
(li avete mai aperti con il notepad?)
le istanze sono di questo genere:

[nome oggetto]
elenco con posizione rotazione, scala pivot
e poi tutta la composizione poligonale, i ltexturing ecc.

quindi... chessò 200 riche fitte di terne cartesiane.

i cloni non sono altro che un copia/incolla di TUTTO il precedente.
le istanze, invece non sono altro che:

[Istanza nome oggetto_xxx]
posizione rotazione, scala pivot

e niente altro... più è complesso l'oggetto maggiore la potenzialità delle istanze, non trovi?

9 valori ed intestazione contro.. migliaia di descrittori...

Davhub

[Fire]

... io credo che sia una "magia" algoritmica del motore HDR interno. tanto lui CALCOLA tutte le soluzioni possibili sfruttando la virgola mobile, no? quindi è un calcolo già pesante di suo e no ncredo che le relazioni siano di semplice somma di tempi e complessità... ma qui si esula dalla mia competenza di programmatore neofita....

Non sei tanto lontano dalla verità, anzi... In effetti, la maggior parte delle "magie" permesse da MW, sono permesse dal sistema ad alta radianza su cui è basato, nella fattispecie, ciò che maxwell sfrutta sono i così detti "Operatori HDR", ...se volete sapere di cosa parlo, scaricatevi il Maxwell Magazine n° 01 e leggetevi il mio articolo sull' HDRI in Maxwell! (così mettiamo a frutto le fatiche trascorse ). Ovviamente non basta basare l'engine su un sistema HDR per ottenere automaticamente le features in più di cui è dotato l'engine di NL, ma occorre che gli stessi algoritmi da cui è costituito siano in "simbiosi" con il sistema. Nel prossimo (spero imminente) numero del Magazine, ci sarà un'articolo (sempre del sottoscritto) che chiarisce un pò di cose al riguardo, pensato sopratutto per chi si accosta per la prima volta al programma (ma non solo).

Stay tuned.

P.S.
...come anticipato, la latenza del sistema ML è minima, è vero, ma è anche vero che come per la maggior parte delle cose in MW, non è un valore assoluto, bensì relativo, in questo caso relativo alla "complessità della scena" sia sotto il profilo luminoso che ottico-geometrico. In ogni caso comunque parliamo di differenze piuttosto trascurabili per la maggior parte dei casi.

[Lab2]

Ma che bello...
quante considerazioni interessanti!

[Lab2]

L'altra sera ho fatto una spiacevole scoperta.
L'attivazione del MotionBlur mi fa impennare i tempi di calcolo.

Di seguito le tempistiche in secondi:
con___MB 67 164 303 502 794 1226 1870 2832 4288 6520 9942
senza_MB 15 032 054 083 122 0179 0261 0376 0544 0792 1165

Come potete vedere c'è un abisso tra i due.
Sono io che sbaglio qualcosa oppure c'è ancora molta strada verso l'ottimizzazione?

[Fire]

Scusa Lab, ma non ben colto il senso della numerazione dei tempi in secondi, ...sono più test?

Riguardo il MB in MW, la cosa che bisogna tener presente è che non si tratta di un'effetto in post produzione come usano fare la maggior parte degli engine, ma di un sistema di calcolo integrato nell'algoritmo principale che permette di riprodurre il comportamento così come avviene nelle fotocamere, per cui calcolerà in MB anche eventuali effetti relativi a tutti i componenti "fisici" della scena, come le caustiche etc..

Per conto mio credo che nel tuo caso ci sia stato qualcosa che abbia interferito, nel senso che abbia pesato nel calcolo. Io feci dei test tempo addietro per il MWR dot it e assolutamente non c'era questa differenza, ...certo parliamo della 1.1 se ben ricordo, però non credo sia peggiorato a tal punto. Necessitano maggiori indagini.

Grassie per la segnalazione.

[davhub]

I tempi, fire, sono quelli degli SL, immagino, vero Lab2??

io comunque vedo: quelli sono globuli rossi, vero LAB2??
con un "pelo" di SSS, vero?

beh.. prova con una differenza di materiali...
secondo me i tempi si riducono.

anche perché dalla 1.1 non penso sia successo qualcosa di drastico...
per cui anche se non è un effetto in post, ma la riproduzione del meccanismo di scatto...
insomma...

Davhub