Annonces Google
Serveur IRC
Serveur : irc.portlane.se
Canal : #AmigaNG
Activité du Site

Pages vues depuis 25/07/2007 : 25 286 896

  • Nb. de membres 187
  • Nb. d'articles 1 270
  • Nb. de forums 19
  • Nb. de sujets 20
  • Nb. de critiques 24

Top 10  Statistiques

Index du forum »»  Création-Développement »» Nouveau moteur 3D (PXS Alpha)

Nouveau moteur 3D (PXS Alpha)#886

15Contributeur(s)
CrisotphardfrK-LMurakamiAmiDARKCreolssinisrusMrodfrSergiusElwoodxrayTurricann2kdavebracozzd10hPetrol
3 Modérateur(s)
K-LElwoodcorto
Crisot Crisoticon_post
W3D_DrawArray() trace tous mes polygons et basta. Le reste c'est mon moteur perso + un gros zbuffer trick (c'est lui qui m'a permis de tripler le framerate en 4 minutes).
--
AmigaOne X1000 - 2 Go DDR2 - Sapphire R9 280x Toxic - Crucial MX200 500 Go - Alim/Cooling BeQuiet
AmiDARK AmiDARKicon_post
Salut :)

Pour le DrawArray, j'utilise le même principe membre par membre d'un objet ... Je pense que je devrais pouvoir optimiser cela ... Par contre le Z Buffer Trick ... faudrat que tu m'expliques ;)

@ +
AmiDARK
Crisot Crisoticon_post
En fait le drawarray je fais des batchs très basique. Je groupe par texture. Donc je scan tous mes objets, ajoutes tous les objets ayant la texture 0 dans mon Array, puis tous les objets ayant la texture 1, puis la 2, puis la 3, etc...

Une fois que mon Array est plein, bah y'a plus qu'à lancer les batchs...

