PDA

Visualizza Versione Completa : Test di velocità



Lab2
10-04-08, 17:23
Durante il contest SpinQuad, mentre utilizzavo Maxwell pr renderizzare la mia Locker Room, mi sono ritrovato alle strette con i tempi di consegna e mi sono dovuto fare qualche calcolo sulla velocità di rendering.

Ovviamente, e si nota anche ad occhio, ad ogni passaggio (S.L.) i tempi si dilatano notevolmente, rendendo il raggiungimento del livello successivo sempre più lungo. Ma ho notato che i tempi incrementano con un valore ben preciso e costante:

Es. il tempo per raggiungere S.L. 13 diviso il tempo per raggiungere S.L. 12 è uguale a 1.5

oppure

Es. il tempo per raggiungere S.L. 18 diviso il tempo per raggiungere S.L. 17 è uguale a 1.5


Che mi porta alla conclusione:
il tempo per raggiungere il Sapling Layer successivo è uguale al 50% del tempo impiegato a raggiungere quello attuale.

Es. se per raggiungere il S.L. 12 Maxwell ha impiegato 100 minuti, il tempo per arrivare al S.L. 13 sarà di 50 minuti; quindi dopo 150 minuti dalla partenza. Di conseguenza, il S.L. 14 sarà raggiunto dopo altri 75 minuti e via dicendo.

Questo ovviamente applicato alla mia scena dove sono presenti molte luci con MultiLight attivo, molti oggetti e pesanti, materiali con SSS e Displacement.


La cosa mi ha incuriosito e ho portato avanti alcuni test sui tempi di resa di Maxwell:
1) in funzione del numero di poligoni o livello di SubPatch
2) in funzione del numero di poligoni per luce o numero di MultiLight
3) in funzione del numero della precisione del Displacement
4) in funzione del numero di cloni o istanze (incompleta)

Oltre al file PDF vi allego anche le immagini di riferimento per avere almeno un'idea di cosa ho renderizzato. Non considerate il loro grado di affinamento, visto che alcune le ho lasciate andare tutta notte e hanno abbondantemente superato il S.L. 14, che ho usato come valore limite per i miei test.




Test di velocità per poligoni

Da questo test si nota che l'aumentare dei poligoni influisce relativamente sul prolungarsi dei tempi. Per raggiungere il S.L. 14 impiego 5822 sec. con 12000 poligoni e 7387 sec. con 768000 poligoni.
Il discorso cambia se si utilizzano le SubPatch. Queste fanno aumentare i tempi di calcolo, come se ad ogni passaggio Maxwell dovesse freezare la mesh, perdendo tempo. Con una sudivisione di 4 (14592 poligoni) impiego quasi lo stesso tempo che a renderizzare 768000 poligoni. Cosa strana accade se aumento di molto il numero di suddivisioni(1459200 sec.); a 40 i tempi di rendering rimangono quasi invariati.

Lab2
10-04-08, 17:25
Test di velocità per luce

Con questo test ho voluto provare le varie soluzioni di illuminazione i Maxwell per valutare la loro incidenza sui tempi di calcolo. La prima cosa che salta all'occhio è la grande differenza che separa i tempi tra luce Dome (3465 sec.) e luce Sun (6312 sec.); quasi il doppio. Ma i tempi aumentano ancora molto se si vuole utilizzare un Emitter (10235 sec.) e in particolar modo se questo è composto da numerosi poligoni (11311 sec.). Mentre la funzione MultiLight incredibilmente non incide particolarmente sui tempi di calcolo, neppure utilizzandone svariati (10860 sec.); il che mi fa pensare che cali da qualche altra parte, tipo nella qualità del singolo canale.

Lab2
10-04-08, 17:26
Test di velocità con Displacement

Il Displacement è una funzione molto comoda e potente ma che porta i tempi di rendering alle stelle. Utilizzando lo stesso oggetto o fato vari test cambiando solamente il valore Precisione del Displacement. Senza di esso servono 6312 sec. per raggiunger il S.L. 14; attivandolo, anche a bassissimo livello di precisione (8) i tempi cambiano drasticamente (21715 sec.), più del triplo! Oviamente più aumentiamo il livello Precision e maggiore sarà i tempo richiesto. Usando Adaptive Precision sarà Maxwell a decidere il giusto livello di precisione, con il rischio di arrivare a 30653 sec. per un S.L. di 14. In questo caso, un tempo comunque minore di un livello di Pecision di 64 che porta il tempo di resa a 36344 sec.

