Bon entendons nous bien... je suis pas du tout au fait de l'actualité Linux. Je ne suis qu'un reluqueur avec une partition Linux sur son vieux PC pour faire fonctionner Gimp et des outils maison pour générer sa page web.
Sans carte 3D, les jeux Linux en vectoriels (2D ou 3D) ça existe?
Je me demande souvent ce que les librairies graphiques open-source sous linux mettent en oeuvre comme algorithme d'affichage, quand elles n'ont pas de carte 3D sous la main bien-sûr...
A l'école, on avait vu l'affichage par balayage d'un polygône, et la façon dont on pouvait l'étendre pour afficher des ensembles de polygônes superposés, classés en hauteur...
J'ai l'impression que des librairies graphiques comme SDL reposent sur un z-buffer, technique beaucoup moins épatante...
enfin voilà... j'avais envie d'écrire quelquechose... d'idiot sans aucun doute.
Journal moteur graphique 2D
25
mai
2004
# Difference ZBuffer / Polygon Sorting
Posté par Jylam / jylam.lnxsce (site web personnel) . Évalué à 8.
Tu nous parles de superposition de poly, en nous disant que le z-buffer n'est pas "epatant". Sache qu'en 3d (ou 2d, mais ca perd de son interet) polygonale, on peux difficilement faire mieux que le zbuffer. Classer les poly c'est bien, mais si 2 se "croisent", tu fais comment ?
Tu fais comme on faisait "avant" (jadis, dans le temps, tout ca), tu classes les polygones du plus eloigné au plus proche, selon la moyenne de leur sommets, en gros (plusieurs techniques, donc "l'algorithme du peintre", chose affreuse que vous apprenez a l'ecole). Si il y'en a 2 qui se croisent, selon la precision, il vont ou "flicker", clignoter chacun leur leur tour, soit tu va voir des "glitches" dans tous les sens parce que tu peux pas determiné quel pixel est effetivement devant l'autre, travaillant a une echelle plus grande.
(oui, les termes anglais sont fait expres, ca en ennerve certain, mais en francais c'est encore plus laid).
Le Zbuffer te permet par contre de savoir EXACTEMENT (selon la precision de celui ci) ou se trouve un pixel par rapport a ceux que tu a pu afficher avant aux meme coordonnées 2d. On peut difficilement faire plus precis.
Le Zbuffer n'empeche pas de classer ses polygones quand meme, sinon on se retrouve tres embeté quand on doit gerer la transparence d'un polygone.
En bref, il faudrais relire tes "cours", ou eviter de dire que telle ou telle chose n'est pas "epatante" quand tu ne l'a pas encore pratiquée :)
(ou alors j'ai rien compris)
[^] # Re: Difference ZBuffer / Polygon Sorting
Posté par Frédéric Lopez . Évalué à 7.
En rendu 3d software, la technique à utiliser dépend du type de données à afficher. Dans le cas des FPS par exemple, le moteur de Quake 1 en mode software reposait sur la technique du BSP (Binary Space Partition) et des portals, car la technique du z-buffer était beaucoup trop lourde. Elle génère en effet de nombreux accès en lecture et écriture dans la mémoire vidéo ce qui était extrêmement lent sur les cartes de l''époque. Le z-buffer n'était utilisé que pour des cas particuliers comme les billboards et les sprites.
L'avantage du BSP est qu'il minimise les recouvrements de poygones et au besoin les divise, il n'y a pratiquement pas d'overdraw donc pas d'accès superflus en écriture sur la carte graphique. Cette technique n'est maintenant quasiment plus utilisée car le z-buffer hard est très rapide et l'utilisation du BSP est assez gourmande en cycles CPU. Les BSP sont néanmoins toujours utilisés dans la détection de collision.
La technique des portals est une technique de plus haut niveau qui permettait de découper une scène en plusieurs zones et de ne retenir que celles susceptibles d'être visibles en fonction de la position de la caméra et des informations de connectivité entre zones. Cette technique n'est utilisée que dans les jeux "indoor" et elle l'est d'ailleurs de moins en moins. A l'heure actuelle, on utilise d'autre technique comme les octrees (pour les environnements extérieurs), le hierarchical occlusion culling, etc.
[^] # Re: Difference ZBuffer / Polygon Sorting
Posté par Olivier Grisel (site web personnel) . Évalué à 0.
[^] # Re: Difference ZBuffer / Polygon Sorting
Posté par drchaos (site web personnel) . Évalué à 2.
le BSP est aussi bien utiliser dans la version soft que hard et il permet de savoir quel poly d'une scene afficher et dans quel ordre de maniere trés rapide.
Pour ce qui est du zbuffer, effectivement la version soft n'utilise pas de z-buffer mais un s-buffer (span buffer) qui est plus efficient en soft que le z-buffer.
voila,voila
[^] # Mouai ;)
Posté par Anonyme . É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 !
# SDL et cie
Posté par gc (site web personnel) . Évalué à 2.
Maintenant, quant à la performance du rendu OpenGL soft, moi j'ai toujours vu des choses dramatiques, mais il me semble que le projet Mesa à l'origine était pour "prototyper" les fonctions OpenGL en software sans chercher la performance mais plutôt la complétude/l'exactitude (le rendu soft avec des performances intéressantes passant quasiment toujours par d'importantes réductions de complexité/précision, donc on n'obtient pas le même rendu, voir la mocheté des démos soft par rapport aux démos accélérées).
# "moteur 2D" dit le titre de l'article
Posté par Sylvain Garden (site web personnel) . Évalué à 1.
Imaginons un jeu où les "lutins" sont des formes polygônales quelconques sur lesquelles sont mappées des images raster.
Par exemple un jeu de courses de voitures vu de dessus avec un beau scrolling multi-directionnel et des tas de choses animées pour les noeil-noeils!
Bref, dans ce cas les polygones se superposent mais ne s'intersectent pas. Chaque polygône est à plat, la profondeur est la même pour tous ses pixels.
J'imagine que c'est un peu les conditions de travail des moteurs de rendu 2D des techno flash ou SVG.
Donc, si on fait "le peintre" dans l'ordre des polys, on perd du temps à peindre des couches qui ne se verront pas.
Ici le z-buffer ne sert à rien sinon à éviter de trier les polys par profondeur... C'est même pire parce qu'on fait des comparaisons de profondeur pixel par pixel au lieu de les faire à l'échelle des polys. En fait, c'est complètement hors-sujet.
En revanche, l'algorithme de balayage généralisé permet de dessiner tous les polygônes en une seule passe sans autre opérateurs que l'addition et la comparaison. Sur la ligne de balayage, on calcule les intersections avec les vecteurs des polygones par delta vis à vis de la ligne précédente.
C'est très peu couteux et entre deux intersections successives sur la ligne de balayage, on sait exactement quelle surface est à peindre.
Alors ici, http://deptinfo.cnam.fr/Enseignement/CycleSpecialisation/IMASON/ima(...)
on en parle.
L'algorithme de balayage n'est pas à la base des serveurs X, parce que dans le cadre de l'affichage de GUI, on fait d'abord du clipping pour isoler des régions rectangulaires homogènes à raffraîchir, et on appelle une fonction dédiée à l'affichage de chaque région.
Démentiel : En codant un moteur de rendu de GUI ayant une orientation "balayage", on pourrait imaginer un bureau qui soit entièrement animé et se raffraichissent à la vitesse d'un Doom-like... J'y pense souvent.
[^] # Re: "moteur 2D" dit le titre de l'article
Posté par Jylam / jylam.lnxsce (site web personnel) . Évalué à 2.
- Ca peut etre efficace dans le cas de peu de polygones (on preferera des triangles pour faciliter les calculs) ne "s'overlapant" pas trop. Superposant pardon :). Si ils ne se superposent pas tous, on peut jouer avec des bounding boxes, de facon a ne tester que les polys de l'aire de test
- Ce n'est donc PAS efficace pour un grand nombre de polygones, car il faudra pour chaque pixel tester quels sont les polys presents. Si trop se superposent, ils faut tous les tester a chaque pixel.
Utile dans peu de cas je pense, meme si la technique est interessante
[^] # Re: "moteur 2D" dit le titre de l'article
Posté par Sylvain Garden (site web personnel) . Évalué à 1.
"on préferera des triangles pour faciliter les calculs" :
aucune raison de triangulariser les polygônes. Avec la technique du balayage, un polygone peut avoir plein d'arêtes.
En fait, on sait si un point sur la ligne de balayage est à l'intérieur du polygône quand le nombre d'arêtes intersectées par la portion gauche de la ligne de balayage est impair. C'est l'un des points clefs de cette méthode.
Donc, une fois qu'on connait les intersections entre les arêtes et la ligne de balayage, il suffit de parcourir les intersections de gauche à droite pour obtenir de façon incrémentale le plus haut polygône visible entre 2 intersections.
"Les polygônes ne doivent pas se superposer" :
au contraire, c'est quand il y beaucoup de poly les uns sur les autres qu'on voit l'avantage du balayage vis à vis de la méthode du peintre.
Quand on balaye l'écran, on gère de façon incrémental une liste des arêtes actives, c'est à dire celles qui intersectent la ligne de balayage. C'est seulement pour ces arêtes qu'on calcule les intersections avec la ligne, les autres sont ignorées (et si on sait en plus ignorer les poly qui sont à l'extérieur de l'écran, c'est encore mieux).
Le x des intersections en cours s'obtient très simplement quand on fait un calcul incrémental par rapport à la ligne de balayage précédente. Le mieux est d'appliquer l'algo de Bresenham qui ne nécessite que des additions et des comparaisons d'entiers.
"il faudra pour chaque pixel tester quels sont les polys presents.
Si trop se superposent, il faut tous les tester a chaque pixel."
alors là pas du tout. c'est toute la différence entre cette technique et l'affichage un à un des polys. Car une fois qu'on connaît 2 intersections successives sur la ligne de balayage, on sait que tous les pixels entre les 2 n'appartiennent qu'à un seule surface, celle du poly visible le plus haut (ou le fond bien-sûr).
Donc, on part de la gauche, on va d'intersection en intersection, on met à jour le compteur de parité pour le polygône de l'arête intersectée, et selon le cas, on retire ou on rajoute ce polygone à une liste des polygônes en cours de peinture. Si la liste est triée en profondeur, la surface à afficher est celle du polygône en tête de liste.
Finalement, c'est une technique *très* intéressante parce que tous les calculs peuvent être fait en incrémental... on ne fait que des petites modifs d'une ligne de balayage à l'autre grâce à ce que l'auteur du papier appelle la "cohérence" de l'image.
[^] # Re: "moteur 2D" dit le titre de l'article
Posté par Anonyme . Évalué à 1.
http://cairographics.org/(...)
Cairo is a vector graphics library with cross-device output support. Currently supported output targets include the X Window System, in-memory image buffers, and PostScript. An OpenGL backend is in progress, and PDF file output is planned. Cairo is designed to produce identical output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.