Moteur3D - Page 1

Y a-t-il moyen de créer une matrice de projection de l'espace vers un plan sans utiliser l'operation divs/divu et sans trop de mulu/muls.

Personnellement, pour chaque point projeté, j'ai 2 divs et 8 muls et ces fonctions sont tres lentes surtout quand il y a plusieurs centaines de points a projeter.

Pour les deux divs, ça me paraît normal (un pour chaque coordonnée du point à l'écran), mais pour les muls, ça fait beaucoup...
Ce que tu peux faire, c'est prendre une puissance de 2 pour la distance focale, ça simplifiera ta multiplication.
Tu peux aussi nous donner exactement à quoi correspond ton calcul ?

Oui mais les muls sont indispensables pour les rotations.

Pardon, mon moteur autorise les 3 translations et 2 rotations (comme les doom-likes).

Ah ok, ce n'est pas seulement pour la projection...

Sinon, tu utilises quoi comme distance focale ?

Oh, ... c'est quoi ca? La distance entre le plan et le centre de la projection? J'ai pris symboliquement 1, et 2 pour la largeur du plan de projection, pour un champ de vision de 90°.

je suis un peu perdu là...
La largeur de ton plan de projection est celle de l'écran, non ?

Oui, la largeur de mon plan de projection est celle de l'écran, mais dans une autre unité.... c.a.d, je dois multiplier les coordonnées des points projetés ([-1,1],[-1,1]) par les dimensions de l'ecran.

donc tu peux gagner ici des multiplications

Est-ce que cela apporte un réel avantage ?
Je te conseille d'utiliser plutôt les dimentions exactes de l'écran, ça t'évitera cette multiplication déjà...

Je vais voir si c'est possible, mais ca m'etonnerait que je puisse eviter ces multiplications (qu'on peut faire avec des operations sur les bits).

Sinon, en 3D on a souvent besoin d'afficher des lignes ou des triangles pleins, le fait de les clipper ne ralenti-t-il pas trop les programmes?

Oui, forcément, les calculs de clipping ralentissent, mais ils sont malheureusement indispensables afin de ne pas afficher n'importe où...

Ce que je fais actuellement, c'est allouer un espace memoire 4 fois plus grand que la taille de l'ecran, projeter les points sur cet memoire, puis n'afficher a l'ecran LCD qu'une partie de cette memoire, le milieu (pour que les lignes dont les extrémités ont leurs coordonnées legerement en dehors de l'ecran soient quand meme affichées).

Avantage: rapidité
Inconvenients: les lignes ne sont pas toutes affichées (si on est vraiment trop pres d'elles par exemple)

J'aimerais donc savoir si ça vaut vraiment le coup de clipper toutes les formes (gain de memoire RAM... ou meme de vitesse car les tres grandes lignes doivent, dans mon programme, etre definies en tant que plusieurs lignes collées bout a bout, pour qu'on la voit meme de pres).

Çe n'est pas bête, ta technique, mais c'est un peu du bricolage, je trouve.
Personnellement, je préfère un clipping bien propre, plutôt que d'utiliser ce genre de technique, mais bon, tu fais comme tu veux...
Il est évident que de clipper les polygones prendra du temps. Ce n'est certainement pas là que la plupart du temps sera passé, mais ça ralentira un peu ton programme.

mais c'est un peu du bricolage, je trouve.

Je cherche des routines pour clipper lignes et rectangles pleins mais je n'en trouve qu'en C .... mais je fais l'assembleur.
En as-tu par hazard?

Non, il faut que j'en écrive moi aussi, mais elles ne sont même pas encore prêtes dans ma tête, alors ce n'est pas la peine que je me mette à la coder tout de suite.

Sinon, genlib en possède, il me semble. Demande à son auteur s'il veut bien te passer la source, ou demande à sBibi s'il en a (mais il me semble que sBibi clippe ses polygones avant de les afficher).

Galmiza
a écrit : Je cherche des routines pour clipper lignes et rectangles pleins mais je n'en trouve qu'en C .... mais je fais l'assembleur.

tigcc -Os -fomit-frame-pointer -S routine.c

Bof, je ne te conseille pas de partir sur la base d'une source C compilée...
Tu peux regarder le code C pour piger l'algorithme et le réécrire en ASM, mais il me semble que tu ne connais pas du tout le C.

C'est pas grave, je vais apprendre le C, ca ne sera qu'utile.

je vais apprendre le C, ca ne sera qu'utile.

je confirme
et en plus, c un langage assez proche de l'algorithmie... (enfin, pour les bases, du moins)

Puis apprendre le C, ca va surtout te permettre de programmer sur toutes plateforme

bah, le C c'est tres bien comme pseudo langage quand tu code en asm
moi c'etait pareil, j'av d'abord appris l'asm, et le C bcp plus tard

et, heu, le clipping, ca ralentit, oui, mais pas tant que ca, et ca permet surtout d'eviter de calculer des tas de trucs qui servent a rien...

Galmiza:
"Personnellement, pour chaque point projeté, j'ai 2 divs et 8 muls et ces fonctions sont tres lentes surtout quand il y a plusieurs centaines de points a projeter."

c'est quasiment rien ca... dans un moteur, c'est pas ca qui bouffe le plus de temps... encore moins dans un jeu. et divisier par deux, c'est comme multiplier par 0.5, dans tes matrices de projections, t'auras bcp de valeurs comme ca, avec des 0.qquechose alors a moins d'utiliser les floats... tout ce que tu pourra faire c'est utiliser une pauvre virgule fixe bien merdique qui te donnera une precision horrible... et t'aura plein de points qui fretilleront partout a l'ecran...
et franchement, deux div par points, c'est pas la mort
quand tu pense que le perfect perspective texture mapping requiert une div par pixel...
et que si t'approxime, tu peux descendre a une div tous les 8 ou 16 pixels (pour chaque scanline), heu, tes 1 div par points, c'est un peu rien du tout

"Je cherche des routines pour clipper lignes et rectangles pleins mais je n'en trouve qu'en C .... mais je fais l'assembleur.
En as-tu par hazard? "

j'ai surtout l'impression que tu cherches a assembler des routines faites par d'autres pour faire TON moteur...
enfin en tt cas c'est l'impression que tu donne avec plusieurs posts de ce style la...
si pour toi reflechir 1h ou 2 sur un probleme c'est trop, je crois que tu te fais un peu des illusions


"Sinon, genlib en possède, il me semble. Demande à son auteur s'il veut bien te passer la source"

heu oui, tu peux toujours demander a PpHd si il veut te filer les sources de GenLib, mais bon, espere pas trop

"Ce que je fais actuellement, c'est allouer un espace memoire 4 fois plus grand que la taille de l'ecran, projeter les points sur cet memoire, puis n'afficher a l'ecran LCD qu'une partie de cette memoire, le milieu (pour que les lignes dont les extrémités ont leurs coordonnées legerement en dehors de l'ecran soient quand meme affichées).

Avantage: rapidité
Inconvenients: les lignes ne sont pas toutes affichées (si on est vraiment trop pres d'elles par exemple)
"

mort de rire
je suis sur qu'avec un clipping bien fait, tu peux aller plus vite qu'avec le truc de porc que tu fais

je dirais plutot:

Avantages: aucun
Inconvenients: bouffe de la place pour rien (t'hesite a mettre une table de cos entiere, mais tu bouffe 4*la taille d'un buffer d'affichage alors que ca sert vraiment a rien), tu dois calculer et dessiner tout plein de pixels qui seront JAMAIS visibles, pour recopier la partie visible de ton buffer a l'ecran, tu dois le faire ligne par ligne (alors que tu pourrais le faire directement, "brute force", tout d'un coup, a coups de movem massifs ), et en plus comme tu l'as dit, les faces trop pres disparaissent parceque soit elles sortent de la zone d'affichage, soit en plus, un ou plusieurs de leurs sommets sont derriere l'ecran pendant que d'autres sont devant...

la methode que t'utilise, c'est la solution de facilite qui demande absolument aucune reflexion, c'est d'ailleurs une des premieres chose a laquelle quelqu'un qui a jamais code de moteurs 3D peut penser... (et encore)

"mais il me semble que sBibi clippe ses polygones avant de les afficher"

oui, perso je les clippe dans le worldspace, et ca resoud tous les inconvenients de sa methode.

Il me semble que j'avais bencher une recopie de buffer à l'écran qui n'utilisait que des movem et une autre composée uniquement de move.l (an)+,(an)+, et la différence de vitesse était négligeable (si mes souvenirs sont bons).

tu gagne qd meme un peu
et t'as benche une routine qui recopie ligne par ligne a partir d'un buffer 4* plus grand dans l'ecran?

sBibi> J'ai une question : quand tu clipes tes polygones dans le worldspace, ça fait qu'après, un triangle peut devenir un quadrilatère (voire même un pentagone, dans certains cas), si il n'a qu'un sommet en dehors de la pyramide de vision ?
Dans ce cas, comment tu fais pour stocker les coordonnées des segments qui constituent le nouveau polygone clippé (tu prévois un espace exprès pour ?) ?

heu, oui, g prevu pour 8 cotes max apres clipping. et c'est redecompose en triangles au moment d'afficher

Et c'est plus rapide de redécomposer en triangles que de remplir le polygone lui-même ?
Enfin, je suppose que de toute façon, tous tes polygones sont des triangles, sauf ceux qui ont été clippés, donc c'est mieux que tu utilise une routine de remplissage de triangles comme ça tes triangles vont bien vite.

Mais sinon, tu penses que si j'ai des polygones convexes qui ont un nombre de côtés variable, c'est mieux de les afficher en les découpant par triangles, ou bien c'est mieux de faire une fonction de remplissage de poly convexes (au niveau de la rapidité) ?

une fonction de remplissage de polys convexes a un nombre quelconque de cotes? je sais pas... fo voir
essaye les deux ^^
(moi g eu la flemme )
tu separe les cotes en deux, les cotes gauches, les cotes droits, tu te fais un tablo de deux byte (ou deux short) de la taille de la hauteur de l'ecran, et pour chaque Y, dans la premiere case tu mets la coord X du cote gauche, dans la deuxieme la coord X du cote droit, et apres, tu trace les scanlines d'un cote a l'autre.

je sais pas si c'est plus rapide. pour un triangle surement pas, pour un polygone avec plus de cotes peut etre... essaye, ca peut etre interessant

C'est forcément plus rapide de décomposer en triangles ... nan ?

sBibi
a écrit : tu separe les cotes en deux, les cotes gauches, les cotes droits, tu te fais un tablo de deux byte (ou deux short) de la taille de la hauteur de l'ecran, et pour chaque Y, dans la premiere case tu mets la coord X du cote gauche, dans la deuxieme la coord X du cote droit, et apres, tu trace les scanlines d'un cote a l'autre.

J'avais pensé à faire ça, parce que ça me semble plus simple à coder : je remplis la liste de scanlines en même temps que je trace les lignes des extrêmités de mes polygones, puis après, je fais une seconde passe où je trace mes lignes horizontales.
Parce que de tout faire en une fois, ça me paraît compliqué...