Ich habe mich einige Zeit der nachweislich falschen Vorstellung hingegeben, meine Camera würde sich korrekt bei der Bewebung durch den Raum verhalten. Nachdem mir nun aber immer öfter aufgefallen ist, dass es Stellen gibt, an denen sie sich vollkommen absurd verhält, bin ich derzeit dabei, dieser Frage nachzugehen.

Ich benutze zur Justierung meiner Camera gluLookAt.

Ich habe also die Vectoren eye,center und up.

Generell können diese Vektoren über verschiedene Bewegungsmodi von außen verändert werden (zb. durch Pfade, sie können konzentrische Kreise ablaufen usw) oder sie werden direkt durch Key und Mouseevents beeinflusst. Die automatische Veränderung über Bewegungsmodi funktioniert fehlerlos. Lediglich die manuelle Modifikation über die Events, also das benutzerdefinierte Navigieren durch die Szene per Pfeiltasten und Maus, weist einige Schwierigkeiten auf:



Soweit ich das nun mehrfach theoretisch durchgegangen bin, sollten diese Berechnungen für die Pfeiltasten stimmen. ArrowUp bewegt die Camera etwas auf den Blickpunkt zu. Damit sie nicht irgendwann am Blickpunkt ankommt, wird der Blickpunkt um den gleichen Weg weiter bewegt. Analog zu ArrowDown. Left und Right bewegen die Camera und den Blickpunkt auf einer Normalen zur Blickrichtung seitlich.




Hier offenbahrt sich das Problem, das sich mir nicht erschließen will. Die Drehung entlang der Y Achse, also nach links und rechts, funktioniert fehlerfrei.
Die Drehung nach oben und unten , also entlang einer Achse, die auf einer Ebene liegen muss, die Paralelle zur x-z-Ebene liegt, funktioniert einfach nicht.

Der Gedanke, der hinter der angegebenen Rechnung steht, ist der folgende:
Direction ist der Vector zwischen Eye(Camera) und Center(Blickpunkt).
Direction soll nun nach oben oder unten rotiert werden. Dazu benötige ich einen Vector, um den Rotiert wird. Dieser Vektor, ist das Kreuzprodukt aus dem Up-vector und direction, da er auf beiden Senkrecht stehen muss.

Soviel die Theorie. Wenn ich die zweite Drehung ausklammere, funktioniert die Camera (, sie dreht sich - oh Wunder - nur eben nicht nach oben und unten), wenn sie mit einbeziehe, setzen sich plötzlich alle Werte auf NAN.

Ich habe mir bereits mal das Kreuzprodukt ausgeben lassen, um zu sehen, ob es null wird. Es wird nicht null, ist also definiert. Daher verstehe ich partout den Fehler nicht....

Weiß jemand Rat?

Ich möchte Dir die folgenden beiden Tutorials im DGL Wiki ans Herz legen, denn da drinnen ist m.E. genau Dein Problem behandelt:

1.Tutorial "Objekt gedreht und dennoch nach vorne bewegt"
2.Tutorial "Objekt immer um eigene Achse drehen"

Sie stehen ein bissel weiter unten, in der Mathesektion.
Viele Grüße
Traude

