corona e antialias

[cecofuli]

Che confusione! ^___^

(*) fisicamente corretto: se il motore si basa su algoritmi fisici. TUTTI i motori di rendering più moderni sono fisicamente corretti.

(*) Biased: se, per risolvere le varie equazioni, viene sfruttato qualche tipo di "truccho" (vedi LC, IM, HDCache, reflection bounces etc...)

(*) Unbiased: tipicamente si definisce un motore unbiased se, per risolvere l'aquazione di Kaija, il valore viene calcolato pixel per pixel (BF+BF, PT+PT etc..) e se non inserisce al suo interno nessun trucco per risolvere le varie equazioni fisiche indispensabili per il calcolo di un render.

(*) Ora, nessun motore, neppure Maxwell può essere definito 100% unbiased, perchè, pure lui, deve inserire al suo interno dei limiti. Infatti, in natura, la luce ha rimbalzi infiniti, non ci sono limiti sul numero di riflessioni possibili etc... E, per i limiti stessi di un software e dell'hardware odierno, ci devono essere un punto in cui si dice al software "stop".

(*) L'AA di Maxwell non so come viene calcolato, quindi non mi pronuncio. Ma l'AA non centra assolutamente con il discorso "fisicamente corretto". Un render potrebbe avere un ottimo AA, ma non essere fisicamente corretto. Per esempio, se disabiliti il decadimento quadratico della luce il render non sarà fisicamente corretto, anche se l'AA è presente.

[walterfog]

Che confusione! ^___^

(*) fisicamente corretto: se il motore si basa su algoritmi fisici. TUTTI i motori di rendering più moderni sono fisicamente corretti.

(*) Biased: se, per risolvere le varie equazioni, viene sfruttato qualche tipo di "truccho" (vedi LC, IM, HDCache, reflection bounces etc...)

(*) Unbiased: tipicamente si definisce un motore unbiased se, per risolvere l'aquazione di Kaija, il valore viene calcolato pixel per pixel (BF+BF, PT+PT etc..) e se non inserisce al suo interno nessun trucco per risolvere le varie equazioni fisiche indispensabili per il calcolo di un render.

(*) Ora, nessun motore, neppure Maxwell può essere definito 100% unbiased, perchè, pure lui, deve inserire al suo interno dei limiti. Infatti, in natura, la luce ha rimbalzi infiniti, non ci sono limiti sul numero di riflessioni possibili etc... E, per i limiti stessi di un software e dell'hardware odierno, ci devono essere un punto in cui si dice al software "stop".

(*) L'AA di Maxwell non so come viene calcolato, quindi non mi pronuncio. Ma l'AA non centra assolutamente con il discorso "fisicamente corretto". Un render potrebbe avere un ottimo AA, ma non essere fisicamente corretto. Per esempio, se disabiliti il decadimento quadratico della luce il render non sarà fisicamente corretto, benchè l'AA sia presente.

no no tranquillo... non c'è nessuna confusione in merito.... comunque vabbè... lasciamo stare.. tu hai le tue convinzioni che da quando frequentavi il forum DOT IT di maxwell sono state sempre puntualmente smentite... dire che MR non è 100% unbiased è dire una cosa assolutamente errata... comunque non ho tempo e soprattutto voglia di star qui a dimenarmi su un argomento che ogni volta si dimostra ostico e poco comprensibile per alcuni.

resta l'argomento della discussione e di questo thread, e cioè il fatto che l'AA di corona in certe situazioni restituisce dei risultati penosi... e riuscire a trovarne un rimedio è alquanto difficile se non impossibile....

[cecofuli]

Con Corona, PT+PT + MSI=0 e avrai un motore 100% unbiased, esattamente MW. Che poi, l'algoritmo per il calcolo delle caustiche tramite PT è scarso, questo è vero, lo sanno e ci stanno lavorando. E comunque, anche così, non sarà mai unbiased, perchè a un certo punto dovremmo stoppare il render e, per il fatto stesso di bloccarlo, stiamo inserendo una variabile che, in natura, non esiste.

AA penoso? E' lo stesso identico DMC che usa V-Ray... Se hai oggetti estremamente luminosi, che si sovrappongono a oggetti scuri, se lavori a 32bit è ovvio che avrai sempre presenza di seghettature (ripeto che non so come MW lavori). La soluzione è semplice (non capisco perchè dici che è impossibile): clampi a 1 (2 o 3, in base all'intensità massima), risolvendo del tutto il problema, ma avrai un render con una profondità colore ridotta.

