Perché i giochi moderni usano un approccio render-to-texture per i mirror?

Quando si guardano vecchi giochi come Mario64 o DukeNukem3D, tutti gli specchi del gioco sono essenzialmente solo buchi nel muro con una copia speculare della geometria davanti allo specchio posta dietro di loro. Nel caso di DukeNukem3D si può anche attivare la funzione No-Clip ed entrare in quella stanza specchiata.

Al contrario, i giochi moderni usano un approccio render-to-texture per i mirror. Questo porta gli pixel ad essere notevolmente pixelati quando si avvicinano a loro. Uno dei primi giochi che ho notato questo approccio è stato Luigi's Mansion, ma sembra essere utilizzato in quasi tutti i giochi moderni.

Quali cambiamenti nell'hardware o nei motori hanno reso il secondo approccio così dominante in questi giorni e quali sono i vantaggi? In termini di effetti visivi puri, il primo approccio sembra superiore, in quanto non presenta problemi di pixel.

1. L'uso di RTT (render-to-texture) consente di ridimensionare facilmente la qualità di rendering (risoluzione, LOD, complessità dell'illuminazione) per prestazioni regolabili. RTT semplifica inoltre la sostituzione della superficie con una mappa cubica a una certa distanza in cui è difficile vedere esattamente il riflesso.
2. Poiché l'output è una trama, ci sono più opzioni riguardo a cosa si può fare in seguito (illuminazione, ombreggiatura, sfumatura, distorsione ecc.).
3. Se una versione speculare della geometria viene posizionata nella scena, richiederebbe l'abbattimento più complicato quando si interseca con la geometria reale e potrebbe essere visto dietro l'angolo. Nei giochi più vecchi, i livelli sono stati progettati per evitarlo. Per non parlare del fatto che qualcuno deve fare il vero mirroring.
4. Se la geometria non viene specchiata manualmente, il rendering deve essere eseguito modificando la matrice di visualizzazione e la modalità di abbattimento (per compensare l'inversione dello spazio nella matrice) e utilizzando il buffer di stencil per ritagliare lo specchio. I motori moderni preferiscono creare in anticipo tutti gli stati di rendering, quindi ci sarebbe un piccolo problema nel fare copie di ogni stato di rendering della scena con le modifiche necessarie per il rendering speculare.

Quindi, fondamentalmente, usare RTT offre più libertà a tutti.

No, ti sbagli: non è così che gli specchi Duke Nukem 3D hanno funzionato.

DN3D utilizzava un motore portale . Una giuntura tra due settori qualsiasi era arbitraria in una certa misura e quando il motore di rendering arrivava a un portale, sapeva che doveva iniziare a renderlo un altro settore. Il settore dietro lo specchio era fondamentalmente un segnaposto per affrontare una stranezza nel motore - l'unico punto del settore era quello di essere più grande di qualsiasi cosa avessi bisogno di "riflesso". Non conteneva alcuna geometria reale. In effetti, ha funzionato praticamente nello stesso modo in cui i "portali" funzionano in Portal - tranne che Portal (essendo esso stesso basato su un motore di portale) crea i portali in fase di esecuzione e ha un limite al numero di volte in cui i portali possono richiamare (ad es. A -> B -> A -> B -> A ...), mentre Build (DN3D) andrebbe semplicemente in crash quando il suo stack traboccava se puntassi uno specchio su un altro mirror.

È ovvio quanto sia semplice implementare uno specchio con quello - creare un portale che punti di nuovo nella stanza. Ciò significa che il rendering dello specchio costerebbe esattamente quanto il rendering della stanza stessa, offrendo grandi prestazioni e coerenza. Finché non hai puntato uno specchio su un altro specchio, cioè. Se guardi attraverso il codice sorgente del motore Build, vedrai che non esiste alcun codice per la gestione dei mirror: non deve essercene uno, perché è così che funzionano i portali NOTA: in realtà, c'è un codice per capovolgere i pixel renderizzati - esso semplicemente non capovolge la geometria e tutti i vari sprite ed effetti. L'editore doveva essere in grado di realizzare questi portali "falsi", guardando indietro su se stesso. Se vuoi sapere di più sul motore di costruzione piuttosto intelligente, c'è una grande analisi di Fabien Sanglard su interni del motore Build. L'intero motore è stato aperto e portato anche su piattaforme moderne, anche se il vecchio funziona ancora perfettamente su Windows 10 (testato per te: P). Molti dei giochi basati su Build sono stati anche open source e / o rifatti.

Perché questo non viene più utilizzato? Bene, alcuni motori non preferiscono più i portali, per esempio. È difficile applicare molti hack e ottimizzazioni grafiche: non posso indicarti nulla di specifico, ma molta post-elaborazione dipende da hack che non funzionerebbero in un vero motore di portale (fanno molte ipotesi che non tenere più). Questo è fondamentalmente lo stesso tipo di problema che questi giochi hanno con immagini stereoscopiche: gli hack non funzionano più.

Ancora più importante, gli specchi sono diventati più complicati. Possono avere forme, trame complesse, possono essere a terra (anche conosciute come "acqua") ecc. Mentre tutti questi problemi sono risolvibili in un motore a portale, RTT diventa la scelta più semplice ad un certo punto e le GPU sono abbastanza veloci per gestirlo.

Tuttavia, nonostante tutto, ci sono molti giochi con accelerazione 3D hardware che fanno le cose "reali". Dei giochi più vecchi, Quake 3 o Alien vs. Predator, per esempio. Per quanto ne so, i giochi del motore di origine usano ancora mirror "reali". Se ti aspetti che le persone si avvicinino allo specchio e puoi garantire che non ci sono troppe superfici riflettenti allo stesso tempo (ad esempio attraverso la progettazione a livello), gli specchi a portale sono ancora molto attraenti.

RTT sarebbe stato usato se fosse possibile, ma la pipeline di rendering dell'hardware era a senso unico.

Anche l'hardware precedente presentava limitazioni che impedivano il rendering alla trama. Scrivere su RAM significa che non può essere letto contemporaneamente. Per migliorare le prestazioni di rendering, il buffer di destinazione era bloccato solo per la scrittura, solo l'hardware di visualizzazione poteva leggere da esso. Potresti richiedere la lettura, ma questo ha bloccato la RAM e il rendering ha dovuto attendere la cancellazione del blocco prima di poter avviare il fotogramma successivo. RTT causerebbe un grosso collo di bottiglia alla pipeline e quindi sarebbero state utilizzate altre soluzioni.

Scoprirai che prima delle pipeline di rendering hardware erano utilizzate le normali RTT in quanto fornivano un modo per ridurre il carico di rendering. Rendering 3D agli sprite per fornire contenuti pseudo 3D. Il rendering delle trame era troppo costoso (CPU) per essere usato allora, a parte le macchine specializzate che erano al di fuori del mercato di consumo generale.

Duke Nukem gestisce che ridigitando la geometria dietro lo specchio, le altre risposte sono parzialmente corrette. Ci sono aree dietro i mirror che in realtà non contengono geometria (nei file di dati di gioco), la geometria viene nuovamente renderizzata in fase di esecuzione, il motivo per cui tali aree esistono è di evitare di posizionare accidentalmente un livello durante la modifica del livello :

poiché esiste un'area contrassegnata, non inserirai accidentalmente alcuna geometria al suo interno.