du brauchst für deine Cam eine vollständige Orientierung, also ein Koordinatenkreuz bestehend aus right, up, front und position vektor. Diese werden bei merstellen einer Camera auf identität geladen also front = (0,0,-1), up = (0,1,0), right(1,0,0), pos = (0,0,0). Das kann man perfekt in eine matrix packen von der größe 4x4. Wenn du jetzt eine seitliche Bewegung durchführen möchtest, also in gamer-sprech ein sidestep/strafe, brauchst du bloß den right-vektor mit der geschwindigkeit mulipliziert auf den positionsvektor addieren. für die front bewegung ist das selbe von nöten.
möchtest du jetzt allerdings eine rotation um die y-Achse machen (meist ist die World-Y-Achse gefragt), dann drehst du den right und den front vekor um (0,1,0) via quaternion rotation. Das hört sich zunächst schwer an, ABER hier im wiki findest du einen kompleten funktions-satz zu quaternions, die man 1:1 übernehmen kann und die rotation kann ich dir hier auch ohne Probleme erklären, falls du das noch brauchst.
Wenn du die rotation um die World-Y-Achse performt hast, dann kannst du anschließend Front- und Up-Vektor um besagten Winkel um den Right-Vektor drehen. das resultat ist eine Camera, die sich wie eine FirstPersonCam verhält.
Die Funktionen um die Bewegungen über die tastatur zu steuern gehört mines erachtens nicht in die Cam sondern in einen gesonderten Interface-Buffer, der alle tastatureingaben bfängt und anschließend an die Cam weiterleitet wenn der Anwendungszustand gerade eine Camerabewegung verlangt. Wenn du einen Mouselook einbauen willst kann ich dir auch gerne erklären wie das geht, denn bei mir hat sich schnell das Problem eingestellt, dass die optik dann ins ruckeln und stocken gerät. Das einzige Problem, das ich bisher noch nicht gelöst habe ist, die Camera auf einen Punkt auszurichten, der kein eigenes Koordinatenkreuz besitzt.
Nachdem alle Camera-transformationen ausgeführt sind (bewegen,links/rechts-schwenk,hoch/runter-schwenk) solltest du die darauß entstandende Matrix direkt als ModelviewMatrix zu begin des Renderns laden um nicht alle transformationen dopplt machen zu müssen ( glMatrixMode(GL_MODELVIEW); glLoadMatrix(myCamMatrix); ). danach kannste fröhlich laufen/fliegen in deinen 3d szenen.

Bei weiteren Fragen, einfach los fragen, für die meisten Dinge hab ich beim Thema Cam Antworten.

_________________
Klar Soweit?

Da hast Du oben aber schon schwerere Probleme gelöst. Die Kamera auf einen Punkt ausrichten macht gluLookat (Quelle: Source Code Mesa 7.2):

Also ich habe mich jetz mal ne weile mit den Tuts beschäftigt und auhc ein bisschen rumprobiert aber eigentlich versteh ich nich, wieso das ganze nicht auch einfach weiterhin mit meinen 3 Vectoren und gluLookAt gehen soll.
Wenn ich meiner Camera eine Position und einen Blickpunkt gebe und ihr sage wo oben ist, ist das realtive Koordinatensystem doch eindeutig definiert. Nur die Berechnung des Blickpunktes its bei mir momentan an einer stelle noch fehlerhaft.

Mag sein, dass es so auch so geht mit ein wenig hin und her rechnen, allerdings werden alle deine Camera translationen/rotationen in die ModelViewMatrix eingerechnet, also warum solltest du nicht direkt diese berechnen, wenn dieser Weg performanter ist und nicht unbedingt mehr code braucht? Anstatt bei jedem Render die Modelviewmatrix mit ihrer Identität zu laden und anschließend alle Transformationen zu berechnen und durchzuführen kannst du auf diese weiße einfach alle Camera-Veränderungen direkt in die ModelVieMatrix übertragen und sparst dir so Berechnungen und hast einen etwas saubereren Code. Desweiteren kannst du mit der Kenntnis über alle Achsen deiner Camera-Orientierung verschiedenste Bewegungsmöglichkeiten wie z.B. das Strafen, oder Kamerafahrten auf Splines/bezier-curves schneller implementieren, als wenn du ständig aus deinem Up-Vektor und dem Blickpunkt in jedem Frame die nötigen Vektoren dafür errechnen musst. Ebenso lohnt es sich die Matrix für Billboarding zu kennen, da du dafür nur die Cameratransformationen invertieren musst und sie auf ein Quadrat anwendest.

Glaube mir es lohnt sich diesen kleinen Aufwand einmal zu machen. Der einzige unterschied zu deinen aktuellen Daten ist, dass der "Blickpunkt" normiert wird und Front-Vektor heißt und, dass ein Right-Vektor dazu kommt. Das wichtigste Argument ist aber, dass mein Weg funktioniert und deiner nicht. <= ist nicht so böse gemeint wie es sich liest

