Orizzonti Lontani

Oggi mi piacerebbe discutere con voi di una tematica piuttosto complicata: quella dei famosi “spazi aperti”.

Sulle riviste e sui forum si discute di quale sia il gioco con gli spazi più ampi o di quale engine sia più capace di fare cosa.

Ma come facciamo a capire quando uno “spazio” è ampio?

In primo luogo cerchiamo di capire la problematica: perchè disegnare uno spazio ampio è un problema?

Per due motivi:

  • Grande quantità di poligoni
  • Grande quantità di materiali
Perchè ho scritto “materiali” e non “texture”? Perchè la texture non è l’unica cosa che appesantisce la pipeline di rendering: anche un semplice cambio di stato la appesantisce.
Possiamo quindi definire un gigantesco quadrato con sopra una texture uno “spazio ampio”?
Dal punto di vista letterale, sì, ovviamente: il quadrato è enorme. Per questo è più corretto utilizzare il termine inglese “Large Environment”, che in sè condensa la grande dimensione dal punto di vista del dato, rispetto al punto di vista visivo.
Purtroppo questo punto è molto difficile da capire, quindi insisterò maggiormente per far capire cosa intendo.
Prendiamo una cartolina qualunque:
Questa è una foto della mia amatissima Champoluc vista dall’alto. Proviamo ad immaginare di dover fare il rendering in tempo reale di questa immagine.
Facciamo finta che ogni casa sia modellata in maniera realistica, con circa 25000 poligoni e 3MB di texture.
Possiamo facilmente intuire che questa scena (solo con le case) prevede circa 1.000.000 poligoni e 120 MB di texture.
Se solo ci fossero le case, la scena sarebbe già abbastanza pesantina. Aggiungiamoci gli alberi (saranno almeno trecento), aggiungiamoci l’illuminazione e il terreno ed ecco che abbiamo una scena che non può essere in alcun modo presentata così com’è alla scheda grafica.
In più consideriamo che, se fosse un gioco, non potrebbe esserci solo questo: appena giriamo la testa dovrà esserci tutto il resto del mondo.
Possiamo quindi già tirare una conclusione: qualunque engine potrebbe mostrare ambienti ricchissimi, se avesse a disposizione un hardware potentissimo.
Quindi: come facciamo a mostrare una scena come quella sopra ad un framerate di (diciamo) 30 fps?
In primo luogo dobbiamo capire cosa significa “30fps”: significa avere circa 32 millisecondi ad ogni frame.
Non molto.
30 fps x 1.000.000 = 30.000.000 di poligoni
Un po’ tanti.
Consideriamo che non abbiamo tutti i millisecondi per noi: c’è anche il gioco in sè che vuole la sua parte.
Ok, possiamo partire a valutare i problemi:

TEXTURES e MATERIALI

Il problema è talmente noto che la soluzione è già stata trovata da quando si fa grafica in tempo reale.
La prima scrematura si fa sulla distanza: perchè usare le texture 2048×2048 quando le case sono così lontante? Basta usare texture 256×256. Facendo così, si riduce drasticamente il tempo di campionamento delle texture.
Questo si chiama “Mipmapping” e non funziona solo sulla lontananza dall’oggetto, ma anche dalla sua posizione rispetto alla camera: più l’oggetto è “di sbieco” più la texture utilizzabile è piccola.
Perfetto, ma questo non basta: una singola casa ha un bel po’ di materiali (il tetto innevato, le finestre, il legno, il muro). Ognuno di questi materiali avrà dei parametri, delle texture e degli stati hardware da settare.
Per ridurre il cambio di stati, possiamo raccogliere per bene tutti gli oggetti col medesimo materiale e disegnarli tutti assieme.
Alcune architetture sono terribilmente più veloci se si riduce il numero di chiamate alla funzione di render, ma passando tanti triangoli: potremmo fare anche così. Questo non è banale per nulla, quindi se decidiamo di farlo, dovremo essere certi che l’architettura sulla quale lavoriamo ci fornisca un boost molto ampio.
Il PC in generale è una di queste architetture, per esempio.

Numero di Primitive

