PDA

Visualizza Versione Completa : Fryrender vBeta1.9



mikadit
28-11-07, 20:42
La versione 1.9 di Fryrender è ora disponibil per tutti i licenziatare del software. Prima di tutto ora c'é anche la versione 64-bit.
Il port a 64-bit porta un sacco di vantaggi, velocità, circa il 5-10% più veloce della versione 32-bit, essendo il codice per le CPU a 64-bit più performante. Il limite a 3 GB di RAM non esite più, ora il limite risiede nella RAM installata.
La nuova verione include anche miglioramnti dei materiali, è stato migliorato il BRDF e conseguentemente ridotto il noise dei materiali metallici, vitrei e platici. Miglioramnti anche con lo sky e color mapping, rendendo il rendering più performante.

Ora è possibile utilizzare nel sistema IBL di Fry anche immagini HDR, sia per interno che per esterno. Miglioramenti vari dell'UI in generale, compreso il material Editor, con alcune funzioni di drag and drop, migliorando così il workflow. Ci sono miglioramnti anche dei plugin, per i quali è stato introdotto un'oggeto Sun per gestire più comodamente ed interattivamente il sole.

A seguente link (http://www.fryrender.com/docs/fryrender_vBeta1.9_changelog.pdf) è possibile leggere l'elenco delle novità in Fryrender vBeta1.9: http://www.fryrender.com/docs/fryrender_vBeta1.9_changelog.pdf

Per quanto riguarda la demo, la nuova verione sarà presto disponibile, 32 e 64-bit, con le stesse limitazioni della versione 1.8.

:D

mikadit
04-12-07, 08:36
Un fix per il plugin di LW, per evitare un eventuale problema nel Media pool del Material Editor, lo si trova nell'account FTP: 2007-12-03_fry_lw.zip

Lab2
04-12-07, 14:13
Non vedo l'ora che esca l'aggiornamento della demo di Fry.

Ma cosa intendi per MediaPool?
Non sono riuscito a trovare il link che indichi, è solo per in possessori di Fry?

Tienici aggiornati sugli aggiornamenti! :D

mikadit
04-12-07, 14:44
Il Media Pool è una porzione del Material Editor che si può utilizzare per il drag and drop all'interno dello stesso delle mappe, di ciò che hai creato nel map Editor.
7733

Il fix è solo per i possessori di Fry, ma sicuramente ci sarà anche per la demo.

Fire
12-12-07, 00:52
Mi chiedevo a quali vantaggi potesse portare un sistema IBL se già l'utilizzo di un'illuminazione HDR porta di per se una notevole accellerazione dei tempi di calcolo, ...perlomeno del calcolo dei primi campioni. :rolleyes:

mikadit
12-12-07, 03:28
Il sistema IBL di Fry ha avuto un drastico miglioramento per l'enviroment mapping tramite immagini HDR. Dire IBL è pressoché sinonimo di dire illuminazione HDRI, è quindi comprensibile chiedersi dove sia il vantaggio, ma la novità c'è e sta nel fatto che ora le immagine HDR, che si potevano già caricare ed utilzzare precedentemente, sono molto più performanti ed accurate, non c'é paragone con prima. Ora non c'è più il notevole disturbo che veniva prodotto a causa della forte discontinuità tra i punti chiari e quelli scuri, discontinuità intesa in termini di valori d'intensità estremi caratteristici delle immagini HDR; il metodo di calcolo è cambiato e questo ha comportato anche una maggiore velocità di calcolo, oltre ad un miglioramento in termini qualitativi. ;)

Fire
14-12-07, 15:55
Mhà, :rolleyes: ho ancora qualche perplessità e spiego il perchè.

Sostanzialmente, il vantaggio di un sistema IBL in un'engine che non lavora nativamente in HDR, è quello di poter allocare molta meno memoria ma sopratutto di poter ridurre drasticamente i tempi di calcolo in quanto esegue di per se un'estrapolazione sulle informazioni di radianza incluse nelle HDRI (che avrebbe invece dovuto calcolare l'engine del SW utilizzato), al cui posto è possibile utilizzare un pool di luci realizzate ad hoc dal SW che ne sostituisce l'efficacia donando un'illuminazione molto simile a quella che avrebbe fornito l'HDRI. Questo è in sostanza ciò che mi è sembrato di capire di questo sistema, se sbaglio correggimi.

Ora, il vantaggio in un engine come quello di MW, questo vantaggio viene parzialmente a cadere, proprio perchè, in virtù del sistema di calcolo nativo HDR, l'engine s'avvantaggia delle informazioni sulla radianza e l'esposizione contentute nelle HDR e già disponibili. Il risultato è che con un'illuminazione di tipo HDR, noteremo che subito dopo la fase della voxelizzazione, apparirà un'immagine già sufficentemente "intellegibile" e i progressi nei primi campioni saranno più rapidi rispetto ad un'illuminazione classica. Vista la similitudine fra gli engine iberici, riportando questo principio anche in Fry, mi chiedevo perchè investire su un sistema che a mio parere porta i suoi principali vantaggi su motori di calcolo tradizionali non nativi HDR, ...a meno che non abbia dato per scontata per Fry una cosa che forse scontata non è. Vedrò di reperire qualche info in più in merito.

Grazie.;)
Fabio.

mikadit
15-12-07, 02:37
Ora mi sto confondendo o non ho capito qual'è il punto, ma credo sia una questione di terminologia, non capisco la differenziazione IBL-HDR, quando i due termini fanno parte della stessa branchia della CG ... se parlo di IBL intendo un sistema di illuminazione che può utilizzare immagini HDR, se parlo di HDRI mi riferisco ad un tipo di immagine digitale che ha un'elevata gamma di dati riguardanti l'intensità luminosa di una scena. Se parlo di un sistema HDR, mi riferisco implicitamente ad un sistema d'illuminazione basato sull'immagine, Image Based Lighting, IBL appunto ... che supporta l'HDRI. L'HDR fa parte del capitolo IBL, quindi perché vederli così separati?
:noidea:

Fire
15-12-07, 12:06
Ho un brutto vizio, do per scontate quelle che sono solo mie supposizioni.

L'incomprensione credo risieda nel fatto che non conoscendo il sistema IBL di Fry, supponevo questo fosse basato sullo stesso principio di quello esistente per LW, dove viene restituito un set di luci che prende le informazioni su colore ed intensità da un campione di punti di un'immagine. Pensavo che fosse stato implementato un sistema simile come alternativa al il sistema di illuminazione HDRI già supportato dal SW.

Parlando invece del termine generico "IBL" ci si riferisce ad un generico sistema di illuminazione basato su immagine, anche di tipo LDR. Parlare di sistema IBL non significa necessariamente parlare di HDR, mentre è vero il contrario. ;)