Lab2
10-04-08, 17:28
Test di velocità con cloni e istanze

Velocemente ho fatto un test sui cloni e le istanze. Se con un oggetto i 30720 poligoni impiego 6312 sec. ad arrivare ad un S.L. di 14, me ne vanno 8746 sec. se clono l'oggetto 35 volte (30720x53 poligoni). Aumenta poco se consideriamo l'enorme quantità di poligoni, ma come avevamo detto in precedenza, il peso degli oggetti influisce poco a Maxwell. Ho provato ad aumentare i cloni ma inevitabilmente esplode LW durante l'esportazione; allora ho attivato le istanze e tutto è andato a buon fine. 11541 sec. con 119 istanze. I tempi sono aumentati nuovamente, ma almeno sono riuscito a lanciare il rendering.

marconwps
10-04-08, 23:00
Grande questi test sono sempre utili ed interessanti.

Grazie
Saluti Stefano

davhub
11-04-08, 12:38
no, non utile, di più! beato te che hai tempo per questo.. io non tocco più renderers dal contest per la 500...

comunque... la cosa non mi stupisce avevo anche io la stessa sensazione...

il discorso multilight, invece, non l'ho capito molto..
è il numero di luci di cui parli?
e quindi il numero incide poco semmai incide di più il TIPO (sun dome emitter)..

e mi sta anche bene e non mi stupsce nemmeno che l'emitter sia più pesante del sun... quest'ultimo è "procedurale" e quindi scalare, matematico, il primo, invece, dipende dalla geometria... cose BEN diverse.

da parte mia... posso dire che displace+ alta risoluzione= render non parte.
anche a ridurre il sampling del displace... a suddividere la scena per avere pochi oggetti, ecc... nada da fare... dovrò aumentare la RAM :D

Grazie ancora!!!

Davhub

desegno
11-04-08, 12:40
a sto punto sono sicuro che lab2 vuole fare le scarpe a fire e vuole farsi assumere da next limit!!!!
!P
interessanti test

Lab2
11-04-08, 17:04
Ora che ho terminato il contest di SpinQuad, mi sembrava un peccato lasciare spento il computer di notte. :D
Spero che i test possano esservi utili o almeno interessanti.

davhub, per quanto riguarda il discorso luci, la maggiore distinzione deriva dalla tipologia.
Per esempio:
Se con una luce Dome arrivo al Sampling Layers 14 in un ora, me ne serviranno 2 se uso il Phisical Sky e quasi 3 se uso un Emitter composto da un solo poligono.

Poi ho proseguito il test suddividendo il poligono Emitter in 484 poligoni e i tempi sono cresciuti nuovamente. Quindi attenzione a non usare oggetti troppo pesanti come Emitter!

Come ultima prova ho testato il Multilight e i tempi non sono praticamente invariati rispetto alla versione con un solo Emitter da un poligono. Anche usando 22 Light (da un poligono ciascuna) non ho visto nessun segno di rallentamento.



P.S. non so se ne ve siete accorti, ma le immagini che ho allegato sono capovolte. Questo perché, con l'ultima versione di Maxwell hanno cambiato il tipo di immagine che viene salvata di default. Agli inizi bisognava scrivere anche l'estensione altrimenti non si riusciva a salvare, poi hanno scelto il formato JPG e ora il salvataggio di default è in BMP.
La parte strana nasce nel momento in cui guardo le immagini con ACDsee; le immagini di preview sono capovolte ma se le allargo a tutto schermo le vedo correttamente. Quindi teoricamente nessun problema. Ma in questo caso che ho convertito il formato in Batch, la immagini sono rimaste storte.

Fire
11-04-08, 18:59
:rolleyes: Ehhh..... caro Nico, ...qui non ti puoi distrarre un'attimo che ti spuntano concorrenti a ...tradimento! :evil: Ma noooo, ...magari ce ne fossero 1000 come il nostro Lab, ...guai a chi me lo tocca! :D