PS: wenn es dir momentan noch einfacher ist die Tastatureingaben direkt in der Camera-klasse abzuarbeiten, tu das. Bis zu einer gewissen Projektgröße spielt das keine wichtige Rolle, aber irgendwann wirst du das trennen müssen um in verschiedensten Situationen auf zum Beispiel doppelt belegte Tasten reagieren zu können deren Funktion sich nur anhand des aktuellen Programmzustandes unterscheidet. Wenn du möchtest kann ich dir auch gerne meine Camera einmal als Code hier reinstellen damit du mal schauen kannst wie ich das gemacht habe, denn viel Code ist es im Endeffekt nicht geworden.

_________________
Klar Soweit?

Also die Bewegung der Camera auf Pfaden hab ich schon implementiert und das Billboarding auch. Alles in allem verstehe ich aber die Vorteile der geringeren Rechenlast. Wenn ich das richtig verstanden habe, würde auf diese Weise jede Camera eine Matrix besitzen, die Position und Ausrichtung angibt und durch das LAden dieser Matrix ist im Grunde schon alles abgeschlossen. Dadurch würde gluLookAt dan unter den Tisch fallen oder?

Also es wär mir schon hilfreich, wenn ich mal etwas abschauen könnt^^ Ich hab bisher die Funktionen aus der Geometry erstmal nachgebaut und anfangen, das ganze in meinem Code zu implementieren.

Danke dir schonmal

Naja, aber prinzipiell sollte sein Weg doch funktionieren. Aber klarerweise ist Dein Ansatz natürlich besser, weil man damit mehr Möglichkeiten hat.

@Shaddow: Ich würde Dir ja helfen, aber ich kann Deinen Code nicht lesen. Quintessenz ist, Du hast 2 Vektoren und willst um einen dritten rotieren. Dagegen ist ja eigentlich nichts einzuwenden.

Tatsache ist dass mich Dein Betrag dazu angeregt hat, eine Kamera zu implementieren, die nach Sellmanns Prinzip funktioniert. Aber NATÜRLICH gehe ich nach denselben Prinzipien vor wie Du: ich muss auch zwei Vektoren um einen Dritten rotieren - und Sellmann muss das ganz genauso machen, denn es gibt keinen Weg drum herum. Daher wäre es vielleicht möglich, dass Du auf Deinen Fehler draufkommst, wenn ich Dir ein Codeschnipsel zeige (sorry, ich habe nicht alle Typdefinitionen hier drin, damit der DemoCode nicht zu lang wird):



Mit dieser Funktion kann ich sowohl Objekte rotieren als auch die Kamera (diese ist ein "InversSystem"). "DefaultRight" und "DefaultUp" sind die Default-Achsen des jeweiligen Systems, bei einer Kamera also der X-PlusVector und der Y-PlusVector, der "DefaultForward" wäre der Z-MinusVector. Und das Ganze ist ein 4 DOF-System (man kann sich frei um 2 Achsen bewegen).


Es ist bei einem solchen Vorgang SEHR wichtig, dass:
1. bei Matrizenmultiplikationen die Reihenfolge der Matrizen richtig ist und
2. beim Kreuzprodukt die Reihenfolge der Input-Vektoren richtig ist


@Flash: Es ist ein neuer Wiki-Artikel fällig: "Wie man eine 6 DOF Kamera implementiert". Das wäre eine nette Erweiterung für den Engine-Pfad. Na, findet sich einer, der so etwas schreibt? Ich kann das bestimmt nicht. Mach sicher lauter Fehler rein.

was heißt den 6DOF? dof kenn ich nur als depth-of-field, macht aber in dem Zusammenhang für mich keinen Sinn...

Edit: Gut das man per Google direk in Phobeus's Gehirn nachblättern kann: 6dof = six degrees of freedom

Ich lese mir mal durch, was damit genau gemeint ist und schau mal an wie das geht und ob ich das kann.

_________________
Klar Soweit?

6DOF = 6 degrees of freedom, also 6 Freiheitsgrade. Man hat drei Achsen und kann sich bei jeder Achse sowohl links rum als auch rechtsrum bewegen, ergibt 6 mögliche Rotationen. (Um die Bewegungsrichtung zu ändern kannst Du entweder einen negativen Winkel eingeben oder die Drehachse invertieren)

WICHTIG: wir manchen das hier NICHT mit Euler-Winkeln, denn sonst wäre die Kamera nicht stabil.

