[Résolu][cartographie / débutant] : Euler / Quaternion (C)

[Moove]

J'ai l'impression que ça ce passe lorsque je suis vers 0° sur l'axe des x, d'un coup j'ai l'inverse pour les coordonnées de z :

[GaBuZoMeu]

Je me demande vraiment ce que tu as bidouillé pour avoir une transformation qui renverse l'orientation. Si tu n'avais fait que multiplier des matrices de rotation, ce serait strictement impossible d'avoir cette image.

Correction : si, c'est possible ! Le problème est qu'on se rend difficilement compte si on voit le 42 par au-dessus ou au-dessous. Si on le regarde par en-dessous, on peut obtenir cette image sans qu'il y ait changement d'orientation. Voir plus bas en date du 17 juillet.

[Moove]

J'ai beau chercher depuis un bon moment je ne vois pas où je fais autre chose qu'une multiplication de matrice. Est ce que ce sont bien les coordonnées des points d'origines que l'on multiplient par la matrice de rotation mise à jour ?

Initialisation iso :

Code: Tout sélectionner

   ret->mx = ft_matrix_rx(0.959931);
   ret->my = 0;
   ret->mz = ft_matrix_rz(0.785398);
   ret->vo = ft_init_coord(ret);
   ret->v = ft_init_coord(ret);
   ret->ri = ft_multiply_matrix(ret->mx, ret->mz);
   ret->r = ft_alloc_matrix();

Multiplication pour rotation :

Code: Tout sélectionner

   if (keycode == 0)
      run->map->r = ft_multiply_matrix(run->map->ri, ft_matrix_rz(0.0872665));
   if (keycode == 1)
      run->map->r = ft_multiply_matrix(ft_matrix_rx(0.0872665), run->map->ri);
   if (keycode == 2)
      run->map->r = ft_multiply_matrix(run->map->ri, ft_matrix_rz(-0.0872665));
   if (keycode == 13)
      run->map->r = ft_multiply_matrix(ft_matrix_rx(-0.0872665), run->map->ri);
   if (keycode == 0 || keycode == 1 || keycode == 2 || keycode == 13)
      run->map->ri = run->map->r;

A chaque fois qu'il y a une action je recalcule la matrice de la manière suivante :

Code: Tout sélectionner

   ft_calculate_point(run->map, run->map->ri, run->map->vo);

Code: Tout sélectionner

double   **ft_multiply_matrix(double **m1, double **m2)
{
   double   **ret;
   int      i;
   int      j;
   int      k;

   ret = ft_alloc_matrix();
   if (!ret)
      exit (EXIT_FAILURE);
   i = -1;
   while (++i < 3)
   {
      j = -1;
      while (++j < 3)
      {
         k = -1;
         while (++k < 3)
            ret[i][j] += m1[i][k] * m2[k][j];
      }
   }
   return (ret);
}

Et je multiplie les coordonnées d'origines par cette nouvelle matrice :

Code: Tout sélectionner

void   ft_calculate_point(t_map *map, double **r, t_point **vo)
{
   int      i;
   int      j;

   j = 0;
   while (j < map->hgt)
   {
      i = 0;
      while (i < map->wdt)
      {
         map->v[j][i].x = vo[j][i].x * r[0][0] + vo[j][i].y * r[0][1] + vo[j][i].z * r[0][2];
         map->v[j][i].y = vo[j][i].x * r[1][0] + vo[j][i].y * r[1][1] + vo[j][i].z * r[1][2];
         map->v[j][i].z = vo[j][i].x * r[2][0] + vo[j][i].y * r[2][1] + vo[j][i].z * r[2][2]; // je sais pas si cette ligne sert à quelque chose...
         map->v[j][i].color = 0xff;
         i++;
      }
      j++;
   }
}

[GaBuZoMeu]

Je ne vois rien qui puisse expliquer le changement d'orientation.
Du point de vue mathématique, ça ne peut pas se produire tant que tu multiplies par des matrices de rotation, elles conservent toujours l'orientation.
Je ne connais pas suffisamment le C pour me plonger en détail dans le code.

[Moove]

Oui, je vais demander à d'autres élèves de l'école qui ont utilisés les matrices pour voir s'ils ont rencontré le même problème, il ce peut que ça vienne de l'interface graphique de l'école.

Je te remercie encore de l'aide apporté ! J'ai donc réussi à faire la rotation sur l'axe des y à partir de ce que tu m'as appris pour l'axe des x et des z.

Je marque le sujet comme résolu et peut être à bientôt.
Moove.

[GaBuZoMeu]

Voila avec python et matplotlib avec lesquels je suis plus familier.
Je pars d'une vue où on regarde parallèlement au terrain (rx=-90°) et j'élève progressivement le point de vue par pas de 15° pour arriver à la verticale (rx=0°). Bien sûr dans ce dernier cas la grille ne laisse plus deviner le relief.

Code: Tout sélectionner

R=Rx(-90)@Rz(-45)
for t in range(7) :
    proj(R,T42)
    R=Rx(15)@R

[GaBuZoMeu]

