Vi riportiamo la traduzione integrale dell’articolo che riassume l’intervista tecnica a Sean Tracy, direttore tecnico di CIG, esperto di CryEngine. Ringraziamo Gamersnexus per l’intervista.
Intervista a Sean Tracy su motore a 64 bit e Edge Blending Procedurale
Meno di due anni fa Cloud Imperium Game iniziò a discutere di motore a 64bit, ma non hanno mai avuto l’occasione di spiegare a fondo cosa questo cambiamento significasse. Successivamente all’intervista con Chris Roberts (Parte 1: pianeti procedurali V2, Alpha 3.0 e Parte 2: sistema meteorologico), abbiamo messo sotto esame il Direttore tecnico di CIG, Sean Tracy, che ci ha spiegato meglio qual è il punto sul CryEngine, i lavori interni per la generazione procedurale V2 e tanto altro. Tracy si è preparato bene per questa intervista, era presente durante quella con Chris e ha scritto su un blocco note una serie di punti. L’intera intervista dura circa 40 minuti e abbiamo deciso di dividerla in due parti:
Parte 1: sulle tecnologie a 64 bit, coordinate spaziali, edge blending, mesh e livelli.
Parte 2(Mercoledì 5 Ottobre) si parlerà di CPU threading, sistema delle risorse, gestione del carico, tecnologie dei personaggi e altre informazioni sul CitizenCon.
Dal “CryEngine” allo “Star Engine”
Il nome non è definitivo, ma abbiamo già discusso, durante la prima intervista, riguardo la possibilità di cambiare il nome dell’engine in “Star Engine” che tra l’altro ha già fatto la sua prima comparsa nella splash screen di Star Citizen. Il cambio del nome, secondo Roberts, riflette meglio quello che è stato il refactoring del motore di casa Crytek per integrarlo con Star Citizen. Abbiamo posto una domanda a Sean riguardo proprio la revisione del motore che ha portato poi allo Star Engine, e lui ha affermato che uno dei principali cambiamenti è stato il passaggio da 32 a 64bit, cosa che di fatto rende possibile la creazione dell’universo. Il motore di CIG è supportato e costruito internamente. Di solito, uno sviluppatore di giochi stipula, con il fornitore del motore, un accordo di licenza per svilupparlo. Le cose, però, sono cambiate negli ultimi anni, con la corsa all’utilizzo di motori gratuiti, ma con i grandi sviluppatori che stipulano comunque accordi privati. Per la maggior parte, questi accordi prevedono un supporto diretto all’engine o consentono leggere modifiche che si traducono in una certa percentuale sul costo del supporto. Questo aspetto in CIG sta cambiando, ma ovviamente non conosciamo quali sono i dettagli sugli accordi tra CIG e Crytek. Ma il punto non è quali sono gli accordi commerciali tra le parti, piuttosto vogliamo sapere quali sono le relazioni tecniche tra Cloud Imperium Game e il prodotto di Crytek, il CryEngine.
CIG ha infatti condotto un enorme refactoring del CryEngine, e sta portando avanti una ingegnerizzazione continua per supportare lo sviluppo di Star Citizen. Tra i comparti che hanno visto più cambiamenti vediamo l’ottimizzazione del netcode, che abbiamo recensito, la grafica, l’ottimizzazione delle performance, la conversione a 64 bit dei moduli più importanti e tanto altro.
Chiariamoci: perchè un motore a 64bit per Star Citizen?
Riguardo lo Star Engine, Tracy ci ha detto:
“Dunque, lo ‘Star Engine’ è stato molto discusso. Non so quanto ufficiale sia o cose del genere. È una versione molto diversa dal CryEngine; ci siamo distaccati dal CryEngine molto tempo fa. Non lo abbiamo aggiornato per molto tempo – l’ultima versione, da quando abbiamo smesso di utilizzarlo, sarà stata la 3.7 o la 3.8 dell’anno scorso. Ce ne siamo distaccati completamente perchè cominciava a essere difficile gestire le integrazioni. A un certo punto, quando stai sviluppando un gioco attraverso un software di supporto, incontrerai una serie difficoltà nell’integrare parti di sistemi perchè le hai personalizzate così tanto da non essere più compatibili con il tuo software. Dunque, qualsiasi cambiamento tu faccia ai tuoi sistemi che gestiscono l’engine, quando il provider del software ti fornisce un aggiornamento o nuove funzioni, diventa ogni volta duro sfruttarli.“
“Allora cominci a essere selettivo, tipo ‘Ok, beh, utilizzeremo questa feature e questa no.’ Per cui quello che non sai dall’inizio è se ci sono delle interdipendenze su questa o quella feature. Cosa succederà? Lo scoprirai purtroppo quando sarà troppo tardi.“
“Abbiamo fatto scelte selettive solo quando ci siamo trovati di fronte a dei cambiamenti sostanziali nel codice di base. Per CIG è stato così per molto; ho collaborato con Crytek per circa due anni e mezzo e fatto esperienza con le ultime versioni dell’engine supportate.”
Tracy scherza dicendo che a quel punto “era tempo di andare a lavorare per CIG“, e infatti iniziò a collaborare con il team per assistere le attività ingegneristiche. La prossima questione che gli abbiamo posto riguarda la conversione del motore a 64bit, chiedendogli in particolar modo che tipo di revisione è stata fatta per consentire il calcolo a 64bit. Tracy ci ha risposto così:
“Uno dei più importanti cambiamenti nel motore è stata la conversione con precisione a 64bit. Quello che molte persone potrebbero non capire è che non si tratta di una conversione dell’intero engine. Il motore è infatti diviso in un certo numero di moduli indipendenti – anche se non abbastanza, secondo Tracy -. Sono moduli che comunicano tra loro, ma cose come il rendering e l’AI sono sistemi che non hanno motivo di essere convertiti. Per esempio il sistema di positioning utilizzerà 64bit, ma al modulo di AI non gliene importa. Sono stati fatti grandi cambiamenti per supportare le coordinate del grande universo. […] Attualmente supportiamo un mondo a 18 zeri, in termini di spazio.“
E con questo cambiamento, il limite è stabilito su virgola mobile. L’elaborazione a 64bit consente un incremento della capacità di memorizzazione e un maggiore indirizzamento dello spazio virtuale, caratteristiche che entrambe rendono l’universo di Star Citizen possibile. L’elaborazione, così, consente un limite in memoria di 16 exbibyte, corrispondenti a 18,446,744,073,309,551,616 bytes, ecco perchè Tracy ci ha detto dei ’18 zeri’. Probabilmente avete già sentito questo numero in No Man’s Sky e i suoi “18 quintilioni”, comunque a prescindere da quanto sia particolare il gioco che considerate, è un numero molto apparentemente legato a qualcosa, in realtà si riferisce proprio a questo limite in termini di memoria. Questo numero viene fuori ogni volta che si parla di giochi perchè sempre più motori sono in grado di lavorare sotto un’architettura a 64bit e supportare, così, capacità di memoria più elevate. Inoltre, per saziare i pedanti, i numeri riportati sopra tengono conto innanzitutto dell’overhead. Si tratta infatti di valori massimi teorici, non pratici. Alcuni bit sono riservati allo sforzo compiuto dall’hardware.
Tracy continua:
“A quel punto diventa complicato lavorare con la memoria. È davvero strano per le persone che operano con il Cryengine. Stai lavorando a un livello di 4, 8 km al massimo. E già quella scala mi sembrava enorme. Ma è come se – è come sentirsi disorientati avendo a che fare con le coordinate del grande universo. Stai lavorando a qualcosa e poi fai uno zoom all’indietro, e ancora, e ancora.. e puoi ancora ridurlo! Il tuo senso dell’orientamento va a farsi benedire. Può essere un’esperienza disorientante. Se stai guardando un pianeta, stai osservando un’area di migliaia di km, perciò è facile sottostimare quanto sia grande l’impresa e quanto ci voglia per costruire una cosa così.“
“Uno dei più grandi cambiamenti è stato quello che abbiamo fatto con il posizionamento dei pianeti. Penso che con il primo sistema che stiamo costruendo (Stanton) – ma magari la velocità del quantum travel potrebbe cambiare – ci vogliono circa 45 minuti di viaggio alla velocità di jump per attraversarlo. Ed è solamente un sistema. Se volete, pensate ai sistemi come livelli, ed è questo il modo con cui li approcciamo. Non ci saranno praticamente schermate di caricamento per 45 minuti di viaggio quantistico, ovvero a 0.2c [c = velocità della luce]. È pazzesco quanto sia grande.“
Il direttore tecnico di CIG e veterano di Crytek enfatizza che, di tutti i punti che abbiamo trattato, uno dei più critici è capire cosa esattamente significa un “motore a 64bit”. I disparati moduli del CryEngine non necessitano una riscrittura totale per supportare il 64bit. Un esempio è il modulo di AI: l’AI non trarrebbe benefici dall’essere convertito a 64 bit, e quindi lo lasciamo così com’è. Il modulo AI può operare e funzionare in un mondo a 64 bit, ma è controllato da un motore a 32. Contestualmente, la fisica e il sistema di positioning devono essere rivisti per supportare più bit in memoria. A proposito di revisioni, Tracy ci ha detto “Non tutto l’engine deve essere convertito a 64 bit ma avevamo necessariamente bisogno di cambiare fisica e positioning.” Tra l’altro non c’è alcun vantaggio in termini di performance nel caso di Star Citizen. Anzi, con l’elaborazione a doppia precisione, viene incrementato il numero di bit di un fattore di due che può avere un impatto negativo sul tempo per completare un’attività. Elaborare un double richiede lo stesso tempo che richiede l’elaborazione di un single ma l’accesso in memoria per un float è doppio. Questo impatta la cache – che contiene al più la metà di un double – e crea problemi di banda. A differenza dell’hardware, comunque, gli sviluppatori dell’engine di gioco possono ottimizzare l’engine per ridurre i cali di performance a livelli impercettibili. Nel caso di Star Citizen, il team è stato in grado di ottimizzare la performance per i recenti componenti hardware in un modo nettamente migliore rispetto all’engine originale, di fatto annullando qualsiasi impatto sulle performance causato dalla conversione a 64bit.
Queste non sono novità nel mondo della computazione a 64bit, e da quando la doppia precisione è stata utilizzata per la prima volta sul Cray Supercomputer abbiamo portato avanti diverse discussioni. A chiunque interessassero un po’ di esperimenti scientifici, potreste prendere in considerazione di acquistare una scheda video a doppia precisione – come la serie originale Titan (pre Maxwell) – e provare a giocare in modalità doppia precisione forzata e confrontarla con la precisione singola. Nella maggioranza dei casi, anche se sono passati anni dai nostri test, i giochi rallenteranno a causa delle limitazioni di banda, limitazioni di cache, e del doppio utilizzo della memoria che gestisce i float. Tutto quel ‘cibo extra’ per la GPU, nel caso della Titan, era necessario a scopi scientifici e per provare applicazioni simulative. Le cose si fanno molto diverse quando si parla di sviluppo di software e motori, ma lo scaling della performance dipende sempre dallo stesso concetto: più bit in memoria richiedono più tempo per essere processati.
Ma Tracy ci tiene a sottolineare che il team di CIG ha fatto enormi ottimizzazioni e il risultato vede anche un leggero vantaggio di performance a favore della doppia precisione.
“Il motore a 64bit non migliora le performance, o altro. Anzi, potrebbe peggiorarle – ma stiamo parlando di differenza marginali. Con l’avvento delle nuove CPU, abbiamo fatto alcuni cambiamenti su come il sistema di positioning funziona, e lo abbiamo reso più performante. Statisticamente ciò non accade spesso.“
Generazione procedurale dei pianeti V2
Nella nostra recente intervista il CIG di CEO, Chris Roberts, ci ha parlato della parte dei contenuti che riguardano la generazione procedurale V2, e abbiamo ritenuto che fosse necessario approfondire gli aspetti tecnici con Sean Tracy. La prima domanda è semplice: come funziona la generazione procedurale in Star Citizen?
“La differenza tra la V1 e la V2 è: nella V1, quello che avete visto nel nostro demo è un terreno a singolo livello. È un solo materiale. Sì, è vero, abbiamo inserito diverse texture che si mescolano a diverse distanze, ma tutti i pianeti che abbiamo mostrato hanno letteralmente un singolo materiale che li compone. […] In molto giochi dove potrete apprezzare le tecnologie procedurali, non si sono mai spinti oltre. Sono semplicemente soddisfatti dei risultati visivi di un unico materiale roccioso che ricopre il pianeta.“
“Quello che la V2 fa è portarci in linea con come volevamo organizzare i livelli in Crysis, in cui i designer e gli artisti potevano avere accesso a sedici livelli per mixare diversi tipi di texture del terreno, e quello che vogliamo fare è dargli la stessa abilità, ma su una scala tremendamente più vasta. Allora ho pensato: ci vuole troppo tempo per disegnare 8km di spazio, ma è da pazzi farlo su migliaia e migliaia di km. Ma sì, vogliamo dargli quel numero di livelli perchè è l’unico modo per raggiungere una certa qualità in uno sparatutto in prima persona. Non otterremo mai la stessa qualità con una sola texture.”
“Un altro grande step che abbiamo raggiunto con la versione 2 sono i biomi. Sulla V1 non esistevano, c’era solo un singolo livello per il terreno e una mappa dei rilievi. Sulla V2, sono presenti i biomi che sono gestiti tramite livelli che a loro volta stabiliscono la posizione di oggetti e contenuti come il meteo e la vegetazione. Questa volta il CryEngine ci è venuto in soccorso perchè abbiamo cercato di riutilizzare il più possibile gli strumenti che mette a disposizione, solo ovviamente su scala più grande. […] Il livello dei terreni è gestito allo stesso modo con cui vengono gestiti i livelli nel CryEngine 4, dobbiamo solo applicarli ai pianeti, così come per la vegetazione – anche se si tratta di regole decisamente più avanzate.“
Nella prossima parte abbiamo discusso il tema della diversità nella generazione procedurale. Ne avevamo già parlato con Roberts, ma Tracy ci ha fornito ulteriori idee che riguardano il meccanismo di variazione delle risorse che dovrebbe ridurre il senso di “già visto”.
“Per darvi qualche informazione storica, in Crysis avevamo a disposizione 16 modelli di alberi. […] Quello che funzionava alla grande era il sistema che utilizzavamo per piazzarle. Era gestito da una scala variabile, che regolavamo in base a una serie di regole definite a livelli. Abbiamo preso questi strumenti e li abbiamo applicati alle tecnologie procedurali. Possiamo gestire cose come la densità – quanto devono essere vicini gli alberi gli uno con gli altri? Sono disposti in maniera random? È un modo semplice per ottenere buoni risultati e fare molte cose. Potrebbe esserci un albero ruotato in questa maniera (gesto della mano), ma se fossero ruotati tutti allo stesso modo, potreste pensare, ‘oh! L’ho già visto’ Così, ruotandoli in maniera random, molte persone non lo noterebbero, anzi direbbero ‘oh wow! C’è un albero! Ma tu guarda quell’altro!’ anche se si tratta dello stesso. E poi ci si può regolare su vasta scala, sempre gestendo la densità, la distribuzione, etc.“
“Abbiamo imparato molto dai progetti Crysis – e in generale lavorando al CryEngine – esperienza che stiamo applicando agli strumenti per la creazione procedurale. La mentalità del CryTek è stata sempre questa: ‘usa gli strumenti per raggiungere il 90% del tuoi obiettivi, e il resto lascialo fare agli artisti’. È esattamente la stessa filosofia che stiamo applicando, ora, con i pianeti. Vogliamo avere strumenti potenti, perchè ripeto ancora una volta, abbiamo migliaia di corpi celesti da costruire.”
“Molti ci davano per pazzi quando abbiamo preso in considerazione il CryEngine. Beh non è del tutto vero perchè il motore mette a disposizione molti strumenti potenti. E stiamo cercando di utilizzarli. Sarebbe uno sbaglio eliminare tutti i moduli esistenti e non c’è motivo per farlo; vogliamo provare a guadagnare tempo e costruire le build attraverso gli strumenti che l’engine ci mette a disposizione.“
Roberts, durante la prima intervista, ci ha indicato che il team vorrebbe utilizzare il meccanismo di edge blending all’interno del Editor dei pianeti per assicurare una accurata fusione dei biomi senza doverlo fare manualmente. Aspetto ancor più rilevante è che, secondo il team, l’edge blending sarà modificato per fondere le mappe dei biomi e creare ambienti unici. Tracy, a proposito, ci ha detto:
“Attualmente stiamo discutendo molto riguardo l’edge blending, per cui quello che sto per dirvi, probabilmente cambierà. Il ragionamento che facciamo è basato, come ha detto Chris, sull’introduzione di una mappa di distribuzione. Potremmo utilizzarla per stabilire l’esatta posizione dei biomi, ma a quel punto non otterremmo fusioni ottimali. Quello che possiamo fare è – ai margini delle mappe di distribuzione -, sapendo dove finiscono, creare degli intervalli che chiamiamo intervalli di fusione. Il problema di quando si ha a che fare con tanti biomi diversi è che le regole da seguire per effettuare una transizione graduale dall’uno all’altro saranno probabilmente differenti a seconda delle coppie di biomi presi in considerazione.“
“Per la fusione dei livelli del terreno è tutto molto più semplice. lo abbiamo già fatto nei capitoli di Crysis. È una specie di tecnica di ripasso. Abbiamo una mappa in scala di grigi dei dettagli e un’altra meno dettagliata ma colorata. Fonderle risulta banale. Dunque non abbiamo problemi con i livelli del terreno, sono la vegetazione e le attuali risorse a crearcene. Se si passa dal deserto alla giungla, è molto semplice – un po’ di erba sui contorni, e poi cominci a disegnare gli alberi. Ma quando fondiamo montagne con giungle o città – cosa fai? Per cui, molte regole sono basate sulla mappa della distribuzione. Avremo un intervallo e questo intervallo è variabile a seconda di come la vegetazione si fonde. Attualmente, stiamo cercando di portarlo avanti in questa maniera, creando regole abbastanza robuste per ottenere delle buone transizioni, ma non così complesso da risultare poco comprensibile.“
E, infine, Tracy conferma che al CitizenCon (9 Ottobre) vedremo alcuni progressi della tecnologia procedurale V2, incluso il meccanismo di edge blending senza il supporto per oggetti più grandi (non ancora).
Interviste precedenti:
Traduzione a cura di Donniebrasco92
Articolo originale presso Gamersnexus
