Matrices de rotations et projections - Page 2

Ok ! Merci.
C'est bien ce que j'avais compris en gros: si j'applique une rotation à un objet sans translation il va tourner sur son repère (son centre par) et si j'applique une rotation après l'ajout de la caméra l'objet va tourner sur un autre repère: la caméra.

Et pour faire des rotations tu te sers de matrices ?

Et puis c'est quoi la formule de rotation pour tourner à gauche ou à droite ?
Par que j'ai essayé celle que j'utilisait pour faire tourner le cube sur lui même mais il y a des gros problèmes (déformation du cube).

Ah, non c'est bon j'ai rien dit !
J'ai fait une petite erreure de variable lors de la transformation des X et donc tout marche et c'est vraiment génial !

Pour faire une rotation avec ta camera il faudrait que la camera ait un chemin circulaire avec l'objet comme centre...si je comprend bien...


Ah bah non, j'ai perdu une bonne occasion de me taire

Ca je le fais déjà avec un ojet qui tourne sur lui même. Oui en fait c'est plutôt l'objet qui tourne autour de lui même

il faudrait que la camera ait un chemin circulaire avec l'objet comme centre...si je comprend bien...
Oui, je pense que ça revient à faire une rotation de la scène autour du centre de l'écran ?
J'ai déjà essayé mais il faut faire une translation supplémentaire au tout début.... à moins que ça ne soit pas comme ça qu'il faut faire mais ce que j'ai fait avait l'air de fonctionner.
Je vais essayer d'élaborer une vraie map pour voir si ça fonctionne toujours.

Par contre il y a un truc que je ne comprend tjrs pas: c'est les matrices de rotation.
Pour l'instant j'utilise des que des fonctions.

J'ai l'impression que tu utilises des formules sans vraiment les comprendre...
Par exemple, au début, tu avais besoin de conseils pour une formule de projection, et d'après ce que tu disais, tu as bidouillé un peu, changé qq trucs par ci, d'autres par là et ça t'a donné un résultat convenable. Puis tu as découvert une autre formule que tu as essayé d'utiliser, mais sans réussite.

Essaie de trouver ta propre formule, celle qui serait la plus adaptée à ce que tu veux faire.
Et cela en faisant un shéma et en trouvant les relations entre les points projetés et les sommets du polygone.
Ou essaie au moinsde comprendre comment elle fonctionnent.
Je me trompe p-ê sur toi, mais c'est l'impression que j'ai.

Normalement, tu devrais faire ton shéma, trouver la relation, écrire une formule en conséquence et la reporter dans ton code source directement (sans changer une ou deux valeurs en espérant trouver un meilleur réglage). Elle doit marcher tout de suite. Sauf si tu t'es gourré dans tes calculs.
Moi, c'est comme ça que je fais.

J'ai l'impression que tu utilises des formules sans vraiment les comprendre...

Non, les formules je les comprend bien mais c'est vrai qu'au départ je ne savait pas qu'il fallait utiliser telles ou telles formules pour projeter les points 3D, comment gérer la caméra et comment utiliser les formules de rotations.

Alors quand j'ai essayer d'intégrer différentes formules de projection sans encore avoir compris le reste, il y a eu des problèmes.

Essaie de trouver ta propre formule, celle qui serait la plus adaptée à ce que tu veux faire.
Ce que je veux faire et bien c'est essayer d'apprendre le plus de chose possible sur la 3D et pourquoi pas créer un moteur.
Maintenant que je commence à mieux comprendre je n'ai plus tellement de problèmes avec les formules mais plutôt de faire un moteur qui puisse gérer plusieurs objet (et ça je ne sais pas du tout comment le faire).
Et puis les matrices de rotation je ne comprend pas bien comment il faut les utiliser et surtout s'il elles sont plus efficasse que des fonctions.


Ou essaie au moins de comprendre comment elle fonctionnent.
Oui... mais non ça c'est fait depuis longtemps !

Je n'utilise pas de formule si je les comprends pas comment elles fonctionnent parce-que sinon je ne pourrait rien modifier, ni savoir ce que je peux faire avec ect...

