---

Forum » » Création-Développement » » Nouveau moteur 3D (PXS Alpha)

---

Posté : 30-10-2010 17:19

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.

---

Cet article provient de Le site des utilisateurs francophones actuels et futurs d'AmigaOS 4.x
https://amiga-ng.org/viewtopic.php?topic=886&forum=14