Quake 2 è adesso l'unico gioco con implementazione completa del Ray Tracing

[cignox1]

>>robe inutili

C'era chi all'inizio degli anni 90 diceva la stessa identica cosa dell'illuminazione per pixel: dicevano che calcolare una radice quadrata per pixel fosse troppo oneroso e, in definitiva, inutile, che tanto il phong shading bastava.

Grazie al cielo c'era anche chi aveva un pó piú di immaginazione...

[Cfranco]

Originariamente inviato da fraussantin

No dimostra solamente che non puoi fare rtx on e basta.

Devi fare rtxon e poi cuttare tutte le fonti di luce che non servono.
Quindi richiiede cmq un lavoro importante.

Non è così semplice, il ray tracing, o meglio, il path tracing (il "vero" ray tracing è ben al di là di qualsiasi potenza computazionale esistente o ipotizzabile) o lo fai o non lo fai, puoi ridurre il numero di raggi (con minore qualità) ma il numero di luci è irrilevante per il calcolo e non ci sono scorciatoie (di per sé il path tracing è già una grossa scorciatoia).
La soluzione alla BF5 è quella di applicarlo soltanto alle pozzanghere, ma chiaramente ne viene fuori un patchwork per cui per alcune superfici viene calcolata la riflessione e altre no, col rischio di avere un framerate estremamente ballerino, con crolli improvvisi quando nella scena ci sono molti elementi da calcolare in RT, pensa se in un gioco fosse previsto una mappa con un lago, appena sei sulla riva e guardi l' acqua vai a 2 fps

Originariamente inviato da cignox1

Ma TUTTE le novitá importaanti sono venute ad un costo:

Ni
Sono venute a un costo tuttavia accettabile e in cambio di un notevole miglioramento della qualità.

Originariamente inviato da cignox1

Ma oggi vogliono tutti i 4k@60fps con RTX su ultra. I tempi, evidentemente, sono cambiati...

Il problema è che RT offre una qualità enormemente superiore alle tradizionali tecniche, ma solo se fatto bene e con una potenza computazionale sufficiente, se fatto male a spizzichi e bocconi, porta pochi vantaggi e molti svantaggi.
Non è una cosa che puoi semplicemente aggiungere a un motore 3D, non è un altro effetto grafico da applicare, è un modo completamente diverso di calcolare l' immagine.

[cignox1]

