Dynamic Branching demo

[Pat77]

Originariamente inviato da flavix25
confermo quello detto da Pat77 e agiungo che sia con i filtri che senza il gioco va sempre a 9 frame. sempre a 1024x768


Una cosa mi fa pensare, dato che dovrebbe girare anche su una 5200 cosa significa che se con la mia fa 9 frame con la 5200 quanti ne fa 0,0005?

Esatto, con filtri o senza poco cambia, girando un po' faccio dai 7 minimo ai 13 massimo con una media simile alla tua.

Puoi mandare tutto via mail a [email protected], se hai bisogno di pubblicarlo posso farlo solo domani (non ho qui il login del mio spazioweb).

Tornando al bench con questo framerate non riesco ad apprezzare la bontà tecnologica di questo dimostratico, spero di poterlo vedere non dico tanto ma almeno a 50 Fps anche se capisco che sono esercizi pensati per un altro hw.

Pk77

[flavix25]

ho fatto circa 12300 frame ma con un piccolo sotterfugio, niente modifica immagine tutto reale

[Pat77]

Su 5600 e Athlon palo 1800+ siamo sui 3 Fps

Viva l'ottimizzazione

[fek]

Originariamente inviato da Maury
Mi chiedo cosa aspetta HUMUS a creare un engine 3d tutto suo, ca@@o qst è un drago, sforna demo tecnologiche come pane

Scrivere una demo non e' scrivere un engine per un gioco, sono due problemi del tutto diversi con soluzioni diverse. Ad esempio questa demo e' un bell'esercizio di programmazione, ma e' sostanzialmente inutile in un motore 3d di produzione:

Originariamente inviato da fek :


Chiariamo il problema.
Il problema sembra quello di renderizzare un oggetto con 4 luci per pixel nella maniera piu' efficiente possibile.
Ovviamente si raggiunge lo scopo di renderizzare un oggetto con 4 luci sia con e' PS2.0 sia con PS3.0 (trascuriamo ora il problema di non avere abbastanza istruzioni con i PS2.0).

Io lo feci 2 anni fa in una sola passata con stencil shadow. Era ragionevolmente veloce su un R300 e faceva sempre tutti i calcoli.

Una possibile ottimizzazione e' capire quando un pixel e' illuminato da meno di quattro luci (magari perche' una luce e' troppo lontana), cosicche' si possono evitare i calcoli delle luci che non influenzano il pixel stesso.

Come affronterei il problema?
Per prima cosa cercherei di capire quanto gli oggetti sono mediamente grandi rispetto al raggio d'azione delle luci. Se sono piu' "piccoli", allora mi limiterei a capire quante luci influenzano l'oggetto ed userei lo shader corrispondente: semplice, veloce ed efficiente. Niente dynamic branching, nella maggior parte delle occasioni basta e avanza.

Ma ammettiamo di trovarci in una condizione particolare (che non e' la norma) nella quale un oggetto molto grande tipo un muro ha alcune parti illuminate da una luce, altre parti da due, e cosi' via, di modo che renderizzare tutti i pixel sempre con quattro luci non e' conveniente.

Come risolvere il problema?
Sicuramente in una condizione particolare come questa, stiamo parlando di un fps, il numero di batch non e' un problema e se posso permettermi un po' di CPU, allora suddivido il muro in diverse batch e per ogni batch trovo il numero di luci che lo influenza. Semplice da implementare, non richiede dynamic branching o doppie passate e si scopre che nel 99.9% dei casi e' piu' veloce che usare dynamic branching o una sua emulazione.

Ma supponiamo di trovarci in una situazione nella quale non posso permettermi neppure quell'overhead di CPU e sto usando troppo fillrate. Come risolvere il problema?
Si ripensa tutta la pipeline di rendering, perche' se ci si trova in questa situazione allora c'e' qualcosa di grosso che non funziona e non serve andare a scomodare il dynamic branching: e' molto meglio ripensare il sistema daccapo.

Morale della favola: una cosa e' scrivere una demo, totalmente un'altra cosa scrivere il motore 3d di un gioco

http://www.nvitalia.com/forum/showth...5&pagenumber=2

[Maury]

Originariamente inviato da fek
Scrivere una demo non e' scrivere un engine per un gioco, sono due problemi del tutto diversi con soluzioni diverse. Ad esempio questa demo e' un bell'esercizio di programmazione, ma e' sostanzialmente inutile in un motore 3d di produzione:



http://www.nvitalia.com/forum/showth...5&pagenumber=2

Nn lo metto in dubbio, ma altresì vedo Humus capace di fare qualcosa di ben più importante che semplici demo, ha stoffa il ragazzo

[MaBru]

Originariamente inviato da Maury
Nn lo metto in dubbio, ma altresì vedo Humus capace di fare qualcosa di ben più importante che semplici demo, ha stoffa il ragazzo

Adesso lavora in Ati, non so se gli lasciano il tempo di "cazzeggiare".

[fek]

Originariamente inviato da Maury
Nn lo metto in dubbio, ma altresì vedo Humus capace di fare qualcosa di ben più importante che semplici demo, ha stoffa il ragazzo

Hai mai visto delle demo serie nella Demo scene mondiale? Tipo quelle che partecipano all'Assembly tutti gli anni.
Fanno cose allucinanti, ma prova a prendere uno di quei programmatori e mettilo in un progetto della durata di due anni assieme ad altri 15 programmatori.
La meta' dei democoder non sa neppure dove stanno le classi di casa.
Non dico che Humus non sia bravo (lo e', se e' stato assunto da ATI), ma dico che fare delle belle demo non significa automaticamente essere dei buoni programmatori. Anzi.

[fabiannit]

Originariamente inviato da REPSOL
C'è pure il buon vecchio 3DC, se avete ut1 provatelo e guardate che goduria, altro che ut2004

Ciaoz

Cioè??
l'hai applicato a unreal 1 ??

[REPSOL]

Originariamente inviato da fabiannit
Cioè??
l'hai applicato a unreal 1 ??

No ho detto una stronzeta assurda
Mi ero confuso con le buon vecchie S3TC

Che differenza c'è? che cambia di un inezia l'algoritmo di compressione?

Dai fek spiegame la differenza da 3DC a S3TC (sempre che si possano paragonare, visto che non ne so quasi nulla sulle 3DC).

Se volete vedere qualche shot di unreal tournament 99 (non unreal1):

http://repsol.altervista.org/immagin...n/Shot0022.JPG
http://repsol.altervista.org/immagin...n/Shot0023.JPG
http://repsol.altervista.org/immagin...n/Shot0024.JPG

Ho deciso di non metterle come immagini, perchè sono quasi 400kb l'una, se le volete vedere cliccateci

Guardate cosa poteva fare un gioco del 99 con quella magnifica compressione di textures.

Ciaoz

[fabiannit]

ah...ecco, ora mi spiego tutto