mikadit
15-12-07, 14:16
Non ho mai escluso il formato LDR. :D

Ora però ho un'altro punto che non capiasco ... la restituzione di un HDR sotto forma di un set di luci? E' una delle possibili prassi, che funziona bene ma non è IBL, è una buona simulazione poiché utilizza valori di esposizione reali.
La restituzione di un set di luci è un metodo per simulare l'IBL, in LW si può usare o non usare questo metodo. LW non sostituisce nulla quando si vuole utilizzare un'HDR per illuminare una scena, se si vuole utilizzare un set di luce sulla base di un HDR o di un LDR allora si usa uno script o un plugin.
Ovviamente si può anche utilizzare sistemi ibridi. D'altro canto in LW i renders mantengono pienamente gli FP e possono essere salvati anche nel formato HDR, vedi quando si producono le immagini di light probe con lo stesso SkyTracer, vedi lo stesso Image Viewer FP.
E poi non bisogna dimenticare che LW legge, modifica e scrive il formato nativo Flexible Format (FLX), Radiance RGBe (HDR) e altri con estesi valori di esposizione, si può modificare i l'esposizione dei White e Black Points a piacimento prima e dopo il rendering ... :D

Fire
15-12-07, 16:28
...Ora però ho un'altro punto che non capiasco ... la restituzione di un HDR sotto forma di un set di luci? E' una delle possibili prassi, che funziona bene ma non è IBL, è una buona simulazione poiché utilizza valori di esposizione reali. La restituzione di un set di luci è un metodo per simulare l'IBL, in LW si può usare o non usare questo metodo. LW non sostituisce nulla quando si vuole utilizzare un'HDR per illuminare una scena, se si vuole utilizzare un set di luce sulla base di un HDR o di un LDR allora si usa uno script o un plugin....
Appunto. Non mi riferivo ad un sistema nativo di LW, ma ad un sistema per LW (forse era una plugin o uno script, non ricordo) che funzionava a questo modo e se ben ricordo si chiamava proprio IBL (fonte dell'equivoco), mi sembra se ne sia parlato proprio di recente. In effetti mi rendo conto che sarei dovuto esser più chiaro sin dall'inizio a questo proposito.:rolleyes:


...Ovviamente si può anche utilizzare sistemi ibridi. D'altro canto in LW i renders mantengono pienamente gli FP e possono essere salvati anche nel formato HDR, vedi quando si producono le immagini di light probe con lo stesso SkyTracer, vedi lo stesso Image Viewer FP.
E poi non bisogna dimenticare che LW legge, modifica e scrive il formato nativo Flexible Format (FLX), Radiance RGBe (HDR) e altri con estesi valori di esposizione, si può modificare i l'esposizione dei White e Black Points a piacimento prima e dopo il rendering ... :D
Come ho spesso avuto modo di dire, (anche nell'ultimo speciale di MWMagazine proprio sull'HDR), LW ha il grande pregio d'essere stato il primo SW commerciale ad implementare il sistema di Paul Debevec e da subito ne ho apprezzato le potenzialità. Ma il fatto che abbia un'uscita FP (altro primato :cool:) e che abbia In e Out nei principali formati ad alta radianza, non significa che il suo engine interno lavori ed utilizzi nel calcolo tutto lo spazio colore HDR nativo, questo non vale solo per LW, ma per qualsiasi altro Sw (e dopo LW, come al solito, si sono per così dire ..."ispirati" in molti alle novità del SW NT :D), che supporti il formato. Ma tutto questo comunque è un'altro discorso. ;)

Fabio.

mikadit
15-12-07, 19:07
No, non è sIBL, che ha l'opzione di creare una luce Sun sula base dell'immagine. Probabilmente ti riferisci al nuovo Lightbitch, l'evoluzione dello script Lightgen.

Non credo ci siano limiti nella lettura degli FP, in fondo è un formato digitale e quindi i dati sono solo numeri. Il primo limite risiede invece nei limiti del monitor e poi dell'occhio umano. Mentre evidentemente concordo che i limiti nell'interpretazione/utilizzo dei dati sono un'altro conto. E per restare nell'argomento limiti, non dimentichiamo che le HDRI, o in generale i sistemi solo IBL, hanno pure loro dei limiti, ma per fortuna i motori di rendering si avvalgono anche di altri strumenti per emulare le caratteristiche illuminotecniche dell'ambiente. :evil:

Fire
16-12-07, 00:18
...Non credo ci siano limiti nella lettura degli FP, in fondo è un formato digitale e quindi i dati sono solo numeri. Il primo limite risiede invece nei limiti del monitor e poi dell'occhio umano...
Infatti non parlo di limiti nella lettura dei FP, ma faccio un distinguo fra i 320bit IEEE FP di cui dispone la pipeline di rendering di LW ('nà putenza!:D), il cui scopo è però più generico, come quello di poter allocare in questo spazio i buffer più disparati come quelli necessari al movimento (sugli assi non già z-buffer), delle geometrie e dello shading, riflessioni ed infine anche della profondità colore. La necessità di un'engine che lavori sempre nativamente in HDR è quello di disporre dello spazio colore della luce visibile, con un'intervallo molto ampio per valori che spaziano da 10 alla - 4 sino a 10 alla 8va e anche oltre, ...per poter far questo l'engine deve poter operare nello spazio E-RGB (o Extended RGB), con valori FP per canale di 16 e 32bit. Lo spazio colore utilizzato invece internamente dagli engine "classici" è quello dell' S-RGB, con una gamma cromatica molto più ristretta, poichè l'obbiettivo è quello di raggiungere solo le capacità di riproduzione dei dispositivi finali (come i monitor), che spaziano in questa gamma limitata ai 16 milioni di colori di 8bit per canale (o 24bit complessivi). Il superamento dello spazio colore sRGB (usato dalle LDR "standard"), sarà ancor più importante in futuro, quando i monitor potranno permettere di più in termine di spazio colore, pensando che la visione umana supera almeno del doppio lo spettro coperto dell' sRGB. Altro vantaggio dei motori che lavorano internamente nel formato ad alta radianza, è quello di poterne sfruttare gli operatori logici su dati HDR, come la variazione di luminosità, contrasto e bilanciamento colore in RT, effetti di Low Vision, Glare, Motion Blur e Flare ed in fine la capacità di poter eseguire operazioni logiche fra dati di radianza, (...come il rendering cooperativo di MW ad esempio :evil:).


...Mentre evidentemente concordo che i limiti nell'interpretazione/utilizzo dei dati sono un'altro conto. E per restare nell'argomento limiti, non dimentichiamo che le HDRI, o in generale i sistemi solo IBL, hanno pure loro dei limiti, ma per fortuna i motori di rendering si avvalgono anche di altri strumenti per emulare le caratteristiche illuminotecniche dell'ambiente. :evil:
Mhà, dei limiti ci sono però bisogna tener conto che le tecniche HDR sono fondate sulla natura fisica della luce, per i cui calcoli si utilizzano le stesse unità di misura della fotometria. Poi volendo troviamo delle approssimazioni anche negli standard usati in fotometria, come i flie IES, ...ma così rischiamo d'allargarci davvero troppo come discorso e mi sembra d'aver fatto già abbastanza "danno" in questo senso (e me ne scuso :D).

;)

mikadit
16-12-07, 15:44
Mi son divertito su quest'argomento. :D
... no, non tiriamo fuori l'argomento IES, è un punto dolente questo. :evil: