Bon alors, je réiterre ma question en la cantonnant au vectoriel 2D.
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.
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.
# "moteur 2D" dit le titre de l'article
Posté par Sylvain Garden . En réponse au journal moteur graphique 2D. É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.