amdplanet.it

La nuova versione del 3DMark nasce dalla consapevolezza di adottare in maniera massiccia lo shader model delle DirectX9.0c e, quindi, di accogliere la compatibilità con le versioni 2.0, 2.0a, 2.0b e 3.0. Un semplice esempio del vantaggio di versioni recenti dello shader model è FarCry: con SM3.0 si renderizzano 4 luci in un unico passaggio, con SM2.0b se ne fanno 3 mentre solo 1 con SM2.0; vi rimandiamo allo scorso articolo per maggiori dettagli. Gli shader sono scritti in maniera dinamica nell' High Level Shader Language dello shader model 2.0 (HLSL) ed in modo che, una volta caricato l'applicativo, siano le stesse DirectX del sistema che andranno a renderizzare le scene adottando lo shader model più competitivo al momento installato sul sistema. FutureMark ha compreso che la velocità con cui si sviluppano i chip grafici è maggiore di quella delle CPU e il mercato dei videogiochi si muove sempre più verso l'estrema flessibilizzazione portata dall'ultima versione delle DirectX, da qui il motivo dell'adozione della sola e ultima versione dello shader model per i suoi test. Naturalmente il dettaglio è aumentato anche per quanto concerne il carico poligonale, passando dalle migliaia di poligoni per frame delle prime versioni del 3DMark al milione odierno. Secondo quanto dichiarato da FutureMark, il nuovo motore di rendering è molto simile a quello degli odierni videogiochi (rispondendo alla critica di coloro che vedevano il 3DMark sempre e solo come un test puramente teorico) e al contempo riesce e tenere sotto pressione la scheda video andando ad eliminare la fisica dei corpi, l'intelligenza artificiale e le altre operazioni della CPU.

Vogliamo ora soffermarci sulla tecnologia del motore di rendering che è alla base dell'applicativo e, in particolare, sulla modalità di gestione delle ombre. Il 3DMark ha da sempre mostrato una certa attenzione nei confronti di questo importante elemento grafico nella generazione di una scena 3D in quanto è uno degli elementi che conferiscono maggiore realismo alla stessa.