"Tunque", ...ovviamente frequentando da diverso tempo ormai il "maxwellrender dot it", capirete che di test di questo genere ne abbiamo già fatti tantissimi ...ma ad onor del vero non ne abbiamo ancora fatti con la l' attuale 1.6.1, per cui resta interessante avere dei riscontri in proposito, ancora grazie Lab! :g1:. Vi anticipo però che questo genere di test sono puramente indicativi perchè MW, a differenza d'altri SW, simulando la realtà (e quindi anche il "caos", inteso come la molteplicità di sutuazioni di luce) in maniera "Hard Core", spesso spiazza, in quanto scene con set di luci che dovrebbero dare un certo comportamento in situazioni di luce particolari, si comportano in maniera opposta alle aspettative, ...ve lo dico per esperienza diretta!

Per lo più le tue deduzioni in effetti, trovano riscontro a quanto già sapevamo, ma non proprio tutto, ...diciamo che ci sono un paio di cosette che non mi quadrano, o perlomeno che non quadrano con le esperienze passare sino alla 1.5.x, e altre su cui vorrei tornare per chiarezza, quindi è solo di queste che parlerò. Ma andiamo per ordine.

Test di velocità per poligoni: ...è ormai risaputo che il genere d'algoritmo alla base non solo di MW, ma di tutti i motori di rendering Unbiased, ha un carattere esponenziale e si dilata quanto più si avvicina a soluzione del rendering, sino a rendere improduttivo proseguire nel rendering oltre certi campioni. Il settaggio delle luci è essenziale per potersi "fermare" per tempo con un'immagine già sufficentemente "pulita".

Test di velocità per Luce: ...il nuovo enviroment di MW permette queste combinazioni...

- Phisycal Sky
- Phisycal Sky + Sun
- Phisycal Sky + Sun + Emitter
- Sky Dome
- Sky Dome +Sun
- Sky Dome + Sun + Emitter
- None (utilizzabile con soli Emitter e/o con illuminazione HDRI)
- Enviroment HDR via MXI (la aggiungo perchè ne parlo dopo)

Ora a parte che vorrei ben capire quale di queste combine hai usato, quello che era noto era che la soluzione più "costosa" (in tempi di rendering), era quella Phisycal Sky + Sun, quindi in contrapposizione con i tuoi risultati, ...sempre se ho ben capito. Posso comunque confermarvi che il sistema più rapido in assoluto è quello via enviroment MXI, probabilmente perchè il motore HDR si avvantaggia di informazioni sulla radianza già disponibili.

Sistema di illuminazione via Multilight: ...è una cosa arcinota che, a differenza di quanto risulta dai tuoi test, il sistema porti via del tempo extra (anche se poco in realtà) se attivo, ...quello che posso pensare è che visto la semplicità della scena test, non si sia potuta apprezzare la differenza, ma con scene complesse un pò di differenza dovrebbe esserci, (anche se poi operativamente conviene comunque per il tempo che si risparmia nel settaggio delle luci ;)).

Riguardo il Displacement: ...è una funzione a detta della stessa casa "non ancora ottimizzata", ma è bene notare che si tratta di "Micro-Displacement" e che ha un sistema di funzionamento avanzato che ha la contropartita di fornire notiriamente superfici estremamente suddivise (anche a basso grado di dettaglio). E' bene ricordare che se si facesse renderizzare un'analoga superfice con il corrispondente numero di poligoni, i tempi non si discosterebbero più di tanto, motivo per cui è bene farne un'utilizzo oculato e attento.

Riguardo le immagini capovolte: ...non ho avuto lo stesso riscontro ma devo approfonfire con altri test.

Vorrei ribadire il Grazie a Lab per aver prodotto questi risultati interessantissimi, spero solo d'aver anch'io un'attimo di tempo in più per fare qualche altra prova. :g1:

Fabio.

Lab2
12-04-08, 11:41
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!

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).
Tutto il resto non racconta nulla di nuovo, semplicemente lo conferma oppure lo mette in evidenza.

Ti seguo a ruota.............

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?

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.

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.

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.

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?

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?


Io ve le butto li....
Spero di non averne sparate troppe....
Ma sono sempre pronto a rivedere le teorie...

Fire
12-04-08, 16:14
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à" :D, 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)...
:rolleyes::D 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"! :D 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! :g1:


..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 (:D), 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. :g1:

Fabio.

Lab2
14-04-08, 09:38
Ciao Fire,
grazie dell'attenzione.

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

