Page 4 sur 4

Publié : jeu. 02/août/2007 20:55
par Anonyme
j'utilise OpenGL & SDL en c++ , c'est des sprites fait maisons, les resultat sont très concluant pour le moment, dommage que je ne puisse faire cohabité les fonctions 2D de base de pb et celle de ma lib... :?
réinventé la roue c'est lourdingue...

Publié : jeu. 02/août/2007 23:39
par Ollivier
Si la Terre sur laquelle je suis debout était aussi légère et docile qu'un grand ballon, avancer d'un pas c'est la faire tourner sur l'axe des x, faire un pas en crabe, c'est la faire tourner sur l'axe des y, et tourner sur moi-même, c'est la faire tourner sur l'axe des z.

Je crois avoir une ébauche de calcul. En fait, c'est un arbre d'additions de vecteurs unitaires. A la racine, c'est très simple, mais plus je monte, plus il y a de trigo en pagaille.

Pour Google code search, je veux bien Cpl, mais rien que pour le code ci-dessus, la partie essentielle du calcul est une usine à gaz:

Code : Tout sélectionner

  matrice(0,0) = Cos(Za)*Cos(Ya) 
  matrice(1,0) = Sin(Za)*Cos(Ya) 
  matrice(2,0) = -Sin(Ya) 

  matrice(0,1) = Cos(Za)*Sin(Ya)*Sin(Xa) - Sin(Za)*Cos(Xa) 
  matrice(1,1) = Sin(Za)*Sin(Ya)*Sin(Xa) + Cos(Xa)*Cos(Za) 
  matrice(2,1) = Sin(Xa)*Cos(Ya) 

  matrice(0,2) = Cos(Za)*Sin(Ya)*Cos(Xa) + Sin(Za)*Sin(Xa) 
  matrice(1,2) = Sin(Za)*Sin(Ya)*Cos(Xa) - Cos(Za)*Sin(Xa) 
  matrice(2,2) = Cos(Xa)*Cos(Ya) 
Je veux absolument comprendre le mécanisme qui manque et ça, c'est du préfa que je ne digère vraiment pas! (Sans critiquer les auteurs qui, à mon avis ont un bulbe supplémentaire greffé derrière l'oreille)

Publié : ven. 03/août/2007 8:17
par tmyke
Si tu veux tout savoir sur les matrice et leur emploie
dans la 3D, je te conseil ce FAQ de référence en la
matière: http://jeux.developpez.com/faq/matquat/

Concernant plus particulièrement les calcul sur la matrice que tu
donnes ci dessus, il sagit de la génération des composant d'une
matrice en fonction des angles de rotations. Plutot que de tout
t'expliquer, dans le FAQ dont j'ai donné le lien , voici ce qu'il
en retourne pour la génération d'une matrice a partir d'angles:

http://jeux.developpez.com/faq/matquat/ ... ations#Q36
Ollivier a écrit :Je veux absolument comprendre le mécanisme qui manque et ça,
c'est du préfa que je ne digère vraiment pas! (Sans critiquer les auteurs qui,
à mon avis ont un bulbe supplémentaire greffé derrière l'oreille)
Alors tu n'as plus qu'a te taper tout le FAQ du developpez.com, en sachant que si tu veux faire un peu
de 3D, ces techniques sont un passage quasi-obligatoire. Cela n'a rien de très complexe en soit, il
faut par contre se taper un peu de math. Si tu veux faire des transformations
3D généraliste (donc qui peuvent s'appliquer à tout objet dans l'espace),
il faut en passer par la. ;)

Publié : ven. 03/août/2007 13:17
par Ollivier
Excuse-moi Tmyke. Je débarque un peu après des heures de réaction en chaîne dans le crâne. Il faut que je fasse une pause, question priorité de programmation, sinon il va y avoir un laissé pour compte à qui je dois un programme dans un autre domaine.

Mais je suis déterminé. Si ce passage est quasi-obligatoire, je le ferai. C'est évident. Nul n'a la science infuse, et moi le 1er. En fait, soit on a un très bon niveau dans un domaine appliqué (ici, les maths, la trigo) et l'on transcrit sa théorie en programmation. Soit on est comme moi, à jongler avec les rudiments niveau Bac, mais à maîtriser assez correctement la création d'algorithmes avec le peu qu'on a.

Une chose est sûre, je sais maintenant, et grâce au code plus haut (merci Cpl) que le calcul 3D possède plusieurs 'étage', et cela s'applique aussi en 2D. La découverte de la matrice plus haut m'a permis au moins de comprendre que je 'bricolais' sur la rotation en Z de mon ellipse (Code source plus bas, avec, cette fois-ci principe analogue à la matrice).

Une ellipse c'est élémentaire : c'est la raison pour laquelle je m'y obstine. Au moins, si je parviens à mes fins, je pourrais tout expliquer de A à Z.

Du point de vue du calcul, j'en suis au stade où j'ai un sommet pointé par un vecteur unitaire. Il subit:
1) une rotation sur l'axe Z 'esclave' de mon milieu d'écran
2) une rotation sur l'axe Y 'esclave' de la rotation Z
3) une rotation sur l'axe X 'esclave' de la rotation ZY
Il me manque le 4ème étage :
(4) une rotation sur l'axe 'Zeta*' 'esclave' de la rotation ZYX

