davidecarr ha scritto:mamma mia che discussione avvincente!!!....cmq ci sono anche i comuni mortali....perche non fate 2 scene di esempio da confrontare?
tornando quindi all'argomento della discussione, e quindi del MIO thread, la soluzione a questo problema non esiste... agire sul clamping serve solamente a migliorare o attenuare l'effetto dei jagged edges... ma non lo risolve al 100%... ad alte risoluzioni poi, a 32 bit, l'effetto del clamping è quasi trascurabile, se comparato allo stravolgimento che tale clamping opera sull'illuminazione della scena.... non c'è altro da aggiungere... fare due scene di comparazione sarebbe totalmente inutile perché tale fenomeno si manifesta nelle situazioni più disparate, e la sua attenuazione dipende da appunto da scena a scena.. non c'è un modo univoco per risolverlo...
Più che altro, se qualcuno usa MW da 10 anni, penso che un po' di robe ne abbia lette, viste e sentite.
E' come se a me venissero a chiedere qualcosa di V-Ray o Corona. Non saprò tutto, ma un po' di cose ne conosco ;-) Ho pensato di scrivere al mio amico perchè l'ho in Skype e so che usa MW da una vita, tutto qui. Se il mio amico non saprà darmi risposta, mi iscriverò al forum di MW e chiederò. Oppure dammi/datemi voi una mano.
V-Ray, Corona, MR etc.. gestiscono quella situazione in un modo. MW lo affronterà in un altro. Non vedo dove vuoi arrivare.
Non mi pare che V-Ray sia così male come software, visto che è uno dei motori di render più usato al mondo. Inoltre, in un sondaggio fatto di recente da CGArchitect (130.000 utenti, 5000 attivi), Corona è il secondo software, in ambiente arch-viz-automotive, più usato al mondo ed è il primo come motore più testato. MW è fuori dai giochi. Se, però, non ti piace come loro affrontano e risolvono quel problema, che ti dobbiamo dire, usa MW ^___^ .
Io, comunque, è dalla Alpha3 che uso Corona (2013) e dal 2001 che conosco V-Ray: di "stravolgimenti" usando il clamping non ne ho mai visti, ne in Corona ne in V-Ray. Certo, perdi un po' informazioni HDR (se clampi a 1, allora hai un'immagine praticamente a 8 bit, ma credo che tu lo sappia), però non sempre abbiamo la necessità di post-produrre in float number. Per me sbagli qualcosa tu... Ripeto, invia la scena a quelli di Corona, magari ti aiuteranno a sistemare il tuo file. Oppure c'è un bug in Corona per C4D. Ti aiuterei io, ma non usiamo Cinema, sorry...=(
Più che altro, se qualcuno usa MW da 10 anni, penso che un po' di robe ne abbia lette, viste e sentite.
E' come se a me venissero a chiedere qualcosa di V-Ray o Corona. Non saprò tutto, ma un po' di cose ne conosco ;-) Ho pensato di scrivere al mio amico perchè l'ho in Skype e so che usa MW da una vita, tutto qui. Se il mio amico non saprà darmi risposta, mi iscriverò al forum di MW e chiederò. Oppure dammi/datemi voi una mano.
V-Ray, Corona, MR etc.. gestiscono quella situazione in un modo. MW lo affronterà in un altro. Non vedo dove vuoi arrivare.
Non mi pare che V-Ray sia così male come software, visto che è uno dei motori di render più usato al mondo. Inoltre, in un sondaggio fatto di recente da CGArchitect (130.000 utenti, 5000 attivi), Corona è il secondo software, in ambiente arch-viz-automotive, più usato al mondo ed è il primo come motore più testato. MW è fuori dai giochi. Se, però, non ti piace come loro affrontano e risolvono quel problema, che ti dobbiamo dire, usa MW ^___^ .
Io, comunque, è dalla Alpha3 che uso Corona (2013) e dal 2001 che conosco V-Ray: di "stravolgimenti" usando il clamping non ne ho mai visti, ne in Corona ne in V-Ray. Certo, perdi un po' informazioni HDR (se clampi a 1, allora hai un'immagine praticamente a 8 bit, ma credo che tu lo sappia), però non sempre abbiamo la necessità di post-produrre in float number. Per me sbagli qualcosa tu... Ripeto, invia la scena a quelli di Corona, magari ti aiuteranno a sistemare il tuo file. Oppure c'è un bug in Corona per C4D. Ti aiuterei io, ma non usiamo Cinema, sorry...=(
credo che quello che sta cercando di dirti sin dall'inizio sia:
machissenefrega di maxwell, vray e chissacos'altro.
E io sto dicendo che esiste più di un modo per risolverlo e l'ho pure dimostrato.
Ed è lo stesso modo che usano VRay, MR. In MW non so. Quindi, credo di aver risposto a tutti i suoi quesiti in modo più che soddisfacente. ^__^
cecofuli ha scritto:Più che altro, se qualcuno usa MW da 10 anni, penso che un po' di robe ne abbia lette, viste e sentite.
E' come se a me venissero a chiedere qualcosa di V-Ray o Corona. Non saprò tutto, ma un po' di cose ne conosco ;-) Ho pensato di scrivere al mio amico perchè l'ho in Skype e so che usa MW da una vita, tutto qui. Se il mio amico non saprà darmi risposta, mi iscriverò al forum di MW e chiederò. Oppure dammi/datemi voi una mano.
V-Ray, Corona, MR etc.. gestiscono quella situazione in un modo. MW lo affronterà in un altro. Non vedo dove vuoi arrivare.
Non mi pare che V-Ray sia così male come software, visto che è uno dei motori di render più usato al mondo. Inoltre, in un sondaggio fatto di recente da CGArchitect (130.000 utenti, 5000 attivi), Corona è il secondo software, in ambiente arch-viz-automotive, più usato al mondo ed è il primo come motore più testato. MW è fuori dai giochi. Se, però, non ti piace come loro affrontano e risolvono quel problema, che ti dobbiamo dire, usa MW ^___^ .
Io, comunque, è dalla Alpha3 che uso Corona (2013) e dal 2001 che conosco V-Ray: di "stravolgimenti" usando il clamping non ne ho mai visti, ne in Corona ne in V-Ray. Certo, perdi un po' informazioni HDR (se clampi a 1, allora hai un'immagine praticamente a 8 bit, ma credo che tu lo sappia), però non sempre abbiamo la necessità di post-produrre in float number. Per me sbagli qualcosa tu... Ripeto, invia la scena a quelli di Corona, magari ti aiuteranno a sistemare il tuo file. Oppure c'è un bug in Corona per C4D. Ti aiuterei io, ma non usiamo Cinema, sorry...=(
allora... perché uno usa MW da 10 anni tu dici che è a conoscenza di cose che nemmeno un matto rivelerebbe ai comuni utenti??? io uso MW dalla prima alfa che hanno realizzato e guarda te di come MW gestisce questa problematica non ne sono assolutamente nulla.... attendiamo quindi di venire ancora una volta illuminati da te e ora anche dal tuo amico esperto conoscitore....
di tutto il resto che hai aggiunto non commento oltre... vedo che il tuo modus operandi di intervenire nei forum e nei thread altrui non è cambiato da quando nel sito DOT IT ti sconfessavano una dopo l'altra le tue teorie quando all'epoca spalleggiavi a spada tratta vray....
ora, dopo averti chiesto per l'ennesima volta di smetterla di intervenire in questo thread che ha uno specifico argomento, con le tue argomentazioni più disparate e fuori tema, la cosa si trasferisce sul piano dell'educazione e del rispetto degli altri utenti.. cosa che senza nessun stupore vedo non hai migliorato.....
continua pure con la tua melina su MR, MW corona.... su chi è più usato... su chi meno...bla bla bla....
io mi ritiro.... ciao.....
enzo_87 ha scritto:credo che quello che sta cercando di dirti sin dall'inizio sia:
machissenefrega di maxwell, vray e chissacos'altro.
tranquillo Enzo... ho capito bene cosa vuole dire... ripeto... conosco il personaggio e il suo modus operandi e di intervenire nei forum e nelle discussioni altrui...
dice che esiste un modo per risolverlo e di aver risposto al quesito... dice puramente cavolate perché il modo per risolverlo NON ESISTE visto che i jagged edges non vengono eliminati... posta un esempio creato ad hoc per far vedere una cosa che in realtà non si può eliminare... punto... nel suo stesso esempio che lui dice di aver dimostrato, i jagged edges sono solamente attenutati e non eliminati... questo la dice lunga... ma comunque niente di nuovo... con lui bisogna farsene una ragione... non c'è altro modo!!!
infatti non esiste un metodo per risolvere questo problema, con nessun motore di render. Poiché esso è un "non problema". Cioè è intrinseco in ogni render a 32bit. E credo che anche in MW si sia trovato qualcosa per aggirare questo tipo di situazione. Se alla Chaos, in Nvidia (MR è stato comprato dalla Nvidia) e alla Render Legion non hanno trovato nessuna soluzione, ci sarà un motivo. Non credo che a loro manchino le competenze o il budget necessario. O meglio, se tutti e tre hanno optato per lo stesso sistema per aggirare questo tipo di situazioni, ci sarà un motivo. Il fatto che non si sappia come MW lo abbia affrontato, non implica che tale problema non ci sia. Mi piacerebbe però parlare di questo con qualcuno di competente.
Da quello che sono riuscito a capire nelle varie discussioni nei link diretti nel forum di Maxwell e dai render sparsi qua e la, anche MW soffre di questo problema. Tant'è che alcuni suggerivano, pure loro, di renderizzare al doppio della risoluzione per poi riscalare in PS, o di aggiustare l'esposizione e via dicendo, proprio come si fa con V-Ray e Corona.
Faccio copia/incolla di discussioni prese dal forum di MW, così è più comodo per tutti leggere.
"looks like that's an aliasing problem caused by how bright the light is coming through the window .... you need to tonemap it better , it might be the case you need to export as exr and tonemap elsewhere as a 32bit."
"This can happen if the AA is too bright (above 1,1,1 RGB). The AA is there but it appears all white. You might be able to solve this by combining two exposures. One for the area with AA problems and one for the rest. Or try changing the the burn."
"I guess you can't do nothing about it. that is alway going to happen when you have very bright areas totally out of range (that is n times above 1.0, where 1.0 it's 255 white before it gets clipped). since maxwell doesn't clamp pixels above 1.0, you may have emitters' edges which can't correctly be displayed as anti aliased because the transition between bright and less bright colours (which is where anti aliasing should do the smoothing), still happens in unclamped/above 1.0 areas. so even where the lights should fade into a darker area, you get clipped, shown as solid 255 white, aliased edges. (if you underexpose that same render in mxcl, you should see the aliasing disappear when the brighter part of your lights gets close to 1.0). one solution is to render at a very high resolution and then scale down, another one is to make sure that all the dynamic range of your render is between 0 and 1.0. " ... "Or just cover it with glare, what would be expected in a shot like that."
"but anyway, those situations where very bright emitters stand against a dark background are very tough ones. and sure it's not maxwell to blame, it happens with any renderer when you work with unclamped colours."
E ancora, uno chiede:
"there was much aliasing in the high resolution render (3000 px) ... did you now why?"
Risposta 1:
I've seen such aliasing problem many times on my renderings on specific areas of too bright pixels. Decreasing exposure fixed it. I think problem is in displaying or converting 32bit images into 8 or 16 bit.
Risposte 2:
I strongly suggest saving LDR images (PNG, TIFF...) from Maxwell for avoiding this problem. For high dynamic range, TIFF32 or EXR would be a better choice. Though, aliasing is mainly related to the tonemapping (during 32 to 8 bit conversion) so, saving out LDR from Maxwell is always better in this case.
Io credo che sia impossibile, come dice anche Rivoli, che in una immagine con zone ad alto contrasto dinamico (se il render è mantenuto in tutto il suo percorso in 32bit full float non clampato) non avere jagged edges. E', per chi conosce un po' di matematica, appare anche logico. Se tu hai tre pixel, il primo [50,50,50], e il terzo [0,2.0,2.0,2] quello di mezzo sarà per esempio, dopo il tone mapping [10,10,10]. Valore RGB che i nostri monitor rappresenteranno come bianco e che, a noi, apparirà come un errore di AA. Errore, che in realtà, non è. Poichè, come viene suggerito anche il forum di MW, riducendo l'esposizione potremo vedere anche i restanti, che ne so, 6 pixel ed il passaggio da [50,50,50] e [0,2.0,2.0,2] apparirà più graduale. Ma forse questo è un concetto un po' troppo complicato da discutere qui.
In allegato un render che ho trovato su forum di MW. L'AA è perfetto, tranne che per le zona dove si riflette la sorgente luminosa, che è estremamente luminosa. Ed è la stessa situazione che può avvenire in Corona, VRay, MR. La mia domanda: come MW affronta tali situazioni?
Comunque mi sembra strano che in un forum come questo nessuno sappia come MW affronta questo tipo di soluzioni.
Vabbeh, mi informerò io e poi ve lo farò sapere ^__^. Ciao!
Allegati
Ultima modifica di cecofuli il mar gen 10, 2017 1:34 am, modificato 1 volta in totale.
It means 24 bits Pixel value + 8 bits exponent and it doesn't have true 32 bit precision per-pixel like TIFF32 or EXR nor MXI.
risposta 2: post del 2012... MW era alla versione 2.. ora siamo alla 4.
risposta 3: post del 2007.. MW era alla versione 1... ora siamo alla 4.
risposta 4: post del 2007.. MW era alla versione 1... ora siamo alla 4.
risposta 5: post del 2010.. MW non era ancora alla versione 2... ora siamo alla 4. e inoltre stesso problema della risposta 1.. e cioè problema legato alla HDR.
poi pubblichiamo pure immagini dove al 100% il problema non esiste.. e zoomiamole pure al 400% così tanto per far qualcosa..
punto!!!
FOLLOW US