---

Forum » » Création-Développement » » Dungeon Crawler (Odyssey) Os4

---

Posté : 26-04-2016 21:49

Alors justement ça tombe particulièrement bien que vous parliez de .OBJ, c'est justement un très bon exercice et quelque chose qui montre "facilement" la différence entre mon moteur "custom" pré-modification, et un moteur OpenGL (pour Artblink).

Prenons un cube. Il est constitué de 8 points, chaque point étant utilisé par 3 faces. Le truc, c'est que si chacune des faces est texturées/colorées différemment, OBJ stockera uniquement 8 points, et plusieurs "pointeurs" avec des couleurs/textures différentes pour chaque utilisation de ce point unique.

Mon moteur fonctionnait pour ingurgiter directement du OBJ, j'avais donc une liste de pointeurs de points, une liste de pointeurs de textures, une liste de pointeurs de couleurs, etc, et au moment de traçage, je faisais un petit medley avec tout ça pour le faire ingurgiter à Warp3D.

OpenGL marche totalement autrement. Pour OpenGL, chaque point est STRICTEMENT unique. Il n'y a qu'une seule et unique liste de pointeurs qui comprend tous les paramètres. Donc si le coin d'un cube est rouge, il est rouge pour TOUTES les faces. Si on souhaite qu'un point soit utilisé avec des couleurs/textures différentes, il faut alors dupliquer l'intégralité du point. Comprendre: Si le cube à 6 faces de couleurs différentes, alors il faudra dupliquer chaque point 3 fois: Total, notre cube fait maintenant 24 points, et non 8.

Ca marche exactement pareil pour l'éclairage. Par défaut l'éclairage est forcément "smooth", doux entre chaque arrête. Si on souhaite avoir un éclairage "dur" avec des arrêtes franches, il faudra dupliquer les points de chaque arrête.

Vu ainsi, on ne voit que des inconveniants : Car notre cube avec ses points dupliqués, au moment du fameux "transform and lightning" que l'on a pas en hardware sur Amiga, il faudra l'appliquer à 24 points et non 8, et il faudra faire dans le vide 3 fois la même chose: Inutile...

Et pourtant... En pratique, ça présente tellement d'avantages. Le fait de supprimer pleins de buffers de pointeurs, ça simplifie tellement de choses, ça optimise tellement l'utilisation mémoire... Chaque point étant unique, il suffit de tout traiter à la chaine avec une bonne moulinette, plus besoin de reconstituer ses points au moment de l'éclairage, du clipping... En fait, tout va plus vite.

Bref, c'est sans doute obscure pour plein de gens d'ici, mais clairement, j'ai carrément divisé la quantité de lecture/écriture mémoire. Les boucles de transform & ligthning, bien qu'ayant plus de points à traiter, sont plus courtes et plus rapide pour chaque point. Du bonheur.

Bref, là je parle de techno de 1995, rien ne neuf. Je me suis juste penché sur le fonctionnement du "pipeline" interne à OpenGL, et j'ai juste eu le déclic du "putain c'est trop bien pensé" avec 20 ans de retard. 

MINIGL:

Si j'en veux à ce truc, c'est parce qu'il est affreusement lent. Hans me disait il y a quelques années que si mon moteur allait vite c'était justement parce qu'il était "custom", et que MiniGL devait ses lenteurs à son obligation de respecter des standards. Avec mon immense respect que j'ai pour ce grand monsieur: Bullshits. Mon moteur n'a jamais été aussi rapide que depuis qu'il mimique OpenGL. C'est si simple et bien pensé que je ne comprend même pas qu'on puisse en louper une implémentation à ce point...

(ce fut long...)
Message édité par : Crisot / 26-04-2016 21:50

---

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