Et finalement, ta figure où l'orientation a l'air d'être inversée s'explique ! En fait, l'orientation n'est pas inversée mais ... on regarde le 42 par en-dessous. J'arrive à produire la même figure (à peu près ) en partant d'un point de vue vertical au-dessus pour arriver à un point de vue vertical au-dessous.







On a du mal à accomoder la vision pour réaliser que dans la 4e figure on voit le 42 par en-dessous alors qu'on le voit par au-dessus dans la 2e.
Finalement, il n'y a pas de problème - juste à savoir de quel point de vue on regarde le 42.

[GaBuZoMeu]

Avec un peu de perspective et en prenant du recul, on réalise nettement mieux le "dessus-dessous" :




PS. On peut assez facilement modifier ton code pour y ajouter de la perspective (projection conique). On utilise pour cela la coordonnée z que tu calcules (celle au sujet de laquelle tu dis "je sais pas si cette ligne sert à quelque chose..."). On remplace les x et y que tu as calculés par x*p/(p-z) et y*p/p-z) où p est un nombre qui donne la distance du point de vue à l'origine (plus p est grand, plus la projection conique ressemble à une projection parallèle). Dans mon cas, les côtés de la grille valent 1 et j'ai pris p=30.
On affiche ensuite avec les nouveaux x et y. Il n'y a besoin de changer rien d'autre.

[Moove]

Merci beaucoup pour ton retour, j'ai effectivement remarqué l'illusion d'optique qui inverse le sens de 42, cependant il y a des cas de figure ou il est indéniable qu'il y a un changement d'orientation. On le remarque surtout sur des maps plus grandes :



Pour la projection conique, j'ai essayé ta formule directement sur les points x et y mais je pense que je ne comprends pas ou que je l'applique mal... Voila le résultat :


Je ne prend pas en compte les côtés de la grille car je ne vois pas trop comment les représenter...

Code: Tout sélectionner

void   ft_change_coord(t_running *run)
{
   int   i;
   int   j;
   int   p;

   p = 30;
   j = 0;
   while (j < run->map->hgt)
   {
      i = 0;
      while (i < run->map->wdt)
      {
         run->map->vo[j][i].x *= p / (p - run->map->vo[j][i].z);
         run->map->vo[j][i].y *= p / (p - run->map->vo[j][i].z);
         i++;
      }
      j++;
   }
}

[GaBuZoMeu]

Ben oui, si tu fais le changement sur tes vo[j][i] et pas sur les v[j][i], ce n'est pas bon ! Il faut faire cette opération après multiplication par la matrice de rotation associée au nouveau point de vue, pas avant.

Ce que je te demandais, c'est la dimension du côté d'un carreau de la grille. Là, il semble que la valeur p=30 ne convienne pas par rapport à cette dimension. Change la valeur de p pour voir ce qui convient. Essaie p=100, 200 ...

[Moove]

C'est rectifié, ça marche pas trop sur les grosse map, mais ça donne :

[GaBuZoMeu]

ça marche pas trop sur les grosse map

Je ne comprends pas ce que ça veut dire.
Ça ne marche pas pour ton 42 ???

[Moove]

J'ai réussie à régler le problème en adaptant p à la taille de la map.

Code: Tout sélectionner

   if (map->wdt > map->hgt)
      p = map->space * (30 + map->wdt);
   else
      p = map->space * (30 + map->hgt);

Cependant, je doit limiter la capacité du zoom en projection isométrique car mon problème à la base c'est que j'avais ce genre d'image (c'est un échantillon). Une ligne de code bien placée pouvant je pense régler le problème, il doit s'agir de points qui dépassent l'image mais qui se relient quand même entre eux... :


À part ça, il ne reste que le problème d'inversion, mais d'après mes camarades d'études, le projet vaut largement la note maximale. On doit démontrer qu'on est capable d'exécuter une rotation, au pire des cas si je tombe sur un correcteur fermé d'esprit je perds le point bonus.

Un petit exemple d'une projection iso sur une grande map avec dégradé de couleur (désolé, je ne sais pas comment réduire la taille de l'image pour avoir une meilleure qualité) :

[GaBuZoMeu]

C'est vrai que ça fait un peu fouillis.
Mais est-ce que ce n'est pas aussi fouillis sans la perspective ? A priori, ça ne peut pas empuirer les choses.

[Moove]

Aucun problème sans la perspective, pourtant les pixels sont ajoutés par la même fonction. Je peux zoomer l'image comme je veux sans la perspective. (Je me suis gouré dans le message précédent je voulais dire perspective).

[GaBuZoMeu]

Si je comprends bien, tu n'as pas vraiment le contrôle sur ce que fait l'interface graphique.
Avec ce que j'utilise dans python (matplotlib), je contrôle exactement ce qui est affiché et les coordonnées x,y de l'image que je calcule se retrouvent comme je le veux ....

[Moove]

Oui, c'est bien ça, la minilibX qu'on utilise est très limitée et c'est à nous d'apporter des modifications supplémentaires pour l'améliorer. Mais une simple limite permettant de contourner le problème est considérée comme suffisante alors j'opte pour cette option. Je ferais un retour sur la note, en tout cas merci encore pour toute cette aide je n'en attendant pas tant !

[Moove]

Et voilà le résultat ! Je suis vraiment content. Merci.