- Linka pure! :g1:
- 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. :D
- 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 :g1:), 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
14-04-08, 23:26
- 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) (http://klausbusse.de/mxc/) , 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/exposure_calculator.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
15-04-08, 07:00
che fantastici link!!!
alcuni li conoscevo altri assolutamente no!!!
thank's

davhub
15-04-08, 09:31
Ciao Ragazzi, al solito fire e Lab2 ci mettono del loro. :D

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 (:evil: ) che ne parla :D. 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
15-04-08, 10:37
... 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 :D). 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. :g1:

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
16-04-08, 14:56
Ma che bello...
quante considerazioni interessanti!
:clap:

Lab2
23-04-08, 11:10
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
23-04-08, 15:37
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
23-04-08, 15:41
I tempi, fire, sono quelli degli SL, immagino, vero Lab2?? :D

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

Lab2
23-04-08, 16:23
Le numerazioni in secondi rappresentano i tempi per raggiungere i primi 11 S.L. nei due test che ho fatto. Con e senza MotionBlur.
Potevo essere più chiaro, ma più che un test voleva essere un riscontro.

Effettivamente utilizzare dei globuli rossi con spessore interno e SSS non può risultare un test troppo indicativo; ma l'enorme differenza di tempi tra i due mi ha fatto cadere dalla sedia.

Stasera ripeto il test con un materiale neutro.



Ma...
domandone.
Il Motion Blur, o sfocatura dovuta al movimento è direttamente collegata al tempo del MB variare in tempo reale a seconda della regolazione dello Shutter. Magari.....
Dove sbaglio?

Fire
23-04-08, 16:50
Non credo tu stia sbagliando in nulla, l'unica cosa è che pensavo potesse esserci un qualcosa a livello geometrie/materiali che poteva dar fastidio. Ma poi magari sono solo mie supposizioni.

Il motion blur varia a seconda dei tempi di posa, più questi son alti, maggiore sarà l'effetto. Quindi se pensi ad una modalità "sport mode" delle camere, certamente troverai dei tempi bassissimi, per es. con 1/1000 di velocità dell'otturatore (SS) "fermi" la classica pallottola, ...il rovescio della medaglia è che tempi così bassi fanno entrare meno luce, per cui occhio a dove si utilizzanno, (per es. la modalità "sport" va bene perchè in genere si utilizza all'aperto e di giorno). Un modo per compensare la poca luce è utilizzare una focale "corta", infatti con valori di f-stop di poche unità, si ottengono immagini molto luminose (nella realtà però obbiettivi così costano uno sproposito, x fortuna noi in virtuale possiamo pazziare :D), ...il rovescio della medaglia (ce n'è sempre uno :evil:), in questo caso è che valori bassi di f-stop producono un notevole effetto di profondità di campo (DoF), non sempre desiderata.

'Nzomma, ...come al solito tocca trovar sempre il giusto compromesso. ;)
Fabio.

Lab2
23-04-08, 17:31
Ho capito, ma quello che non capisco è.....

Il tempo di apertura (Shutter Speed) va regolato all'inizio, prima di lanciare il rendering; perché se vado a variarlo durante il calcolo non varia il MotionBlur ma solo la luminosità.

Giusto?

Fire
23-04-08, 18:25
Forse è che stai trascurando un particolare non trascurabile :D ...qui parliamo di movimento, quindi di animazione, non di fotogramma singolo, nel senso che per ottenere un determinato "effetto scia", bisogna considerare la velocità dell'oggetto rispetto al tempo d'apertura. Quello che tu modifichi è l'apertura su un singolo fotogramma, non sull'animazione, ...per cui ciò di cui noti variazione, è solo la quantità di luce che fai entrare in quel dato fotogramma, (tenendo sempre presente inoltre, che se la velocità dell'oggetto varia, un fotogramma non sarà come un'altro in termini di MB). Per poter calcolare una scia diversa, MW avrebbe disogno che LW gli passasse tramite plugin d'esportazione, delle info sul movimento dell'oggetto che al momento non ha, (o che non sa se sono variate), per cui se vari lo SS, per notare cambiamenti devi rilanciare il rendering, poichè al momento dell'esportazione il SW sarà informato dell l'ammontare del MB da suddividere e calcolare come resa nei vari fotogrammi.

Diciamo pure che se vogliamo, il lato animazione in MW è indubbiamente "spartano", ...essendo un SW pensato a monte essenzialmente per lo still-life. ;)