--Non è così semplice, il ray tracing, o meglio, il path tracing (il "vero" ray tracing è ben al di là di qualsiasi potenza computazionale esistente o ipotizzabile) o lo fai o non lo fai, puoi ridurre il numero di raggi (con minore qualità ma il numero di luci è irrilevante per il calcolo e non ci sono scorciatoie (di per sé il path tracing è già una grossa scorciatoia).

Questa poi sarebbe da spiegare meglio. Perché, dal punto di vista della computer grafica, é esattamente il contrario: é il "path tracing" il "sacro graal" e il "raytracing" ("whitted style raytracing") la versione "povera" - e piú vecchia.
l'obbiettivo é il path tracing, ma tutti dicono "raytracing" perché alla fin fine sempre di sparare raggi in una scena e di calcolare l'illuminazione si parla, e una volta che hai questa funzionalitá, puoi fare quello che vuoi: raytracing, path tracing, bidir pt, metropolis, pure photon mapping se proprio ci tieni.
Se quello di cui parli tu é la risoluzione analitica della funzione di illuminazione: beh, nessuno al mondo lo fa. Il path tracing risolve l'initegrale tramite monte carlo e tanto basta a tutti, grafici e scienziati compresi.

--Sono venute a un costo tuttavia accettabile e in cambio di un notevole miglioramento della qualità.
Se parli del costo economico ti do ragione. Ma non mi interessano le politiche commerciali di nVidia, solo i progressi tecnologici che il rt (e non necessariamente attraverso RTX) permetterá.

--Il problema è che RT offre una qualità enormemente superiore alle tradizionali tecniche, ma solo se fatto bene e con una potenza computazionale sufficiente, se fatto male a spizzichi e bocconi, porta pochi vantaggi e molti svantaggi.
Non è una cosa che puoi semplicemente aggiungere a un motore 3D, non è un altro effetto grafico da applicare, è un modo completamente diverso di calcolare l' immagine.

Assolutamente d'accordo su tutto. Ma siccome l'introduzione di forza dell'rt completo era impossibile per cosí tanti motivi che non mi metto neppure ad elencarli, il fatto che abbiano escogitato un modo per introdurre un rendering ibrido ci permette di affrontare la migrazione in maniera progressiva. Potrá non avere un impatto col botto, ma chi sa cosa é il raytracing non puó che attendere con trepidazione i prossimi sviluppi.
E se nVidia fa pagare troppo, rivedrá i prezzi in base al mercato, come sempre si fa.

[Cfranco]

Originariamente inviato da cignox1

Questa poi sarebbe da spiegare meglio. Perché, dal punto di vista della computer grafica, é esattamente il contrario: é il "path tracing" il "sacro graal" e il "raytracing" ("whitted style raytracing") la versione "povera" - e piú vecchia.

Perché si fa molta confusione tra "ray tracing" e i vari algoritmi che cercano di approssimarlo ( tra cui il ray casting e l' algoritmo di Whitted e innumerevoli altri ), il vero, unico e assoluto ray tracing è la costruzione della scena a partire dalle fonti di luce, il che richiede una potenza computazionale di vari ordini di grandezza superiore al concepibile.
Quindi si dovrebbe parlare di vari algoritmi di approssimazione al ray tracing.

Originariamente inviato da cignox1

l'obbiettivo é il path tracing, ma tutti dicono "raytracing" perché alla fin fine sempre di sparare raggi in una scena e di calcolare l'illuminazione si parla, e una volta che hai questa funzionalitá, puoi fare quello che vuoi: raytracing, path tracing, bidir pt, metropolis, pure photon mapping se proprio ci tieni.
Se quello di cui parli tu é la risoluzione analitica della funzione di illuminazione: beh, nessuno al mondo lo fa. Il path tracing risolve l'initegrale tramite monte carlo e tanto basta a tutti, grafici e scienziati compresi.

Esatto, proprio questo intendevo.

Originariamente inviato da cignox1

--Sono venute a un costo tuttavia accettabile e in cambio di un notevole miglioramento della qualità.
Se parli del costo economico ti do ragione. Ma non mi interessano le politiche commerciali di nVidia, solo i progressi tecnologici che il rt (e non necessariamente attraverso RTX) permetterá.

Parlavo di costo computazionale, non economico
Le varie funzionalità hanno appesantito sicuramente i motori grafici, ma hanno anche portato a un notevole incremento del realismo, da Quake 2 a BF V c' è un bel po' di differenza

Originariamente inviato da cignox1

--Il problema è che RT offre una qualità enormemente superiore alle tradizionali tecniche, ma solo se fatto bene e con una potenza computazionale sufficiente, se fatto male a spizzichi e bocconi, porta pochi vantaggi e molti svantaggi.
Non è una cosa che puoi semplicemente aggiungere a un motore 3D, non è un altro effetto grafico da applicare, è un modo completamente diverso di calcolare l' immagine.

Assolutamente d'accordo su tutto. Ma siccome l'introduzione di forza dell'rt completo era impossibile per cosí tanti motivi che non mi metto neppure ad elencarli, il fatto che abbiano escogitato un modo per introdurre un rendering ibrido ci permette di affrontare la migrazione in maniera progressiva. Potrá non avere un impatto col botto, ma chi sa cosa é il raytracing non puó che attendere con trepidazione i prossimi sviluppi.
E se nVidia fa pagare troppo, rivedrá i prezzi in base al mercato, come sempre si fa.

Ovviamente chi fa Ray Tracing non può che sbavare sulle RT, il miglioramento di prestazione è massiccio, sono invece molto scettico sulla possibilità di ibridare i motori 3D convenzionali con tecniche RT, si parte da concetti e algoritmi profondamente diversi, la cosa richiede molto, molto, molto lavoro e attenzione da parte delle SW house, cose che normalmente mancano

[cignox1]

--Perché si fa molta confusione tra "ray tracing" e i vari algoritmi che cercano di approssimarlo ( tra cui il ray casting e l' algoritmo di Whitted e innumerevoli altri ), il vero, unico e assoluto ray tracing è la costruzione della scena a partire dalle fonti di luce, il che richiede una potenza computazionale di vari ordini di grandezza superiore al concepibile.

Ma hai una fonte per questa cosa? Perché continuo a non capirla (e, potrei sbagliare, ma avevamo discusso di questo anche su un altro sito?)
Il raytracing "vero e proprio" (se vogliamo mettere i puntini sulle "i" ) sarebbe quello di sparare i raggi dalle fonti di luce, e forse é questo quello a cui ti riferisci? Quello che noi chiamiamo raytracing é in realtá il whitted style raytracing che é in realtá il whitted style "backward" raytracing, ma dal punto di vista grafico un vero path tracer giá produce risultati qualitativamente perfetti, non avresti alcuun vantaggio nell'usare un forward raytracer (anche se in realtá il bidirectional path tracing fa un misto dei 2 perché la convergenza é piú veloce in certe scene).
Almeno che io sappia, il path tracer non é una "approssimazione" di niente (ok, matematicamente non produce una soluzione per via analitica ma non lo fanno neppure le altre tecniche), e produce in linea di principio lo stesso identico risultato del forward raytracing. Poi, potrei anche sbagliarmi...

--sono invece molto scettico sulla possibilità di ibridare i motori 3D convenzionali con tecniche RT

Questo si vedrá. Abbiamo giá visto i primi esempi di questo, poi non resta altro che aspettare. Confido sul fatto che gli sviluppatori stessi non vedono l'ora che avvenga questo cambiamento a causa delle ben note complessitá ormai ingestibili dei motori grafici attuali e che siano quindi spinti a dare il meglio.
Vedremo

[Cfranco]

Originariamente inviato da cignox1

Ma hai una fonte per questa cosa? Perché continuo a non capirla

Per come la vedo io il ray tracing è la risoluzione dell' equazione di illuminazione, tutto il resto sono algoritmi che approssimano il ray tracing più o meno bene e richiedono più o meno potenza computazionale.
Spesso si confondono i due termini e quindi si parla di ray tracing quando in realtà si intende un algoritmo particolare, quindi il path tracing è meglio di altri algoritmi più vecchi che approssimano il ray tracing, ma il santo Graal della risoluzione dell' equazione completa è e rimarrà per un bel pezzo un miraggio lontano.

Originariamente inviato da cignox1

Almeno che io sappia, il path tracer non é una "approssimazione" di niente (ok, matematicamente non produce una soluzione per via analitica ma non lo fanno neppure le altre tecniche), e produce in linea di principio lo stesso identico risultato del forward raytracing.

E' una tecnica statistica, in teoria se usi un numero infinito di raggi il risultato è corretto, ma di solito ne usi molti meno

Originariamente inviato da cignox1

Questo si vedrá. Abbiamo giá visto i primi esempi di questo, poi non resta altro che aspettare. Confido sul fatto che gli sviluppatori stessi non vedono l'ora che avvenga questo cambiamento a causa delle ben note complessitá ormai ingestibili dei motori grafici attuali e che siano quindi spinti a dare il meglio.
Vedremo

Da un punto di vista dell' algoritmo il path tracing è meravigliosamente semplice, solo che quando parte la ricorsione e devi farti 1000 o più raggi per pixel ... diventa un mattonazzo da paura

[cignox1]

--Per come la vedo io il ray tracing è la risoluzione dell' equazione di illuminazione

No, il "rendering" é la risoluzione dell'equazione di illuminazione. Il raytracing (& co.) é solo uno degli algoritmi per farlo. Ma ce ne sono altri, come il radiosity.

--E' una tecnica statistica, in teoria se usi un numero infinito di raggi il risultato è corretto, ma di solito ne usi molti meno

Beh, chiaro, ma l'alternativa qual'é? La soluzione "perfetta" sarebbe di risolvere l'equazione in maniera analitica, ma nessuno lo fa (salvo casi estremamente basilari per verificare la correttezza di un renderer tradizionale) e non credo neppure che si possa fare, nel caso generale. Il monte carlo é una strategia legittima per risolvere gli integrali...

--Da un punto di vista dell' algoritmo il path tracing è meravigliosamente semplice, solo che quando parte la ricorsione e devi farti 1000 o più raggi per pixel ... diventa un mattonazzo da paura

Ah, vero

[cdimauro]

https://en.wikipedia.org/wiki/Radios...puter_graphics)