[walterfog]

Con Corona, PT+PT + MSI=0 e avrai un motore 100% unbiased, esattamente MW. Che poi, l'algoritmo per il calcolo delle caustiche tramite PT è scarso, questo è vero, lo sanno e ci stanno lavorando. E comunque, anche così, non sarà mai unbiased, perchè a un certo punto dovremmo stoppare il render e, per il fatto stesso di bloccarlo, stiamo inserendo una variabile che, in natura, non esiste.

AA penoso? E' lo stesso identico DMC che usa V-Ray... Se hai oggetti estremamente luminosi, che si sovrappongono a oggetti scuri, se lavori a 32bit è ovvio che avrai sempre presenza di seghettature (ripeto che non so come MW lavori). La soluzione è semplice (non capisco perchè dici che è impossibile): clampi a 1 (2 o 3, in base all'intensità massima), risolvendo del tutto il problema, ma avrai un render con una profondità colore ridotta.

ripeto.. in merito alle tue convinzioni su cosa sia fisicamente corretto e unbiased non ci voglio stare sopra... non ho proprio voglia e tempo soprattutto!!

vorrei rimanere nell'argomento del thread aperto senza andare off topic... quindi qui parliamo di AA nell specifico.. che sia lo stesso di vray, o meno a me non interessa.. nel senso che qui parlo dell'AA di corona e di come lo calcola / gestisce... si ho capito il clamp a 1, 2 o 3... il problema si risolve, creandone un'altro nel senso che come ribadito sopra, l'illuminazione della scena viene totalmente sballata... hai mai provato? crea un classico set fotografico con 3 luci... una a destra, una a sinistra e una di fondo da controluce... posiziona un oggetto che riceva il controluce della luce di fondo... e inclina la telecamera di un tot a piacere... ( se lasci la telecamera perfettamente frontale all'oggetto illuminato il problema non si presenta).
per risolvere l'odiato problema dell'AA allora clampiamo in base al valore che ci serve... perfetto.. l'AA ora sembra andare ok.. cosa succede?? l'illuminazione del set fotografico va a farsi benedire totalmente... provare per credere!!!

[cecofuli]

so che non stiamo pralando di VRay, ma visto non mi pare l'ultimo arrivato e visto che viene usato praticamente d'appertutto, e che corona funziona all'o stesso identico modo, mi sembra strano che ci si lamenti di Corona, dopo che è da anni che, con VRay abbiamo lo stesso sistema.

Comunque, ho fatto un test veloce. Giudica tu.
Piano grigio chiaro, sfera bianca molto luminosa e sfondo nero (peggio di così, non so che fare).
Default: seghettature (ovviamente).
Con Clamp= 5 ho risolto il problema, con 2 va ancora meglio, ma perdo un po' troppe informazioni.
In VRay, dovrebbe essere la stessa cosa.

[walterfog]

so che non stiamo pralando di VRay, ma visto non mi pare l'ultimo arrivato e visto che viene usato praticamente d'appertutto, e che corona funziona all'o stesso identico modo, mi sembra strano che ci si lamenti di Corona, dopo che è da anni che, con VRay abbiamo lo stesso sistema.

Comunque, ho fatto un test veloce. Giudica tu.
Piano grigio chiaro, sfera bianca molto luminosa e sfondo nero (peggio di così non so).
Default: seghettature (ovviamente).
Con Clamp= 5 ho risolto il problema, con 2 va ancora meglio, ma perdo un po' troppe informazioni.
In VRay, dovrebbe essere la stessa cosa.

ohh ma siamo duri di comprendonio eh..... inutile ripetere le stesse cose come un disco rotto.... l'ha capito anche i muri che clampando il problema dell'AA si risolve.... :-) :-) non ho mai detto il contrario!! il fatto è che se tu applichi un valore di clamp tale da risolverti la situazione, in una scena da set fotografico con altri oggetti e luci, se da un lato risolvi il problema dell'AA dall'altro se ne crea uno peggiore perché l'illuminazione della scena, e il comportamento delle luci viene totalmente stravolto... appunto perché agendo sul clamp si stravolte il comportamento dell'highlight delle luci.... quindi che senso ha clampare a quel modo se tutto il resto va a farsi benedire? tanto vale sistemare il problema della seghettatura direttamente in photoshop...punto!! spero di esser stato chiaro ora!!!

