id Software rilascia nuove immagini di Rage e spiega le sfide del motore grafico

id Software rilascia nuove immagini di Rage e spiega le sfide del motore grafico

In occasione del Siggraph di New Orleans, J.M.P. van Waveren, senior programmer di id Software, ha spiegato alcune delle caratteristiche del motore grafico di Rage e come la software house texana ha risolto le sfide più ostiche.

di pubblicata il , alle 10:52 nel canale Videogames
 

Per gli appassionati di grafica, J.M.P. van Waveren, in una presentazione tenuta al Siggraph 09 che si è svolto dal 3 al 7 agosto a New Orleans e che è un evento interamente dedicato alla grafica per computer e alle tecniche di intrattenimento, ha spiegato le caratteristiche principali di id Tech 5, ovvero il motore grafico di Rage, e le sfide che la software house texana si è trovata a risolvere.

Come noto, il nuovo motore grafico è basato principalmente sul processo di virtual texturing (in passato indicato con il nome di Megatexturing). Il sistema applica un'unica texture per l'intero mondo di gioco e, in seguito, in una struttura di tipo piramidale applica su di essa le altre texture e gli altri elementi poligonali.

Tech 5 si basa su due assunti di base: streaming delle texture e compressione. Si avvale di due motori di megatexturing: uno è adibito alla gestione del terreno, l'altro di tutte le altre componenti dei mondi di gioco.

Il sistema può generare un ritardo tra il momento in cui la texture è richiesta e quella in cui può essere resa disponibile. id Software ha stabilito che l'immagine deve aggiornarsi con una frequenza di 60 Hz e questo equivale a dire che il motore ha 16 millisecondi per produrre ogni frame e per farlo deve portare a compimento una serie di processi più o meno onerosi per l'hardware.

id Software identifica i seguenti processi: miscela delle animazioni, che richiede 2msec; individuazione delle collisioni, 4msec; elusione degli ostacoli, 4msec; trasparenze, 2msec; virtual texturing, 8msec; processi vari, 4msec; rendering, 10msec; audio, 4msec. Per eseguire tutti questi processi nel lasso di tempo che si è imposta la software house texana è stato necessario creare un'architettura del software che fosse di tipo parallelo. Questo tipo di architettura favorisce l'esecuzione di Rage sui computer dotati di processori multicore, primo dei quali il processore Cell che sta alla base di PlayStation 3. Senza questo tipo di organizzazione, Rage sarebbe pressoché impossibile da eseguire su PlayStation 3.

Il carico di lavoro è stato quindi suddiviso in "jobs", che vengono analizzati e risolti in modo parallelo. I "jobs" di cui si occupa Tech 5 riguardano l'individuazione delle collisioni, la miscela delle animazioni, l'elusione degli ostacoli, il virtual texturing, i processi relativi alle trasparenze (fogliame, effetti particellari), la simulazione dei vestiti e quella delle superfici liquide, la generazione dei modelli (rocce, sassi).

id Software parla anche di supporto per il futuro per sistemi CUDA, OpenCL e Larrabee. Un resoconto completo delle caratteristiche di Tech 5 e delle sfide di cui abbiamo parlato nella news è disponibile in questo pdf. Ricordiamo che nei giorni scorsi lo stesso John Carmack, direttore creativo di id Software, aveva ammesso gli stenti di Tech 5 con l'architettura hardware di PlayStation 3, come riportato qui.

Rage sarà rilasciato nel corso del 2010 nei formati PC, PlayStation 3, XBox 360 e Mac. Qui l'ultimo trailer e qui le più recenti informazioni sul gameplay.

73 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
pioss~s4n07 Agosto 2009, 10:54 #1
Questo Rage ha sempre più l'aria di essere uno spettacolo..
Horizont07 Agosto 2009, 11:01 #2
le immagini sono piccole è...e ciò contribuisce a ridefinirle...però NACCHIO PROF (Cit.) il CIELO E' VERO!
E POI LO COMPRERO' ANCHE SOLO PER L'UOMO FUNGO!
PrototypeR07 Agosto 2009, 11:06 #3
Se il Tech 5 ha anche una fisica ben fatta e un multiplayer degno...credo che lo comprerò da subito.
WarDuck07 Agosto 2009, 11:11 #4
Basta che le texture siano di qualità, non come Doom III dove ti avvicinavi ai muri e vedevi tutto squadrettato e sfocato... va bene usare la compressione però...
Horizont07 Agosto 2009, 11:12 #5
Originariamente inviato da: WarDuck
Basta che le texture siano di qualità, non come Doom III dove ti avvicinavi ai muri e vedevi tutto squadrettato.


esatto, la paura un po' è quella...e le immagini piccole di certo non aiutano il check
The3DProgrammer07 Agosto 2009, 11:23 #6
omg il cielo
mjordan07 Agosto 2009, 11:23 #7
Originariamente inviato da: deepdark
In pratica il problema qual'è? Quello di sfruttare (finalmente) i multicore....e ci voleva la PS3 per farlo???


Con id Software il "finalmente" è fuori luogo. Già Quake III Arena aveva pieno supporto all'SMP, quando SMP era un concetto ignoto al mondo dektop. Quà si parla di architettura del gioco e del concetto di "jobs". Anche se è spiegato in modo grossolano, credo che si intenda ben piu' che dei semplici thread di esecuzione ma dei veri e propri engine separati per compiti diversi eseguiti in parallelo. Parallelismo che va oltre una semplice manciata di thread come nella programmazione tradizionale, visto che quà si parla di OpenCL e, anche se non è indicato nello specifico, sono sicuro che si faccia uso anche di OpenMP.
freedzer07 Agosto 2009, 11:23 #8
Quoto appieno deepdark. E si conosce benissimo il risultato di giochi non ottimizzati.... titoli del 2007 che ancora fanno fatica a girare in DX10 a dettagli alti sui pc odierni.....e sapete tutti di chi sto parlando
Lanfi07 Agosto 2009, 11:32 #9
Qualcosa mi dice che finalmente cominceranno ad essere sfruttati i processori multicore. Se così sarà spero che questo gioco consegua delle ottime vendite, in modo che le altre sh capiscano qual'è la direzione da intraprendere ....
jo.li.07 Agosto 2009, 11:38 #10
Originariamente inviato da: mjordan
Con id Software il "finalmente" è fuori luogo. Già Quake III Arena aveva pieno supporto all'SMP, quando SMP era un concetto ignoto al mondo dektop. Quà si parla di architettura del gioco e del concetto di "jobs". Anche se è spiegato in modo grossolano, credo che si intenda ben piu' che dei semplici thread di esecuzione ma dei veri e propri engine separati per compiti diversi eseguiti in parallelo. Parallelismo che va oltre una semplice manciata di thread come nella programmazione tradizionale, visto che quà si parla di OpenCL e, anche se non è indicato nello specifico, sono sicuro che si faccia uso anche di OpenMP.


Si, ho letto anche io il pdf e sembra che abbiano o siano stati costretti ad usare il concetto di "jobs" al posto dei thread per la particolare architettura del processore cell. In più come diciamo effetto collaterale penso gradito di questo engine ci sarà la possibilità di poterlo sfruttare anche tramite OpenCl e quindi molti di quei compiti che di solito svolge la CPU verranno delegati alle unità di calcolo vettoriale delle GPU.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^