Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »SeeBee« (10.03.2021, 02:43)
Zitat
Der RCCSWU (RandomCamelCaseSomtimesWithUndersquare) Stil bricht auch mal mit den veraltet strukturierten Denkmustern und erlaubt dem Entwickler seine Kreativität zu entfalten.
Du müsstest in deiner Kameramatrix/Berechnung einen Up-Vektor (0,1,0) haben. Diesen einfach mit der Blickrichtung (senkrecht zur Blickrichtung natürlich) mit drehen, anstatt konstant zu lassen.
Naja, beim Links/Rechts drehen darf man die Kamera dann halt nicht um die globale z-Achse drehen, sondern muss sie um die lokale z-Achse drehen. Aber mit der Accumulative Methode scheinst du ja schon irgendwie sowas ähnliches zu machen. Nur verstehe ich nicht, wieso das gegen unendlich geht? Wo findet denn da der Überlauf statt?
Naja, beim Links/Rechts drehen darf man die Kamera dann halt nicht um die globale z-Achse drehen, sondern muss sie um die lokale z-Achse drehen. Aber mit der Accumulative Methode scheinst du ja schon irgendwie sowas ähnliches zu machen. Nur verstehe ich nicht, wieso das gegen unendlich geht? Wo findet denn da der Überlauf statt?
Zitat
Der RCCSWU (RandomCamelCaseSomtimesWithUndersquare) Stil bricht auch mal mit den veraltet strukturierten Denkmustern und erlaubt dem Entwickler seine Kreativität zu entfalten.
Gimbal-Lock hast du bei Euler-Winkel, also wenn du immer um die selben globalen Achsen drehst.
"lokale Z-Achse" ist auch eher als eine Art Intuition zu verstehen, das ist nicht wirklich sauber definiert, und hängt immer ein wenig davon ab, wie man Dinge aufschreibt. Generell gibt es für fast alles in der 3D Grafik unterschiedliche Konventionen, das kann sehr verwirrend sein. Der einzige Ausweg ist es zu verstehen, was man tut, und es im eigenen Projekt immer konsistent zu halten. D.h. wenn man fremden Code sieht, wird man den oft noch an das Projekt anpassen müssen.
Soweit ich mich erinnere ist die Menge der Quaternionen (also EInheitsquaternionen die man zur Drehung verwendet) prinzipiell isomorph zur Gruppe der Drehmatrizen (vermutlich noch abzüglich der Tatsache, dass man jede Rotation durch genau zwei Quaternionen darstellen kann, usw.). Was das alles nur heißt ist: Absolut alles, was man mit Drehmatrizen tun kann, kann man genau so auch mit Quaternionen tun und umgekehrt. Quaternionen sind aber netter, da sie weniger Komponenten haben und daher weniger Speicher brauchen und vielleicht auch schneller anzuwenden sind. Zumindest ich benutze in der Praxis aber meist ganze Transformationsketten, und dafür braucht man eh Matrizen.
=> Vergiss Quaternionen einfach wieder, du wirst auf kein Problem stoßen, wofür du sie brauchst (höchstens auf welche, die man mit ihnen minimal eleganter lösen kann).
Zum Akkumulieren: Interessant, dass das bei dir numerisch so instabil ist. Macht aber nix. Du solltest einfach in jedem Schritt deine 3 Vektoren des Koordinatensystems orthonormalisieren. D.h. zuerst bringst du alle Vektoren auf die Länge 1, danach sorgst du dafür, dass alle senkrecht zueinander stehen (nimm etwa den X Vektor als Referenz und benutze 2 mal das Kreuzprodukt). Damit bist du alle numerischen Instabilitäten los, d.h. deine Werte werden niemals +-inf.
Werbeanzeige