spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wenn ich das richtig sehe, beinhaltet doch die TriBase Engine aus dem Buch "3D-Spiele-Programmierung" alle benötigten Matrix- und Vektor-Routinen für die Rotation. Da Du ja vermutlich mit Z-Achsen Rotation hinkommst, ist die Rotation ohnehin recht einfach, in etwa: Zitat pVBuffer->x =cosf(fRotationZ)+sinf(fRotationZ); pVBuffer->y =cosf(fRotationZ)-sinf(fRotationZ); Natürlich ggf. vor und nach der Rotation um Offset des Objektmittelpunktes(Rotationszentrums) zum Ursprung des Kamera-Koordinatensys...

So kann man die Schwierigkeit auf den Punkt bringen: Es liegen aus der Eingabe des Anwenders nur die drei Rotationswinkel vor. Wenn ich daraus die drei Achsenvektoren berechnen kann, und zwar ohne das Problem, dass diese Achsen danach nicht mehr senkrecht zueinander stehen, habe ich gewonnen. Aller Dokumentation nach zu urteilen, die ich bisher dazu gefunden habe, ist genau das nicht möglich. Das dabei auftretende Problem des Verlusts der korrekten Ausrichtung der Rotationsachsen zueinander, und...

Zitat da würden die koordinatenachsen aber nacher nicht mehr wirklich normal aufeinander stehen Genau. Die Definition der Rotation über ein Quaternion kann das leisten, aber eben nicht die Beschreibung der Objektlage über drei Rotatinswinkel (Euler-Winkel). Siehe dazu die Links aus meinem vorigen Beitrag, sehr anschaulich auch der letzte davon. Alle beliebigen Lagen des Objekts im Raum sind also nur erreichbar, wenn die Reihenfolge der Rotationen um die drei Achsen variiert wird, was naturgemäß...

Hallo Nox, die erste Frage kann ich mit "nein" beantworten: Die Rotationswinkel für x, y, und z, die mein Renderer erhält, sind immer absolut, beziehen sich also auf das objekt in "Normallage", untransformiert. Dadurch erübrigt sich die zweite Frage ja eigentlich, es gibt in dem System keine vorangegangenen Schritte, sondern zu jedem Zeitpunkt nur eine absolute Angabe der Rotation des Objekts in Form von drei Rotationswinkeln (und neben der Rotation natürlich auch eine Position in Form eines 3D-...

@Nox: Relativ zum Objektkoordinatensystem (siehe Betreff). Der Grund ist: Es werden in einem Editor bestimmte Bewegungspfade von Objekten über einen Zeitverlauf vordefiniert. Man muss jederzeit den Zustand (die Lage der Objekte) für jeden beliebigen Zeitpunkt herstellen können, ohne vorher eine u.U. sehr lange Vorgeschichte durchzurechnen. Außerdem sind in dem System durch Rundungsfehler akkumulierte Abweichungen nicht tolerierbar. Der Zustand der Szene ist also über bestimmte, z.T. nicht kontin...

Es handelt sich zunächst um ein schlichtes Dreieck. Man kann das Problem natürlich auf einen Punkt reduziert betrachten, aber am Dreieck kann man das besser visuell veranschaulichen.

Das Problem liegt darin, dass so wie es nun läuft: - das Objekt bei Veränderungen des Winkels für Y (in meinem Beispiel m_vR3D_Rotation.y) um seine objektbezogene Y-Achse rotiert -> korrekt - das Objekt bei Veränderungen des Winkels für Z um seine objektbezogene Z-Achse rotiert -> korrekt - das Objekt bei Veränderungen des Winkels für X um die absolute oder kamerabezogene X-Achse (1, 0, 0) rotiert -> falsch Danke für den Hinweis auf D3DX. Es löst das Problem aber nicht. In meinem folgenden Versu...

Eine Frage an die Mathe-Spezialisten: In meiner Anwendung muss ich ein Objekt um alle drei Raumachsen rotieren. Kein Problem soweit, dank Scherfgen-Buch "3D-Spieleprogrammierung" ;-) Allerdings ist es aus bestimmten Gründen hier nicht möglich, die Rotation relativ zur vorherigen Lage des Objekts durchzuführen es muss also jeweils aus der Normallage der Achsen rotiert werden. Habe dazu bereits diverse Quellen zu Euler, Gimbal Lock, Quaternion etc. gelesen, jedoch scheint das für diese Anforderung...