[cecofuli]

A me non sembra che l'illuminazione nel mio semplice test è andata a farsi benedire. Forse sbagli qualcosa nella tua scena.
Allora anche tutti quelli che hanno usato V-Ray negli ultimi 15 anni che cosa dovevano fare?
Si, è vero, non puoi avere un'immagine a 32bit di profondità full float, con AA perfetto se ci sono parti del render con elevato contrasto RGB. Ma lo si sa ed è sempre stato così. Per questo che esiste in V-Ray e in Corona il parametro clamp. Non conosco MR credo che abbia anche lui qualcosa di simile. Inoltre non mi pare che venga "stravolto" completamente il risultato, come invece dici tu.

[walterfog]

A me non sembra che l'illuminazione nel mio semplice test è andata a farsi benedire. Forse sbagli qualcosa nella tua scena.
Allora anche tutti quelli che hanno usato V-Ray negli ultimi 15 anni che cosa dovevano fare?
Si, è vero, non puoi avere un'immagine a 32bit di profondità full float, con AA perfetto se ci sono parti del render con elevato contrasto RGB. Ma lo si sa ed è sempre stato così. Per questo che esiste in V-Ray e in Corona il parametro clamp. Non conosco MR credo che abbia anche lui qualcosa di simile. Inoltre non mi pare che venga "stravolto" completamente il risultato, come invece dici tu.

va bene OK.... lasciamo stare.. se non vuoi capire inutile insistere..... ma è ovvio che nel tuo esempio e anche in quello che si trova in internet la scena non viene falsata... hai una luce... 1 oggetto... che discorsi sono... applica la cosa a una scena reale... con un set con 4 o 5 luci... diversi oggetti.. con materiali reali... poi mi saprai dire sto cavolo di clamp cosa combina!!
cosa posso aver sbagliato io se l'unica cosa su cui si agisce è il valore del clamp?
e infine... visto che si insiste... MR non ha nessun clamp e nessun parametro che controlla l'AA... tanto per metterti l'anima in pace....

[cecofuli]

Ok, volevo capire se magari era un bug nella nuova versione di Corona e ho fatto una scena veloce, come dici tu.
Se hai scene più complesse, puoi spedire a quelli di Corona per il debugging.
Non sarà bellissima, ma rende l'idea.
Ancora una volta, a me non sballa nulla.
Ripeto, forse sbagli tu qualcosa. Oppure dovresti impostare la scena sapendo che andrai in contro a questa problematica e comportanti di conseguenza.
Sarebbe invece interessante capire, under-the-hood, come MW e MR risolvono questo tipo di situazioni.
Corona e V-Ray lo fanno così, clampando. MW e MR?

[walterfog]

Ok, volevo capire se magari era un bug nella nuova versione di Corona e ho fatto una scena veloce, come dici tu.
Se hai scene più complesse, puoi spedire a quello di Corona per il debugging.
Non sarà bellissima, ma rende l'idea.
Ancora una volta, a me non sballa nulla.
Ripeto, forse sbagli tu qualcosa. Oppure dovresti impostare la scena sapendo che andrai in contro a questa problematica e comportanti di conseguenza.
Sarebbe invece interessante capire, under-the-hood, come MW e MR risolvono questo tipo di situazioni.
Corona e V-Ray lo fanno così, clampando. MW e MR?

ho già scritto nel forum ufficiale circa la problematica.. è una cosa nota e conosciuta e condivisa da molti utenti... nella tua scena di esempio, come puoi vedere anche clampando a 6 la seghettatura sulla luce rimane... se provi a mettere come ti ho indicato una luce dietro la teapot che faccia da controluce, come è il mio caso postato a inizio thread, la scalettatura verrà ripetuta giusto nei punti dove in bianco della luce incontro l'oggetto in primo piano... parlo comunque di una scena, nello specifico una immagine per un catalogo, dove ci sono scrivanie.. divani.. librerie etc.. su fondo bianco.. con diverse luci.. capisci che per sistemare la seghettatura e clampando a valori estremi, tutti gli highlight delle luci sulla scena vanno a farti benedire... inutile quindi clapmare a quei valori se tanto comunque non si sistema al 100%... preferisco sistemare in post in photoshop...