Test di velocità

[Lab2]

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]

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]

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]

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]

Grande questi test sono sempre utili ed interessanti.

Grazie
Saluti Stefano

[davhub]

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

Grazie ancora!!!

Davhub

[desegno]

a sto punto sono sicuro che lab2 vuole fare le scarpe a fire e vuole farsi assumere da next limit!!!!
!P
interessanti test

[Lab2]

Ora che ho terminato il contest di SpinQuad, mi sembrava un peccato lasciare spento il computer di notte.
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]

Ehhh..... caro Nico, ...qui non ti puoi distrarre un'attimo che ti spuntano concorrenti a ...tradimento! Ma noooo, ...magari ce ne fossero 1000 come il nostro Lab, ...guai a chi me lo tocca!

"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! . 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.

Fabio.

[Lab2]

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...