Nel 3DMark01 si usavano ombre generate dalla GPU secondo l'approccio "Projection Shadow Maps": le ombre non erano altro che vere e proprie mappe (texture per intenderci) che venivano sovrapposte alla scena illuminata generando zone scure. I limiti di questo approccio, che da un lato permette notevole risparmio della potenza grafica in quanto si va a fare essenzialmente del riempimento di schermo, stanno nell'incapacità di eseguire il self-shadowing (se un oggetto proietta l'ombra non la riceve su se stesso) e nella generazione di proiezioni d'ombra multiple. In questo caso se illumino un oggetto con una fonte luminosa, per esempio puntiforme, e pongo 3 pareti distinte e non trasparenti dietro lo stesso, tutte e 3 saranno investite dal cono d'ombra del primo oggetto, una situazione inverosimile. C'è inoltre da considerare il fatto che essendo una texture, questa è legata a tutti i limiti della stessa, come l'effetto di aliasing che affliggono le stesse a bassa risoluzione.

Nel 3DMark03 si è passati all'approccio "Volume Shadow" o "Stencil Shadow", lo stesso adottato oggigiorno da Doom3. Questo genera un poligono scuro dalla parte opposta alla luce che investe un oggetto e tutto ciò che si trova nel cono d'ombra è visto come scuro, o meglio nero. E' vero che questo non corrisponde a situazioni verosimili in quanto la natura adopera anche la penombra, ma è pur sempre migliore del precedente approccio. Inoltre necessita di maggior potenza tanto nella gestione del carico poligonale aggiuntivo quanto nel riempimento. I vantaggi stanno nell'assenza dello sgranamento dell'ombra (aliasing) e nel fatto che vengono generate ombre corrette e nette.

A questi approcci, FutureMark ha deciso di avanzare la proposta del "Perspective Shadow Maps" (PSM). Come per il primo approccio, anche in questo caso la scena è renderizzata dalla direzione della luce al fine di generare una mappa (texture) di cui si analizza la profondità di ogni texel; questa texture è denominata "depth map". Si realizzano 2 passaggi di rendering: nel primo si va a generare le scena secondo il punto di vista dell'osservatore (post-perspective space) invece che del mondo (come nel primo approccio) e poi si renderizza dal punto di vista della luce memorizzando i dati di profondità in una mappa che contiene, quindi, i dati di ombra in prospettiva, cioè la PSM. A questo punto la GPU è consapevole, dall'analisi di profondità dei valori z, di quali sono i texel in ombra e quali no, per cui si va ad applicare questa mappa alla scena e il gioco è fatto. Tale approccio è stato poi riveduto da FutureMark in modo da avere illuminazione globale, self shadowing e diverse tipologie di luci.

Come nel primo caso, si soffre dell'aliasing perchè si va sempre a gestire una texture, ma molto meno, le ombre non sono fisicamente corrette ma il carico di lavoro è accettabile e la resa finale notevole. Vi sono problemi di resa quando la normale alla superficie tende ad essere ortogonale alla direzione della luce in quanto l'ombra in questi casi si va ad allungare e si hanno casi di flickering al bordo d'ombra per via della scarsa risoluzione della mappa rispetto alla scena, Questo è quanto accade in alcuni frame della scena 3 del 3DMark05 in cui si ricreano queste condizioni.

Nell'applicazione di questa texture sta la chiave di volta. Per tutte le ombre che vengono generate da una luce direzionale si vanno a definire mappe ad alta risoluzione (2048x2048) in formato R32F e vengono usate 2 volte: una per renderizzare la profondità degli oggetti vicino alla camera e l'altra per il resto della scena. Le ombre da fonti di luce puntiformi si concretizzano in mappe cubiche da 512x512x6 di tipo R32F. Come si può comprendere a questo punto, la gestione di texture così voluminose porta la scheda video a soffrire in quanto a banda, ma questo rende anche l'applicativo anche molto poco dipendente dalla risoluzione di rendering della scena. La generazione di queste mappe può essere accelerata in hardware e si parla di "Depth Stencil Texture" (DST), in questo caso il formato scala a D24X8. Le mappe DST vengono poi fuse alla scena usando l'approccio del "Percentage Closest Filtering" (PCF). In generale si vanno a fondere 4 texel adiacenti e non filtrati (point filter) che vengono mediati tra loro e forniscono un valore di colore. Quando, invece, il DST è accelerato in hardware, la GPU applica un filtraggio di tipo bilineare (con media pesata dei componenti di colore). In principio è questo il caso in cui si raccoglie la migliore qualità visiva, ma spesso il primo approccio è migliore perchè si assiste alla visualizzazione di ombre pseudo-morbide di gradevole effetto quando l'area di applicazione è molto ampia. Allora non solo l'accelerazione hardware del DST porta a diversi valori velocistici, ma anche qualitativi. FutureMark, a tal proposito, ha sempre considerato comparabili le due situazioni. Il diverso approccio si basa su valutazioni velocistiche che sono necessarie qualora non si voglia vedere il proprio frame rate precipitare vertiginosamente. Con l'accelerazione hardware si vanno ad impiegare al massimo 2 cicli di clock con una istruzione di shader, in generale sono 14 istruzioni per altrettanti cicli (o la metà); se si fosse fatta la media pesata, il risultato sarebbe stato ancora più lento. Oggigiorno solo nVidia supporta il DST e PCF in hardware a partire dal GeForce3 (con l'esclusione del GF4-MX).

A questo punto potrebbe sorgere un sospetto se si pensa al fatto che FutureMark abbia "favorito" una tecnologia di nVidia e non una di Ati. La stessa azienda ha pubblicamente affermato che si è preferito favorire il DST e PCF per via della notevole diffusione sul mercato dei videogames di questa tecnica di generazione delle ombre: basti pensare a titoli come FarCry, SplinterCell e Tomb Raider: the Angel of Darkness. Inoltre è di facile implementazione e si pensa verrà largamente adottata in futuro. Queste non sono le premesse, almeno al momento, della tecnologia proprietaria di Ati denominata 3Dc che, come sappiamo, si preoccupa della compressione delle normal map. L'azienda stessa ha affermato che qualora ve ne fosse bisogno, un aggiornamento del proprio applicativo permetterà l'adozione anche di questa tecnologia.