Vai al contenuto

cecofuli

Members
  • Portfolio

    Portfolio
  • Numero messaggi

    10961
  • Registrato

  • Ultima Visita

  • Days Won

    14

cecofuli last won the day on May 5

cecofuli had the most liked content!

1 che ti segue

Info su cecofuli

  • Rango
    treddizzofrenico

Informazioni professionali

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

Ospiti che hanno visualizzato il profilo

23947 lo hanno visualizzato
  1. cecofuli

    V-Ray vs Corona

    Novità che potrebbero essere inserite nelle prossime versioni di Corona (*) Easy Caustics (on-off button). Nessun parametro da settare. (*) New Light Solver ( fino a 6 volte più veloce) (*) Architectural sketches (Toon Shader) (*) CoronaScatter PRO, plug-in separato che potrà essere utilizzato con V-Ray e, per chi lo vorrà, anche per altri motori. Infatti rilasceranno l'SDK. Sarà da comprare e chi ha già acquistato Corona avrà uno sconto. Il vecchio CoronaScatter rimarrà così com'è e riceverà solamente bug-fix. (*) Corona for ArchiCAD (*) Aprire file .max creati con Corona all'interno di C4D e viceversa
  2. cecofuli

    V-Ray vs Corona

    Nuovo strumento, fresco fresco di giornata: CoronaVolumeGrid
  3. cecofuli

    V-Ray vs Corona

    3D-mappable volumetric objects
  4. cecofuli

    Alcune considerazioni su V-Ray RT

    Bisogna capire se il terzo posto di VRay-RT (GPU immagino) è inteso come strumento di lavoro (tipo l'IR di Corona) o se effettivamente lo utilizzano per rendering/frames finali. Comunque, è molto interessante il secondo posto di Corona con il 30%. Una software con alle spalle solo 5 anni di sviluppo ha scavalcato "mostri" come Maxwell (4%??? O_O ) , Octane (5%) e MantalRay (7%). E ancora, un 30% sta testando Corona (immagino per capirne le potenzità). Infine, UE4 sta rosicchiando spazio. Ma UE4, Unity e Twinmotion dovrebbero essere messi in una classifica a parte. Perché un conto sono motori per rendering offline di elevata qualità, altri sono i software in real-time. Non credo che li utilizzino per cinematiche, pubblicità video o cataloghi. Lumion e Enscape, invece, fanno parte di un'altra categoria.
  5. cecofuli

    Alcune considerazioni su V-Ray RT

    picojoule/op? No no, non sono così "avanti"... io in ufficio utilizzo, spesso, un semplice wattometro per capire quanto consumano i vari nodi. Comunque, non è raro vedere bollette di oltre 1.500 euro/mese per chi usa renderfam fatte da GPU. Diciamo che le CPU sono più "tranquille" con i consumi. Nel calcolo costo/prestazioni tra GPU e CPU, spesso si dimenticano anche i costi di gestione. Anche se Juray (Corona forum) ha detto che il suo ultimo i9 18 core delighted (OC +-5 GHz) consuma 700 Watt ! Cioè, quasi tre volte il mio sistema. Vero anche che "viaggia" 6-7 volte più veloce di un i7 970 (00:40min vs 4:30min) Quindi, a parità di corrente consumata, l'i9 è più efficiente ( e ci credo... stiamo parlando di 2011 vs 2018)
  6. cecofuli

    Alcune considerazioni su V-Ray RT

    "A livello di rapporto costo/prestazioni vince la GPU." mmm ne sei così sicuro? Hai messo in conto anche il consumo di energia? Mettere in un PC 4 1080Ti e farle andare in full load consuma un fottio di corrente, per non parlare del rumore e calore prodotto. Ora, bisognerebbe tenere in conto anche questo fattore. Mi spiego. Mettiamo che tu hai un dual Xeon che produce un rendering in 60 minuti consumando1Kwh. Ora, poniamo il caso, invece, che le tue 4 GPU hanno prodotto lo stesso risultato in 30 minuti. Pero controlla il loro consumo. Magari hanno consumato 3 KWh. Inoltre produrranno molto più calore che dovrai dissipare (magari accendendo un condizionatore). Inoltre fanno molto rumore ( a meno di non metterle a liquido) Questi sono numeri presi a caso, ma è risaputo che le GPU consumano molto, ma molto di più.
  7. cecofuli

    Annunciata la prima Beta di Corona Renderer per Cinema 4D

    Brevemente, hanno cercato davvero bravi programmatori che volessero volare a Praga per lavorare allo sviluppo di Corona4Sketchup. E' stata una lunga ricerca e non ha portato risultati concreti. Inoltre, VRay4Sketchup è davvero ottimo e, anche utilizzando un paio di programmatori per sviluppare Corona4Sketchup, ci sarebbero voluto anni per raggiungere anche solo la metà dello sviluppo che ha VRay. In conclusione, economicamente parlando, per la Render Legion non ha più interesse. Si stanno dedicando, inoltre, ad altri progetti che sono sotto NDA. Personalmente mi dispiace, perché, anche solo a livello d'immagine, avrebbe giovato alla Render Legion lo sviluppo di una versione, anche "light" di Corona4Sketchup. Ad alti livelli, V-Ray è inattaccabile, attualmente, da Corona. Ma mi pare ovvio. 20 anni di sviluppo contro 5 vincono facile ;). A livello prosumer (piccoli-medi studi di grafica, advertising, publishing, arch-viz, design), diciamo che siamo ben oltre il 10% e, dopo V-Ray, al secondo posto c'è Corona. Sento sempre più gente, attorno a me, che ha abbandonato VRay a favore di Corona.
  8. cecofuli

    V-Ray vs Corona

    (4000/640)*(3000/480) 6.25*6.25=39.0625
  9. cecofuli

    V-Ray vs Corona

    Ma tu non devi fare nessun calcolo =) Se NL=3.5% è ok per te, tu imposta la risoluzione che vuoi e sarà Corona che deciderà il tempo di "cottura" necessario. Dopo i primi 5 Passes (Adaptivity recal=5 di default), Corona ti dirà quanto tempo ci vorrà per far si che raggiunga il NL che hai impostato. Se a 640x480 il NL=3.5% lo hai raggiunto, che ne so, in 10 minuti, significa che a 4000x3000 avrai lo stesso NL in, circa: 39 volte * 10 minuti = 6:30 ore. Perchè 39? Perchè nella risoluzione di 4000x3000 "ci stanno" 39 rendering dalla risoluzione 640x480. (*) GI vs AA lo devi abbassare (anche fino a 2) solo se hai un forte DOF. (*) LSM lo devi alzare (4-6) quando vedi noise nelle areashadows (tipo quando hai un ambiente interno molto grande, aperture piccole e vedi che i Portals creano molto noise nella luce diretta). Ma ti consiglio di lasciare quelli di default. Nel "classici interni" GIvsAA=16 e LSM =2 vanno più bene
  10. cecofuli

    V-Ray vs Corona

    Beh, mi pare ovvio. Aumentando la risoluzione, aumenti il numero di pixel che Corona deve elaborare. Quindi, 1 Pass ci impiegherà di più per essere generato. Tutto è abbastanza lineare. Al raddoppio della risoluzione del rendering, per ottenere gli stessi Pass, il tempo di rendering quadruplicherà 320 x 240 = 1 pass in 5 secondi 640 x 480 = 1 pass in 20 secondi 1280 x 960 = 1 pass in 1:20 minuti 2560 x 1920 = 1 pass in 5:20 minuti 5120 x 3840 = 1 pass in 21:20 minuti Ho fatto un test reale: 320 x 240 = 5 pass in 4 secondi 640 x 480 = 5 pass in 16 secondi 1280 x 960 = 5 pass in 59 secondi Come vedi, più o meno, ci siamo.
  11. cecofuli

    V-Ray vs Corona

    SI, vero. E' colpa mia. Avevo installato la vecchia Corona Toolbar e ha fatto un po' di "casini". L'ho cancellata, riavviato 3ds Max e, ora, è tornata normale. Onestamente, non mi piacciono per nulla le icone tutte dello stesso colore. Speriamo le cambino
  12. cecofuli

    V-Ray vs Corona

    Si, il DrServer.exe fa tutto da solo. Se vede che gli manca una texture, la preleva lui. Toolbar per Corona v2.0 ufficiale
  13. cecofuli

    V-Ray vs Corona

    Q1 2018, ovvero entro fine marzo. Ma, vedendo le passate release, immagino che non la vedremo prima di Aprile. Dipende da cosa ci vogliono mettere dentro e da quanto sarà lungo il processo di testing.
  14. cecofuli

    V-Ray vs Corona

    Sempre nella 2.0, hanno migliorato l'adaptivity oversampling nelle zone più scure . Il risultato è una netta riduzione del noise. --- LINK ---
  15. cecofuli

    V-Ray vs Corona

    In V-Ray c'è l'opzione noise threshold (default, è 0.005) che, però, lavora in simbiosi con Max subdivs. Mentre in Corona abbiamo un valore espresso in %. Credo che sia difficile trovare una corretta corrispondenza. Per metterli a confronto credo che l'unico modo sia quello di far cuocere i due rendering, per esempio, per 10 minuti e vedere "a occhio" il risultato migliore. Comunque, in Corona 2.0 hanno migliorato l'algoritmo di denoise nel bump. Come dici tu, Corona "mangiava" troppi dettagli in quel canale. --- LINK --- Inoltre prova a giocare con i parametri: (*) Denoise radius - controlla il raggio di azione del denoise. (*) Denoising texture blurs - permette di intervenire sulla quantità di denoise applicata alle sole textures. Questi due parametri, però, necessitano di un ricalcolo del denoise e non funzionano il real time come avviene, invece, con il Denoise amount.
×