4. Umrechnung von YAW, PITCH und ROLL

Umrechnung von YAW, PITCH und ROLL

  • W

    Hi
    kann mir jemand sagen, wie ich YAW, PITCH und ROLL -werte in eine matrix umrechnen kann?
    Danke für alle antworten

    0
  • R

    Roll=Z
    Yaw=Y
    Pitch=X

    Was meinst du eigentlich? Wie man in einer Matrix Rotationen speichert?

    0
  • T

    while(1)fork(); schrieb:

    Hi
    kann mir jemand sagen, wie ich YAW, PITCH und ROLL -werte in eine matrix umrechnen kann?
    Danke für alle antworten

    das scheitert allein schon daran, daß du nicht erwähnst in welcher reihenfolge. und weil die eben nicht egal ist gibt es nur wenige möglichkeiten seine orientierung zu handhaben, die noch schlechter als obige 3 winkel sind.

    in diesem sinne:
    http://www.euclideanspace.com/maths/geometry/rotations/conversions/eulerToMatrix/
    http://mathworld.wolfram.com/EulerAngles.html

    0
  • W

    ich weis dass das nicht egal ist ob man
    glRotatef(10, 1,0,0);
    glRotatef(15, 0,1,0);
    oder ob man
    glRotatef(15, 0,1,0);
    glRotatef(10, 1,0,0);
    sagt - genau das ist ja der grund warum ich wissen will WIE ich ein Objekt drehe, damir es um 10° in X richtung und 15° in Y richtig gedreht ist, sodass die 2.achse nicht vom drehwinkel des 1. abhängt.
    PS: Danke für deine Links - ich werd sie mal durchlesen

    0
  • D

    Falls Du darauf hinaus willst, Objekte in Deiner Welt immer wieder relativ zu seinen Achsen zu drehen (z.B. FlugSim), dann nimm für jedes Objekt ne Matrix zur Angabe seiner Lage. Willst Du dann drehen (z.B. um x-Achse), kannst Du ganz einfach diese Matrix entsprechend ändern (Drehung um x-Achse).

    0
  • W

    genau darauf will ich hinaus. Klar für jedes Objekt eine eigene Matrix und jedes Objekt wird gezeichnet mit der gesamtMatrix*objektMatrix. Aber wie berechnet sich die Objekt-Matrix, wenn jedes Objekt (z.b. bei einem flugsim) Yaw Pitch und Roll hat? Also z.b. mein flugzeug ist um 3° nach oben geneigt, um 10° gedreht und um 90° "ge-rollt". Wie berechne ich dann die Objekt-Matrix dieses Obejktes??
    PS: die beschreibung auf http://www.euclideanspace.com/maths/geometry/rotations/conversions/eulerToMatrix/ von Trienco konnte ich leider noch nicht testen, da mein mesa im moment nicht kompiliert. ich werd mal ne anfrage in UNIX/LINUX stellen...

    0
  • D

    Die Objektmatrix kannst dann einfach mit glRotate ändern. also z.B. für x-Achse glRotatef(angle, 1.0, 0.0, 0.0). Das stimmt schon so, ist ja immer relativ zur Lage des Objektes.

    0
  • H

    Kann ich - aber ich will ja Yaw Pitch und Roll direkt angeben.
    Also ich kann ja nicht sagen:
    ...
    glRotatef(xrot, 1.0, 0.0, 0.0);
    glRotatef(yrot, 0.0, 1.0, 0.0);
    glRotatef(zrot, 0.0, 0.0, 1.0);
    ...
    wenn es sich mal z.b. um einen flugsim handelt. (probiers mal aus und vertausch dann des 2. glRotatef mit dem 1. und du wirst sehen, was sich ändert)

    0
  • D

    HellKnight schrieb:

    Kann ich - aber ich will ja Yaw Pitch und Roll direkt angeben.
    Also ich kann ja nicht sagen:
    ...
    glRotatef(xrot, 1.0, 0.0, 0.0);
    glRotatef(yrot, 0.0, 1.0, 0.0);
    glRotatef(zrot, 0.0, 0.0, 1.0);
    ...
    wenn es sich mal z.b. um einen flugsim handelt. (probiers mal aus und vertausch dann des 2. glRotatef mit dem 1. und du wirst sehen, was sich ändert)

    Doch genau so 🙂
    Hab ich auch ausprobiert, ich mach meinen FlugSim ja auch so.. Kann ja morgen mal Bsp-Code veröffentlichen, bin momentan unter Win drum geht das jetzt nicht..

    0
  • H

    ne eigentlich bin ich mir ziemlich sicher nicht (ich hab sogar mal, also bei mir mesa noch ging, ein ufo-game gemacht (eigentlich nur 2d aber 3d gerendert - das heisst, man kann sich einfach nur auf einer landschaft hin-und-her bewegen) bei dem ich die ufo-abstürz-animation mit dem trick animiert hab, das ufo ERST zu kippen und dann immer zu drehen. Andersrum hat es einen _ganz_ andern effekt gegeben (also erst drehen dann kippen). Ist ja auch klar, weil die glRotatef funktionen immer relativ zu den coordinaten-system-achsten rotaten und nicht zu den achsen des Objects (d.h. wenn du die matrix drehst dann wird der nächste aufruf von glRotatef davon beeinflusst - das ist genauso wie beim multiplizieren von matiten a*b nicht b*a ist)

    0
  • D

    HellKnight schrieb:

    ne eigentlich bin ich mir ziemlich sicher nicht (ich hab sogar mal, also bei mir mesa noch ging, ein ufo-game gemacht (eigentlich nur 2d aber 3d gerendert - das heisst, man kann sich einfach nur auf einer landschaft hin-und-her bewegen) bei dem ich die ufo-abstürz-animation mit dem trick animiert hab, das ufo ERST zu kippen und dann immer zu drehen. Andersrum hat es einen _ganz_ andern effekt gegeben (also erst drehen dann kippen). Ist ja auch klar, weil die glRotatef funktionen immer relativ zu den coordinaten-system-achsten rotaten und nicht zu den achsen des Objects (d.h. wenn du die matrix drehst dann wird der nächste aufruf von glRotatef davon beeinflusst - das ist genauso wie beim multiplizieren von matiten a*b nicht b*a ist)

    Ja eben, wir drehen aus diesem Grund nicht um die Weltkoordinaten, sondern erstellen für jedes Objekt eine Matrix die dessen Lage beschreibt. glRotate setzen wir auf diese Matrix an -> Die Drehung erfolgt um die Achsen des Objektes, und dann ist die Reihenfolge egal.

    0
  • T

    while(1)fork(); schrieb:

    Klar für jedes Objekt eine eigene Matrix und jedes Objekt wird gezeichnet mit der gesamtMatrix*objektMatrix. Aber wie berechnet sich die Objekt-Matrix, wenn jedes Objekt (z.b. bei einem flugsim) Yaw Pitch und Roll hat?

    der springende punkt ist, daß du yaw,pitch,roll komplett in die tonne trittst und NUR die matrix verwendest. du willst um die lokale x achse drehen? mit der entsprechenden rotmatrix multiplizieren. du willst warum auch immer um die globale achse rotieren? das gleiche, nur tauschen die matrizen die plätze (ie. "zeitlich" passiert die neue rotation dann als erstes, als die lokale und globale x-achse noch gleich waren).

    was passiert z.b., wenn du spielst und über die zeit folgendes machst:
    yaw, pitch, yaw, roll, pitch, yaw
    aber nur "gesamtrotationen" in drei winkeln speicherst? das ganz geht tierisch in die hose, weil die reihenfolge flöten geht, in der die rotationen gemacht wurden.
    falls du nur die drei rotationen für einen frame/ein update zusammenfassen willst: spars dir. bei allem was spielbare geschwindigkeit ist sind die einzelnen rotationen so klein, daß die reihenfolge tatsächlich keinen sichtbaren unterschied macht.

    in dem fall einfach z.b. den joystick hernehmen und
    flugzeugmatrix *= rotX(joy.y);
    flugzeugmatrix *= rotY(joy.z);
    flugzeugmatrix *= rotZ(joy.x);

    und ausgehend von ogl:
    glmultmatrix(flugzeugmatrix);
    //rendern
    //feddich

    für ganz faule:
    http://festini.device-zero.de/downloads/camera.zip

    setview und einige andere funktionen kann man sich natürlich sparen. außerdem würde ich bei vielen objekten nicht mehr ogl für matrix-rechnungen mißbrauchen, sondern eine eigene lib benutzen.

    warum? weil ansonsten die gesamte queue durchlaufen muß, bis man das ergebnis von der karte zurücklesen kann, die anwendung in der zwischenzeit stillsteht, ergo keine neuen befehle in die queue packt und entsprechend auch die karte danach erstmal arbeitslos ist und nichts sinnvolles macht. wenn du natürlich absolut sicher bist, daß zu dem zeitpunkt sowieso der letzte frame fertig ist und die karte nichts tut, dann sieht die sache anders aus. allerdings muß dir dann ein eingeweihter sagen, wie schnell/langsam das zurücklesen von der karte unter "idealen" bedingungen ausfällt. unter mesa sieht das ganze natürlich auch wieder anders aus, weil software.

    0
  • H

    aber ist es dann wirklich kein unterschied, ob ich
    flugzeugmatrix *= rotX(joy.y);
    flugzeugmatrix *= rotY(joy.z);
    flugzeugmatrix *= rotZ(joy.x);
    schreibe oder
    flugzeugmatrix *= rotY(joy.z);
    flugzeugmatrix *= rotX(joy.y);
    flugzeugmatrix *= rotZ(joy.x);
    ?? (ich muss unbedingt mesa wieder hinbekommen, ich kann hier ncihts testen 😞 )

    0
  • D

    Ne, wirklich nicht. Kommt ja aufs gleiche raus, ob Du erst um x oder um y drehst, solang Du relativ zu den Flieger-Achsen drehst.

    Warum laueft mesa nicht?

    0
  • T

    durito schrieb:

    Ne, wirklich nicht. Kommt ja aufs gleiche raus, ob Du erst um x oder um y drehst, solang Du relativ zu den Flieger-Achsen drehst.

    du ignorierst aber gerade fleißig, daß nach der rotation um x die y-achse eine andere ist und umgekehrt. das ergebnis ist also NICHT das gleiche. wenn die winkel aber sehr klein bleiben ist der unterschied so klein, daß er keine rolle mehr spielt.

    heb deine hand in die luft, dreh sie 45° um den mittelfinger und dann 45° senkrecht zum handrücken. und jetzt nochmal das gleiche umgekehrt.

    a) finger zeigen nach vorn, dann nach links oben
    b) finger zeigen nach links vorne, dann immer noch nach links vorne

    0
  • D

    Hm, Mist, tatsaechlich 🙂
    Dann spielt das bei nem FlugSim ja nur keine Rolle, weil die Veraenderung pro Frame sehr gering ist. Naja, Hauptsache es fliegt irgendwie.. 😉

    0
  • T

    durito schrieb:

    Dann spielt das bei nem FlugSim ja nur keine Rolle, weil die Veraenderung pro Frame sehr gering ist. Naja, Hauptsache es fliegt irgendwie.. 😉

    die ganz harten simulieren sowieso sämtliche klappen und luftströmungen statt nur billig das flugzeug zu drehen *fg* aber ich bleib dann doch lieber softie

    0
  • H

    @durito:
    deswegen kompilierts nicht: http://www.c-plusplus.net/forum/viewtopic.php?t=87749

    @Trienco:
    Genau das hab ich gemeint!! Wie kann man jetzt so eine matrix berechnen? Also z.b. bei einem flugsim, wo man das flugzeug um z.b. 10grad rollen und um 50° nach oben neugen und um 70grad drehen will?

    0
  • H

    ahh mir ist gerade eine idee dafür gekommen: kann man nicht einfach gluLookAt nehmen, und die erzeugte matrix als objektmatrix nehmen??

    0
  • D

    Trienco schrieb:

    durito schrieb:

    Dann spielt das bei nem FlugSim ja nur keine Rolle, weil die Veraenderung pro Frame sehr gering ist. Naja, Hauptsache es fliegt irgendwie.. 😉

    die ganz harten simulieren sowieso sämtliche klappen und luftströmungen statt nur billig das flugzeug zu drehen *fg* aber ich bleib dann doch lieber softie

    Jo, das mach ich auch so 🙂 Allerdings reichts für mich trotzdem nicht in den Club der ganz Harten, meine Flugphysik ist ne einzige grosse Katastrophe.. 🙂 Mein grösstes Problem ist, dass der Geschwindigkeitsvektor zu langsam an die Flugrichtung angepasst wird, mein Flugzeug "schleudert" also in den Kurven.. *g* Aber das bieg ich schon noch hin..

    @HellKnight: Machs mit dieser Obj-Matrix. Das geht wunderbar. Du hast pro Frame eh nur ganz geringe Richtungskorrekturen.

    0
Anmelden zum Antworten