4. Umrechnung von YAW, PITCH und ROLL

Umrechnung von YAW, PITCH und ROLL

  • 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
  • S

    Bei meiner FPS-like Maussteuerung klappt es mit Yaw und Pitch in Winkeln speichern, und mehr nicht, anscheinend aber wunderbar. Warum?
    Ich mache dabei glaub ich als erstes ne Rotation um die y-Achse und dann um sie veränderte x-Achse. Das ganze dann noch umgekehrt (und immer negativ weil camera), wegen den OpenGL-Matrizen, und es funzt:

    (Pitch hab ich noch nicht probiert, is immer 0)

    void Camera::setMatrix() {
	glLoadIdentity();
	gluLookAt(0.0f, 0.0f, 0.0f, 0.0f, 0.0f, -1.0f, 0.0f, 1.0f, 0.0f);
	glRotatef(-direct_.x, 1.0f, 0.0f, 0.0f);					
	glRotatef(-direct_.y, 0.0f, 1.0f, 0.0f);			
	glRotatef(-direct_.z, 0.0f, 0.0f, 1.0f);
	glTranslatef(-pos_.x, -pos_.y, -pos_.z);		
}
    0
  • T

    spl@t schrieb:

    Bei meiner FPS-like Maussteuerung klappt es mit Yaw und Pitch in Winkeln speichern, und mehr nicht, anscheinend aber wunderbar. Warum?

    weils was ganz anderes ist? pack da mal noch ne rotation um z rein (um den kopf seitlich zu neigen) und in der reihenfolge wirds auseinanderfallen. du würdest bei einem shooter auch nie auf die idee kommen um die lokale y achse zu rotieren, weils extrem seltsam aussehen würde.

    0
  • H

    eigentlich müsste man doch das problem lösen können, wenn man gluLookAt verwendet. Dann müsste man nurnoch Yaw Pitch und Roll winkel in die "to"-coord umrechnen oder??

    EDIT: ich habe es geschafft!!!!!!!! OPEN GL GEHT!
    Edit2: ahh ne doch nich ... hat jemand ne ahnung was das 'Xlib: extension "XFree86-DRI" missing on display ":0.0".' heissen soll? Ich denk mal, dass der X server das OpenGL extention protocol nicht unterstützt oder?? was kann ich dann tun? XFree hab ich gradeben neu compiliert.

    0
  • D

    Hast Du denn keine GraKa-Treiber?

    0
  • H

    doch ich denk auch nicht dass das etwas damit zu tun hat.
    eher fehlt mir die X11-protocol-extention für OpenGL oder so (muss man da vielleciht noch ein compiler-flag anschalten?!?). Also früher gings bei mir. 😞

    0
  • D

    Hm, aber wenn Du nen GraKa-Trieber hast, brauchst Du doch keine mesa, oder? oder täusch ich mich da?

    0
  • H

    nee mesa ist doch nur ein OpenGL clone
    Mesa redet so-zu-sagen mit dem graka-treiber -> entweder direkt über /dev/dri (direct rendering interface) oder eben über X11 (oder beides weis nich so genau) - auf jeden fall kann mein X-Server die protocol erweiterung irgendwie nicht.

    0
  • T

    HellKnight schrieb:

    eigentlich müsste man doch das problem lösen können, wenn man gluLookAt verwendet. Dann müsste man nurnoch Yaw Pitch und Roll winkel in die "to"-coord umrechnen oder??

    ? wenn du die ganzen sachen weißt, die man für lookat braucht, dann ist die sache sowieso schon erledigt, denn lookat baut daraus GENAU die matrix, die du sowieso von anfang an benutzen solltest und invertiert sie noch schnell. was steht in so einer matrix schon drin? rechts/oben/vorne vektoren und eine position. was braucht man für lookat? einen über den "vorne" vektor berechneten punkt, die position und einen wenigstens grob korrekten oben vektor. lookat bügelt in dem fall nur ein paar überflüssige kreuzprodukte und wurzeln drüber.

    0
Anmelden zum Antworten