Fabio.

Lab2
24-04-08, 09:53
Quello che tu modifichi è l'apertura su un singolo fotogramma, non sull'animazione, ...per cui ciò di cui noti variazione, è solo la quantità di luce che fai entrare in quel dato fotogramma

Fabio.


Ops, avevo tralasciato un piccolo dettaglio.:argh:
Giustamente Maxwell preleva le informazioni di movimento da LW solo all'inizio del rendering (difatti, durante l'esportazione si vedono i fotogrammi avanzare in OpenGL).
Grazie della delucidazione, Fire. :g1:



Ieri sera ho fatto un'altra prova con il MotionBlur, ma stavolta ho assegnato alle gocce di sangue un materiale Diffuse Standard.
Senza SSS i tempi riducono in entrambi i test e anche la differenza tra i due si assottiglia. Rimane comunque un detto stacco che tende a crescere con il passare dei S.L. (all'undicesimo abbiamo già superato il doppio del tempo).


senza__MB 22 50 078 112 157 219 306 431 0612 0878 1273
con____MB 29 65 114 182 277 414 614 907 1341 1987 2950

skyler
24-04-08, 10:39
rovescio della medaglia è che tempi così bassi fanno entrare meno luce, per cui occhio a dove si utilizzanno, (per es. la modalità "sport" va bene perchè in genere si utilizza all'aperto e di giorno). Un modo per compensare la poca luce è utilizzare una focale "corta", infatti con valori di f-stop di poche unità, si ottengono immagini molto luminose (nella realtà però obbiettivi così costano uno sproposito, x fortuna noi in virtuale possiamo pazziare :D), ...il rovescio della medaglia (ce n'è sempre uno :evil:), in questo caso è che valori bassi di f-stop producono un notevole effetto di profondità di campo (DoF), non sempre desiderata.

'Nzomma, ...come al solito tocca trovar sempre il giusto compromesso. ;)
Fabio.


Per maggiore correttezza in tema fotografico, quando si parla di f/.. è accettato l'assunto di tutta apertura(numeri bassi) e quindi diaframma aperto, minimo DOF e diaframma chiuso (numeri alti) massimo DOF, sempre e cmq. in funzione della lunghezza focale.
Poi nella pratica non conviene mai usare un'ottica a tutta apertura in quando non da il meglio di se..:evil: meglio scattare a f/6- f/11.
Scusate l'intrusione in una discussione seria e tecnica, che leggo volentieri sempre e dove non metto bocca, data la mia assoluta ignoranza in merito.:D

Fire
24-04-08, 11:30
Per maggiore correttezza in tema fotografico, quando si parla di f/.. è accettato l'assunto di tutta apertura(numeri bassi) e quindi diaframma aperto, minimo DOF e diaframma chiuso (numeri alti) massimo DOF, sempre e cmq. in funzione della lunghezza focale.
Poi nella pratica non conviene mai usare un'ottica a tutta apertura in quando non da il meglio di se..:evil: meglio scattare a f/6- f/11.
Scusate l'intrusione in una discussione seria e tecnica, che leggo volentieri sempre e dove non metto bocca, data la mia assoluta ignoranza in merito.:D
..."l'effetto profondità di campo" e la "profondità di campo" sono inversamente proporzionali, quindi se dico che avrò molto effetto profondità di campo, significa che avrò un DoF basso e viceversa, ...a volte ci si "incarta" su sti assunti ;) Riguardo gli obbiettvi, se ne acquisto uno che parte da una focale bassa, tipo 2,8, certamente lo pagherò un'occhio perchè comunque sarà un'ottica molto luminosa e farà la differenza a parità d'escursione con un'analogo che parte più su. Fortunatamente nel virtuale possiamo "scialare" in questo senso (della serie... "aggratis ...ungimi tutto" :D:D).

Ben risentito. ;)
Fabio.

davhub
24-04-08, 17:12
senza__MB 22 50 078 112 157 219 306 431 0612 0878 1273
con____MB 29 65 114 182 277 414 614 907 1341 1987 2950

CVD.. ecco qui :D

coem sempre è esaltante parlare con Fire e gli altri di fotografia...

ma accidenti a voi!! avete anche il tempo per i contest!! e dire che multiply mi gasa moltissimo! (mi ricordo i miei mondi virtuali randomici fatti con POVray.. :D)

Davhub