MaBru
02-07-2004, 09:23
http://esprit.campus.luth.se/~humus/3D/index.php
View Full Version : Dynamic Branching demo
Maury
02-07-2004, 09:44
Mi chiedo cosa aspetta HUMUS a creare un engine 3d tutto suo, ca@@o qst è un drago, sforna demo tecnologiche come pane :eek:
DjLode
02-07-2004, 09:46
Se guardi nei vecchi demo, l'ha fatto :)
.Kougaiji.
02-07-2004, 12:52
O_O però .-. quasi 300 fps in media con 9800xt :x
Maury
02-07-2004, 12:53
Originariamente inviato da DjLode
Se guardi nei vecchi demo, l'ha fatto :)
Nn lo sapevo, farò una capatina sul suo sito ;)
Ma è una cosa completa oppure appena abbozzata ? io intendevo una cosa tipo l'engine di Far Cry o di Doom3, sn convinto che ne è perfettametne capace :)
Se guardi nei vecchi demo, l'ha fatto :)
Nn lo sapevo, farò una capatina sul suo sito ;)
Ma è una cosa completa oppure appena abbozzata ? io intendevo una cosa tipo l'engine di Far Cry o di Doom3, sn convinto che ne è perfettametne capace :)
DjLode
02-07-2004, 12:55
Ah non so, credo sia roba vecchissima...
andreamarra
02-07-2004, 19:53
L'avete provato :) ??
REPSOL
02-07-2004, 20:39
C'è pure il buon vecchio 3DC, se avete ut1 provatelo e guardate che goduria, altro che ut2004 :D
Ciaoz
Ciaoz
TheDarkAngel
02-07-2004, 20:54
quello delle bandiere (chiamato clothes) è impressionante :eek:
Pat77
04-07-2004, 22:19
Dynamic branching su una 5900 (1024x768) Fsaa 4x Af 8x mi va in media a 8 fps :O
E' l'unico demo in cui ho problemi di performance :O
Pk77
E' l'unico demo in cui ho problemi di performance :O
Pk77
TheDarkAngel
04-07-2004, 22:37
Originariamente inviato da Pat77
Dynamic branching su una 5900 (1024x768) Fsaa 4x Af 8x mi va in media a 8 fps :O
E' l'unico demo in cui ho problemi di performance :O
Pk77
l'hai usata poco quella sk video allora :asd:
Dynamic branching su una 5900 (1024x768) Fsaa 4x Af 8x mi va in media a 8 fps :O
E' l'unico demo in cui ho problemi di performance :O
Pk77
l'hai usata poco quella sk video allora :asd:
Pat77
04-07-2004, 22:47
Non direi, se una 9800xt fa 300 fps di media è evidente che ci sono dei problemi o semplicemente una programmazione mirata come si legge nelle pagine dove si fa il download dei demo.
Per il resto non ho mai avuto problemi di prestazioni da quando è entrata nel mio case.
Pk77
Per il resto non ho mai avuto problemi di prestazioni da quando è entrata nel mio case.
Pk77
Yagami
04-07-2004, 22:51
Con il bartolo a 2.5gigi e X800pro in Dynamic branching faccio dai 360 ai 410 fps a default (a 600/585 faccio dai 470 a 500).
Con il bartolo a 2.5gigi e X800pro in 3Dc faccio 220 di media (a 600/585 faccio 280 di media).
Cmq ho notato che è uscito anche il bench di Ruby sia per NV40 che per R420 :confused:
Con il bartolo a 2.5gigi e X800pro in 3Dc faccio 220 di media (a 600/585 faccio 280 di media).
Cmq ho notato che è uscito anche il bench di Ruby sia per NV40 che per R420 :confused:
Pat77
04-07-2004, 23:18
Ma con quali impostazioni?
Yagami
04-07-2004, 23:30
Di driver? Su bilanciato.
Domani in caso faccio con AA8x e AF16x se ti serve.
Domani in caso faccio con AA8x e AF16x se ti serve.
Pat77
04-07-2004, 23:41
Parlo delle impostazioni interne del progemma, puoi mettere la risoluzione e modalità finestra o pieno schermo, questo influisce molto sulle performance ho notato.
Pk77
Pk77
flavix25
04-07-2004, 23:49
ora provo su una 5900xt con frequeze della 5900 per vedere se ci sono problemi con gf.
Devo mettere qualche impostazione particolare nel demo?
Devo mettere qualche impostazione particolare nel demo?
Pat77
04-07-2004, 23:53
Schiacciando f1 prova a mettere 1024x768 full screen
Il Demo gira su un 2800xp barton con un giga di ram, provando senza filtri faccio 7 fps.
Pk77
Il Demo gira su un 2800xp barton con un giga di ram, provando senza filtri faccio 7 fps.
Pk77
flavix25
04-07-2004, 23:59
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?
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?
flavix25
05-07-2004, 00:03
x pat77 hai un sito per publicare uno screen? ti devo inviare una bella cosa e poi ti spiego come ci sono riuscito!
Pat77
05-07-2004, 00:11
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 patrick@unifinsrl.it, 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
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 patrick@unifinsrl.it, 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
05-07-2004, 00:24
ho fatto circa 12300 frame ma con un piccolo sotterfugio, niente modifica immagine tutto reale
Pat77
05-07-2004, 08:30
Su 5600 e Athlon palo 1800+ siamo sui 3 Fps :O
Viva l'ottimizzazione :D
Viva l'ottimizzazione :D
fek
06-07-2004, 10:20
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 :eek:
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/showthread.php?s=&threadid=37314&perpage=15&pagenumber=2
Mi chiedo cosa aspetta HUMUS a creare un engine 3d tutto suo, ca@@o qst è un drago, sforna demo tecnologiche come pane :eek:
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/showthread.php?s=&threadid=37314&perpage=15&pagenumber=2
Maury
06-07-2004, 10:26
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/showthread.php?s=&threadid=37314&perpage=15&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 :)
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/showthread.php?s=&threadid=37314&perpage=15&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
06-07-2004, 10:29
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".
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
06-07-2004, 10:35
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.
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
08-07-2004, 09:54
Originariamente inviato da REPSOL
C'è pure il buon vecchio 3DC, se avete ut1 provatelo e guardate che goduria, altro che ut2004 :D
Ciaoz
Cioè??
l'hai applicato a unreal 1 ?? :wtf:
C'è pure il buon vecchio 3DC, se avete ut1 provatelo e guardate che goduria, altro che ut2004 :D
Ciaoz
Cioè??
l'hai applicato a unreal 1 ?? :wtf:
REPSOL
08-07-2004, 13:13
Originariamente inviato da fabiannit
Cioè??
l'hai applicato a unreal 1 ?? :wtf:
No ho detto una stronzeta assurda :D
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/immagini/S3TC/Niven/Shot0022.JPG
http://repsol.altervista.org/immagini/S3TC/Niven/Shot0023.JPG
http://repsol.altervista.org/immagini/S3TC/Niven/Shot0024.JPG
Ho deciso di non metterle come immagini, perchè sono quasi 400kb l'una, se le volete vedere cliccateci :D
Guardate cosa poteva fare un gioco del 99 con quella magnifica compressione di textures. :D
Ciaoz
Cioè??
l'hai applicato a unreal 1 ?? :wtf:
No ho detto una stronzeta assurda :D
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/immagini/S3TC/Niven/Shot0022.JPG
http://repsol.altervista.org/immagini/S3TC/Niven/Shot0023.JPG
http://repsol.altervista.org/immagini/S3TC/Niven/Shot0024.JPG
Ho deciso di non metterle come immagini, perchè sono quasi 400kb l'una, se le volete vedere cliccateci :D
Guardate cosa poteva fare un gioco del 99 con quella magnifica compressione di textures. :D
Ciaoz
fabiannit
08-07-2004, 13:40
ah...ecco, ora mi spiego tutto :D
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.