GTX 3090 e Intel i9

[Bicio]

Interessante è proprio un mondo a parte

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

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?

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ò

[Picard]

Interessante è proprio un mondo a parte

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

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?

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ò

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.

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.

[Dadocoso]

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

[Picard]

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

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!

[Dadocoso]

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!

Premetto che non sono un esperto di motori real time.

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

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

Rileggendo ora il tuo messaggio, parli di fondali e personaggi prenderizzati 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ó

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).

[Bicio]

Ora allora faccio una domanda ancora da più ignorante che è un passo indietro.

Cosa vuol dire "renderizzare"?

Fin'ora ho pensato che volesse dire mettere insieme una serie di poligoni con sopra delle textures per creare cose

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

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?

Perché appunto, sempre ignorantente, sempre rendering è, e si passa da tanto lavoro a qualcosa di molto semplice

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?

[Dadocoso]

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

[Bicio]

A quindi è la trasformazione da 3D a 2D pensavo che fosse la realizzazione in 3D

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

Quindi seguendo questa cosa che mi dici, la mera realizzazione in 3D di cose, è un calcolo molto più leggero e sbrigativo il discorso cambia nettamente quando ci metti l'illuminazione, soprattutto se "dinamica"

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
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

[Dadocoso]

A quindi è la trasformazione da 3D a 2D pensavo che fosse la realizzazione in 3D

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

Quindi seguendo questa cosa che mi dici, la mera realizzazione in 3D di cose, è un calcolo molto più leggero e sbrigativo il discorso cambia nettamente quando ci metti l'illuminazione, soprattutto se "dinamica"

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
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

anche i poligoni contano, ma appunto qui dipende dal tipo di motore.

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

[Bicio]

Quindi insomma è la realizzazione della scena in modo "realistico"

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

[Krys]

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ù
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
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

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

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

[Bicio]

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

[Krys]

esattamente

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

[Lux !]

...e poi c'è questo che è un mattone, ma crea delle foto

[Bicio]

alcune sembrano davvero vere

[Dadocoso]

...e poi c'è questo che è un mattone, ma crea delle foto

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.

Dall'altra parte la concorrenza offre molta piú flessibilitá artistica e sono piú veloci.