in wiefern nicht mit eulerwinkeln? Das die daten nicht als winkel gespeichert werden sollen, oder das die rotation nicht anhand von winkeln durchgeführt werden darf? Oder unterscheidest du da einfahc nur Grad und Radiant? Weil meine Rotation ist bisher in Radiant um eine Achse aus der Camera-Orientierung und klappt soweit echt gut. Ich mache das einfach mal so, dass ich eine anwendung hochlade und ihr sagt mir dann, ob es das ist was ihr meint.

_________________
Klar Soweit?

Das ist so gemeint: Es sollte die Kamera-Orientierung nicht mit Winkeln abgespeichert werden, sondern mit Vektoren, genauer: zwei der drei lokalen Koordinatenachsen der Kamera.

Zu Beginn sind die Kamera-Achsen mit den Welt-Achsen identisch. Der Benutzer gibt an, welche Transformation er ausführen will, zum Beispiel eine Drehung nach rechts, das heißt: Drehachse ist die Y-Achse der Kamera, derzeit auch die Y-Welt-Achse, als Winkeländerung legen wir z.B. "1" fest. Soll heißen, bei jedem Tastendruck wird der Winkel um "1" geändert.

Wir haben z.B. auch festgelegt, dass immer der UpVector und der Forward-Vector gespeichert sind. Fehlt uns nocht der Right-Vector, den kriegen wir über das Kreuzprodukt.

Die beiden Kamera-Achsen, um die jetzt nicht gedreht wird - also der Forward-und der Right-Vektor - werden beide um ein Grad um den Up-Vektor gedreht. Da kann m.E. überhaupt nichts passieren. Der neue UpVector ergibt sich wieder als Kreuzprodukt der beiden anderen.

Weil die Kamera-Achsen aber jetzt beliebige Achsen sind, kann man keine Euler-Winkel mehr nehmen, sondern Rotationsmatrizen, die aus einer Winkel/Achse Angabe errechnet werden können oder eben aus Quaternionen.

Die Rotationsmatrix der Kamera ergibt sich aus den drei neu berechneten lokalen Kamera-Rotationsachsen.

Ich mach das bei mir mit Quaternionen, weil mir Rotationsmatrizen irgendwie suspekt sind, Aber an sich funktioniert es bei mir genau so, wie du es beschrieben hast, mit Ausnahme, dass ich eben auch den rightvektor immer mit speicher. Allerdings baue ich gerade zwei Rotations-Modi. Einmal den Modus der um die bekannten Achsen der Kamera dreht und einmal den Modus, der immer um (0,1,0) dreht, egal wie der top, vektor steht. Die Rotation um die eigenen Achsen ist ne simple Spielerei, bei der Drehung um die (0,1,0) ist es aber schon was ganz anderes, denn die Rotation wird gespiegelt, sobald die Camera einen überschlag macht. Falls du eine Idee haben solltes, wie man feststellt, ob die Kamera überkopf steht, sofort her damit. Dann muss nur noch das look_at rein und sie ist reibungslos fertig.

Edit: Problem gelöst:

_________________
Klar Soweit?

Hmm, was meinst Du mit "einen Überschlag macht"? Wenn ich um (0/1/0) drehe, ist das Ergebnis immer definiert. Ich drehe so, wie OpenGL dreht: ich gebe einen Winkel und eine Achse an und erzeuge eine Rotationsmatrix draus.

EDIT: die Kamera-Achsen sollten immer ein orthogonales System bilden, also alle einen rechten Winkel zueinander haben.

EDIT2: Du könntest Dich bei der Lösung oben irren: Du berechnst die Spitze des Y-Vektors, oder? Was ist, wenn die Kamera im positiven Y-Bereich überkopf steht? Da müsste man die Differenz Kamera-Position zur Spitze des Y-Vektors ansehen, das könnte gehen.

Aber wozu brauchst Du diesen zweiten Modus?

Also ich verfolge die Diskussion interessiert, stehe aber schon seit einigen Posts ziemlich im Wald..

Irgendwie fehlt mir grad ziemlich der Einstieg das ganze irgendiwe umzusetzen. Mit meinen Vektoren erschien mir das alles so nachvollziehbar und logisch, Matrizen geht grad noch so, aber spätestens bei Quaternation hörts bei mir ziemlich auf und ich kann euch inzwischen nichtmehr folgen^^