Normalement, tu devrais faire ton shéma, trouver la relation, écrire une formule en conséquence et la reporter dans ton code source directement (sans changer une ou deux valeurs en espérant trouver un meilleur réglage). Elle doit marcher tout de suite. Sauf si tu t'es gourré dans tes calculs.
Moi, c'est comme ça que je fais.

Si je fais comme ça je n'y arriverais jamais !
Le plus simple pour moi et de prendre une formule qui existe déjà, de voir sur un schéma pourquoi elle ne va pas (en fonction des transformation que je fait avant), de la taper dans TIGCC (une fois qu'elle me paraît bonne), de la tester puis de l'optimiser.

De toute façon il n'y a pas 20 000 de formules de projection lorsque l'on utilise une caméra. C'est encore bien plus bête que ce que je pensais au départ.
J'ai donc modifier mon ancienne formule pour arriver à celle-là :

Pixel[t].x = (x<<1)/(z>>7) + 80; //Pixel[t].x = ((x/128) *256)/(z/128) + 80;
Pixel[t].y = (y<<1)/(z>>7) + 50; //Pixel[t].y = ((y/128) *256)/(z/128) + 50;


Là j'ai la caméra:

x1 = Transform[t].x + (camera.x<<7);
y1 = Transform[t].y + (camera.y<<7);
z1 = Transform[t].z + (camera.z<<7);

Et là la rotation de la scène autour de la caméra:

x = ((x1*Cos[vue]+z1*Sin[vue])>>7);
y = y1;
z = (((-x1)*Sin[vue] + z1*Cos[vue])>>7) ;

Par contre j'ai énormément de mal à créer des objet en 3D. Il faudrait que je fasse un éditeur pour trouver les coordonnées des vertices.

Sinon j'aurais une petite question: pour maximiser l'exécution (après avoir spécifier la fonction du tracé de ligne d'extgraph pour mon programme, intégré la gestion des touches de GraphX), je cherche maintenant à réduire le nombres de cycle pris par la gestion du buffer.
Normalment pour toute les calcs on doit utiliser un buffer de 3840, non ?
Seulment c'est énervant d'utiliser un buffer qui est largement plus grand que sa Ti89 surtout si l'on peut avoi le programme le + rapide possible.
J'ai essayé avec 3000 et si le cube sort pas trop de l'écran ça ne plante pas.

Alors je voulais savoir si c'était possible d'utiliser un buffer plus petit pour une Ti89 (si ça ne risque pas de planter ou de créer des problèmes dans la mémoire) et quelle taille faut-il utiliser exactement pour qu'il fasse la taille de l'écran d'une Ti 89 ?
... Sachant que j'utilise uniquement FastCopyScreen() d'extgraph et memset()

Mais bon même bon même avec un buffer de 3840 ça tourne très très bien quand même. ... Même trop bien !!!

C'est possible, tu peux prendre un buffer de 2000 octets (160*100/8=2000)
Mais il faudra que tu modifies la fonction d'extgraph pour tracer des lignes, car je pense qu'elle a été faite pour un écran de 240*128 pixels.
ensuite, il faudra recopier ton écran virtuel de 2k octets vers le "vrai" écran (de 3840 octet).
Il faudra donc utiliser une boucle pour le recopier ligne par ligne...
Le seul avantage est que pour l'effacer, ce sera presque 2 fois plus rapide qu'un buffer de 3840 octets.

Ou plus simple, tu prends un écran virtuel de 3k octets, comme ça tu n'as rien à modifier dans extgraph et tu peux le recopier avec un simple appel à memcpy. L'avantage est que tu peux l'effacer plus rapidement qu'un buffer 3840 (pas beaucoup plus, c'est environ 1.2x plus rapide...).
Apparemment, c'est cette solution que tu as utilisée.

Sinon, si ça plante quand tu sors de l'écran, c'est normal, parce que tu essaies d'écrire des données dans un endroit de la mémoire qui n'est pas fait pour, donc ça risque de planter... Il faut absolument que tu gères le clipping pour éviter ça.

Merci bien !
Oui, dc je vais rester avec un buffer de 3ko parce-que même si je modifie les lignes après ce sont les fonctions de textes qui ne passeront pas (g essayé).
Moi je pensais que l'on pouvait simplement modifier les sources d'extgraph pour avoir un buffer de 2ko mais je n'avait pas pris en compte que les fonctions d'affichage sont prévue pour un écran de 92.

Sinon et bien pour le plantage je sais j'ai déjà des jeux que j'ai abandonnés à cause de pb de collisions et il y a toujours un vaissaeu qui sortait de l'écran au bout de 5 dix minutes.

J'ai essayé de mettre un buffer de 3000 sur un jeu avec un écran remplit de sprite mais ça plante tjrs au lancement. Peut-être qu'il y a des sprites qui sont dessiné plus loin que la limite de l'écran virtuel ?

Enfin optimiser la gestion des buffer c'est interressant surtout quand les FPS atteignent 60 fps.
Là je passe de 91 FPS à 96 FPS, dc c'est pas énormé mais ç'est tojours ça en plus.

Les fonctions de texte peuvent marcher sur un buffer 160*100 (2k octets) si tu utilises celles du tios (en faisant PortSet(buffer2000,159,99) avant d'appeler le fonction de texte), mais elles sont lente. Et c'est plus simple d'utiliser un buffer de 3k octets. Je ne pense pas qu'il y ait un gain considérable de rapidité entre les deux...

sinon, si ton jeu a planté avec un buffer de 3k octets et plein de sprites, c'est soit parce que ton code buggait, ou bien parce que tu dessinais des sprites en dehors de l'écran. Il suffit d'utiliser une routine de sprites qui gère le clipping...

Ah, bon ? ... Parce-qu'en faisant PortSet(buffer2000,159,99) ça plantait justement (ou ça n'affichait pas le texte, je ne sais plus).
Et au minimum j'ai essayé avec un buffer de 2800 je crois et la partie basse de l'écran ne n'effaçait pas.

Tu utilisais quelle fonctions d'affichage de texte ?

Raphaël a écrit :
Enfin optimiser la gestion des buffer c'est interressant surtout quand les FPS atteignent 60 fps.
Là je passe de 91 FPS à 96 FPS, dc c'est pas énormé mais ç'est tojours ça en plus.

Sache que l'œil humain ne voit pas vraiment la différence au-delà d'environ 10 FPS.

Si, moi je la voit la différence. et jusqu'à 20 fps au moins même.
Et puis pour l'instant, son moteur est vraiment basique, donc c'est sûr que ça paraît bête d'optimiser alors qu'il tourne à 90 fps, mais quand il sera texturé et qu'il gèrera le clipping, les collisions, etc, ça ira plus lentement, donc heureusement qu'il aura optimisé, de façon à ce que ça ne soit pas trop lent.

Sache que l'œil humain ne voit pas vraiment la différence au-delà d'environ 10 FPS.

Oui, d'accord mais:

-Plus il y a de FPS plus ça va vite : logique !
-Quand un objet animé en 3D passe de 100 à 10 image/s si l'on veut qu'il garde la même vitesse il faut incrémenter 10 fois plus (je sais pas si ça se dit mais c'est ça que je veux dire ). Et quand une ligne se déplace de pixels en pixels et de 10 pixels en 10 pixels je vois une grosse différence !!! Pourtant je ne suis pas anormal !

Moi ce qui m'intéresse c'est pas d'avoir une animation fluide parce-que je me suis fixé 12 fps au minimum, mais plutôt les performances ! Parce-que plus mon moteur actuel tourne vite plus je pourrais afficher de polygones avec 12 Fps minimum.

Voilà pourquoi même à 95 Fps je cherche à avoir tjrs plus de frames.


Sinon la fonction texte que j'utilise est printf (elle affiche juste le taux de fps et rien de plus soit 2 caractères qd les fps ne dépasse pas 100, quand on fait un gros zoom sur le cube quoi).
J'ai déjà fait une fonction pour afficher du texte car j'ai commencer un éditeur de texte (que je ne finirai probablment pas). Mais elle lit simplment les sprites des caractère dans un tableau d'après la touche pressé par ngetchx();
Je sais bien que printf() est très très lente mais c'est juste pour le compteur.
Mais en appyant sur FPS ça désactive complètement le compteur de FPS et là je gagne encore plus de FPS (enfin j'utilise 19 pour le timer).

Avant mon moteur reliait juste les vertices entre eux par une ligne, et ne gérait pas les faces en tant que telles. Donc les polygones était des carrés, et il y avait 8 vertices pour le cube.
Avec un logiciel 3D j'ai fait un rectangle de 24 vertices et j'ai modifier les sources de mon moteur pour qu'il affiche des triangles (et donc ils y a pleins de lignes qui sont dessinées pour rien ).
Tout ça à diviser le taux de FPS par 2 sans compter qu'avant l'objet était un peu plus complexe qu'un cube.

Donc si je veux faire un vrai moteur il vaut mieux chercher partout où l'on peut gagner de la vitesse. En plus j'ai même pas encore clippé le tracé lignes d'extgraph que j'ai simplifié.

Au fait est-ce quelqu'un connait une fonction plus rapide que celle d'extgraphpour le tracer de ligne en sachant que celle que j'ai modifié ne dessine que dans un mode et directement dans le buffer ?

Si tu utilises printf pour afficher ton texte, je pense que ça devrait marcher sur un écran virtuel de taille quelconque normalement, vu que ça utilise des ROM_CALLS pour afficher le texte, il me semble... M'enfin, garde ton buffer de 3k octets, je pense que c'est le mieux.

Ensuite, pour accélérer ton moteur, je ne sais pas trop ce que tu as déjà fait comme optimisation, donc si ça se trouve, tu l'as déjà fait. c'est l'optimisation de base, je trouve : pour ne pas calculer plusieurs fois les coordonnées d'un point qui appartient à plusieurs sommets, il faut stocker tous tes points dans une liste et les transformer les uns après les autres.
Par exemple, pour un cube, si tu stockes ses coordonnées de cette façon : une liste qui contient des sommets définis chacuns par 2 points. Tu vas te retrouver avec 12 sommets, donc 24 points. Alors qu'en ne stockant que les points puis pour chaque sommet tu dis quel est son premier et son deuxième point, tu te retrouve avec 8 points ! 3 fois moins ! ce qui s'ignifie que tu feras 3 fois moins de transformations...
Je ne sais pas si c'est clair, si tu n'as pas compris, demande-moi de réexpliquer et je te mettrai un exemple...

Pour ce qui est du tracé de lignes d'extgraph, il est déjà extrêmement rapide, ça me paraît difficile de l'optimiser en pur C.

Non pour l'instant j'ai une liste de 24 sommets et je transformes le 23.
En fait j'ai fait ça juste parce-que j'utilise un logiciel 3D pour obtenir les coordonnées
des vertices, parce-qu'à la main j'ai du mal. Et le logiciel renvoie 24 sommets et 12 faces
pour un cube. Quand je vais essayere des objets plus complexe il va valloir que je supprime les 2/3 des vertex
et que je trouve les nouvelle faces à afficher. Dc c'est pas la peine.
Le mieux c'est que je trouve les vertices à la main puis que je trace le strict minimum des lignes (et dc je reviens comme je faisais avant).

Je crois que je serais obliger de me faire un éditeur pour connaître les coordonnées des vertices et les lignes à tracé pour relier les vertices.
Et puis de toute façon je crois pas que je vais aller plus loin que le fil de fer donc les faces c'est peut-être pas si important.

Essaie de trouver quelle fonction de ton prog prend le plus de temps.
Je pense que c'est celle de tracé de ligne, même si elle est très optimisée.
si tu fais un affichage en fil de fer, je trouve que c'est mieux si tu ne triangularises pas tes polygones. Mais je crois qu'il existe des techniques très rapides pour afficher des triangles, donc si ça se trouve, ce serait plus rapide en gardant les triangles...
Je te conseille de faire ce que j'ai dit dans mon post #48 pour accélérer un peu les opérations de projection (c'est pas là que le temps est le plus consommé, mais c'est déjà ça...). Et ce sera plus rapide si tu ne triangularises pas, puisque tu afficheras moins de lignes.
Mais je pense que tu pourrais faire des faces remplies d'une couleur, plutôt qu'en fil de fer, ce serait plus beau (en 4 nvg).
Est-ce que ton moteur gère le BackFace Culling ? (ça évite d'avoir à afficher la moitié des faces qui sont cachées)

Essaie de trouver quelle fonction de ton prog prend le plus de temps.
C'est ce que j'ai fait.

Je pense que c'est celle de tracé de ligne, même si elle est très optimisée
Quand je transforme les 24 vertices du cube j'ai bien l'impression que c'est la transformation qui est la plus lente (surtout que je toujours tourer l'objet sur lui même en plus des rotation pour tourner à gauche et à droite).
Sans afficher les polygones ça tourne à 89 fps. Et dc le tracé de ligne ne prend pas plus temps que la transformation.
Mais dans le cas on je relie simplment les vertices entres eux c'est le tracé de ligne le plus lent.


Pour ce qui est du tracé de lignes d'extgraph, il est déjà extrêmement rapide, ça me paraît difficile de l'optimiser en pur C.
Oui c'est bien ce qui me semblait. De toute façon ça m'a l'air tellement bien programmer que même en asm ça n'irait pas tellement plus vite (enfin je pense).
Et puis j'ai rajouter des petits "register" devant quelques variables de la fonction au cas où ça optimiserait quelque chose !







En fait j'ai deux solutions:

Soit je reviens à mon premier moteur: je relie simplement les vertices par des lignes: c'est la méthode la plus rapide mais à mon avis on est limité au fil de fer vu que l'on n'affiche ni face ni triangles.
Je me trompe ?
En dans ce cas là il faut que je fasse tout mes objets à la main.

Soit j'utilise un éditeur pour les objets 3D au quel cas je suis obligé de tracé des triangles, transformer 23 vertices pour un cube...

Parce-que la solution que tu m'a indiqué est pas mal mais elle n'est pas aussi rapide que de ne pas tracer des faces (on trace une seule lignes entre deux vertices et on n'a pas de triangles) et en plus elle ne me permet pas une conversion facile des objets édité par les éditeur 3D... Quoique finalment il y a peut-être des options pour utiliser ta méthode ? Ca ce serait génial !

Est-ce que ton moteur gère le BackFace Culling ? (ça évite d'avoir à afficher la moitié des faces qui sont cachées)
Non mais justement j'était entrain d'étudier tout les moyens possibles pour ne pas afficher les faces cachés.
D'après ce que j'ai vu le BackFace culling fait perdre 4 fois plus de temps qu'il en fait gagner (pour des objets simples déjà).
Et puis j'ai pas encore compris comment le mettre en place.
Et mes faces ne sont pas stocké dans une matrice mais je les écris en les affichant pour faire gagner un peu de temps:

inline void DrawFace(register short v1, register short v2,register short v3)
{
DrawFastLine(Pixel[v1].x,Pixel[v1].y,Pixel[v2].x,Pixel[v2].y);
DrawFastLine(Pixel[v2].x,Pixel[v2].y,Pixel[v3].x,Pixel[v3].y);
DrawFastLine(Pixel[v3].x,Pixel[v3].y,Pixel[v1].x,Pixel[v1].y);
}

DrawFace(0,3,2);
DrawFace(3,0,1);
DrawFace(4,6,7);
DrawFace(7,5,4);
DrawFace(8,10,11);
DrawFace(11,9,8);
DrawFace(12,14,15);
DrawFace(16,18,19);
DrawFace(19,17,16);
DrawFace(20,22,23);
DrawFace(23,21,20);

... Pour le BackFace Culling il faut trier les faces, non ? Et donc il faut que je stoque les faces dans une matrice.
Dans toute les démo que j'ai vu le BackFace culling ralentit 10 fois plus que l'affichage des textures.

Mon moteur ne tournerait pas à 50 fps (avec une cube de taille moyenne) si il le gèrait ?!!!


Mais je pense que tu pourrais faire des faces remplies d'une couleur, plutôt qu'en fil de fer, ce serait plus beau (en 4 nvg).

Oui, c'est sûr que ce serait bien plus beau ! Mais c'est horriblement lent ça !!!
Pour remplir un polygones il faut utiliser les lignes horizontales ? J'ai essayé une fois les lignes verticales d'extgraph mais elles ont l'air d'être complètement "buggées".

Raphaël a écrit :
En fait j'ai deux solutions:

Soit je reviens à mon premier moteur: je relie simplement les vertices par des lignes: c'est la méthode la plus rapide mais à mon avis on est limité au fil de fer vu que l'on n'affiche ni face ni triangles.
Je me trompe ? En dans ce cas là il faut que je fasse tout mes objets à la main.

Si j'ai bien compris ta méthode, non, on n'est pas limité à du fil de fer. On peut même texturer les polygones. À partir du moment où tu as les points qui délimitent une face, tu peux la remplir ou la texturer. Bien sûr, c'est plus simple d'avoir des polygones convexes pour cela.

Parce-que la solution que tu m'a indiqué est pas mal mais elle n'est pas aussi rapide que de ne pas tracer des faces (on trace une seule lignes entre deux vertices et on n'a pas de triangles) et en plus elle ne me permet pas une conversion facile des objets édité par les éditeur 3D... Quoique finalment il y a peut-être des options pour utiliser ta méthode ? Ca ce serait génial !

Je ne comprends pas est-ce que tu peux réexpliquer, stp ?

Non mais justement j'était entrain d'étudier tout les moyens possibles pour ne pas afficher les faces cachés. D'après ce que j'ai vu le BackFace culling fait perdre 4 fois plus de temps qu'il en fait gagner (pour des objets simples déjà).

C'est vrai qu'en fil de fer, le gain n'est pas très important, mais dès que tu passes en texturé, tu le sens ! Mais même en fil de fer, ça évite d'afficher des lignes, donc c'est plus rapide (sachant que calculer si on va afficher le polygone ou non ne prend que 3 multiplications et 2 additions, ce qui n'est vraiment pas énorme).

Pour le BackFace Culling il faut trier les faces, non ? Et donc il faut que je stoque les faces dans une matrice. Dans toute les démo que j'ai vu le BackFace culling ralentit 10 fois plus que l'affichage des textures.

Le mieux est d'utiliser des arbres BSP. Mais c'est assez compliqué.
Pour calculer si on doit afficher ou non les lignes qui forment le polygone, il faut en fait orienter tes polygones : de face on l'affiche, de dos on ne l'affiche pas. Pour un cube vu de l'extérieur, il faut que toutes les faces soient orientées vers l'extérieur.
Pour calculer si un polygone est face à l'utilisateur ou dos à lui, il faut faire le produit scalaire de la normale au polygone avec un vecteur unitaire dans la direction de l'utilisateur. Si le résultat est négatif, c'est que le polygone est face à l'utilisateur.

Mon moteur ne tournerait pas à 50 fps (avec une cube de taille moyenne) si il le gèrait ?!!!

Pour un cube, dans le meilleur des cas, on affiche une seule face, dans le pire trois faces. Ça fait qu'on évite d'afficher 5 faces dans le meilleur des cas et 3 dans le pire. Je pense que ça fait une différence.

Oui, c'est sûr que ce serait bien plus beau ! Mais c'est horriblement lent ça !!! Pour remplir un polygones il faut utiliser les lignes horizontales ? J'ai essayé une fois les lignes verticales d'extgraph mais elles ont l'air d'être complètement "buggées".

Non, leur routine n'est pas buggée.
Et afficher des polygones d'une couleur unie est assez rapide si tu fais un bonne routine. En tous cas, c'est nettement plus rapide que de les texturer et le résultat n'est pas très moche.

Avec les écrans en 8 pixels par octet (comme celui de la TI-89/92+/V200), normalement, les lignes horizontales pour le remplissage sont plus rapides que les lignes verticales.

Ok, merci Kevin !

J'en ai marre !!! ... J'ai pas un éditeur 3D qui n'est pas en version limité ou d'évalution.
Et puis j'ai toujours un gros problème avec mon PC: Quand je ne suis pas en mode VGA l'ordi plante soit tout de suite soit trois heures après. Et ça vient ni de Windows XP ni des drivers.
Ce qui fait que ceux qui ont besoin d'une accélération matérielle ne marche pas !!!

Là j'en ai qu'1 seul qui va bien mais j'ai le droit à 19 sauvegarde.

Sinon j'en ai eu marre des cubes alors je l'ai remplacé par une sphère qui fait 14 vertices et 24 faces !!! Soit l'inverse du cube ! Et en plus ça fait que j'utilise la même technique que tu me conseillais sans le vouloir.

Et puis j'ai trouvé un tuto excellent sur la 3D où il y a une formule du BackFaceCulling et donc je me suis servit.
Par contre c'est vrai que pour cette fonction je n'ai pas tout compris: même en première les produit scalaire et les vecteurs c'est pas mon fort

Et pour ne pas perdre trop de temps je l'ai couplé à ma fonction qui dessine les faces :

inline void DrawFaceBackCulling(register short v1, register short v2,register short v3)
{

int x1=Pixel[v1].x;
int x2=Pixel[v2].x;
int x3=Pixel[v3].x;
int y1=Pixel[v1].y;
int y2=Pixel[v2].y;
int y3=Pixel[v3].y;
int va1=x1-x2;
int vb1=y1-y2;
int va2=x3-x2;
int vb2=y3-y2;
int resultat=va2*vb1-va1*vb2;
if(resultat<1)
{
DrawFastLine(Pixel[v1].x,Pixel[v1].y,Pixel[v2].x,Pixel[v2].y);
DrawFastLine(Pixel[v2].x,Pixel[v2].y,Pixel[v3].x,Pixel[v3].y);
DrawFastLine(Pixel[v3].x,Pixel[v3].y,Pixel[v1].x,Pixel[v1].y);
}
}

... Avec ma sphère je suis obligé d'afficher les lignes lorsque le résultat est négatif parce-que l'éditeur à dû ordonner les point à l'envers.
Par contre il y a une des face qui foire (peut-être que les points de celle-là ont été ordonnés à l'endroit).

Sur HW2 je passe par ex de 64 Fps à 88 Fps et de 34 à 60 Fps lorsque le cube est en plein écran !!! Je pensais pas que c'était aussi efficasse et je pensais qu'on était obligé de trier les faces.

Tu vois pas une otimisation à faire dans ma fonction, non ?

Bon et bien maintenant il va falloir que je trouve un éditeur. Sinon j'ai Blender (une version assez ancienne) mais j'ai pas encore trouvé comment enregistré l'objets pour avoir les vertcies + les faces ordonnées pour le Back Face Culling.

C'est possible de mettre un screen même si il n'y a pas d'adresse url ? (je prend le screen depuis le bureau de Windows par vex ?)

Raphaël a écrit :
Sinon j'en ai eu marre des cubes alors je l'ai remplacé par une sphère qui fait 14 vertices et 24 faces !!! Soit l'inverse du cube ! Et en plus ça fait que j'utilise la même technique que tu me conseillais sans le vouloir.

Comment ça, sans le vouloir ?

Et puis j'ai trouvé un tuto excellent sur la 3D où il y a une formule du BackFaceCulling et donc je me suis servit.

Tu peux me donner l'adresse, stp ?

inline void DrawFaceBackCulling(register short v1, register short v2,register short v3)
{

int x1=Pixel[v1].x;
int x2=Pixel[v2].x;
int x3=Pixel[v3].x;
int y1=Pixel[v1].y;
int y2=Pixel[v2].y;
int y3=Pixel[v3].y;
int va1=x1-x2;
int vb1=y1-y2;
int va2=x3-x2;
int vb2=y3-y2;
int resultat=va2*vb1-va1*vb2;
if(resultat<1)
{
DrawFastLine(Pixel[v1].x,Pixel[v1].y,Pixel[v2].x,Pixel[v2].y);
DrawFastLine(Pixel[v2].x,Pixel[v2].y,Pixel[v3].x,Pixel[v3].y);
DrawFastLine(Pixel[v3].x,Pixel[v3].y,Pixel[v1].x,Pixel[v1].y);
}
}

... Avec ma sphère je suis obligé d'afficher les lignes lorsque le résultat est négatif parce-que l'éditeur à dû ordonner les point à l'envers. Par contre il y a une des face qui foire (peut-être que les points de celle-là ont été ordonnés à l'endroit).

Je ne sais pas. Moi, le moteur sur lequel je travaille en ce moment est simplifié. Je ne vois pas trop quel calcul tu as fait...

Tu vois pas une otimisation à faire dans ma fonction, non ?

Non, mais tu sais je ne suis pas un boss. Il faudrait qq1 de fort en C pour t'aider.
Par contre, pourquoi tu mets if(resultat<1), ce n'est pas if(resultat<0), plutôt ?

Voici l'adresse du tuo:

http://liocity.free.fr/delphicharger/tutorial/les_principes_de_la_3d_1.zip

Comment ça, sans le vouloir ?

Eh, bien c'est tout simple: avec le cube j'avais 24 vertices et 12 faces je crois.
Et toi tu m'avais dit d'en transformer que 8 car tout les vertices sont en triple en fait.
Mais avec les coordonnées de la sphère que j'ai récupérer grâce à l'éditeur à sauvegarde limitées, il n'y a pas deux points qui ont les même coordonnées !
Ce qui fait que j'ai 14 vertices et 24 faces !!!! Là au point je n'ai pas trois fois + de transformation à faire que de face à afficher.

Je ne sais pas. Moi, le moteur sur lequel je travaille en ce moment est simplifié. Je ne vois pas trop quel calcul tu as fait...
Par contre j'ai un gros problème avec cette fonction qui me bouffe 2 ko !!!!
Là je viens de rajouter une option pour activer ou désactiver le Back Face Culling et puis mon prog est passé de 6 ko à 4 ! Les variables doivent être mal déclaré ou alors il faut rajouté des crochets ?

J'ai commencé la programation en C avec TIGCC sur Ti 89 en juin et je ne connais pas énormément de chose non plus.

Par contre, pourquoi tu mets if(resultat<1), ce n'est pas if(resultat<0), plutôt ?
Bien vu ! Oui normalment c'est 0 mais je pensais que ça allait résoudre le problème avec la face quoi marche pas... Ce qui n'a évidement pas marché.

Raphaël a écrit :
J'en ai marre !!! ... J'ai pas un éditeur 3D qui n'est pas en version limité ou d'évalution.

http://www.blender3d.com/
Il y a une version gratuite, mais closed-source, déjà disponible, et la sortie d'une version sous GPL (et toujours gratuite) est prévue pour demain.

Raphaël a écrit :
Par contre j'ai un gros problème avec cette fonction qui me bouffe 2 ko !!!! Là je viens de rajouter une option pour activer ou désactiver le Back Face Culling et puis mon prog est passé de 6 ko à 4 ! Les variables doivent être mal déclaré ou alors il faut rajouté des crochets ?

Alors là, je ne sais pas. Je ne vois rien en cette fonction qui devrait prendre 2 KO...

Par contre, pourquoi tu mets if(resultat<1), ce n'est pas if(resultat<0), plutôt ?
Bien vu ! Oui normalment c'est 0 mais je pensais que ça allait résoudre le problème avec la face quoi marche pas... Ce qui n'a évidement pas marché.

OK.
Sache que les comparaisons avec 0 sont plus rapides et prennent moins de code que les comparaisons avec une constante non-nulle. Ceci dit:
* Un test <1 devrait être transformé par le compilateur en un test <=0, qui revient au même. (Je n'ai pas testé, mais je pense bien que GCC le fasse.)
* En tout cas, ce n'est pas ça qui prend 2 KO.