Ese
Visualizzazione Stampabile
Ese
specialmente quelli da gaming :asd:Citazione:
Originariamente Scritto da freddye78
Non so se é rimasto qualcosa nel campo workstation, ma mi pare che anche li il design moderno ormai sia giunto anche li.
E ringrazia il cielo che devi solo togliere il guscio posteriore. Qualche design particolarmente avanzato richiede di togliere proprio la scheda madre perché la roba da cambiare é installata SOPRA la scheda madre :rotfl:
Installa questo e poi vedi https://www.digitalcombatsimulator.com/it/Citazione:
Originariamente Scritto da Picard
Appena provato con bright memory, maxato con rtx, tutto spettacoloso, framerate rock solid
Ieri provato con forza horizon 5, anche qui tutto maxato, non fa una piega, framerate solidissimo, praticamente non avverto differenza rispetto al desktop.
Godo, mi è costato ma la soddisfazione è grande :rullezza:
ora sono indeciso se cimentarmi con l'installazione del secondo nvme da 1tb o lasciare perdere e tenermi solo quello da 500gb, tutte quelle vitine a chiudere la copertura mi fanno paura :tremo:
Mi mangio le mani a non aver speso quei 15 euro in più mettendolo direttamente nella configurazione,ma ero convinto che, essendo un laptop configurabile ed espandibile, fosse progettato per rendere una stupidaggine aprirlo per fare i vari upgrade.
Le vitine non sono un gran problema alla fine, almeno se il tuo è un modello standard. La cosa a cui devi stare attento è che non ti cada nessuna vitina sulle scheda madre… io ci ho fuso un portatile così. :bua:
Controlla nel bios se c’è una modalità “service”. Praticamente quello che fa questa opzione è staccare la batteria, di modo che non corri rischi se appunto devi aprire il laptop. Poi la riattacca automaticamente alla riaccensione. Non ce l’hanno tutti i portatili però
A me tocca stasera aprire il laptop per cambio ram (2x16gb) e secondo ssd nvme 970 evo plus da 2TB presoCitazione:
Originariamente Scritto da freddye78
per questo bisogna staccare la batteriaCitazione:
Originariamente Scritto da Dadocoso
beh si... l'ho scoperto, ora lo so, non preoccuparti :asd:Citazione:
Originariamente Scritto da magen1
La cosa "simpatica" é che l'avró aperto 300 volte per cambiare dischi, pasta termica, batteria o altre cose. Tutto ok. Poi ho preso il fisso, dovevo prendere l'ssd per i dati del laptop nel fisso, e questa é stata l'operazione del patatrack :bua:
Comunque a mio credito, sono riuscito a risaldare la motherboard, aggirando il circuito bruciato. Ho anche riportato le mie gesta qui sul forum :snob:
ottimo:smugranking:
a me invece si fuse un Vaio.
aveva la plastica cotta, un giorno il dado di blocco della vite dell'HDD si stacca e si deposita da qualche parte, dopo averlo spostato e acceso inizio a sentire rumori interni, credo sia finito nella ventola di raffreddamento che lo sparava a destra e sinistra facendolo rimbalzare sulla mobo, poi puff, spento e mai più riacceso.
lo smontai pezzo per pezzo in cerca di un segno visivo ma nulla :\.
Le vostre storie mi stanno terrorizzando, no lascio perdere :tremo:
no il mio era spento... lo mossi da un tavolo a un altro e una maledetta vite mi era caduta sulla mobo. Durante il trasporto si é mossa la vite, l'ho vista muoversi e poi ho visto un puff di fumo bianco :bua:Citazione:
Originariamente Scritto da magen1
Quindi comunque sapevo dov'era il punto dove si é bruciato il circuito. Ho provato a bypassare il circuito in questione cercando i condensatori giusti con un multimetro (saldare direttamente il circuito era impossibile) e ci ho saldato un cavetto elettrico. Li per li non ha funzionato una mazza, esattamente come mi aspettavo. Invece dopo un mesetto o giú di li, ho riprovato per sfizio e tac... si é acceso :bua: Funziona ancora a distanza di piú di un anno, anche se a batteria si spenge quando lo metto un po' sotto torchio, ma quello lo faceva giá prima.
facebook mi ha segnalato la pubblicità di questo sito https://superrendersfarm.com/
https://scontent.frmi1-2.fna.fbcdn.n..._A&oe=61EF1A65
non pensavo che ci fossero siti/aziende che vendessero il rendering online/in cloud :uhm:
ora, non ci capisco niente di niente, ma hanno un qualche vantaggio rispetto al comprarsi un pc proprio per farsi questi calcoli/lavori? :uhm:
i prezzi come sono? :uhm:
poi, nello specifico, come mai vendono separatamente la cpu o la gpu per il rendering? :uhm:
vabè che una 1080Ti può sembrare meh magari per questo lavoro :uhm:
il vantaggio é che a seconda di quello che devi renderizzare anche su una 3090 ti ci vogliono 3 mesi, invece qui paghi, che so... 1000, 2000 euro e ce l'hai in 3 ore. Il costo di comprarsi l'hw necessario a renderizzare in 2 ore te lo lascio immaginare.Citazione:
Originariamente Scritto da Bicio
bè ma per renderizzare cose non le devi anche caricare? :uhm: cioè boh, vedendo il peso dei giochi di oggi tipo, dovrai caricare giga di modelli grafici sulla macchina :uhm: o forse li disegni direttamente in cloud e sul tuo pc tieni poco e niente? :uhm:
poi puoi davvero aumentare la potenza di calcolo così "all'infinito"? :uhm:
Prepari il render sulla tua macchina e lo invii al server cloud. Sono giga di roba e il tempo di invio va ovviamente ad aggiungersi al tempo di render, e ovviamente lo paghi.Citazione:
Originariamente Scritto da Bicio
All'inizio era la soluzione che usavo, ma è diventata lenta e terribilmente poco efficiente con caricamenti che saltavano dopo decine di minuti di upload. Ho preferito comprare un PC serio con Iray server sopra. Anche perché spesso usano schede Quadro che, nel mio caso specifico rendono meno delle Geforce
ma ti sei fatto anche una botta di conti per rapportare le due soluzioni? :uhm:
cioè chessò, un pc di fascia boh alta come quello che hai ora con RTX e i9 costa tot soldi che equivalgono a tot ore di affitto di una macchina in cloud :sisi:
perchè adesso i costi HW sono schizzati alle stelle, però tipo un pc come il tuo dovrebbe costare sui boh 3/4mila euro che corrispondono, a veder tipo i prezzi così su quel sito, a 280 giorni di rendering (6720 ore) che equivalgono a 810 giorni lavorativi da 8 ore, quindi vuol dire che in 3 anni ripaghi il costo della macchina invece di lavorare in cloud :uhm:
numeri spannometrici che magari ho scazzato, anche perchè poi tocca aggiungere anche il costo di un pc per fare parte del lavoro, corrente elettrica blabla :sisi:
cioè è per capire se, sbatti e disservizi a parte, conviene realmente andare in cloud o comprarsi un pc "degno" direttamente :uhm:
Bicio, anche con la fibra, in quel modo, costi o meno, facevo 40/50 render al mese. Col rischio, raro ma presente, di doverne rifare alcuni perché il risultato finale faceva pietà, e spendendo circa 100 dollari al mese.
Adesso ne faccio anche 400 al mese, e posso permettermi di rilasciare prodotti migliori. Ci guadagno non solo economicamente, ma anche di immagine con i clienti e in tempo, oltre che poter sperimentare più soluzioni diverse. E alla fine è un costo che si ripaga da solo
Quindi in linea di massima conviene farsi un pc per queste cose che appoggiarsi a servizi esterni :uhm:
Poi come dici, dipende anche dalla mole di lavoro.. Una cosa è renderizzare così saltuariamente, un altra è farla costantemente :sisi:
Ma davvero è possibile comprare potenza di calcolo all'infinito così da abbattere nettamente i tempi? :uhm:
Cioè boh, passare da un qualche ora di tempo a qualche minuto comprando un botto di potenza? :uhm:
Pensavo che più di tot non si potesse, anche perché implicherebbe far lavorare in parallelo un botto di macchine che non so se c'è un limite a quante macchine in parallelo si possano mettere per svolgere un determinato lavoro / software ecc :uhm:
no, dipende da cosa devi fare. Per i render che faccio io, e immagino anche Picard, un pc di fascia alta é probabilmente la soluzione piú conveniente, in quanto bene o male mi permette di renderizzare le animazioni che faccio nel giro di qualche giorno, facendo macinare il computer di notte, non ho problemi di upload e rientro del costo unico del pc rispetto a quelli della render farm prima o poi.
Dall'altra parte peró ci sono render che su un computer locale non ce la fai a renderizzare. Potrebbero essere render enormi che non entrano nei 24gb della 3090 (giá successo), potrebbero essere animazioni talmente complesse che magari anche sulla 3090 ti ci vogliono 10-15 minuti a frame e magari devi renderizzare 2000 frames e non hai 20 giorni di tempo per tenere il computer a renderizzare 24h al giorno.
In questi casi la render farm, malgrado i suoi limiti, diventa indispensabile.
Oggigiorno si, puoi aumentare la potenza di calcolo pressoché all'infinto. Inoltre secondo me ci sono anche soluzioni migliori delle render farm, che peró richiedono un po' piú di setup manuale: il cloud.
Ad esempio su google cloud o amazon o microsoft azure puoi tenere tutto sul cloud, di modo che praticamente aggiri i problemi di upload, perché di fatto hai tutti i tuoi progetti giá nel cloud. Certo, devi fare l'upload volta volta, ma io lo faccio giá su dropbox quotidianamente e con una buona linea non é assolutamente un problema, specialmente perché non é che uppi 90gb alla volta, ma pochi gb ogni giorno. In questo modo quando devi fare il render é giá tutto li, e decidi quanti computer lanciare all'unisono. Paghi un tot a computer all'ora a seconda della potenza del computer, renderizzi e via. Il render poi ti appare nel tuo cloud. Il cloud puó essere sincronizzato con il tuo disco locale, quindi la cosa é abbastanza seamless.
Io avevo messo su un setup del genere con azure, e ho renderizzato anche con 100 computer una volta. Pagato mi pare 60 dollari australiani per un paio d'ore di render. Peró non avevo messo su tutto il discorso del cloud, é un pó piú complesso, almeno per me.
Insomma, non c'é una soluzione migliore, dipende dalle tue esigenze.
Nota finale: oggi ti puoi anche fare una workstation in cloud. L'idea é di avere solo un computer di qualsiasi tipo (potrebbe essere anche un chromebook) che ti fa da client e te ti colleghi a una workstation in cloud, che ha giá tutto lo storage in cloud. Non devi preoccuparti di hw difettoso, upgrade e via dicendo. Per me é un po' troppo presto ancora, ma é una figata e credo sia il futuro :sisi:
Interessante :uhm: è proprio un mondo a parte :sisi:
Ora faccio una domanda ancor più da ignorante. Siccome non so nulla di programmazione ecc, quando parlate di renderizzare mi viene in mente tipo un'ambientazione con dei personaggi da mondo di gioco in 3D come ormai siamo abituati da tempo :sisi:
Abbiamo quindi videogiochi con motori grafici che renderizzano il tutto in una manciata di secondi.
Che differenza c'è tra questa renderizzazione e la vostra, visto che anche ad esempio picard fa videogiochi? :uhm:
Ignorantemente appunto, vedo una differenza abissale di tempo e potenza di calcolo e mi sfugge completamente la differenza visto che forse irroneamente si usa lo stesso termine "renderizzare" su dui lavori che paiono diversi però :uhm:
I videogiochi non fanno un render istantaneo, sono già pre-renderizzati sia gli ambienti che i personaggi. I 100 e passa giga di ogni gioco altro non sono, le linee di codice, anche di un GTA V, non peseranno più di qualche megabyte a esagerare.Citazione:
Originariamente Scritto da Bicio
Inoltre io non faccio animazioni (se non roba molto blanda a 24 fps), le Visual Novel mi permettono di fare render a singolo frame in pochi minuti (con la 3090, un'oretta con la 1080ti, un paio di ore con la render farm compreso il costo di upload che spesso dava tra l'altro errore e mi costringeva a star dietro a ogni singola immagine, invece di fare altre cose nel mentre).
Su dropbox carico tutti gli asset volta volta, Dio benedica la fibra, perché quando ho iniziato questo lavoro con l'ADSL ci voleva anche una giornata a fare un aggiornamento su Steam, cosa che ora riesco a fare in pochi minuti, anche di roba complessa.
sono sistemi diversi, e la diversitá sta fondamentalmente nell'accuratezza dei calcoli dell'illuminazione.
Ci sono i motori di render offline, che sono piú accurati e piú lenti, e i motori di render in real-time, che sono quelli dei videogiochi che devono renderizzare circa 60 frames al secondo o piú.
Avrai sentito parlare di path tracing (o ray tracing) forse, che é una tecnica di calcolo della luce, riflessi e via dicendo molto accurata, ma che é piú lenta. Viene usata nei motori offline. Esempi arnold, vray, cycles, corona render, iray, renderman etc etc.
I motori real time si basano invece sul raster, un'altra tecnica che é molto piú approssimata ma veloce. Esempi Unreal engine, unity, qualsiasi altro motore di videgiochi proprietario.
C'é da dire che ultimamente il path tracing sta facendo passi da gigante in termini di velocitá di calcolo, e infatti iniziano ad esserci i primi motori path tracing in real time, come si é visto nell'unreal engine... fondamentalmente l'RTX, real time ray tracing e via dicendo. Hanno ancora molte limitazioni e compromessi, ma in alcune situazioni i giochi iniziano ad avvicinarsi molto a dei render offline.
Comunque al momento quando spingi motori di render offline al limite, ci vuole ancora molto tempo. Fai conto che anche Luca, l'ultimo film pixar, ha delle scene che impiegano 50 ore (si 50 ore) per frame per renderizzare. Ovviamente si parla della pixar, quindi esempio limite e senza compromessi, peró capisci bene che un computer con una 3090 non é sempre sufficiente :asd:
No no aspetta, non mi torna. Ogni volta che faccio qualcosa in Unity lo devo pre-renderizzare e pacchettizzare, cosa che impiega poco o molto a seconda. Se mi dici delle luci e degli effetti ok, ma i fondali e i personaggi non sono prerenderizzati? Mi smonti una certezza!Citazione:
Originariamente Scritto da Dadocoso
Premetto che non sono un esperto di motori real time.Citazione:
Originariamente Scritto da Picard
Ci sono 2 cose che credo vadano pre calcolate: shaders e illuminazione.
La prima credo non si scappi. La natura di questi motori é che gli shader vanno precompilati, e a seconda della scena ci vuole un po'. Mi pare sia cosí tutt'ora.
Per quanto riguarda l'illuminazione, dipende. C'é l'illuminazione senza GI (global illumination) che é sempre stata real time. Tuttavia prima, se volevi la GI in un gioco dovevi fare il baking, appunto, della GI. Quindi praticamente facevi fare un render offline in background al motore di gioco, e questo creava della textures (le light map) che messe sopra le altre textures degli oggetti, ti faceva venire fuori la GI.
PRO di questo sistema: molto leggero, solo lo spazio delle light maps nella GI
CONTRO: devi fare il baking prima e, soprattutto, é statico. Quindi la GI non reagisce a niente durante il gioco.
Oggi peró c'é il real time raytracing. So che la gente dice che non serve a un cazzo, ma a mio avviso si sbagliano. Quello che ti permette di fare il real time ray tracing é di saltare a piú pari la parte di baking della GI, ma soprattutto di averla in real time. Il che vuol dire che puoi modificare l'illuminazione, la posizione degli oggetti, di sorgenti luminose e via dicendo, e la scena si aggiorna in tempo reale.
É un vero e proprio game changer, sia dal punto di vista dello sviluppo, sia da quello delle possibilitá da parte dell'utente finale.
Con una 3090, direi che cercherei di cambiare il mio workflow sfruttando il real time raytracing, decisamente :asd:
Poi ovvio, se il tuo gioco deve girare in real time devi tenere conto dell'hardware della gente che vuole giocare al tuo gioco. Peró se magari devi fare delle sequenze pre-renderizzate che vengono fuori dal motore di gioco, non ci penserei due volte :nono:
Rileggendo ora il tuo messaggio, parli di fondali e personaggi prenderizzati :uhm: Beh direi che dipende, non c'é una regola qui. Nella maggior parte dei giochi, ad esempio un qualsiasi open world tipo the witcher o cyberpunk o skyrim, non c'é niente di pre-renderizzato.
Peró magari se prendi altri titoli, magari un platform a scorrimento, in quel caso si, magari il fondale lo fanno pre-renderizzato perché tanto é solo un orpello visuale, non deve essere "vero". Non so se ho capito bene la domanda peró :uhm:
Infine, discorso di "pacchettizzare" il gioco... beh si, quando crei l'eseguibile lui impacchetta tutto. Peró quando l'utente lancia l'eseguibile, la grafica viene calcolata in real time dal suo computer. Torno all'esempio di the witcher: quando hanno creato l'eseguibile, sicuramente ci vuole un bel po' di tempo a impacchettare tutto. Peró quando io lancio the witcher, ogni singolo frame é calcolato in real time dalla mia scheda grafica e dal mio processore, non c'é niente di pre-renderizzato (tolte forse alcune parti dell'illuminazione, come dicevo prima, visto che non c'é l'rtx li).
Ora allora faccio una domanda ancora da più ignorante che è un passo indietro.
Cosa vuol dire "renderizzare"? :uhm:
Fin'ora ho pensato che volesse dire mettere insieme una serie di poligoni con sopra delle textures per creare cose :uhm:
Quindi chessó, renderizzare un personaggio vuol dire assemblare il tutto per aver poi un modello in 3d che può essere più o meno definito in base a come si è deciso di costruirlo :sisi:
Perché poi qua ne segue la domanda di riflesso : come si fa a passare da ore ed enorme potenza di calcolo per renderizzare, ad una manciata di secondi poi in un videogioco? :uhm:
Perché appunto, sempre ignorantente, sempre rendering è, e si passa da tanto lavoro a qualcosa di molto semplice :uhm:
Che sia perché poi si creano delle istruzioni di "assemblaggio" dove il gioco non si deve inventare niente e sa già come costruire ogni cosa e quindi fa prima rispetto al lavorare in grezzo per tentativi migliorando e cambiando il tutto ogni volta col motore che appunto deve rifarsi tutti i calcoli da capo? :uhm:
la definizione di renderizzare, credo si possa riassumere in due parti:
1. é il processo attraverso il quale converti un ambiente tridimensionale in un'immagine bidimensionale.
2. durante questo processo, avvengono i calcoli dell'illuminazione. Si prendono i dati immessi nella scena 3d (principalmente geometria, sorgenti luminose, materiali) e in base a questi dati l'algoritmo calcola il colore risultante per ogni pixel. Nel caso del path tracing, dalla camera vengono "sparati" un sacco di raggi che rappresentano la luce. Questi rimbalzano sulla geometria e se poi incontrano la sorgente luminosa, viene calcolato cosa succede su quella geometria. Quindi si prendono i dati del materiale (riflessivitá, rifrazione, scattering, bump e via dicendo), i dati della luce (intensitá, grandezza, colore) e si calcola il valore dei colori per quel pixel. E via dicendo.
Nel caso di un motore in real time, questi calcoli vengono semplificati enormemente (e in molti casi, si vede). Questo é il motivo delle differenze di velocitá di calcolo. Non sono uno sviluppatore di motori di render, quindi non so darti piú info di questo. Come dicevo prima comunque, la potenza odierna delle gpu sta rendendo possibile accorciare enormemente i tempi del path tracing, tanto da rendere una versione semplificata di questo, possibile in real time. Questo non vuol dire che l'accuratezza sará la stessa di un render di Luca della pixar, peró la forbice si sta riducendo molto.
Probabilmente é anche il classico caso dove per ottenere quel 10% di qualitá finale, devi impiegare il 90% di risorse in piú. Quindi magari dal punto di vista visuale la differenza é molto piú piccola che dal punto di vista dei calcoli necessari per avere questa piccola differenza, ma questa é solo una mia ipotesi. Comunque io credo che nel giro di 10 anni avremo grossomodo tutti i motori in real time, o quasi.
Quindi la renderizzazione é un po' l'ultimo stadio del processo 3d. Quando fai un personaggio ci sono altri stadi: modellazione, texturing, shading, grooming (per i capelli ad esempio), rigging (per prepararlo all'animazione). Nel caso tu dovessi creare delle immagini per far vedere il personaggio nella sua forma finale, faresti un render :sisi:
A quindi è la trasformazione da 3D a 2D :pippotto: pensavo che fosse la realizzazione in 3D :asd:
Poi a leggerti, sottolini molto che il peso maggiore sia tutto sulle luci e come esse impattano sulla scena, pensavo che il peso maggiore fosse nel tendering in 3D dei modelli (magari dovuto al fatto che sono molto dettagliati), non pensavo che il peso maggiore fosse nelle luci :uhm:
Quindi seguendo questa cosa che mi dici, la mera realizzazione in 3D di cose, è un calcolo molto più leggero e sbrigativo :uhm: il discorso cambia nettamente quando ci metti l'illuminazione, soprattutto se "dinamica" :uhm:
Seguendo il ray tracing, che calcola in tempo reale le varie luci e rifrazioni, ad oggi è un mattone assurdo di calcolo nei videogiochi per una resa che si nota poco o niente.. Quindi capisco il fatto che la luce pesi un botto nella rappresentazione dell'immagine :sisi:
poi sicuramente finirà come ricordo la fisica, che all'inizio ci voleva una scheda a parte e ora viene calcolata senza problemi dalle schede grafiche :sisi:
anche i poligoni contano, ma appunto qui dipende dal tipo di motore.Citazione:
Originariamente Scritto da Bicio
In un motore offline i poligoni hanno un impatto pressoché nullo sul tempo di render. Una volta che sei riuscito a caricare tutto nella ram, basta, le differenze nei tempi di calcolo sono irrisorie.
Per quelli in tempo reale cambia, anche se le tecniche moderne stanno aggirando anche questo, vedi tecnologie come nanite in UE5, che permettono di renderizzare miliardi di poligoni in tempo reale.
Si, direi che l'illuminazione, riflessi e rifrazioni (accurati) al momento é la cosa piú complessa da calcolare :sisi:
Quindi insomma è la realizzazione della scena in modo "realistico" :uhm:
Siamo arrivati quindi al punto, che, almeno per i modelli in 3D e il loro più o meno fotorealismo, è diventato un peso minore del tutto, quando ad esempio diversi anni fa erano il peso maggiore della rappresentazione in 3D di un videogioco :uhm:
Ne approfitto pure io per spiegare alcune cose.
Il motivo per cui riusciamo a passare da ore di rendering a svariati millisecondi per i videogiochi è perché, nel secondo caso, non facciamo altro che simulare il risultato evitando di calcolare il processo reale. Tutte le tecniche che utilizziamo nei videogiochi non sono altro che semplificazioni estreme di cose decisamente più complicate.
Il punto dell'rtx, ad esempio, non è quello di simularti i riflessi vari, ma quello di calcolare realmente i processi fisici della luce. Il risultato a volte sembra avere poca differenza tra on e off a seconda del gioco ma, in realtà, hai la "sicurezza" (se ben implementato) che quella sia la scena illuminata come dovrebbe essere realmente. Questo comporta anche una certa facilità per gli sviluppatori nella creazione di un ambiente, dato che puoi letteralmente associare un materiale e regolare un paio di parametri sapendo che il risultato finale sarà parecchio affidabile.
Capisci bene che se la luce è tutto per la realizzazione di un buon ambiente, se proprio quell'elemento è "finto" e calcolato male, resterai sempre trattenuto nell'avanzamento grafico che verrà negli anni.
Ti faccio 3 esempi.
SSR (Screen Space Reflections): se hai giocato a destiny 2 (il primo che mi è venuto in mente), sulla terra ci sono spesso grandi corpi d'acqua, tra laghi e mari. Spesso, sulle lunghe distanze, alla fine trovi pure dei monti, delle colline e così via dicendo. Quei monti vengono riflessi nell'acqua solo se stanno all'interno della tua inquadratura. Abbassa la telecamera e vedrai quel riflesso venire meno man a mano che la tiri giù :asd:
Quake 3: ok, qui andiamo troppo indietro, ma è un esempio abbastanza calzante. Nel source code di Q3 c'è una linea legata ad alcuni effetti di luce con un commento tipo "Non ho idea di perché con questo valore funzioni, non so neanche io che cazzo ho scritto, però funziona e lo lasciamo così". Questo per darti l'esempio di approssimazione che abbiamo :asd:
MGS2: tutti i corridoio hanno riflessi qua e la, pure nei pavimenti. In realtà i pavimenti in questione hanno una bassa opacità e sotto hai i doppioni che seguono i movimenti :asd:
Hai visto cosa hanno fatto con l'ultima versione di metro exodus? La prima versione non era in grado di calcolare la global illumination, quindi oltre a mancare lo spill della luce, le stanze non avevano una vera diffusione della luce che entrava da porte e finestre. Adesso puoi simulare realmente il comportamento della luce, senza dover ricorrere a mezzi vari ed imprecisi. La stessa cosa vale per la velocità dello sviluppo, come spiegava dadocoso :sisi:
Il motivo per cui l'rtx è così gamechanger è proprio questo. Abbiamo utilizzato soluzioni alternative varie che fanno il loro lavoro ad una prima occhiata ma, se ti soffermassi un attimo a guardare nei vari giochi, spesso e volentieri noteresti come certe cose non hanno un cazzo di senso. Con l'rtx implementato nella sua interezza invece si :sisi:
bè si sicuramente, almeno a parole, il fatto che alcune cose possano sempre essere più calcolate sul momento, da più spazio a concentrarsi su altro, lasciando poi che, chessò, gli effetti atmosferici se lo smazzoli in game in tempo reale il gioco visto che hai un bel pò di potenza di calcolo :sisi:
esattamente :sisi:
in futuro ci saranno sicuramente altre cose in grado di mettere in ginocchio le schede future. Nella prossima generazione mi aspetto una buona simulazione dei corpi morbidi in tempo reale, con tanto di simulazione dei tessuti ecc :snob:
alcune sembrano davvero vere :sisi:
maxwell credevo fosse sparito dalla circolazione. Si é il motore che piú punta sull'accuratezza totale degli algoritmi, peró come hai detto é lento. Io ho l'impressione che negli ultimi anni abbia perso molto interesse, visto che il resto dei motori é in grado di riprodurre roba molto vicina quanto a realismo, credo ormai indistinguibile ad occhio nudo. Il grosso lo fa l'artista, infatti a mio avviso diversi render sono un po' meh in quella gallary.Citazione:
Originariamente Scritto da Lux !
Dall'altra parte la concorrenza offre molta piú flessibilitá artistica e sono piú veloci.