Quelques petites corrections et precisions s'imposent ;)
1. Le ZBuffer est utilisé en hard et en soft, c'est le seul moyen efficace et facilement "cablabe" pour afficher les faces dans le bon ordre.
2. Le BSP, comme les octree, portals et compagnie consiste a diminuer le nombre de polygonne a envoyer a la carte graphique.
Pour mieux comprendre on va prendre un exemple.
On a une scene composée de polygonne que l'on desire afficher, pour cela il nous faut determiner quels sont les polygonnes cachant les autres et figurant devant l'observateurs. Il existe plusieurs techniques : le ZBuffer et le raytracing sont les plus utilisés.
Si cette scene est composée d'un milion de polygonnes on va faire tourner ces algorithmes sur cet ensemble, ce qui n'est pas tres efficace, car il est possible de reduire celui-ci a l'avance. Cette reduction prend en compte la position de l'observateur et determine les polygonnes qui ne seront jamais visibles.
Ce choix peut etre :
- arbitraire : en bornant volontairement le champ de vision (clipping)
- logique : dans les scenes indoor, il est inutile d'envoyer a la carte graphique les polygonnes des pieces ou l'observateur n'est pas present (principe "simplifié" des portals)
- basé sur une repartition spatiale des polygonnes : en classant les polygonnes par zones dans des arbres (Octree, BSPTree, KD-Tree, ...)
Que ce soit en soft ou en hard, ces techniques peuvent etre utilisées conjointement. Ce qui est le cas de Quake. De plus le ZBuffer et derivé sont systematiquement utilisés car ce sont les seules techniques a etre aussi efficaces, polyvalentes et independantes de la scene. Dans l'avenir on se dirigera progressivement vers des methodes hybrides raytracing/zbuffer puis 100% raytracing. Ce qui est un juste retour aux choses, car les tous premier moteurs (Wolfenstein, doom I et II, ...) etaient basés sur un algorithme de raytracing (extremement) simplifié ;)
Sinon pour repondre aux questions de sylvain, les jeux et applications utilisant un moteur 3D basé sur OpenGL exploiteront la bibliotheque openGL installée sur ta config. Si tu possedes une carte 3D et que les drivers du constructeurs sont installé, OpenGL pourra etre vue comme l'interface entre le moteur 3D applicatif et la partie hardware de la carte 3D. Si aucune carte n'est installée, une autre implémentation sera utilisée effectuant tous les calculs en soft (Mesa generallement).
Pour SDL, il ne faut pas tout melanger ;) SDL est une couche d'abstraction du materiel permettant d'acceder de maniere simple a des zones de la memoire video, aux fonctionnalités audios, thread, communication, ... independament de la plateforme. SDL ne sait pas faire de 3D et n'utilise donc pas de zbuffer. Par contre, il est possible d'utiliser ces zones de memoires videos pour l'affichage de scene OpenGL ou le calcul du ZBuffer.
[^] # Mouai ;)
Posté par Anonyme . En réponse au journal moteur graphique 2D. Évalué à 5.
1. Le ZBuffer est utilisé en hard et en soft, c'est le seul moyen efficace et facilement "cablabe" pour afficher les faces dans le bon ordre.
2. Le BSP, comme les octree, portals et compagnie consiste a diminuer le nombre de polygonne a envoyer a la carte graphique.
Pour mieux comprendre on va prendre un exemple.
On a une scene composée de polygonne que l'on desire afficher, pour cela il nous faut determiner quels sont les polygonnes cachant les autres et figurant devant l'observateurs. Il existe plusieurs techniques : le ZBuffer et le raytracing sont les plus utilisés.
Si cette scene est composée d'un milion de polygonnes on va faire tourner ces algorithmes sur cet ensemble, ce qui n'est pas tres efficace, car il est possible de reduire celui-ci a l'avance. Cette reduction prend en compte la position de l'observateur et determine les polygonnes qui ne seront jamais visibles.
Ce choix peut etre :
- arbitraire : en bornant volontairement le champ de vision (clipping)
- logique : dans les scenes indoor, il est inutile d'envoyer a la carte graphique les polygonnes des pieces ou l'observateur n'est pas present (principe "simplifié" des portals)
- basé sur une repartition spatiale des polygonnes : en classant les polygonnes par zones dans des arbres (Octree, BSPTree, KD-Tree, ...)
Que ce soit en soft ou en hard, ces techniques peuvent etre utilisées conjointement. Ce qui est le cas de Quake. De plus le ZBuffer et derivé sont systematiquement utilisés car ce sont les seules techniques a etre aussi efficaces, polyvalentes et independantes de la scene. Dans l'avenir on se dirigera progressivement vers des methodes hybrides raytracing/zbuffer puis 100% raytracing. Ce qui est un juste retour aux choses, car les tous premier moteurs (Wolfenstein, doom I et II, ...) etaient basés sur un algorithme de raytracing (extremement) simplifié ;)
Sinon pour repondre aux questions de sylvain, les jeux et applications utilisant un moteur 3D basé sur OpenGL exploiteront la bibliotheque openGL installée sur ta config. Si tu possedes une carte 3D et que les drivers du constructeurs sont installé, OpenGL pourra etre vue comme l'interface entre le moteur 3D applicatif et la partie hardware de la carte 3D. Si aucune carte n'est installée, une autre implémentation sera utilisée effectuant tous les calculs en soft (Mesa generallement).
Pour SDL, il ne faut pas tout melanger ;) SDL est une couche d'abstraction du materiel permettant d'acceder de maniere simple a des zones de la memoire video, aux fonctionnalités audios, thread, communication, ... independament de la plateforme. SDL ne sait pas faire de 3D et n'utilise donc pas de zbuffer. Par contre, il est possible d'utiliser ces zones de memoires videos pour l'affichage de scene OpenGL ou le calcul du ZBuffer.
Voili voilou ! mes 2c !