Hallo

Ich denke ich hab beim einarbeiten in die funktionen einen fehler gemacht.
Ich finde aber nicht heraus wo der ist.

Ich hab eine Funktion (draw_objekt). Dort werden werden Linien und eine Sphere im Raum verteilt.




Dann wird alles mit der Mausbewegung rotiert.




Hier zwei Bilder: Beide Bilder zeigen die Scene von oben. (eigentlich sollten daher beide bilder gleich aussehen)
Der rote Rahmen ist immer unten - der blaue oben.

Also wenn ich das ganze zwei drei mal gedreht hab dann passiert es zufällig das alles was ich habe an der y achse gespiegelt wird - und die im Raum liegenden Objekte werden an der [y,x]-Ebene im z-buffer andersherum Überlagert.

http://www.htwm.de/~vannacke/cpp/Bild1.png
http://www.htwm.de/~vannacke/cpp/Bild2.png

*verzweifel*

Grüße

Edit:

Wenn ich mir das recht anschaue und überlege ist der depth_buff immer invertiert zu dem was zu sehen ist.
Das was zu sehen ist wird während des drehens dann sporadisch an x,y Ebene gespiegelt.

Das Problem kommt mir irgendwie bekannt vor. Bei einer Anwendung die ich vor einigen Jahren programmiert hatte, kam dieser Fehler bei der Kamera auch vor.
Das hat wohl irgendwelche mathematische Gründe. Da es nur bei recht wilden Kamerafahrten auftrat konnte ich es ignorieren.

Singularitäten im Fluxspeicher der Hydrogonkammern, wenn du mich fragst.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

^^
Arigato für die Antwort.

Das Problem stört bei mir zu sehr. Das muss ich umschiffen.
Und ich denke immernoch ein wenig das ich etwas falsch gemacht habe.

Also ich hab in meinem Model bzw meiner Scene verschiedene Linien im Raum.
Ich glaube das passiert am häufigsten (oder sogar nur) wenn ich entlang der Z-Achse von + oder - z auf die Objekte schau.
Also genau in der Lage wie die Bilder gemacht sind. Von der Seite passiert das glaube nicht.

Weiterhin glaube ich das es je nachdem aus welcher Richtung ich schaue - also aus +Z oder -Z - sowohl das Depth-Buffering als auch die Position im Raum umschaltet. (das glaub ich nicht - das ist SO)

Ich find aber einfach nicht den Grund.

Grüße

Ich tippe mal auf einen Gimbal Lock. Dazu haben viel klügere Leute als ich bereits eine Menge geschrieben, das Web ist voll davon, google mal ein bisschen.

Ich könnte mir dabei auch ein simples numerisches Problem bei der Matrix vorstellen, wegen der endlichen Genauigkeit der Zahlen. Wenn man von +-z auf die Szene schaut, können eventuell durch vorherige Drehungen noch -sehr kleine- Anteile in anderen Richtungen vorhanden sein, mit denen dann irgendwie fehlerhaft gerechnet wird/ ein Vorzeichen flippt.

Gimbal Lock tritt prinzipiell erst ab 3 Drehungen auf, also könnte es maximal innerhalb jeweils 1.5 Schleifendurchläufe auftreten, wenn die Matrix nur an der Stelle modifiziert wird. Ich kann mir dabei aber nicht vorstellen, wie es durch diesen Effekt immer genau gespiegelt wird.

Also, wenn man dem englischen WIKI-Artikel http://en.wikipedia.org/wiki/Gimbal_lock folgt, kann ein Gimbal Lock bereits nach einer einzigen Euler-Rotation auftreten, denn schon bereits nach einer einzigen Rotation von 90 Grad um eine der Koordinatenachsen sind zwei Achsen praktisch deckungsgleich. Das sagt zum Beispiel auch http://books.google.at/books?id=0VOEjFmPB-0C&pg=PA358&lpg=PA358&dq=%22Gimbal+Lock%22&source=bl&ots=hYvne73cgT&sig=xiSdJhVCUh0DqgWau7KSI3VJaPs&hl=de&ei=lJT1SbvvH4Gw-Qa6qe3DDw&sa=X&oi=book_result&ct=result&resnum=4:



Ich kanns aber nicht mit absoluter Sicherheit behaupten, weil ich es selber noch nicht ausprobiert habe.

Naja aber im Code sieht man ja, um welche Achsen er dreht ( y und z -Achse).
Um ungewollt an der Y-Achse zu spiegeln, müsste er also erst ausversehen die z-Achse auf die y-Achse diese drehen, wozu man aber eine Rotation um die x-Achse braucht, und dann nochmal die z-Achse um 180°.
Oder irgendwo im Code ist noch was versteckt, was z.b. die Y-Achse einfach so zu weit dreht.
Ansonsten ist am Gimbal-Lock ja interessant, Drehung um 3 "irgendwelche" Achsen schon zu einem führen kann, auch um Achsen, bei denene das nicht wirklich offensichtlich ist.

Aber: Ob der Lock in OpenGL überhaupt eintreten kann, weiß ich jetzt auch nicht mehr sicher. Ich sehe dass so, dass die tatsächlichen Achsen immer senkrecht zueinander bleiben, egal wie man dreht und wendet. Also irgendwohin dreht man immer, und es werden keine Achsen "verschluckt". Das Problem ist ja in der Realität aufgetreten, wo z.B. bei Kreiseln in Flugzeugen/Raumschiffen mehrere der an sich beweglichen Achsen übereinander gefahren sind, und ab dann (ohne die Lösung: Hilfsmotor) zusammen bleiben.