Parlando terra terra, una primitiva è un triangolo. Non è sempre così (OpenGl ad esempio prevede triangoli, punti, linee, quadrati e poligoni), ma possiamo facilmente dire che è così nel 99% dei casi.
La regola principale nel campo della computer grafica è: il modo più veloce per fare una cosa è non farla.
Quindi: qual’è il modo più veloce per disegnare un sacco di triangoli? Risposta: disegnarne pochi.
Ma come possiamo fare? Nella storia ci sono state mille e mille soluzioni. Vediamone qualcuna:
Riduzione del livello di dettaglio: se un oggetto è lontano, possono bastare pochi poligoni per descrivere la sua forma, rispetto a quando è vicino. Ci sono algoritmi che riducono il numero di poligoni in tempo reale (algoritmi “continui”) oppure è possibile utilizzare N modelli 3D prefabbricati, con sempre meno triangoli (algoritmi “discreti”).
Eliminazione degli oggetti fuori dal campo visivo: se un oggetto non è nel campo visivo (frustum) si può evitare di mandarlo in rendering. il controllo si chiama “frustum test” ed in genere si fa per oggetto.
Eliminazione dei triangoli fuori dal campo visivo: questo punto si differenzia dal precedente perchè la precisione scende al triangolo. Tal sorta di test si fa in genere su modelli 3d di grandi dimensioni (come i terreni o gli ambienti), che altrimenti sarebbero sempre in camera e sarebbero sempre disegnati per intero, poiché ben più grandi di quello che la camera può vedere. Per risolvere questo problema ci sono varie soluzioni, come gli OctTree, una struttura dati che consente di partizionare lo spazio e di fare velocemente i conti per decidere “chi è dentro e chi è fuori”, oppure il “Potential Visible Set“, un sistema che divide (in preprocessing) tutto il mondo in blocconi e decide quali oggetti siano visibili nei vari settori. Se un triangolo non è mai visibile, potrebbe essere semplicemente eliminato dalla scena.
Eliminazione dei triangoli coperti da altri triangoli: Il test che si compie, in questo caso si chiama “Occlusion Test” o “Visibility Test”. Un sistema per eseguirlo è utilizzando i “Binary Space Partition Trees”, amati da sempre da Id Software.
Ognuno di questi sistemi (più i mille altri che non ho citato) servono ad evitare di disegnare tutto ciò che non serve, in modo da mandare alla scheda grafica la quantità minore di triangoli (od oggetti) possibile.

Oggetti Ripetuti

Se guardiamo la scena, notiamo che ci sono una quantità troppo elevata di alberi. Da soli, questi alberi, rischiano di prendere interamente tutto il tempo che abbiamo per fare il nostro rendering. Come fare?
Qui abbiamo fondamentalmente due soluzioni, a seconda dell’hardware che abbiamo a disposizione: se l’hardware supporta l’instancing, possiamo mandare un singolo modello 3d di albero, seguito dalle informazioni necessarie per il rendering per ogni albero che vogliamo. Ad esempio, possiamo mandare l’albero e poi cento posizioni diverse, così l’hardware disegnerà questo albero cento volte in queste cento posizioni.

Conclusione

Dopo tutto questo articolo, cosa possiamo dire? Possiamo dire che se un engine non supporta tutte queste feature, allora non supporta gli spazi aperti? No, non possiamo dirlo.
Perchè? Perchè se abbiamo un megaPC pazzesco, con tantissima RAM ed una scheda grafica pazzesca ed immensa, possiamo completamente ignorare tutti i problemi di cui sopra e mandare alla scheda quei 30 milioni di triangoli al secondo, oppure quei gigabyte di texture, tanto il sistema è potente e reggerà il colpo.
Il problema, per i progettisti, è pensare a dei sistemi per far girare questi ambienti su computer esistenti.
Proviamo a pensare a “Grand Theft Auto San Andreas”: non voglio nemmeno immaginare da quanti poligoni e texture sia composto il mondo. Nonostante questo, gira su una PS2 a 30 fps (o 60?). Se tutte queste tecnologie non fossero implementate, non girerebbe mai su una PS2.
Quindi, ora, sapendo questo, poniamoci questo quesito: ha senso chiedere se un engine supporta gli spazi aperti? Viste le migliaia di possibilità dietro questa domanda, io dico di no.
Ha senso, allora, chiedere quanti poligoni e che mole di texture può disegnare un dato engine con un dato PC garantendo i 30 (o 60) fps? Questa domanda ha molto senso, ma capirete bene che non è un equivalente della precedente: se dieci anni fa 500.000 triangoli e 100MB di texture per tutto il mondo potevano essere un “Large Environment”, oggi come oggi questi numeri sono decisamente cambiati.
Quindi, quando vi trovate in una discussione sulla capacità o meno di un engine di disegnare i dannatissimi spazi aperti, cercate sempre di capire con chi state parlando: se è un giornalista o un videogiocatore fanatico del PC, allora molto probabilmente sarà meglio non entrare nemmeno nel discorso 🙂

