Matrices de rotations et projections - Page 1

Est-ce quelqu'un pourrait m'expliquer à quoi servent les matrices de rotations, de transformations... en 3D ?

Comme bcp de personnes sur ce forum j'ai réalisé en petit moteur 3D en fil de fer (pour l'instant je fait tourner un cube et puis 4 autres lignes).
Je fais tourner l'objet grâce à ces trois fonctions :

inline void RotationY(void)
{



Transform[t].x = Vertex[t].x*Cos[i] + Vertex[t].z*Sin[i];
Transform[t].y = Vertex[t].y*128;
Transform[t].z = (-Vertex[t].x)*Sin[i] + Vertex[t].z*Cos[i];
}


inline void RotationX(void)
{
Transform[t].x = Vertex[t].x*128;
Transform[t].y = Vertex[t].y*Cos[i] - Vertex[t].z*Sin[i];
Transform[t].z = Vertex[t].y*Sin[i] + Vertex[t].z*Cos[i];
}

inline void RotationZ(void)
{
Transform[t].x = Vertex[t].x*Cos[i] + Vertex[t].y*Sin[i];
Transform[t].y = (-Vertex[t].x)*Sin[i] + Vertex[t].y*Cos[i];
Transform[t].z = Vertex[t].z*128;
}

Avec ça mon moteur tourne très bien (117 fps) mais je ne peut pas effectuer plusieurs rotation en même temps.
Et puis à part faire un zoom (via le Offset lors de la projection) je ne sais pas faire d'autres transformations.

Avec les matrices de rotations il faut faire bcp de calcules qui ne ne servent pas à grand chose. Donc, c koi l'intérêt d'utiliser des matrices pour les rotations ?
Et puis quand on effectue plusieurs rotation (avec 3 matrices par ex) comment on fait pour avoir qu'une seule matrice qui corresponde à la transformation désiré ?


Et puis sur Internet je trouve souvent cette formule de projection mais évidement elle marche pas:

xp = (largeur de l'écran / 2) + d * x / z
yp = (hauteur de l'écran / 2) + d * y / z

La seule formule que j'ai trouvé et qui marche et celle-ci.
Parce-que si on ajoute rien à Z et que Z est négatif on se retrouve avec un nombre trop grand et qui est négatif.

Pixel[t].x = Xset + (Transform[t].x<<8) / (Transform[t].z+Offset); //
Pixel[t].y = Yset + (Transform[t].y<<8) / (Transform[t].z+Offset); //

Parce-que si on ajoute rien à Z et que Z est négatif on se retrouve avec un nombre trop grand et qui est négatif.

Dernier petits trucs:

Pour la liste des vertex et la matrice qui contient les coordonnées 2D des lignes à afficher j'utilisais des char.
Mais en les remplacant par des short j'ai gagné 400 octets et quelques FPS.
C'est normal ? Ca vient de quoi ?

> Avec les matrices de rotations il faut faire bcp de calcules qui ne ne servent pas à grand chose. Donc, c koi l'intérêt d'utiliser des matrices pour les rotations ?
> Et puis quand on effectue plusieurs rotation (avec 3 matrices par ex) comment on fait pour avoir qu'une seule matrice qui corresponde à la transformation désiré ?
Multiplications de matrices cherche sur Google...

Et puis sur Internet je trouve souvent cette formule de projection mais évidement elle marche pas:
xp = (largeur de l'écran / 2) + d * x / z
yp = (hauteur de l'écran / 2) + d * y / z

La seule formule que j'ai trouvé et qui marche et celle-ci.
Parce-que si on ajoute rien à Z et que Z est négatif on se retrouve avec un nombre trop grand et qui est négatif.

Pixel[t].x = Xset + (Transform[t].x<<8) / (Transform[t].z+Offset); //
Pixel[t].y = Yset + (Transform[t].y<<8) / (Transform[t].z+Offset); //
Parce-que si on ajoute rien à Z et que Z est négatif on se retrouve avec un nombre trop grand et qui est négatif.

Oui, si tu ne fais pas de translations sur tes coordonnées. Non, si tu en fais (et c tjrs le cas sauf pour un cube qui tourne )
D'ailleurs si Z est négatif il ne faut pas afficher le point (cas où le point est derrière la caméra)

Pour la liste des vertex et la matrice qui contient les coordonnées 2D des lignes à afficher j'utilisais des char.
Mais en les remplacant par des short j'ai gagné 400 octets et quelques FPS. C'est normal ? Ca vient de quoi ?

Oui : le 68k est fait pour gérer des nombres sur 16 ou 32 bits, et pour mal d'opérations sur les char (genre multiplication...) il est obligé de les convertir en short...

D'ailleurs à moins de faire un moteur de cubes qui tournent, tu auras besoin de short ou de long

Merci bien pour ta réponse ! :-)

Oui, si tu ne fais pas de translations sur tes coordonnées. Non, si tu en fais (et c tjrs le cas sauf pour un cube qui tourne )
D'ailleurs si Z est négatif il ne faut pas afficher le point (cas où le point est derrière la caméra)
Tu veux dire quoi ? J'ai pas bien compris.

Avec cette formule de projection:
Pixel[t].x = Xset + (Transform[t].x<<8) / (Transform[t].z+Offset); //
Pixel[t].y = Yset + (Transform[t].y<<8) / (Transform[t].z+Offset); //

on peut bien faire des translations ? Et puis on peut bien faire un "vrai" moteur 3D et pas qu'un cube qui tourne ?

Et puis avec ça:
xp = (largeur de l'écran / 2) + d * x / z
yp = (hauteur de l'écran / 2) + d * y / z
on peut pas bien faire grand chose. C'est pas normal qu'une coordonnées soit négative qd Z est négatif sinon il faudrait avoir que des Z positif et dans ce cas là je vois pas bien comment on peut faire des rotations.
Et si on veut faire un zoom sans déformation il est préfèrable d'ajouter un nombre positif à Z pour pouvoir régler la taille de l'objet.

Ma fomule est directement issu du tuto de Christophe Heulin et sur son site il en propose une autre :

X' = Xo + Zo * (X-Xo) / (Zo-Z)
Y' = Yo + Zo * (Y-Yo) / (Zo-Z)

Mais avec celle là j'arrive toujours pas à projeté mon cube. Admettons que j'arrive à projecter qq chose avec cette formule, est-ce qu'elle serait mieux adapté pour un "vrai" moteur 3D ?
Je m'y connais pas très bien en 3D, alors je sais même pas quelle formule de projections il faut utiliser.

Et toi tu as déjà fait un moteur 3D sur TI ?
t puis tout ceux du forum qui ont essayés ils en sont où ? J'ai déjà vu des screens mais ils n'y a pas eu de démos ni de jeux qui sont sortit me sembe-t-il, non ?

Merci pour ton explications sur les char. Et au fait le processeur (68k) est en 16 bits ou un 32 ?
De toute façon j'utilise plus que des short et j'utlise déjà des long vu que pour les angles je me sers de grand entiers que je multiplie par 256.

Mais il me semble que les calculs avec des long peuvent être légèrement plus lents qu'avec des short, notemment la division et la multiplication.
Je me trompe ?

Les multiplications/divisions les plus rapides sont:
short*short->long
long/short->short
long%short->short
Tout le reste doit être synthétisé. (Et short*short->short est beaucoup plus rapide que long*long->long parce que GCC n'a qu'à ignorer le short de poids fort du long résultant plutôt que de décomposer la multiplication en 3 sous-multiplications - pas 4 parce qu'on travaille modulo 2^32.)

Je suis obligé d'utiliser un tableau de long car quand je multiplie les shorts par 256, ils ne se multiplie pas comme il faut vu que les shorts sont trop petits. Même si je stoque aucun long dans une variable, avec la formule de projection que j'utilise il faut des long pour la matrice qui contient les points 3D transformés.

Justement j'ai essayé la 2° formule du tuto de Christophe heulin et ça donne ça:

Pixel[t].x = Xset+ (10*Zset * (Transform[t].x/128-Xset) / ((Zset-Transform[t].z/128)));
Pixel[t].y = Yset+ (10*Zset * (Transform[t].y/128-Yset) /((Zset-Transform[t].z/128)));

Par contre la je suis obligé de faire une translation de vertex après la transformation et avant la projection pour que le cube rendre complètement dans l'écran.
Et sinon j'ai de très gros problème avec la perspective !!!!

Avec celle-ci il n'y a pas de pb car on multiplie les X et les Y par un grand nombre (256) et puis on réduit la taille avec Offset.
Pixel[t].x = Xset + (Transform[t].x<<8) / (Transform[t].z+Offset); //
Pixel[t].y = Yset + (Transform[t].y<<8) / (Transform[t].z+Offset); //
Mais par contre c'est vrai qu'elle ne prend pas en compte la postion de celui qui voit la scène et donc à part faire tourner des cubes c'est tout ce que l'on peut faire.



Pour corriger cela il faudrait peut-être faire ça ?:

Pixel[t].x = Xset+ (10*Zset * (Transform[t].x/128-Xset) / ((Zset-Transform[t].z/128+Offset)));
Pixel[t].y = Yset+ (10*Zset * (Transform[t].y/128-Yset) /((Zset-Transform[t].z/128+Offset)));

Et puis modifier les valeurs de Zest pour que ça soit un grand nombre.

Les calculs de cette formules sont assez couteux surtout que je suis obligé de diviser les vertex * angles (Transform[t]) par 128 vu que j'ai fait des tables de cos et de sin en multipliant les cos et les sin par 128 pour avoir de grand entiers et une bonne précision.

Quelqu'un pourrait m'aider à améliorer cette formule ou me donner des astuces ?

>Je suis obligé d'utiliser un tableau de long car quand je multiplie les shorts par 256, ils ne se multiplie pas comme il faut vu que les shorts sont trop petits.

Déjà, on ne multiplie jamais un nombre par 256, on le décale vers la gauche de 8. (GCC optimise ça lui-même, mais bon.)
Ensuite, pas la peine de le stocker en long, il suffit de le transtyper avant le décalage:
unsigned short tableau[1234];
unsigned long resultat;
resultat=((unsigned long)tableau[123])<<8;
(D'ailleurs, utilise des unsigned si les nombres ne peuvent pas être négatifs, ça élargit la rangée des nombres positifs possibles.)

Non en fait je ne stoque AUCUN long !
Je fais plutôt un truc comme ça:

long point3D[9];
short point2D[9];

point2D[x].x=80+(point3D[x].x<<8)/(point3D[x].z+160000);
point2D[x].y=50+(point3D[x].y<<8)/(point3D[x].z+160000);

donc point2D[9] est un short comme point3D[x].x<<8 par et divisé par point3D[x].z+160000 pour retrouvé des proportions affichable à l'écran.
Ensuite on ajoute 80 pour qu'il se trouve au milieu de l'écran.

Mais comme point3D[9] contient des grand nombres (entre -1280 et 1280 avec les coordonées du cube (10 au max et -10 au min)* le plus grand angle (128)) quand je les multiplie par 256 (ou décale de 8), la multiplication ne marche pas vu que l'on décale un grand short de 8. En remplacant le tableau de short par un tableau de long on peut décaler correctement de 8 comme la variable est assez grande, je me trompe ?

Et si TIGCC décalait pas de 8 et multipliait par 256 quand on fait mavar*256 par ex, il n'y aurait pas ce problème ?

Moi je croyais que si on multipliant par 256, TIGCC ne décalait pas les bits. Ca serait bien qu'il optimise rien comme ça chacun à le choix de faire ce qu'il veut en fonction des problèmes et des avantages que ça pose. Sinon ça sert à rien de laisser les opérateur pour décaler les bits.

Pour unsigned long je sais déjà, merci quand même !


Et pour les formules de projections, quelqu'un pourrait m'aider ?

Raphaël
a écrit : Et si TIGCC décalait pas de 8 et multipliait par 256 quand on fait mavar*256 par ex, il n'y aurait pas ce problème ?

Bien sûr que si ! cela revient exactement au même de multiplier un nombre par 256 ou de le décaler de 8 bits !
prends 5, par ex (0b00000101), multiplié par 256, ça fait 1280, soit 10100000000 en binaire, on a bien un décalage de 8 bits.
Mais réfléchis un peu, ça aurait été complètement débile, si cela ne revenait pas au mêm, de décaler de n cran et de multiplier par 2^n, parce que si un utilisateur veut faire une multiplication par huit et que le compilo fait un décalage de 3 bits vers la gauche, si ça ne revient pas au même, le résultat de sa multiplication est faussé !

Ok, d'accord. Je comprends mieux mnt.

Raphaël
a écrit : Mais comme point3D[9] contient des grand nombres (entre -1280 et 1280 avec les coordonées du cube (10 au max et -10 au min)* le plus grand angle (128)) quand je les multiplie par 256 (ou décale de 8), la multiplication ne marche pas vu que l'on décale un grand short de 8. En remplacant le tableau de short par un tableau de long on peut décaler correctement de 8 comme la variable est assez grande, je me trompe ?

As-tu lu mon message #6?
Tu peux définir point3D comme short et utiliser:
point2D[x].x=80+(short)(((long)point3D[x].x<<8)/((long)point3D[x].z+160000));
point2D[x].y=50+(short)(((long)point3D[x].y<<8)/((long)point3D[x].z+160000));

Si, si j'ai bien lu mais j'avais mal compris. Merci bien !

Sinon personne peut m'aider pour les formules de projections ?!

un tuyau: utilise le theoreme de thales...

un truc du genre:

x' = x*focal/z
y' = y*focal/z

Oui, mais c'est bien ce que je fais non ?
Et je comprend tjrs pas exactement comment faire une formule qui prenne en compte l'observateur.
D'ailleurs j'ai posté le même sujet dans la section Prog en C.

sBiBi, c'est bien toi qui à réalisé un moteur 3D dans l'objectif de faire des "mini-maps" ressemblant à celles de quake ?
Sur les screens qui l'y a a sur le forum la projection à l'air d'être vraiment parfaite !!!!
Tu fais comment ? Es-ce qu'il serait possible que tu m'expliques tes formules de projections 3D ?

bah... mes formules de projections, c'est celles deux posts au dessus
"prendre en compte l'observateur"
cad???
comment ca prendre en compte l'observateur?

on ne projète plus sur le plan z=0, mais sur un autre plan selon l'endroit où on est et la direction qu'on a.

??????

heu je comprends rien...
bon...
transformations a appliquer aux points:

- translations de la camera
- rotations de la camera
- projection

Eh bien là j'utilise une formule qui permet de projeter des vertex dont les coordonnées vont de -10 à10) et qui sont multiplier par des angles entiers allant de -128 à 128 (pour effectuer une des 3 formule de rotation):

Pixel[t].x = Xset + (Transform[t].x<<8) / (Transform[t].z+Zset);
Pixel[t].y = Yset + (Transform[t].y<<8) / (Transform[t].z+Zset;

Xset=80, Yset=50 et Offset=16000

La perspective est parfaite et tout marche bien.
Mais quand on déplace l'objet (par ex on incrémente Xset) l'objet se déplace vers la droite et on le voit toujours de face alors que normalment on devrait progressivement voir apparaître le côté de l'objet. (en fait on est dans un repère qui n'est pas celui de l'observateur, enfin en imaginant que quelqu'un regarde la scène).

En fait c'est peut-être bien un truc comme ça :

on ne projète plus sur le plan z=0, mais sur un autre plan selon l'endroit où on est et la direction qu'on a.

Mais je ne vois pas comment faire: Pour l'instant avec mon moteur la caméra est fixe et c'est l'objet qui se déplace.

bon, attends...
ta projection, tu la garde, les rotations, laisse tomber pour l'instant...
tu ajoutes la position de la camera aux coordonnees des points, et apres tu les projettes...

un truc du genre:

x = vertex[t].x + camera.x;
y = vertex[t].y + camera.y;
z = vertex[t].z + camera.z;

if(z)
{
  pixel[t].x = (x << 8)/z + half_screen_width;
  pixel[t].y = (y << 8)/z + half_screen_height;
}

x = vertex[t].x + camera.x;
y = vertex[t].y + camera.y;
z = vertex[t].z + camera.z;

if(z)
{
pixel[t].x = (x << 8)/z + half_screen_width;
pixel[t].y = (y << 8)/z + half_screen_height;
}

Oui mais la camera ça correspond à quoi ? Pour calculer la caméra il faut faire comment ?
Et puis si je veux que ça marche avec cette formule il faut que ce que l'on ajoute à vertex[t].z (la caméra) soit assez grand pour que Z soit positif ?
Parce-qu'avec la formule d'avant ça marchait même avec un Z négatif.

pt1... mais camera, c'est la structure de ta camera, camera.x, .y, .z c'est la position de ta camera dans ton monde 3D! c'est la position de l'observateur!! c'est ca que tu change quand tu te deplace! et ce que t'ajoutes a vertex[t].z, tu t'en fous, c'est l'utilisateur qui le controle avec les touches avancer/reculer, aller a gauche/a droite...
ca marche meme avec les Z negatifs, parceque ca projette aussi les points qui sont derriere l'ecran, pour projeter uniquement ceux qui sont devant, tu dois transformer le test if(z) en: if(z > 0)
et tu peux initialiser camera.z a 100 ou 200 par exemple, si tu veux voir ton objet
pke si tu le laisse a 0, ta camera sera situee a l'interieur de l'objet, si celui ci est centre a l'origine, et dans la plupart des cas, tu ne verra rien...

pour tester, fais une fct qui incremente ou decremente camera.z selon que t'appuies sur fleche haut/fleche bas....

et camera, c'est une structure du genre:

struct camera
{
  short x,y,z;
};

Trop bien !!!!! Ca marche !!!!!!!!
MERCI, c'est vraiment sympa !
En fait j'avais bien compris comment on définisait la caméra mais je ne pensais pas que c'était aussi simple ! Je pensais qu'il manquait quelque chose.

Par contre je n'ai pas encore essayé de remettre les rotation. Normalement si j'applique une formule de rotation aux vertex avant la transformation par la caméra, ça devrait marcher ?
De toute façon je verrais ça très vite !

Encore merci !

Ouais, par contre pour les rotation c'est pas ça... avec les formules de rotation que j'utilisais avant ça marche plus

Ah, si c bon ça marche en faisant comme ça:

x = Transform[t].x + camera.x*128;
y = Transform[t].y + camera.y*128;
z = Transform[t].z + camera.z*128;


if(z)
{
Pixel[t].x = ((x/128) << 8)/(z/128) + 80;
Pixel[t].y = ((y/128) << 8)/(z/128) + 50;
}

C'est tjrs à cause des angles que je multiplie par les vertex lors de la rotation.

bah si tu fais les rots avant les translations, tu dois garder le mm format de virgule fixe...

par contre pour avoir les deplacements d'un doom-like (vue a la 1ere personne), tu dois faire les translations AVANT les rotations...

par contre pour avoir les deplacements d'un doom-like (vue a la 1ere personne), tu dois faire les translations AVANT les rotations...

Ah, bon ?
J'ai essayé mais ça ne marche carrément pas !
Quand mon cube tourne il sort tout de suite de l'écran. :-(

Je vois pas comment je pourrais faire.

Sinon j'ai fait une truc qui marche très bien d'après ce que tu m'as expliqué:


static int Cos[360]={128,128,128,128,128,128,127,127,127,126,126,126,125,125,124,124,123,122,122,121,120,119,119,118,117,116,115,114,113,112,111,110,109,107,106,105,104,102,100,99,98,97,95,94,92,91,89,87,86,84,82,81,79,77,75,73,72,70,68,66,64,62,60,58,56,54,52,50,48,46,44,42,40,37,35,33,31,29,27,24,22,20,18,16,13,11,9,7,4,2,0,-2,-4,-7,-9,-11,-13,-16,-18,-20,-22,-24,-27,-29,-31,-33,-35,-37,-40,-42,-44,-46,-48,-50,-52,-54,-56,-58,-60,-62,-64,-66,-68,-70,-72,-73,-75,-77,-79,-81,-82,-84,-86,-87,-89,-91,-92,-94,-95,-97,-98,-99,-101,-102,-104,-105,-106,-107,-109,-110,-111,-112,-113,-114,-115,-116,-117,-118,-119,-119,-120,-121,-122,-122,-123,-124,-124,-125,-125,-126,-126,-126,-127,-127,-127,-128,-128,-128,-128,-128,-128,-128,-128,-128,-128,-128,-127,-127,-127,-126,-126,-126,-125,-125,-124,-124,-123,-122,-122,-121,-120,-119,-119,-118,-117,-116,-115,-114,-113,-112,-111,-110,-109,-107,-106,-105,-104,-102,-100,-99,-98,-97,-95,-94,-92,-91,-89,-87,-86,-84,-82,-81,-79,-77,-75,-73,-72,-70,-68,-66,-64,-62,-60,-58,-56,-54,-52,-50,-48,-46,-44,-42,-40,-37,-35,-33,-31,-29,-27,-24,-22,-20,-18,-16,-13,-11,-9,-7,-4,-2,0,2,4,7,9,11,13,16,18,20,22,24,27,29,31,33,35,37,40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,73,75,77,79,81,82,84,86,87,89,91,92,94,95,97,98,99,101,102,104,105,106,107,109,110,111,112,113,114,115,116,117,118,119,119,120,121,122,122,123,124,124,125,125,126,126,126,127,127,127,128,128,128,128,128};
static int Sin[360]={0,2,4,7,9,11,13,16,18,20,22,24,27,29,31,33,35,37,40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,73,75,77,79,81,82,84,86,87,89,91,92,94,95,97,98,99,101,102,104,105,106,107,109,110,111,112,113,114,115,116,117,118,119,119,120,121,122,122,123,124,124,125,125,126,126,126,127,127,127,128,128,128,128,128,128,128,128,128,128,128,127,127,127,126,126,126,125,125,124,124,123,122,122,121,120,119,119,118,117,116,115,114,113,112,111,110,109,107,106,105,104,102,100,99,98,97,95,94,92,91,89,87,86,84,82,81,79,77,75,73,72,70,68,66,64,62,60,58,56,54,52,50,48,46,44,42,40,37,35,33,31,29,27,24,22,20,18,16,13,11,9,7,4,2,0,-2,-4,-7,-9,-11,-13,-16,-18,-20,-22,-24,-27,-29,-31,-33,-35,-37,-40,-42,-44,-46,-48,-50,-52,-54,-56,-58,-60,-62,-64,-66,-68,-70,-72,-73,-75,-77,-79,-81,-82,-84,-86,-87,-89,-91,-92,-94,-95,-97,-98,-99,-101,-102,-104,-105,-106,-107,-109,-110,-111,-112,-113,-114,-115,-116,-117,-118,-119,-119,-120,-121,-122,-122,-123,-124,-124,-125,-125,-126,-126,-126,-127,-127,-127,-128,-128,-128,-128,-128,-128,-128,-128,-128,-128,-128,-127,-127,-127,-126,-126,-126,-125,-125,-124,-124,-123,-122,-122,-121,-120,-119,-119,-118,-117,-116,-115,-114,-113,-112,-111,-110,-109,-107,-106,-105,-104,-102,-100,-99,-98,-97,-95,-94,-92,-91,-89,-87,-86,-84,-82,-81,-79,-77,-75,-73,-72,-70,-68,-66,-64,-62,-60,-58,-56,-54,-52,-50,-48,-46,-44,-42,-40,-37,-35,-33,-31,-29,-27,-24,-22,-20,-18,-16,-13,-11,-9,-7,-4,-2};


Vertex[0].x=-20; Vertex[0].y=-20; Vertex[0].z=-20;
Vertex[1].x=20; Vertex[1].y=-20; Vertex[1].z=-20;
Vertex[2].x=20; Vertex[2].y=20; Vertex[2].z=-20;
Vertex[3].x=-20; Vertex[3].y=20; Vertex[3].z=-20;
Vertex[4].x=20; Vertex[4].y=-20; Vertex[4].z=20;
Vertex[5].x=-20; Vertex[5].y=-20; Vertex[5].z=20;
Vertex[6].x=-20; Vertex[6].y=20; Vertex[6].z=20;
Vertex[7].x=20; Vertex[7].y=20; Vertex[7].z=20;
Vertex[8].x=0; Vertex[8].y=0; Vertex[8].z=0;



inline void RotationY(void)
{

Transform[t].x =Vertex[t].x*Cos[i] + Vertex[t].z*Sin[i]; ;
Transform[t].y =(Vertex[t].y<<7);
Transform[t].z =(-Vertex[t].x)*Sin[i] + Vertex[t].z*Cos[i] ;
}

inline void RotationX(void)
{
Transform[t].x = (Vertex[t].x<<7);
Transform[t].y = Vertex[t].y*Cos[i] - Vertex[t].z*Sin[i];
Transform[t].z = Vertex[t].y*Sin[i] + Vertex[t].z*Cos[i];
}

inline void RotationZ(void)
{
Transform[t].x = Vertex[t].x*Cos[i] + Vertex[t].y*Sin[i];
Transform[t].y = (-Vertex[t].x)*Sin[i] + Vertex[t].y*Cos[i];
Transform[t].z = (Vertex[t].z<<7);
}





do{

for(i=0;i<361;i++)
{

if (_keytest (RR_F2))
{
rotation=0;
}

if (_keytest (RR_F3))
{
rotation=1;
}

if (_keytest (RR_F4))
{
rotation=2;
}

if (_keytest (RR_RIGHT))
{
camera.x++;
}
if (_keytest (RR_LEFT))
{
camera.x--;
}
if (_keytest (RR_UP))
{
camera.z--;
}
if (_keytest (RR_DOWN))
{
camera.z++;
}


for(t=0;t<9;t++)
{


if(!rotation)
{
RotationX();
}

if(rotation==1)
{
RotationZ();
}

if(rotation==2)
{
RotationY();
}


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

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

}

DrawFastLine(buffer,Pixel[0].x,Pixel[0].y,Pixel[1].x,Pixel[1].y);
DrawFastLine(buffer,Pixel[1].x,Pixel[1].y,Pixel[2].x,Pixel[2].y);
DrawFastLine(buffer,Pixel[2].x,Pixel[2].y,Pixel[3].x,Pixel[3].y);
DrawFastLine(buffer,Pixel[0].x,Pixel[0].y,Pixel[3].x,Pixel[3].y);
DrawFastLine(buffer,Pixel[4].x,Pixel[4].y,Pixel[5].x,Pixel[5].y);
DrawFastLine(buffer,Pixel[5].x,Pixel[5].y,Pixel[6].x,Pixel[6].y);
DrawFastLine(buffer,Pixel[6].x,Pixel[6].y,Pixel[7].x,Pixel[7].y);
DrawFastLine(buffer,Pixel[4].x,Pixel[4].y,Pixel[7].x,Pixel[7].y);
DrawFastLine(buffer,Pixel[0].x,Pixel[0].y,Pixel[5].x,Pixel[5].y);
DrawFastLine(buffer,Pixel[1].x,Pixel[1].y,Pixel[4].x,Pixel[4].y);
DrawFastLine(buffer,Pixel[2].x,Pixel[2].y,Pixel[7].x,Pixel[7].y);
DrawFastLine(buffer,Pixel[3].x,Pixel[3].y,Pixel[6].x,Pixel[6].y);

DrawFastLine(buffer,Pixel[0].x,Pixel[0].y,Pixel[8].x,Pixel[8].y);
DrawFastLine(buffer,Pixel[1].x,Pixel[1].y,Pixel[8].x,Pixel[8].y);
DrawFastLine(buffer,Pixel[2].x,Pixel[2].y,Pixel[8].x,Pixel[8].y);
DrawFastLine(buffer,Pixel[3].x,Pixel[3].y,Pixel[8].x,Pixel[8].y);

FastCopyScreen(buffer,LCD_MEM);
memset(buffer, 0, 3840);


}


}while(!_keytest (RR_ESC));


J'ai juste mis les partie les plus importante du programme.
Par contre si j'inverse la rotation et la translation (en cheangeant les variables sans rien faire d'autre) il y a des gros pb !
Et si je fait ce que tu dis c'est la caméra qui va tourner au lieu de se déplacer avec une caméra fixe, non ?

Et pour faire des rotations avec la caméra on fait comment ? Et puis dans le moteur 3D que tu as fait les translations sont faites avant les rotations ?

mais justement! c'est normal qu'il sorte de l'ecran! c'est pas le cube qui tourne, c'est toi qui regarde sur les cotes! forcement si tu regardes a gauche, le cube va sortir de l'ecran! mais essaye avec une map un peu plus complexe, et tu verras

>Et pour faire des rotations avec la caméra on fait comment ? Et puis dans le moteur 3D que tu as fait les translations sont faites avant les rotations ?

dans mon truc, les translations de la camera sont faites AVANT, puis apres, y peut y avoir encore d'autres translations...

Je comprend pas là:
Pour se déplacer ou modifie bien la caméra et non pas l'angle de rotation de l'objet sur lui même ?
La rotation du cube sur lui même c'est bien normal que je la fasse avant toute translation, non ?
Et puis pour tourner à gauche ou à droite il faut faire une rotation (c'est peut-être de ça que tu veux parler plutôt).
Dans ce cas là il faut que les touches modifie l'angle de rotation du cube par rapport à la caméra et non par rapport à son centre comme la roation que je fais actuellement.

Et en parlant de faire des maps plus grande tu fais comment pour avoir les coordonnées des vertices ? Tu te sers d'un éditeur ou pas ?

nan, je fais tout a la main

et a moins que tu veuilles faire des mondes avec des objets dynamiques directement integres a la map, tu ne dois pas raisonner comme ca au debut pour l'affichage d'un monde statique. Les coordonnees des points restent ce qu'elles sont, la seule chose que tu dois deplacer et faire tourner, c'est la camera...

c'est a dire en gros un seul point....

Pour deplacer et faire tourner la camera, tu dois deplacer et rotationner tous les points de ta map selon les transformations de ta camera.... si tu fais les translations apres les rotations, ta camera ne tournera pas sur elle meme, mais autour de l'origine! pour que ta camera tourne sur elle meme, comme quand tu regarde autour de toi, tu dois d'abord effectuer les translations, PUIS les rotations...