BindTexture 0
DrawArray (...a partir du debut, de la longueur qu'il faut)

BindTexture1
DrawArray (... à partir de la suite, de la longueur qu'il faut)

etc...

Donc que j'ai 1 objet ou 450, j'ai autant de batch qu'il n'y a de texture... Si y'a 3 textures pour 450 objets, bah ça fait 3 batchs... 6 textures pour 12 polygons (une skybox), bah 6 batchs.

BON, pour l'AOne, et exclusivement pour l'AOne, c'est un peu différent. Lorsqu'un batch devient trop long, je le coupe en 2/3/4/autant qu'il faut pour éviter de locker le hardware trop longtemps, ce qui permet d'éliminer les craquements sonore de la machine. Mais même en divisant mes batchs en 10, je perd moins de 2% de vitesse.

Le problème commence à se poser lorsqu'il faut trier... Encore, si on tri les objets (pour faire de l'occlusion culling ou éviter le surrafichage grace à un zbuffer à l'envers), ça va encore, mais si on doit carrément trier les polygons (faces transparentes), ça devient vite le bordel et le nombre de batch devient vite énorme.

D'ou l'idée d'avoir deux arrays:

- Un premier pour les materiaux qui n'ont aucune transparence, trié uniquement par texture.
- Un second avec exclusivement des materiaux/polygons transparents, mais là il faut écrire un bon radix pour avoir un tri rapide.

Bon, je t'apprend sans doute pas grand chose, mais en tout cas c'est comme ça que j'envisage mon moteur actuel. Il se pose encore une question pour moi, je vais attaquer le multitexturing et je compte monter à 3 textures, et pour construire les batchs à mon avis ça va être gentillement chiant.


ZBUFFER TRICK

Où comment trippler le framerate en 4 minutes de code.

Avec Warp3D, le Z doit toujours être compris entre 0.0 et 1.0. Je ne sais pas quelles sont les valeurs employées par minigl, mais que ce soit une fourchette 0->1 ou une fourchette 0->whatever, c'est pareil.

Donc dans un monde "normal", voici comment ça se passe.

10:
Cleaner le ZBuffer.
Traçage de la scene avec un Z compris entre mini et maxi.
goto 10

Bref, on clean le ZBuffer à chaque frame... ce qui est attocemen lent. Et c'est là qu'on a la chance d'avoir des cartes graphiques "récente" avec un zbuffer de très grande précision... On va couper ce zbuffer en plusieurs...

Voici en gros comment bosse mon moteur.

Cleaner le Zbuffer
Tracer la scene avec un Z compris entre 0.9 et 1.0
...
Tracer la scene avec un Z compris entre 0.8 et 0.9
...
0.7 et 0.8
...
blablablabla
0.0 et 0.1

PAN, notre Zbuffer est fini... On le clean, et on recommence dans la fourchette 0.9 -> 1.0...

Dans cet exemple tu l'aura compris, je ne clean le ZBuffer qu'une fois sur 10... Mais la réalitée est encore plus belle que ça! Car dans mon code, je clean le ZBuffer une fois sur 600... (dans le cas d'un affichage à 60 fps, le ZBuffer est donc clean toutes les 10 secondes, sans perte de précision visible).

Si 600 est un peu abusif, déjà en coupant en 100, en 50, ou même en 10, le temps machine gagné est énorme.
--
AmigaOne X1000 - 2 Go DDR2 - Sapphire R9 280x Toxic - Crucial MX200 500 Go - Alim/Cooling BeQuiet
Creols Creolsicon_post
ça me rappelle le bon vieux temps, quand je programmais en hexadécimal !
Pour des calculs un peu longs, au lieu de faire des boucles, je répétais autant de fois qu'il le fallait les mêmes instructions :b
0

Message édité par : Creols / 30-10-2010 18:03
AmiDARK AmiDARKicon_post
@Crisot :
Concernant le Draw Array, je peux pas faire comme toi car pour chaque objet 3D, tu peux avoir des propriétés différentes ( lumières ambiance ponctuelles ou directionnelles, transparence, translucence, alpha mapping, etc .... ) et donc je suis obligé de tracer chaque objet membre par membre ... (ceci aussi pour garder la compatibilité avec DarkBASIC Pro et DarkGDK.

sinon, ton astuce du ZBuffer, je vais voir si elle est appliquable à MiniGL et si je peux, je l'applique :) C'est un système qui ne devrait pas être compliqué à mettre en place et le gain semble logiquement très intéressant ... Faut aussi que je voie le champ d'application de cet astuce par rapport aux commandes précises de vidage d'écran auto ....

Merci en tout cas pour l'info.

EDIT :
Crisot, j'ai un peu étudié ton idée, je vais pouvoir la mettre en place dans l'AmiDARK Engine et, je dirais même plus, si tu as un backdrop en fond, tu peux même éviter d'avoir à éffacer le zbuffer ...
en OpenGL 2.1 je dois utiliser ça :
glDepthRange( GLclampd nearVal, GLclampd farVal );
Mais je peux inverser les test ( genre nearVal = 0.6f et farVal = 0.4f )
Résultat tu utilises le zbuffer dans un sens puis dans un autre genre :

Tu boucles dans ce genre (chaque ligne est 1 frame ) :
1/ 0.6 - 0.8
2/ 0.4 - 0.6
3/ 0 .2 - 0.4
4/ 0.0 - 0.2
5/ 0.4 - 0.2
6/ 0.6 - 0.4
7/ 0.8 - 0.6
8/ 1.0 - 0.8

en tout cas, en OpenGL 2.1 il est mentionné que tu peux inverser les valeurs, c'est accepté et utilisé ...

Cependant, miniGL le permet-il ? On va voir :p

EDIT #2 :
Effectivement, MiniGL permet d'utiliser ce principe et je gagne en FPS (et donc en fluidité) avec le procédé. Merci Crisot pour cette astuce :)

@ +
AmiDARK

Message édité par : AmiDARK / 31-10-2010 11:49
Message édité par : AmiDARK / 31-10-2010 11:51
Message édité par : AmiDARK / 31-10-2010 14:05
Message édité par : AmiDARK / 31-10-2010 18:08
K-L K-Licon_post
PS: 1440x900 : 48 FPS avec Ship et 39 FPS avec le MultiShips

Ca c'était avec la Radeon 9200 Pro.

1440x900 : 76 FPS avec Ship et 60 FPS avec le MultiShips

Et ça c'est avec ma nouvelle Radeon 9000 Pro :-)
--
AmigaONE X1000/1,8 Ghz (A-Eon), Radeon RX560, 2 Go de Ram et OS4.1 FE
Creols Creolsicon_post
Tu triches : tu ne précises pas si tes 1440x900 ont une profondeur de 8, 16 ou 32 bits ! ;-)
0
K-L K-Licon_post
32 bits pour les deux essais bien sûr :-)
--
AmigaONE X1000/1,8 Ghz (A-Eon), Radeon RX560, 2 Go de Ram et OS4.1 FE
Crisot Crisoticon_post
Ca change la vie hein? :-)

Ebay ta 9000? :-)
--
AmigaOne X1000 - 2 Go DDR2 - Sapphire R9 280x Toxic - Crucial MX200 500 Go - Alim/Cooling BeQuiet
K-L K-Licon_post
Je garde la 9200 Pro, je pense que si quelqu'un en exprime le besoin, elle pourra servir pour un AmigaOne ayant une vieille carte graphique :-)
--
AmigaONE X1000/1,8 Ghz (A-Eon), Radeon RX560, 2 Go de Ram et OS4.1 FE
Petites Annonces

0 annonce(s) publiée(s)

Consulter

AmigaOS 4.1

Laissez-vous tenter par
AmigaOS 4.1
AmiTheme

AmiTheme