I Criterion hanno svelato una delle caratteristiche che differenzierà la versione PC di Burnout Paradise da quanto abbiamo visto su PlayStation 3 e Xbox 360: si tratta della tecnica chiamata “ambient occlusion”.
Ambient occlusion non è altro che un algoritmo per creare “soft shadows”, ombre realistiche che aggiungono profondità all’immagine su schermo. Potete vedere i risultati dallo scatto che accompagna questo articolo, anche se i Criterion sono pronti a giurare che l’effetto è più evidente in movimento.
Fra le altre novità per la versione PC (che non ha ancora una data di uscita), ricordiamo ingrandimento del multiplayer, funzioni online avanzate, possibilità di creare contenuti e modalità Ultra-Wide Screen.
via | Criterion Games
Seguici
Dragon's Dogma: la recensione
Action Replay 3DS/DSi/DS: la recensione
Mortal Kombat - la recensione per PS Vita
gamesblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Gamesblog.it contattare la concessionaria esclusiva Populis Engage.
MC 4 ever
12 giu 2008 - 09:10 - #1lool il bello è che in un altro forum stavo parlando proprio di questo
in oltre le ombre su gli oggetti sono estremamente realistiche
l’algoritmo è molto veloce (quello delle SSAO)
tanto è che in questo forum uno di nome vicentz l’ha programmate senza usare gli SHADER!!!
Cino
12 giu 2008 - 09:14 - #2L’ambient occlusion in molti casi da un tocco di realisticità in più e non capisco come mai non lo adottino tutti, dato che è anche relativamente leggero… Di certo ne sento la mancanza in ninja gaiden :(
Mi ricorco che in principio è nato come plugin per cinema 4d, poi è stato applicato ai videogiochi.
MC 4 ever
12 giu 2008 - 09:17 - #3@plugin per cinema 4d,
davvero!’ non lo sapevo
io ho il vecchio C4D originale
esiste un plugin per questa versione!?
O è già “incluso”
Antonio.Reset
12 giu 2008 - 10:49 - #4è incluso se non sbaglio dalla versione 9 di c4d, prima dovevi usare un plugin free.
E’ errato credere che sia un algoritmo veloce, nei processi tradizionali di rendering (da cpu) aumenta la durata del processo di almeno il 100%.
Alla fine calcola dove la luce viene occlusa dove coincidono 2 o + oggetti, lanciando dei samples e calcolando il disturbo delle ombre.
Fran
12 giu 2008 - 12:05 - #5>L’ambient occlusion in molti casi da un tocco di realisticità in più e non capisco come mai non lo adottino tutti, dato che è anche relativamente leggero
Non e’ cosi’ leggero. E’ sempre uno o due millisecondi se vuoi implementarlo in maniera hce sia effettivamente utile. In un gioco di macchine dove le caratteristiche prestazionali sono abbastanza costanti e prevedibili, si possono allocare quei due millisecondi a discapito di altro. In giochi con ambienti piu’ vasti e meno prevedibili questo non e’ sempre possibile. Si ricorre ad altri trucchi.
E’ una questione di trade-off.
Fran
12 giu 2008 - 12:08 - #6>anto è che in questo forum uno di nome vicentz l’ha programmate senza usare gli SHADER!!!
Con la sola imposizione delle mani? :D
Giusto!!
12 giu 2008 - 12:24 - #7fantastico tutto questo che dite… ma la data di uscita?XD
MC 4 ever
12 giu 2008 - 13:25 - #8io ho la versione 6 e 7
MC 4 ever
12 giu 2008 - 13:28 - #9@Fran
che domande fai lol l’ha programmate da 0 (vicentx/z)
funzionano anche sensa l’ausilio degli SHADER
anche se più lente :P
che frase idi@ta da parte tua
sono solo più lenti ma se le otimizi .. giraro ugualmente anche su schede che supportano solo la DX7 XD
Fran
12 giu 2008 - 13:55 - #10Sei sicurissumo di cio’ che dici? Sei certo che SSOA si possa implementare su GPU di classe DX7? ;)
MC(il vero)
12 giu 2008 - 15:03 - #11http://img210.imageshack.us/my.php?image=v13dh6.jpg
queste sono quelle che sto citando sotto DX7 non sono come quelle che usano gli SHADER randerizate con un immagine 800×600 su una GF8800 vanno a 30 fps xD
cmq funzionano
glorfindel
12 giu 2008 - 15:20 - #12Sarebbe bello apprezzare la differenza in un’immagine più grande di un francobollo come quella postata…
Fran
12 giu 2008 - 16:29 - #13MC, credo che tu stia facendo un po’ di confusione, ma mi spiegheresti come implementeresti SSOA senza shader ed renderizzare su una GPU che non ha fixed pipe come la serie 8 di NVIDIA? :-)
MC 4 ever
12 giu 2008 - 17:47 - #14non so
non è l’algoritmo ufficiale è modificato
e non l’ho fatto io so
solo che gira sulla mia 9400 ati XD del mio pc in DX7 visto che l’engine utilizato gira in DX7
Fran
12 giu 2008 - 18:11 - #15Allora provo ad essere sintetico: SSOA senza shader non si implementa su una GPU.
Serve eseguire della matematica relativamente complessa per ogni frammento su schermo, ed inoltre serve per ogni frammento la distanza dalla telecamera.
Un semplice filtro di sharpening sul depth buffer non e’ SSOA :)
MC 4 ever
12 giu 2008 - 21:26 - #16con sdk di blitz con funzioni esterne si può fare quello detto
da te
anche se con un sdk che supporta solo la DX7
ecco la demo
http://digilander.libero.it/eyeandlight/Demo_Occlusion_Ambient_v009.zip
SSOA senza SHADER
MC 4 ever
12 giu 2008 - 21:26 - #17è un truchetto usato in crysis :D
Fran
12 giu 2008 - 21:33 - #18Crysis usa una ricerca stocastica sul depth buffer. ovviamente implementata in uno shader, per valutare l’AO per pixel.
Ascolta, visto che per tua stessa ammissione non e’ roba tua e non sai che cosa ci sia dentro, perche’ non ti fidi visto che io queste cose le faccio per lavoro? :)
MC 4 ever
12 giu 2008 - 21:44 - #19perché chi l’ha fatto l’ha detto che non usa gli SHADER
e visto che io e lui usiamo lo stesso sdk so che gira solo sotto DX7
perché ti initigni tanto lol
Fran
12 giu 2008 - 21:58 - #20Allora ha detto una cosa errata :)
Mi limito a correggere un grossolano errore.
MC 4 ever
12 giu 2008 - 22:03 - #21lol se non erro è possibile vede che api sta usando una plicazione … basta vedere se gira sotto DX7 (e chissa perché sono sicuro ) per capire se usa gli shader oppure no…
MC 4 ever
12 giu 2008 - 22:11 - #22cmq buona notte programmatore di fable (se non ero XD)
iol
12 giu 2008 - 23:33 - #23MC, certo che puoi farlo senza shader, accedendo al depthbuffer (o asserirlo dalla scena) e, calcolando e disegnano pissssel x pissselll la tua bella texturona ( o meglio, campionarne alcuni aleatoriamente ed andare giu di blurr)
E cade pure uno dei vantaggi del SSAO, quello di appoggiarsi appunto solo sulla gpu..
senza contare che 1) la resa sarà con ogni probabilità inferiore rispetto alla controparte reale SSAO (senza contare che con Dx7 senza shader ti mancano una montagna di altri effetti che bene o male completano il fotorealismo SSAO: avere solo il SSAO senza gli altri filtrozzi non è la stessa cosa…)
2) le prestazioni in termini di framerate saranno nettamente inferiori. E’ gia molto che ti faccia un 60 fps renderizzando una stanza medio-complessa, texturizzata, senza ombre nè niente… figuriamoci se vuoi aggiungere l’odierno stardard minimo che prevedere appunto ombre in realtime: ingiocabile.
The Edge
13 giu 2008 - 00:18 - #24MC io mi fermerei prima che la figura di m3rd@ raggiunga proporzioni bibliche.
Vincentx
13 giu 2008 - 09:33 - #25Allora dato che si parla di me vorrei rispondere ad un pò di domande ;)
come diceva “MC 4 Ever ” e vero non uso alcun SHADER! elaboro lo Zbuffer (in accessibile o nostro SDK) come crysis e in oltre ora riesco a fare oltre i 30FPS,
difatti per sopperire nella versione 15 ho dovuto utilizzare delle dll che avevamo utilizzato per le ombre per disattivare e riattivare dei filtri.
PS: anch’io ero un ex programmatore professionista di video giochi, ora mi occupo sempre di 3D ma in altri campi dove si lavora con qualche milione di poligoni al 30 di secondo in C++ e OpenGL il mio linguaggio nativo.
Ho lavorato con la Raylight di Napoli che approfitto a salutare, con la quale abbiamo sviluppato Wing Commander Prophecy per GBA in 3D R-Type 3 con un motore di rendering Pixel x Pixel.
Un saluto a tutti anche se non vi conosco
Ciao ;)
Fran
13 giu 2008 - 10:27 - #26A parole si puo’ anche essere campioni olimpici di sci :)
Ma nei fatti stai scrivendo cose che non hanno senso, perche’ in fixed pipe non puoi fare la decina di texture fetch piu’ la matematica che serve per valutare l’AO per pixel. Inoltre, in DX7 (ma neppure in DX8 e in DX9 solo via qualche trucchetto) il depth buffer non e’ accessibile come texture.
Se sei riuscito a fare qualcosa che il resto del mondo non ha fatto, rendi per cortesia pubblico il codice. Grazie.
Vincentx
13 giu 2008 - 11:55 - #27ma …. mi sembra che la demo parli chiaro non ho detto che devo andar sulla luna utilizzando le gli sci :D
sto scrivendo qualcosa per dar la possibilità a i comuni esseri umani che non possiedono schede video da €300 in su di far qualcosa di carino anche con una geforce2 che possiedo sul mio vecchio pc di test che cmq fa 10fps
certo al momento non ci sono soft shadow che con il sistema che ho messo su, perdendo qualche fps potrò gestire.
poi mi permette di far una grande esperienza sull’elaborazione pixel che sembra ormai dimenticata!
e a sua volta mi permette anche di capire come migliorare il codice degli shader.
i demo coder di un tempo facevano cose assurde con macchine che oggi scartiamo o conserviamo sotto 3 metri di polvere, di tanto in tanto guardo il mio vecchio amiga 1200 e una lacrimuccia scende.
mi Scrivi:
“Se sei riuscito a fare qualcosa che il resto del mondo non ha fatto, rendi per cortesia pubblico il codice. ”
ma io non ho scoperto nulla di nuovo ho solo riprodotto un effetto con i mezzi a mia disposizione ed in più con un Basic nello specifico Blitz3D.
ma l’ho provato anche scrivendo un pezzo di codice (DLL) per bliz e sono andato anche oltre.
be io ora devo lavorare ci risentiamo quanto prima
Ciao
Fran
13 giu 2008 - 12:46 - #28Ripeto che stai scrivendo non-sense perche’ l’SSOA alla Crysis senza shader non si fa, non solo non c’e’ riuscito nessuno, ma e’ tecnicamente impossibile. Ma puoi sempre postare il codice e smentirmi :)
Vincentx
13 giu 2008 - 15:20 - #29il codice te lo scordi ………
anzi ..
ora ti posto una parte del codice senza 2 funzioni ora trova il sistema per il deph buffer qui si vede il vero rogrammatore.
e come dice Degac :
“Se c’è un problema c’è almeno una soluzione. ”
Function GIL_ProcessImmage(YStart,YStop)
;===>
GIL_PI_Read(YStart,YStop) ; quì leggo li Depth Buffer
;===>
GIL_PI_GenAO(YStart,YStop) ; e quì c’è la generazione dell’SSAO
;===>
;GIL_PI_Smooth(YStart,YStop) ; Questo è lo smo….
;===>
GIL_PI_Write(YStart,YStop) ; quì Genero l’immanige
;===>
End Function
Function GIL_AO3%( TexCoord)
;======================================
;
Local Dist#= GIL_Depth(TexCoord); + GIL_LenghtRay;
GIL_AO_Value# = 0.0;
Local id%,Idx%,Idy%;
;======================================
For id=1 To GIL_Interation
;===>
Idx = id*id
Idy = GIL_SizeTexAO*id*id
;===>
GIL_Ray0 = Dist >= GIL_Depth(TexCoord+Idy)
GIL_Ray1 = Dist >= GIL_Depth(TexCoord+Idx+Idy)
GIL_Ray2 = Dist >= GIL_Depth(TexCoord+Idx)
GIL_Ray3 = Dist >= GIL_Depth(TexCoord+Idx-Idy)
GIL_Ray4 = Dist >= GIL_Depth(TexCoord-Idy)
GIL_Ray5 = Dist >= GIL_Depth(TexCoord-Idx-Idy)
GIL_Ray6 = Dist >= GIL_Depth(TexCoord+Idy)
GIL_Ray7 = Dist >= GIL_Depth(TexCoord-Idx+Idy)
;===>
GIL_AO_Value = GIL_AO_Value + GIL_Ray0 + GIL_Ray1 + GIL_Ray2 + GIL_Ray3 + GIL_Ray4 + GIL_Ray5 + GIL_Ray6 + GIL_Ray7;
;GIL_AO_Value = GIL_AO_Value + GIL_Ray0 * GIL_Ray1 * GIL_Ray2 * GIL_Ray3 * GIL_Ray4 * GIL_Ray5 * GIL_Ray6 * GIL_Ray7;
;===>
Next
;======================================
;===>
Return GIL_AO_Value
;===>
End Function
Function GIL_PI_GenAO(YStart,YStop)
Local pix#, pix1#, x, y, offsetY, b,blur=2
;===>
;For y=0 To GIL_SizeTexAO-1
For y=YStart+GIL_Interation To YStop-GIL_Interation
offsetY = y*GIL_SizeTexAO
For x=GIL_Interation To GIL_SizeTexAO-GIL_Interation
;===>
GIL_AOBuffer(x+offsetY) = ((GIL_AO3(x+offsetY)*GIL_InterationMUL)And MaskBit)
;===>
Next
Next
;===>
End Function
oltre questo non mi chiedete anche perchè non vi rispondo!
Spazio alle proprie conoscenze !!
Fran
13 giu 2008 - 15:40 - #30Ovvio che mi scordo il codice ed e’ ovvio che non rispondi ad altro. Perche’ quello che stai scrivendo non ha senso e non puoi dimostrarlo.
Scrivere AO in una funzione in Basic non vuol dire fare SSAO. Come dimostrato, senza shader non si puo’ fare su una GPU.
Il vero programmatore lavora :)
The Edge
13 giu 2008 - 15:52 - #31ma veramente un semi analfabeta e uno che spara pezzi di codice a caso vogliono continuare a discutere con un programmatore 3D che lavora per uno dei game designer più leggendari della storia dei videogiochi? Ma avete almeno la sensibilità necessaria per percepire il limite del ridicolo?
Invece di approfittare per imparare qualcosa usate toni arroganti e saccenti con uno che ste cose le fa per lavoro, e ad altissimi livelli… un po’di pudore no?
Maurizio Sciglio
13 giu 2008 - 16:19 - #32“sto scrivendo qualcosa per dar la possibilità a i comuni esseri umani che non possiedono schede video da €300 in su di far qualcosa di carino anche con una geforce2 che possiedo sul mio vecchio pc di test che cmq fa 10fps”
Il mondo te ne sara’ grato :)
A parte gli scherzi, un filtro su una immagine lo puoi scrivere anche in Cobol ma da qui ad implementare una tecnica real-time che deve essere utilizzata per qualcosa leggermente piu’ avanzato di un cubo che ruota nello spazio ovviamente ne passa.
Altra cosa che non mi convince… vuoi ottimizzare il tuo codice e usi Basic? C’e’ qualcosa che non mi torna.
Fran
13 giu 2008 - 16:30 - #33Uh, Maurizio :-)
Vincentx
13 giu 2008 - 16:44 - #34Ho capito che credete di essere degli Dei e per tanto non ammettete nulla che sia fuori dai tuoi schem, quindi non c’è verso di farvi ragionare, non serve neanche continuare.
chiudo qui questa discussione, e in bocca al lupo per i vostri progetti.
ciao
Maurizio Sciglio
13 giu 2008 - 16:50 - #35Stai facendo tutto tu. Ti e’ stato solo fatto notare che tu hai scritto un filtro per un’immagine, non SSAO in GPU.
Hai poi ignorato la seconda parte della mia risposta. Come mai hai scelto di utilizzare Basic se il tuo obiettivo era quello di ottenere il massimo delle prestazioni su hardware vecchio?
David
13 giu 2008 - 16:59 - #36Vincentx: secondo me, se come tu stesso asserisci ne sei in grado, puoi “farli ragionare” solamente dimostrando le teorie che sostieni e argomentando, non postando pezzi di codice incompleti e poi dicendo “dopo di questo non vi dico più niente”.
Io non ci capisco moltissimo di programmazione quindi non mi esprimo, ma dal tuo comportamento pare proprio che abbia ragione chi dice che non sai più su quali specchi arrampicarti :)
Se hai modo di dimostrare quel che dici fallo e basta, altrimenti significa che non puoi, che stai facendo il finto offeso perché non sai più cosa dire e che tutta questa discussione è sempre stata inutile ;)
P.S.
The Edge smorza un po’ i toni ;)
Vincentx
13 giu 2008 - 17:13 - #37come ho già detto il codice primario non lo posto per il semplice morivo che ho creato qualcosa ad ok per simularlo ho detto che a testimonianza posto una demo non vedo cosa di più, il codice non lo voglio postare la teoria è == a quella di crysis .
il perchè lo sto facendo in basic?
l’ho accennato nella prima fase, perché basta scrivere poche righe di codice per far tutto l’indispensabile di base tipo caricare gli oggetti aprire uno schermo etc… poi gli faccio una strutture bozza tipo quella che ho scritto prima con le parti rimanenti, e se il gioco vale la candela lo faccio in C++ con tutti i crismi, e lo faccio già con un codice debaggatto al quale devo solo applicare le ottimizzazioni opportune del C.
spero di esser stato chiaro
Vincentx
13 giu 2008 - 17:13 - #38come ho già detto il codice primario non lo posto per il semplice morivo che ho creato qualcosa ad ok per simularlo ho detto che a testimonianza posto una demo non vedo cosa di più, il codice non lo voglio postare la teoria è == a quella di crysis .
il perchè lo sto facendo in basic?
l’ho accennato nella prima fase, perché basta scrivere poche righe di codice per far tutto l’indispensabile di base tipo caricare gli oggetti aprire uno schermo etc… poi gli faccio una strutture bozza tipo quella che ho scritto prima con le parti rimanenti, e se il gioco vale la candela lo faccio in C++ con tutti i crismi, e lo faccio già con un codice debaggatto al quale devo solo applicare le ottimizzazioni opportune del C.
spero di esser stato chiaro
il demo lo scaricate da quì
http://digilander.libero.it/eyeandlight/Demo_Occlusion_ambient_v016.zip
Fran
13 giu 2008 - 17:19 - #39> come ho già detto il codice primario non lo posto per il smplice morivo
Non lo posti per il semplice motivo che quello che hai scritto non e’ SSAO. Francamente quello che hai scritto non si capisce proprio che cosa sia a parte qualche linea di codice casuale in Basic.
Per il resto ti consiglio di approfondire la differenza fra una CPU e una GPU.
Maurizio Sciglio
13 giu 2008 - 17:28 - #40Ho provato la demo e a parte diversi errori visivi molto evidenti l’applicazione gira a 15 FPS su un Quad Core e NVidia 9800 confermando che un approccio del genere totalmente basato su CPU non e’ assolutamente fattibile per diverse ragioni che se vuoi sono ben lieto di approfondire con te.
Vincentx
14 giu 2008 - 07:38 - #41accetto ben volentieri “Maurizio Sciglio” lo scambio di opinioni, anche perche solo così si può imparare e non dire no a priori.
quando vuoi ci risentiamo ciao
Fran
16 giu 2008 - 12:30 - #42Non stiamo dicendo no a priori, stiamo dicendo no perche’ sono cose che abbiamo fatto e che conosciamo :)