Vermutlich hast Du recht und es ist gar kein Gimbal Lock.

Man kan in OpenGL ganz leicht einen Gimbal Lock erzeugen. Nimm irgendein Objekt (ein Würfel genügt) und probier es einfach mit dem normalen glRotate (bzw. mit mehreren glRotates) aus. Man sieht den Effekt ganz deutlich, denn das Objekt fängt an zu "eiern", so lange, bis es den prekären Bereich wieder verlassen hat. Ich wette Ihr habt so etwas alle schon einmal am Bildschirm gesehen, ohne zu wissen, dass es sich um einen Gimbal Lock handelt.

@antimon: Heute nachmittag hätte ich Zeit, um den Code auszuprobieren. Vielleicht krieg ich was raus.

Hm. Wahrscheinlich kommt das Eiern dann auch über numerisch ungünstige Zahlen in den Matrizen zustande, was dann den Gimbal Lock erzeugt. In Drehmatrixen stehn ja auch noch lauter lustige sin-cos-Kombinationen der Winkel drin, was ja gerade im Bereich 0 und 90°(*n) zu nur geringen Abweichungen von 0 oder 1 führt. Gepaart mir einer Multiplikation einer vielleicht vergleichsweise großen Drehachse... aber auf Anhieb sehe ich in dem Code direkt erstmal solche Probleme nicht.
Man ist sich meistes ja auch garnicht bewusst, das Computer garnicht sooooo exakt rechnen, wie man es gerne hätte, insbesondere, wenn man z.b. bewegungen auf recht kleine Intervalle zerstückelt.
Ich hatte letzen bei einer Messwertauslese von sehr kleinen Strömen auch schon "Probleme", mit diesen zwecks Skalierung/Darstellung in einem Diagramm zu hantieren. Da ist mir nichts übrig geblieben, als die Werte einfach um ein paar Zehnerpotenzen größer zu machen um was damit anfangen zu können (leider kann man vom verwendeten Messgerät aber auch nur doubles empfangen, und keine echten Exponential-Zahlen ala 5*10^(-6) oder so).

Hallihallo,
Ich habe Deinen Code - oder sagen wir mal: eine Interpretation Deines Codes - ausprobiert.

Versuchsanordnung:

1) Meine 3D-Welt ist nur ganz einfach, ein texturiertes Quad bei Z=0



2) Renderprozedur:



3) Eine "OnMouseMove" - Prozedur:



ERGEBNIS:
Das Quad benimmt sich ganz manierlich. Die mit "*)" gekennzeichneten Zeilen
sorgen dafür, dass der Winkel immer positiv bleibt. Vielleicht liegt es bei Dir an dem Umspringen der positiven/negativen Winkel?

So hallo - Bin wieder da =)

War unterwegs.
Ich hab auch nochmal bissl rumgebastelt. Und werd morgen nochmal schaun.

Ja ich hab negative winkel. Aber das umkippen passiert einfach irgendwo - und nicht an der grenze zum negativen.

Gimbal look ist nen guter Gedanke aber müste dann nicht eine Achse gesperrt sein und das ganze Eiern ?
Ich hab nach wie vor dann aber alle 3 Achsen zur Bewegung zur Verfügung.
Nur der Inhalt springt um.

Ich probier mal was.

Grüße

Es passiert auch innerhalb nur positiver und es passiert innerhalb der ersten Drehungen.

Und es reicht auch die Drehung um ausschließlich eine Achse.
Aber um z - Achse gehts nicht - schließlich klappt es nur um wenn ich von der anderen Seite "schaue".

Grüße

Mach doch mal folgendes:

Logge alle x,y und z rotationen in einem Graph. Und wenn das Schnappen passiert guckst du mal welche Werte da so anliegen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

@ traude

Warum machst du bei jedem render durchgang:


Damit wird ja alles wieder resettet o.O
Im übrigen hab ich Ortho unn nicht Perspektive.


Ok ich werd mal alle anzeigen. Hab bisher nur zwei angezeigt.
Dies benötigt ein paar zeilen mehr code ^^

grüße

Nein, wird es nicht. Es würde genügen, die Perspektivmatrix bloß ein einzigesmal zu setzen, ich habe das bloß der Deutlichkeit wegen dazugeschrieben. Hier wird nur die aktuelle Perspektivmatrix mit einer neuen Perspektivmatrix überschrieben, die genau die gleichen Werte hat wie die vorige Matrix. Dadurch ändert sich gar nichts.

Welchen Perspektivmodus Du nimmst - Ortho oder Zentralsperspektive - ändert für das Rotations-Ergebnis auch nichts.

Das einzige, was sich hier ändert, ist die Modelviewmatrix, die durch den Winkel verändert wird, den Du ins glRotate hineinschreibst. Diesen Winkel musst Du kontrollieren, um zu sehen, wann und warum das Umschnappen auftritt. Mittels Debugger oder Logfile oder was auch immer.

Du musst ja nicht Dein ganzes Programm hier reinstellen. es genügt doch, wenn Du dokumentierst was genau X und Y dieser Funktion sind bzw. wie sie berechnet werden:



Dann wärs möglich, dass ich Dein Problem nachvollziehen kann.