21 comments on “Orizzonti Lontani

  1. Istruttivo e chiaro, come tutti i (rari purtroppo) articoli di Monopoli. Leggendo questi brevi testi il profano (cioé quasi tutti coloro che credono invece di saperne) riesce davvero a comprendere qualcosa. Chi non impara da questi articoli è perché non è umile, non perché il linguaggio è oscuro o sbagliato. (Non sarà che l’autore scrive e spiega chiaramente perché è uno dei pochi che ne capisce davvero?)

  2. Quando dico che chi sa veramente di cosa parla è in grado di spiegarsi con semplicità e rendersi comprensibile da tutti..bravo monò.

  3. Complimenti.
    Un unica cosa:tornerai sui “materiali”? Io sono abituato a usare Cinema4D e so che rallentano alla grande ma per il real time come si gestiscono in modo agile?
    Grazie.

  4. bellissimo articolo e per me che voglio creare videogiochi è veramente un toccasana.
    e soprattutto ave a te per averlo postato alle 7del mattino ;D

  5. Complimenti per l’articolo, i concetti di base li avevo imparati all’epoca nel corso di Informatica Grafica, ma hai davvero esposto tutto molto bene.

  6. Grazie a tutti 🙂

    Fortunatamente il software che gestisce il sito si occupa autonomamente della pubblicazione 😀 In futuro tornerò sulla questione dei materiali, per parlare per bene di cosa sono e come si rappresentano.

    Il prossimo articolo lo dedicherò alle ombre (sempre che i miei amati amici mi mandino le risposte al questionario per un articolo sui designer 😀 ).

  7. > e soprattutto ave a te per averlo postato alle 7del mattino ;D

    A costo di causare un’immane incidente diplomatico svelando i nostri scheletri nell’armadio: i postaggi mattutini sono programmati in precedenza.

  8. Bell’articolo 🙂 Sopratutto la conclusione

    chissà perchè mi viene in mente un solo nome quando parli di fanatici del pc 😉

  9. A costo di causare un’immane incidente diplomatico svelando i nostri scheletri nell’armadio: i postaggi mattutini sono programmati in precedenza.

    uops non lo sapevo :p

  10. Ma se la manciata di triangoli dello scorso decennio è diventata facilmente gestibile lo si deve anche a engine dalle specifiche determinate che, nel corso del tempo, hanno reso obsoleti svariati limiti (tramite chessò.. l’implementazione di superfici polinomiali o la parametrizzazione). In tal senso, l’esempio di San Andreas mi sembra quantomai appropriato dal momento che rappresenta una macroscopica ottimizzazione di tecnologie pensate per funzionare… quattro anni fa. E gli engine che permettono una gestione di texture procedurali? O le MegaTexture, non ipotetica fantascienza ma realtà sotto agli occhi di tutti. Per gestire gli spazi aperti non ci vuole un PC grande ma un grande sviluppatore e questo è trasparente, però mi sembra di avere letto spiegazioni rivolte esclusivamente al passato, prive di riflessioni e domande su cosa oggi rappresenta la programmazione (e concezione) di “spazi aperti”. Sarà per la prossima volta…

  11. Faccio i miei complimenti al Mono’, un divulgatore nato. Se fosse meno polemico sarebbe perfetto. 😉

  12. Per quanto riguarda il futuro, ci sono sempre ricerche in corso. Alcune di queste o non sono ben chiare, o sono accademiche e del tutto inutilizzabili in ambito produttivo, oppure semplicemente sono soluzioni custom adatte solo per una realtà (il caso di Oblivion).

    Ho preferito concentrarmi sulle soluzioni note ed usate ancora oggi massicciamente: ad esempio pensa che gli algoritmi continui per ridurre il dettaglio delle mesh sono ancora usati molto poco, poichè se fatti in maniera eccellente (mantenendo per bene il profilo, ad esempio), prendono praticamente più tempo che non disegnare la mesh intera 😀

    Sulle Megatexture, purtroppo devo ridurre gli entusiasmi: non sembra essere una tecnologia particolarmente allettante, però prima vorrei vederla davvero all’opera.
    Quake wars, ad esempio, è stato a mio parere un pieno fallimento, da questo punto di vista.
    Mi aspetto molto, però, da Rage: l’engine di Doom3 è stato un flop, in confronto alle licenze vendute da quello di Quake3. Se Id vuole di nuovo essere la leader, ad oggi deve confrontarsi con molte più realtà di quelle passate. Dalla sua ha la possibilità di fare ricerca e sviluppo per anni senza praticamente produrre nulla, una cosa che può fare praticamente solo lei.

  13. Ottime osservazioni. E comunque mi accodo ai complimenti per l’articolo, davvero ben scritto e capace di riassumere concetti complessi in modo facilmente intellegibile: coin drop nello slot Monopoli di Ars Ludica.

Leave a Reply