*:Dans la rotation ZYXZeta, je pense que la rotation sur Zeta est en fait une rotation sur X alors que Y est temporairement décalé d'un quart de tour durant le calcul Zeta.

Et le tour sera joué. Comme dit Cpl, le code fourni plus haut, est un bon modèle pour créer cette 4ème rotation. Elle n'est pas si méchante en fait.

Elle demande juste de maîtriser parfaitement les rotations (1), (2) et (3) sous forme de procédure pour effectuer 'temporairement' un quart de tour sur l'axe Y, calculer la rotation Zeta, puis annuler ce quart de tour.

Code de l'ellipse : Rotation ZYX

Code : Tout sélectionner

  InitSprite()
  InitKeyboard()
  OpenScreen(1024, 768, 32, "x")
  ;***********
  R.F = 100.0
  Xtheta.F = 0.0
  Ytheta.F = 0.0
  Ztheta.F = 0.0      
  Ttheta.F = 0.0      
  ;***********
  Repeat
    StartDrawing(ScreenOutput() )
      Box(0, 0, 1024, 768, #Black)
      Vxx.F = Cos(Ztheta)
      Vxy.F = -Sin(Ztheta)
      Vyx.F = Cos(Ztheta + #PI / 2.0)
      Vyy.F = -Sin(Ztheta + #PI / 2.0)
      Line(512, 384, Vxx * 20.0, Vxy * 20.0, #Blue)
      Line(512, 384, Vyx * 20.0, Vyy * 20.0, #Blue)
      For i = 0 To 359
        ; MaJ référentiel Vecteur x et Vecteur y
        X.F = #PI * i / 180.0
        
        Tx.F = Cos(X) * Cos(Ytheta) * 100.0
        Ty.F = Sin(X) * 100.0
     
        Ex.F = Vxx * Tx + Vxy * Ty
        Ey.F = Vxy * Tx + Vyy * Ty
        ;Trace vecteur E
        Plot(512 + Ex, 384 + Ey, #Blue)
        If Abs(X - Xtheta) < 0.01
          Line(512, 384, Ex, Ey, #White)
          Box(511 + Ex, 383 + Ey, 3, 3, #White)
        EndIf
        
      Next    
    Xtmp = Xtheta * 180 / #PI
    Xtmp % 180
    DrawText(0, 0, Str(Xtmp), #White, #Black)
    Ytmp = Ytheta * 180 / #PI
    Ytmp % 180
    DrawText(0, 16, Str(Ytmp), #White, #Black)
    ZTmp = (Ztheta * 180 / #PI)
    Ztmp % 180
    DrawText(0, 32, Str(Ztmp), #White, #Black)
    DrawText(0, 48, "Utilisez les 4 flèches de direction et PageUp, PageDown pour modifier x, y, et z")
    StopDrawing()
    FlipBuffers()
    ExamineKeyboard()
    If KeyboardPushed(#PB_Key_PageUp)
      Ztheta + 0.04     
    EndIf
    If KeyboardPushed(#PB_Key_PageDown)
      Ztheta - 0.04
    EndIf
    If KeyboardPushed(#PB_Key_Up)
      Xtheta + 0.04
      If Xtheta > 2.0 * #PI
        Xtheta - 2.0 * #PI
      EndIf
    EndIf
    If KeyboardPushed(#PB_Key_Down)
      Xtheta - 0.04
      If Xtheta < 0.0
        Xtheta + 2.0 * #PI
      EndIf
    EndIf
    If KeyboardPushed(#PB_Key_Left)
      Ytheta + 0.04
    EndIf
    If KeyboardPushed(#PB_Key_Right)
      Ytheta - 0.04
    EndIf
  Until KeyboardPushed(#PB_Key_Escape)

Publié : ven. 03/août/2007 17:40
par tmyke
Ollivier a écrit :Excuse-moi Tmyke. Je débarque un peu après des heures de réaction en chaîne dans le crâne. Il faut que je fasse une pause, question priorité de programmation, sinon il va y avoir un laissé pour compte à qui je dois un programme dans un autre domaine.

Mais je suis déterminé. Si ce passage est quasi-obligatoire, je le ferai. C'est évident. Nul n'a la science infuse, et moi le 1er. En fait, soit on a un très bon niveau dans un domaine appliqué (ici, les maths, la trigo) et l'on transcrit sa théorie en programmation. Soit on est comme moi, à jongler avec les rudiments niveau Bac, mais à maîtriser assez correctement la création d'algorithmes avec le peu qu'on a.
Rassure toi, personne n'a la science infuse, et c'est y allant a taton,
en s'impregnant des moultes cours et tuto qu'il y a sur le net, et enfin en
s'appuyant sur l'experience de ceux qui connaissent bien le domaine
qu'on aprend et finalement, on y arrive ;)

Rien est insurmontable, surtout avec beaucoup de pédagogie et de patience...
:)