Vai al contenuto

dagon

Members
  • Portfolio

    Portfolio
  • Numero messaggi

    6711
  • Registrato

  • Ultima Visita

  • Days Won

    2

dagon last won the day on April 9 2010

dagon had the most liked content!

Info su dagon

  • Rango
    treddizzofrenico

Informazioni professionali

  • Sito Web
    http://www.matteomagnazzi.com/

Ospiti che hanno visualizzato il profilo

10631 lo hanno visualizzato
  1. dagon

    Autodesk - 2012

    dimenticavo, mi astengo da fare commenti su maya perché sono troppo innervosito per essere obiettivo
  2. dagon

    Autodesk - 2012

    non è il prodotto a essere in WIP, ma la sua implementazione fatta da autodesk, dai un´occhiata a shot pro, che lo integra da un anno, o anche a come è stato integrato in c4d dire che l´implementazione fatta da autodesk è penosa è usare un eufemismo
  3. dagon

    Bunkspeed Presenta Shot

    sempre shot (le immagini sono dell'utente xtrm3d)
  4. dagon

    Bunkspeed Presenta Shot

    un paio di render fatti in shot in cpu mode: dual-quad xeon@2.27 15 minutes 20 minutes 3h un test sulle caustiche tratto dal forum di maxwell 45minutes 45minutes
  5. mi sembra di averti detto che ero interessato, non ho mai detto: luxrender non renderizza nativamente in nurbs, quindi non devo dimostrarlo, mi sembra che tu abbia detto il contrario e ti sono state chieste informazioni in merito cmq ho segnalato il tuo messaggio precedente, giusto per avvisarti
  6. e infatti ti hanno chiesto documentazione relativa al rendering navito di nurbs, io non so se lo faccia o meno, ma dire che "io so così" non è che risolva il problema tra l'altro renderizzare nativamente in nurbs non significa renderizzare efficientemente le nurbs, dipende come questo viene fatto (ci sono tanti papers a riguardo), anche perché molti algoritmi di data structure sono estremamente ottimizzati per i poligoni
  7. a naso il problema sembra dovuto al memory limit, che su max 2011 viene impostato automaticamente mentre prima era manuale
  8. non direi proprio, lo sviluppo di cuda è iniziato molto prima dello sviluppo di open cl ed è anche decisamente più avanti a livello di features questo mi sembra quantomeno improbabile, la gpu deve avere le informazioni delle textures, mi spieghi come fa a effettuare il pathtracing altrimenti? i motori di rendering ibridi caricano tutte le informazioni su ciascuna delle periferiche usate (vale a dire memoria di sistema per la cpu e vram per la/le gpu), questo è possibile sia su cuda, sia su open-cl (tanto che il primo motore di rendering ibrido è stato arion e iray è anche lui ibrido) cosa che può fare anche cuda, anzi in teoria essendo più specializzato sull'architettura nvidia e più avanti a livello di sviluppo dovrebbe farlo meglio giusto per correggere un paio di imprecisioni
  9. scanline attivo o disattivo? che metodo usi per il raytracing?
  10. fate i bravi dai il problema del transparency non si risolve usando IP+FG, o meglio, lo si risolve solo in parte (perché è solo il FG a calcolare la luce che passa attraverso i vetri e ovviamente calcola solo un rimbalzo) l'unico modo per evitare il problema è crearsi dei layer con i materiali trasparenti, calcolarsi l'IP map separatamente, togliere il rebuild, riattivare i vetri e effettuare il render finale per quanto riguarda invece gli importons forse ho capito perché dario (mi pare fossi tu, non vorrei sbagliarmi), mi parlava di risultati differenti rispetto al passato, sostanzialmente quando abilitate importons+photonmap(GI)+FG la photon map viene esclusa dal calcolo, che viene effettuato solo con imp+FG lo si può vedere dal log, ma è anche evidente se portate i diffuse bounce del FG a 0, in quel momento vi accorgerete che i rimbalzi li sta calcolando il FG e non la photon map unico modo di aggirare il problema? calcolare importons+photonmap, togliete il rebuild, attivate il fg e tutto torna alla normalità fortunatamente la fase di setup di importons e photon map in genere si fa prima di attivare il FG, quindi non ci sono grandissimi problemi, dovete solo ricordarvi di salvarla e non farla ricalcolare
  11. dagon

    Bunkspeed Presenta Shot

    la beta di octane è pubblica, se vuoi acquisti la licenza della versione 1.0 in anticipo per la beta di shot devi iscriverti sul loro sito, non so se avranno dei filtri perché ho sentito che gli iscritti sono già parecchi, per quanto riguarda le licenze non hanno rilasciato informazioni su possibili sconti
  12. dagon

    Bunkspeed Presenta Shot

    costa meno di 1/4 se lo compri adesso che è in beta, è la stessa politica che usava maxwell ai tempi, ovviamente quando avranno un software stabile e con tutte le features costerà di più tieni presente che in questa fase poi comprare un software è sempre una scommessa, forse qualcuno si ricorda ancora maxwell alpha e tutte le polemiche che sono arrivate al rilascio di maxwell 1.0 vero? Ecco perché il software costa così poco allo stato attuale, il che non significa che non sarà fantastico quando uscirà, solo che non puoi esserne certo per quanto riguarda la velocità dipenderà da vari fattori, l'ottimizzazione del codice per l'esecuzione su gpu è uno di questi, l'ottimizzazione degli algoritmi di sampling un altro aggiungerei che ci sono attualmente due differenti approcci, se non tre, octane (a quanto dicono) ha preso la strada del motore puramente gpu, quindi se non ti funziona la scena sulla gpu (perché è troppo pesante a esempio) ti attacchi al chiodo, arion e iray usano una soluzione ibrida (gpu, cpu, gpu+cpu), vray rt per ora ha gpu e cpu, ma probabilmente implementerà anche gpu+cpu, questo tipo di approccio forse porta a qualche compromesso in termini di velocità sull'esecuzione in gpu mode ma a mio modo di vedere è più flessibile e più "sicuro" per l'utente, nel senso che se la scena non ci sta sulla gpu per lo meno puoi usare la cpu e non sei costretto a passare ad altri software credo che ci sia un terzo approccio, che un po' tutti stanno cercando di sviluppare sui motori di rendering classici, ovvero di delegare alla gpu solo alcune operazioni, per tenere tutte le features già implementate e velocizzare una parte dei calcoli, i primi a mostrare qualcosa sono stati quelli di indigo, ma una cosa del genere (anche se con hw specializzato) la stanno svilupando quelli di cebas e splutterfish p.s. la beta di shot dovrebbe essere imminente, a quanto dicono hanno ancora 3 "known issues" che vogliono risolvere prima e poi inizierà la beta
  13. dagon

    Ctrl.irradiance Con Max2011

    puoi usare il "color override / ray type switcher"
  14. ecco appunto l'highlight only è un altra ottimizzazione, quindi non ottieni l'effetto corretto, ma un'approsimazione che ci si avvicina, è tutta una questione di compromessi, secondo me col progressive si riescono a fare meno compromessi e ottenere cmq una qualità migliore, ma soprattutto si fa meno fatica con prove e controprove in scene come la tua ad esempio basta usare max samples a 200 e error threashold abbastanza basso e vedrai che con poco tempo in più (quando raggiunge un certo numero di samples le passate le fa anche a 1/2 secondi a frame) ottieni un'immagine perfettamente pulita per non parlare poi degli effetti in più che puoi aggiungere senza avere degli effetti eccessivi sui tempi di rendering (vedi dof) cmq posso dirti che stanno lavorando su tutti i difetti in questione, la direzione è questa, nelle prossime versioni tutto sarà molto più preciso e più semplice
  15. manca un test con l'adaptive AA e i valori di samples che eventualmente avresti usato con questo tipo di AA, per me la versione con 8 sample per i materiali è il giusto compromesso, infatti se non sbaglio avevo suggerito di tenere a 4 i sample per i materiali con meno glossy e 8 per quelli più glossy mentre la differenza dei samples delle area light secondo me è abbastanza trascurabile, volendo puoi modificare l'ihighlight balance dei mia_material se proprio vuoi correggere le perdite
×