4. OpenGL: Kamera bewegen

OpenGL: Kamera bewegen

  • K

    ???
    Ich hab jetzt mal ein inverse() hinzugefuegt, und in der Anfangsposition verhaelt sich die Kamera auch richtig. Aber sobald ich in eine Richtung rotiere, habe ich wieder den Effekt, dass die Rotationsachsen mit den Tasten vertauscht sind...

    0

  • Eine Rotationsmatrix wie du sie gebaut hast, transformiert aus lokalen Koordinaten in das Koordinatensystem in dem sich die Achsen befinden, in deinem Fall also Weltkoordinaten. Eine Kameramatrix sollte dagegen von Weltkoordinaten in Kamerakoordinaten (Kamera im Ursprung und blickt z.B. entlang der z-Achse) transformieren, was also genau der umgekehrten Transformation deiner Rotationsmatrix entspricht. Genau das meinte pVoid wohl auch in der ersten Antwort hier, von wegen dass man "in OpenGL nicht die Kamera bewegt, sondern den Raum": Eine Bewegung der Kamera ist äquivalent der inversen Bewegung der Welt; du kannst entweder deinen Kopf um 30° nach links drehen oder die ganze Welt um dich herum um 30° nach rechts drehen und wirst in beiden Fällen das selbe Ergebnis erhalten. Wir wollen am Ende ein Bild am Bildschirm ausgeben und dafür brauchen wir Koordinaten relativ zum Bildschirm, was bedeutet, dass wir die Welt um den Bildschirm herum bewegen müssen, da wir den Bildschirm selbst ja nicht bewegen können...

    0
  • K

    Okay, danke fuer die Erklaerung. Offenbar ist es jetzt doch noch 'falscher'. Schon 'langsam' verlier ich auch die Lust an diesem ganzen OpenGL Kram. Ich sitze hier seit Tagen an diesem bekloppten Ding und habe
    - Ein paar Wuerfel, zufaellig generiert
    - Eine nicht funktionierende Kamera
    Ist es zu viel verlangt, dass das Zeug *ein einziges Mal* funktioniert, so wie ich mir das vorstelle?

    0
  • ?

    ➡ http://nehe.gamedev.net/

    0
  • K

    Ich will keine Engine verwenden, ich will dass der Mist einfach funktioniert 😡

    0
  • S

    Kellerautomat schrieb:

    Wenn ich nun die Rotationstasten verwende, dreht sich nicht die Kamera, sondern der grosse Wuerfel. Ich weiss nicht, wieso mir das erst jetzt auffaellt, aber das liegt wohl daran, dass ich etwas verwirrt bin, was das ganze angeht.

    W - Welt,
    V - View.
    R - Rotation

    VW - wir sind Kamerasystem (lokal -> World -> View)

    VWR - rotiert objekt lokal (lokal -> drehen -> World -> View)

    VRW - rotiert Welt ( lokal -> Welt -> drehen -> View) - beachte das ist analog dazu die Kamera um den Weltursprung zu rotieren (Orbit).

    RVW - rotiert kamera! (lokal -> Welt -> View -> drehen) - rotiert kamera um den lokalen Kamera Ursprung.

    die Reihenfolge ist wichtig. Aber tatsächlich heisst das auch, dass du die Kamera wie jedes andere Objekt auch drehts, von links dran.

    0
  • ?

    Kellerautomat schrieb:

    Ich will keine Engine verwenden, ich will dass der Mist einfach funktioniert 😡

    Engine? I see no engine if I take a look in nehe´s tutorial section.

    💡 💡

    Texture Filters, Lighting & Keyboard Control
    http://nehe.gamedev.net/tutorial/texture_filters,_lighting_&_keyboard_control/15002/

    It´s legacy, I know but it should help you anyway.

    0
  • N

    Kellerautomat schrieb:

    Ich will keine Engine verwenden, ich will dass der Mist einfach funktioniert 😡

    Warum eigentlich nicht? Mit sowas wie Irrlicht müsstest du dich nicht dauernd mit Low-Level-Angelegenheiten herumschlagen, vieles gäbe es schon fertig, und du bräuchtest massiv weniger Code.

    Indem du rohes OpenGL benutzt, nimmst du entsprechende Mühseligkeiten geradezu in Kauf 😉

    0
  • K

    Irrlicht ist ein haessliches Drecksstueck, die anderen Engines sind da auch nicht besser und wenn doch viel zu ueberladen.

    0
  • N

    Kellerautomat schrieb:

    Irrlicht ist ein haessliches Drecksstueck

    Ah, alles klar. Der Code, den du so schnell auf OpenGL schreibst, wird sicher auf Anhieb besser sein 😉

    Ich finde auch viele Design-Entscheidungen von Irrlicht fragwürdig. Zum Beispiel die inkonsistent verwendeten UN-Präfixe, manuelles Reference Counting oder übertrieben viele Operatoren für Vektorklassen. Trotzdem kann man damit arbeiten, und erreicht relativ schnell gute Resultate. Man muss halt irgendwo Kompromisse eingehen, leider ist sind die wenigsten C++-Bibliotheken so sauber wie SFML.

    Falls du mehr als nur 3D-Würfel zeichnen willst, solltest du dir vielleicht schon überlegen, ob sich eine Bibliothek nicht lohnt (muss ja nicht unbedingt Irrlicht sein). Alleine schon weil OpenGL nur ein minimaler Teil einer Anwendung ist -- dazu kommen neben Fenster-Erstellung, Input, Physik auch fortgeschrittene Grafikfeatures wie Szenegraphen, Licht und Schatten, oder Terrain. Um das alles selbst zu implementieren, hast du Jahre.

    Das gilt für Produktivcode. Wenn du dein Projekt aus Interesse an Low-Level-Techniken machst, ist das natürlich was anderes 🙂

    0
Anmelden zum Antworten