Doom - intervista tecnica
Ecco come id software ha creato il gioco a 60fps graficamente migliore della generazione.
È passato parecchio tempo da quando abbiamo realizzato un'intervista come questa! Durante la stesura della nostra analisi tecnica del fantastico reboot di Doom, una cosa è diventata chiara: questo è un gioco che offre un notevole livello di fedeltà visiva mantenendo un frame-rate estremamente alto. La portata del risultato non può essere sottovalutata: siamo di fronte a un titolo a 60fps che offre una grafica migliore di molti, se non della maggior parte, di quelli che girano a 30fps. Come ci sono riusciti?
Lo sviluppo di videogiochi richiede talmente tanto tempo al giorno d'oggi che molti creatori parlano delle loro tecniche nel corso di eventi come GDC e Siggraph, dandoci modo di approfondire gli aspetti tecnici di molti titoli moderni prima ancora che siano disponibili: tutto ciò è ottimo per il Digital Foundry, perché ci dà modo di fare delle ricerche preziose durante la stesura dei nostri articoli e video. Nel caso di idTech6 si sapeva però poco del motore e della sua relazione con il suo predecessore, e della struttura del motore alla base del cancellato Doom 4.
Quando c'è stata l'opportunità di mettere insieme un'intervista tecnica 'senza esclusione di colpi' con id software, l'abbiamo colta con entusiasmo. In quest'articolo andremo in profondità, coprendo l'evoluzione di idTech, i principi di rendering su cui si basa l'ultima versione del gioco, l'opinione del team su risoluzione, scaling e anti-aliasing, e ovviamente la crescente importanza del calcolo asincrono e le nuove API grafiche PC.
Anche il momento è fortunato: la scorsa settimana, id ha lanciato l'attesa patch Vulkan per Doom, che ha portato dei miglioramenti notevoli per il gaming su PC e ha dato una boccata d'ossigeno in particolare all'hardware Radeon di AMD. È tempo che gli sviluppatori passino dalle DirectX11 a Vulkan e DX12? Lo leggerete più in basso.
Alle nostre domande hanno risposto delle vere personalità dello staff tecnico di id software. Ringraziamo il team per averci concesso così tanto del suo tempo per quest'articolo.
- Robert A Duffy - Chief Technical Officer
- Billy Khan - Lead Programmer
- Tiago Sousa - Lead Rendering Programmer
- Jean Geffroy - Senior Engine Programmer
- Axel Gneiting - Senior Engine Programmer
Digital Foundry: Guardando alla storia di Doom, e a quella di id software, vediamo una fenomenale eredità di eccellenza tecnologica. Quali erano gli obiettivi per idTech6? Siete soddisfatti dei risultati finali?
Robert A Duffy: Gli obiettivi originali erano molto semplici; volevamo la grafica migliore a 60fps e il miglior movimento e feeling per uno shooter. C'è ovviamente un'intera lista di obiettivi minori che formano le basi per raggiungere questo traguardo, ma quelli principali visibili agli utenti erano questi. Siamo molto felici dei risultati finali, ma stiamo continuando a produrre aggiornamento per console, supporto Vulkan per PC, e altri update indirizzati alla community.
Digital Foundry: Possiamo farci un'idea delle tappe di sviluppo di idTech6? Si è evoluto in parallelo con lo sviluppo di Doom, insieme al gioco finale a al cancellato Doom 4? O avete rinnovato la tecnologia esistente quando avete puntato ai 60fps?
Robert A Duffy: Durante la realizzazione di prototipi di gameplay per Doom e mentre gli scenari cominciavano a prendere forma, era chiaro che avevamo bisogno di prendere una direzione differente con la tecnologia per ottenere la fedeltà visiva che secondo noi un Doom moderno deve garantire. I 60fps sono sempre stati l'obiettivo del gioco, ma man mano che abbiamo aggiunto illuminazione dinamica, ombre e altre funzioni, le prestazioni sono diventate un punto d'attenzione per il team di programmazione. La risposta breve è che abbiamo cambiato molto, ma non tutto.
Digital Foundry: Potete parlare dei cambiamenti principali avvenuti tra idTech5 e 6? Rage aveva un approccio all'illuminazione molto più statico, e presumibilmente un forward renderer. Doom, invece, è molto più ricco di luci e ombre dinamiche. È una qualche forma di renderer differito o clusterd differito?
Tiago Sousa: Fin dall'inizio, uno dei nostri obiettivi per il renderer di idTech 6 era di avere un design performante e più unificato possibile, che permettesse a luci, ombre e dettagli di lavorare fluidamente su diversi tipi di superficie, tenendo presente al tempo stesso la scalabilità e cose come console, MSAA, buona qualità dell'immagine e scalabilità MGPU [multi-GPU].
L'attuale renderer è un ibrido tra forward e differito. Con questo design abbiamo tentato di prendere il meglio dei due sistemi: la semplicità di un forward renderer e la flessibilità di uno differito, per poter approssimare in maniera efficiente alcune tecniche. Un altro obiettivo fin dall'inizio era di migliorare i tempi di iterazione del team artistico, e cose come il consumo di spazio su disco. Volevamo deviare dall'approccio dell'idTech5, in particolare dal modo in cui il dettaglio veniva applicato alle texture. In passato, il motore utilizzava i risultati delle texture pre-elaborate nelle mega-texture e così via: in questa versione abbiamo trasformato il procedimento in un approccio in tempo reale della GPU, senza l'aggiunta di draw call.
Per quanto riguarda la parametrizzazione dei dati da fornire alla GPU, “Clustered Deferred and Forward Shading” di Olson e “Practical Clustered Shading” di Emil Person hanno attirato la mia attenzione all'inizio della fase di ricerca a causa della loro semplicità ed eleganza, quindi abbiamo approfondito partendo da quella ricerca. Il nuovo sistema permette di avere un gran numero di luci, volumi luminosi basati su immagine e così via.
Digital Foundry: Quando del DNA di idTech5 è ancora presente nel nuovo motore? Il texturing virtuale, ad esempio, sembra ancora presente.
Billy Khan: Vediamo il nostro motore come un organismo in costante evoluzione e adattamento. È molto importante, per noi, essere sempre all'avanguardia sul fronte tecnologico. Doom utilizza ancora i Virtual Materials per fornire i dati delle texture al renderer PBR.
Digital Foundry: Il passaggio al nuovo sistema di rendering ha richiesto grossi cambiamenti negli strumenti di lavoro?
Tiago Sousa: Sì, come detto uno dei nostri obiettivi principali era di far diventare idTech 6 in un modello di rendering fisicamente plausibile. Tutto è cominciato facendo passare l'intero team da un rendering agnostico lineare a quello in high dynamic range e lineare, e dopo questo passo siamo approdati allo shading basato sulla fisica.
È stato un cambio di registro abbastanza grande, particolarmente per il team artistico, che ha dovuto abituarsi a cosa come tone-mapping, esposizione dell'immagine, parametrizzazione fisicamente plausibile delle texture, e così via. La transizione è stata notevole anche per il team di programmazione, in cui tutti hanno dovuto capire le sfumature rilevanti, come le lightmap HDR, richieste per un rendering coerente e d'alta qualità.
Digital Foundry: In che modo la ESRAM limitata di Xbox One influenza l'implementazione dello scaling della risoluzione dinamica? In generale, qual è il vostro approccio alla gestione della ESRAM?
Tiago Sousa: Non ha una relazione diretta con lo scaling della risoluzione. La ESRAM è stata utilizzata per velocizzare le tecniche a banda limitata, in particolare il rendering delle shadow maps. Per migliorare le prestazioni, nella ESRAM sono state gestite anche cose come i render target di light buffer/thinGbuffer. Questi elementi sono stati riutilizzati più avanti per velocizzare anche le trasparenze alpha.
Digita Foundry: Non abbiamo potuto fare a meno di notare la qualità di oggetti come lo shading dei metalli. Qual è stato l'approccio al rendering basato sulla fisica? Sono state utilizzate tecniche specifiche per, diciamo, la pelle dei demoni?
Tiago Sousa: Il nostro approccio all'illuminazione è un mix di approssimazioni in tempo reale e componenti precalcolate. Per l'illuminazione indiretta, idTech utilizza luci precalcolate per le geometrie statiche e un'approssimazione volumetrica per gli elementi dinamici. Per i riflessi speculari indiretti abbiamo utilizzato un approccio basato su immagine.
I componenti in tempo reale utilizzano un modello d'illuminazione analitico allo stato dell'arte per l'illuminazione diretta, combinato con occlusione direzionale in teampo reale e approssimazione dei riflessi. Il sub-surface scattering della pelle è approssimato tramite un'anteprima delle texture e il calcolo dei dati delle traslucenze. È abbastanza efficiente, in particolare se confrontato alle pesanti approssimazioni screen-space utilizzate di solito.
Il nostro traguardo più importante è stato la sua buona resa su diversi tipi di superficie, anche se siamo sempra in cerca del modo per migliorare ancora di più.
Digital Foundry: Potete parlarci di come funziona l'implementazione del TSSAA 8x? È coerente tra console e PC?
Tiago Sousa: Il TSSAA ricostruisce un'immagine con super-sampling 8x dai dati acquisiti da vari fotogrammi.
Il suo costo è relativamente basso, e ha il vantaggio aggiuntivo dell'anti-aliasing temporale che mitiga l'aliasing tra diversi fotogrammi. L'implementazione è quasi la stessa su console e PC, le differenze stanno in alcune ottimizzazioni specifiche per console e un paio di semplificazioni.
Digital Foundry: Lo scaling dinamico della risoluzione funziona benissimo su console: ci sono delle ragioni tecniche che gli impediscono di funzionare su PC?
Billy Khan: Lo scaling dinamico della risoluzione in realtà funziona su tutte le piattaforme. Al momento non lo utilizziamo su PC perché l'utente può scegliere la risoluzione che preferisce dal menu delle impostazioni. Offriamo uno scaling statico che permette di utilizzare risoluzioni superiori, ma che poi diminuisce i buffer di rendering in percentuale per ottenere frame-rate superiori.
Digital Foundry: Lo scaler è molto efficace su PS4 e Xbox One. Quanto pensate che sia importante la risoluzione in generale e in termini di qualità dell'immagine?
Tiago Sousa: Non utilizziamo lo scaler nativo di PS4/Xbox One, ma eseguiamo il nostro upsampling tramite un filtro bicubico. È anche importante menzionare che il TSSAA tiene conto dei cambiamenti nella risoluzione dinamica, mitigando l'aliasing generato dal passaggio da una risoluzione all'altra.
L'importanza della risoluzione è una funzione di distranza dell'occhio dallo schermo e dall'area di visualizzazione (in pratica la risoluzione angolare), e in una certa misura anche dell'acuità visiva individuale. Più lontani si è dallo schermo, più è alta la densità di pixel. Dopo una certa distanza si raggiunge il limite e si finisce per sprecare potenza che potrebbe essere impiegata per migliorare altre cose. Con la realtà virtuale, ad esempio, si ha questo piccolo schermo davanti al viso, e spingere per una densità di pixel superiore ha senso per gestire cose come l'aliasing delle geometrie.
Su console il giocatore tipicamente si trova a una distanza di due metri o più, e quando lo schermo è di dimensioni medie, le risorse iniziano ad andare sprecate relativamente presto, in particolare quando si parla di 4K. Se uno sviluppatore adotta l'approccio della forza bruta, in pratica si rasterizza lo stesso contenuto, ma 4 volte più lentamente, per un incremento non così grande. Anche per il rendering del desktop, a cui di solito gli utenti sono molto vicini, posso pensare a una miriade di approcci alternativi per gestire i costi della risoluzione.
Digital Foundry: Potete parlarci dell'impostazione relativa all'occlusione direzionale su PC?
Tiago Sousa: Le impostazioni inferiori utilizzano un minor numero di campionature, quelle più alte un numero superiore. In generale utilizziamo un numero di campioni piuttosto basso, ma ci affidiamo al TSSAA per ricostruire un risultato di qualità superiore. Su PC impiega circa 0.1ms a 1440p.
Digital Foundry: È possibile separare il motion blur per oggetto da quello per inquadratura?
Tiago Sousa: In termini di plausibilità, il motion blur è la simulazione della luce accumulata dall'esposizione di un'immagine per un certo periodo di tempo su pellicola/sensore digitale. Per approssimarla dobbiamo ricostruire il percorso dei pixel. Al fine del calcolo in tempo reale si esegue solitamente tramite la velocità relativa di una superficie proiettata sul piano visivo, tra il fotogramma attuale e quello precedente, mentre il frame successivo è solitamente estrapolato. Da un punto di vista della plausibilità fisica, non ha molto senso separarlo tra oggetto e inquadratura. È possibile, ma introdurrebbe dei chiari artefatti e l'immagine finale non avrebbe un bell'aspetto.
Digital Foundry: Quali sono le differenze tecniche tra le varie modalità di rendering, come quella cinematografica?
Tiago Sousa: Ciascuna modalità di rendering è stata ideata in modo che l'utente potesse giocare con essa e avere un'esperienza grafica relativamente differente a ogni playthrough. Tecnicamente si tratta solo di regolare i parametri di cose come saturazione delle luci, tone-mapping, esposizione automatica dell'inquadratura e via di seguito. La modalità cinematografica aggiunge sottili effetti di lens-flare e vignettature, più evidenti se provenienti da fonti luminose.
Digital Foundry: Potete approfondire i vantaggi forniti dal calcolo asincrono su console e delle eventuali differenze tra PS4 e Xbox One in questo campo?
Jean Geffroy: Guardando alle prestazioni delle GPU, diventa subito ovvio che alcuni passaggi di rendering utilizzano a malapena le Compute Units. Il rendering delle shadow map, ad esempio, è tipicamente limitato dal collo di bottiglia di una linea di calcolo fissa (come la rasterizzazione) e dalla banda di memoria, più che dalla vera potenza di calcolo. Quindi, quando vengono renderizzate le shadow map, se non c'è nulla che gira in parallelo si spreca molta potenza di calcolo della GPU.
Anche i calcoli di shading più intensi non sono potenzialmente in grado di impegnare tutte le Compute Units, per numerosi motivi legati alla linea di calcolo interna. Quando ciò accade, il calcolo asincrono può sfruttare quelle unità inutilizzate per altri compiti, esattamente come in Doom. I nostri post-processing e tone-mapping, ad esempio, girano in parallelo con buona parte del lavoro grafico. È un buon esempio di una situazione in cui una diversa distribuzione del lavoro tra linee grafiche e di calcolo può far guadagnare vari millisecondi.
Questo è solo un esempio, ma in generale il calcolo asincrono è un ottimo strumento per sfruttare meglio la GPU. Quando è possibile sovrapporre del lavoro intensivo per la memoria con calcoli pesanti, è possibile guadagnare qualcosa a livello di prestazioni. Utilizziamo il calcolo asincrono nello stesso modo su entrambe le console. Vi sono delle differenze hardware nel numero di linee di calcolo disponibili, ma la cosa non ha avuto molta importanza a causa del modo in cui abbiamo gestito la sequenza dei compiti da eseguire.
Digital Foundry: Vedremo il calcolo asincrono all'opera nella versione PC tramite Vulkan?
Billy Khan: Sì, il calcolo asincrono verrà utilizzato ampiamente nella versione Vulkan per PC con hardware AMD. Le Vulkan permettono di programmare in maniera molto più vicina al 'metallo'. Con Vulkan, viene eliminato lo spesso strato di driver e le prestazioni miglioreranno in un modo che non era possibile con OpenGL o DX.
Digital Foundry:Pensate che il calcolo asincrono diventerà un fattore improtante in tutti i motori grafici e tutti i formati?
Billy Khan: Già lo è. Doom è già un chiaro esempio di come il calcolo asincrono, se utilizzato a dovere, possa migliorare drasticamente le prestazioni e l'aspetto di un gioco. In futuro lo utilizzeremo ancora più estensivamente in idTech6. È quasi certo che gli sviluppatori lo sfrutteranno man mano che scopriranno come utilizzarlo efficacemente nei loro giochi.
Digital Foundry: Cosa pensate dell'adozione di Vulkan/DX12 come API primarie per lo sviluppo di titoli tripla-A? È ancora troppo presto?
Axel Gneiting: Consiglierei a tutti di cominciare il prima possibile. C'è decisamente una curva d'apprendimento da affrontare, ma i benefici sono ovvii. Vulkan ha già degli strumenti di supporto utili con RenderDoc, e quelli di debugging sono efficaci. Il grande beneficio di Vulkan è che il compiler degli shader e gli strumenti di debug e RenderDoc sono tutti open source. In più, supportano pienamente Windows 7, quindi non ci sono svantaggi dal lato del supporto OS come su DX12.
Tiago Sousa: Credo che sarà interessante constatare i risultati ottenuti con un gioco ideato interamente per sfruttare le nuove API, visto che nessun gioco finora l'ha fatto. Mi aspetto un incremento relativamente grande nel dettaglio, con elementi come ombre dinamiche. Un altro aspetto sottovalutato è che i team artistici potranno lavorare in maniera più efficiente.
Digital Foundry: Potete darci un'idea di come sfruttate la CPU delle console e delle opportunità di ottimizzazione in quell'ambito? La versione PC richiede un quad-core, che dovrebbe spazzare via l'architettura Jaguar di PS4/Xbox One.
Axel Gneiting: Utilizziamo tutti e sette i core disponibili di entrambe le console, e per alcuni fotogrammi viene sfruttata quasi tutta la potenza di calcolo del processore. Sospetto che la versione Vulkan girerà bene su un sistema con dual-core ragionevolmente veloce. Le OpenGL impiegano un intero core, mentre le Vulkan ci permettono di ripartirlo tra più lavori.
Digital Foundry: Senza violare alcun accordo di non divulgazione, il futuro della tecnologia videoludica sembra mostrare un'inclinazione ancora maggiore verso le GPU. Credete che con idTech6 potrete sfruttare di più le componenti grafiche per compiti solitamente associati alla CPU?
Axel Gneiting: In generale è molto difficile prevedere il futuro, quindi tentiamo di mantenere semplice più che possiamo il nostro codice. Al momento sembra che si stia andando proprio in quella direzione.
Tiago Sousa: Nel lungo termine posso prevedere un futuro in cui il lavoro di molte GPU in contemporanea sarà molto più interessante del vecchio metodo di rendering a fotogrammi alterni. In particolare, ora che gli sviluppatori stanno tentando di ammortizzare i costi per poter scalare su piattaforme differenti, il syncing tra GPU sta diventando un grosso collo di bottiglia per approcci di questo tipo.
Digital Foundry: Durante la fase beta, su console siete passati dalla sincronia verticale adattiva a una sua variante permanente. Come mai?
Jean Geffroy: Abbiamo migliorato parecchie cose tra la beta chiusa e quella aperta, tra cui la nostra soluzione di sincronia verticale. Abbiamo optato per una soluzione a triplo buffer con la quale presentiamo sempre l'ultima immagine che è stata renderizzata dalla GPU con latenza minima. Il sistema è molto simile alla Fast Sync che Nvidia ha recentemente introdotto su PC.
Digital Foundry: Potete spiegarci come ottimizzate in generale per migliorare le prestazioni?
Axel Gneiting: Non credo che ci siano grossi segreti. Facciamo come chiunque altro: usiamo un profilatore, troviamo i punti migliorabili, li ottimizziamo e ripetiamo.
Tiago Sousa: Mi piace mantenere semplici le cose. Di solito affronto le cose da una prospettiva minimalistica quanto a dati e codice, tenendo presente l'hardware finale e tentando di prevedere un po' il futuro. Ad esempio, ha senso trattare una grossa quantità di dati, o è possibile prenderne una parte? Il set di dati considerato è quello minimo? Se la soluzione è un po' complicata o folle, cosa possiamo fare per renderla il più semplice possibile? Come potrebbe girare bene sulle piattaforme più lente, e che tipo di scalabilità possiede? E via di seguito. Ovviamente, ci sono poi le solite micro-ottimizzazioni da profilazione.
Digital Foundry: idTech5 è stato impiegato in un certo numero di titoli Zenimax: idTech6 è ideato per essere altrettanto accessibile ad altri sviluppatori?
Robert A Duffy: L'evoluzione dei nostri motori è solitamente dettata dai bisogni dei nostri titoli in sviluppo. A differenza delle compagnie che tentano di vendere o concedere in licenza la loro tecnologia, abbiamo questo lusso.
Stiamo espandendo le capacità della tecnologia nel corso del tempo al fine di includere un numero più ampio di funzioni, e condividiamo anche parecchia tecnologia tra studi differenti. Se uno studio a noi collegato fa qualcosa molto bene non c'è bisogno di reinventare la ruota, quindi gli chiediamo come fanno. È molto più veloce così.
Digital Foundry: Cosa c'è nel futuro di idTech6? State valutando qualcosa in particolare?
Robert A Duffy: Supporto migliore per gli sviluppatori tramite degli strumenti è un obiettivo principale a breve termine, così come migliorare la linea di lavoro in ambito di Arte e Design. All'E3 2016 abbiamo mostrato la demo tecnica in realtà virtuale "Doom Universe" e basandoci sul nostro lavoro precedente per l'hardware VR, stiamo spingendo molto sulla parte software. Crediamo che la base tecnologica sia in una buona posizione per offrire una fedeltà estrema a 90+fps.