3D vers 2D: doit on en finir au point ?
6 sujets de 1 à 6 (sur un total de 6)
-
Bonsoir,
je partage une petite réflexion.
Pour un affichage, passage 3D vers 2D.
Un tri pour l’affichage peut se faire en fonction de la profondeur (Coordonnée Z), si X;Y;Z.
Si l’on a que quelques objets(au sens « Blitter »), tenir ce tri est facile.Si en plus de ces quelques objets on utilise d’autres matériels graphiques (ex: ligne, ellipse).
Cela n’est plus possible, il faudrait segmenter la droite/cercle (partie visible, partie recouverte) et ainsi de suite…
Devrait on en finir a ne gérer que des points pour être capable d’en déterminer l’ordre d’affichage ?
Donc des centaines/milliers de coordonnées ?
La technique du ZBuffer est vieille. J’ai un bouquin acheté en 1987-88 qui faisait le point sur les techniques graphiques pour ordinateur de 2D vers 3D (de l’époque) et le ZBuffer y était déjà mentionné comme une bonne alternative au raytracing.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)De toute façon, que ça soit un cercle un polygone une ligne ou un point, vous n’allez pas trier la primitive par l’ensemble de ses points, ça obligerait à faire du clipping en Z à chaque intersection et ça serait ultra gourmand, sinon z-buffer mais pareil ça impose une lecture écriture à chaque point, on oublie sur Amiga, sauf carte rapide genre 040 060 vampire et autre.
Sur mon moteur 3D ce que je fais, pour que ça tourne sur 020 030, c’est une moyenne des Z de la primitive, ce qui donne vaguement un centre, c’est approximatif mais comme c’est le même algo sur l’ensemble, ça fonctionne quand même, combiné à un calcul de vecteur d’orientation (pseudo normale), ça fonctionne sur toute primitive.
mais de toute façon, si vous mélangez des lignes polygones et autre, le problème que vous aurez c’est l’échelle, une grande ligne risque de s’afficher derrière ou devant un petit objet qui sera avant le point le plus loin et plus éloigné du point le plus proche.
Donc dans ce cas, vous pouvez découper la ligne en sections plus petites, ça suffira pour donner l’illusion.
« Utilise Warp3D ou MiniGL ou StormMesa… » ??? pas tout compris là !
Pour la technique du « Z-Buffer », oui.
Cela sous entant qu’on gère justement par points (en tous cas pour ceux affichables: pixels).
Je pense partir vers un algorithme du peintre avec du matériel qu’en points (ni ligne, ni ellipse) le tout trié par Z.
Le temps d’affichage sera marginal face aux temps µP pris pour les calculs. Je voulais dire comme comme Warp3D ou MiniGL ou StormMesa utilisent directement le Zbuffer alors si tu traces en utilisant les fonctions de ces .library alors le problème est géré
Ceci dit la plupart nécessitent une carte 3D et il arrive que le driver pour une carte donnée ne gère pas le tracé de lignes/points
par contre StormMesa a (aussi) un rendu soft qui devrait marcher sur tout Amiga puissant mais juste écrire un prog OpenGL qui trace des lignes c’est beaucoup de lignes de code, chiant….
Le plus simple c’est implémenter un Zbuffer soi même c’est pas hyper compliqué: juste un tableau de la taille écran rempli de la valeur max z à chaque nouvelle image et pour tout pixel si valeur z est inférieure à celle du zbuffer à cet endroit x y alors copier ce pixel à l’écran et mettre à jour zbuffer à cet endroit x y
6 sujets de 1 à 6 (sur un total de 6)
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › 3D vers 2D: doit on en finir au point ?
