spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »jjwayne«

Zitat von »LInsoDeTeh«

Naja, für mich sieht das eher so aus, als wäre das dem Code zuzuschreiben, denn du übergibst die Rotationen aller drei Achsen ja jedes Mal neu. Oder setzt du die m_rotation Variablen wieder auf 0 zurück? Ich denke, das += bricht dir hier das Genick.
Wenn du eine Rotation um die Y-Achse willst, versuch's doch z.B. mal mit D3DXMatrixRotationYawPitchRoll( &m_rotate, m_rotationY, 0, 0 );

Dass += habe ich, um immer 90° zur bestehenden Rotation hinzuzufügen. Also 1x rotieren = 90°, 2x rotieren = 180° usw.

Ich weiß, aber hier liegt meiner Meinung nach genau der Fehler.

Welchen Vorteil würde er aus Quaternions hier genau ziehen?

Zitat von »Bambi«

Besseres Hantierung mit Rotationen um beliebige Achsen.

Er wird viele Mauern brechen müssen wenn er im 3D Raum mit Matrizen arbeitet. Bei Starrkörperanimationen und Interpolation zum Beispiel wird es auch nicht leichter.

Rotationen sind das einzige, was du mit Quaternionen darstellen kannst. Für "Starrkörperanimationen" brauchst du in der Regel auch noch Translationen, die du mit Quaternionen nicht darstellen kannst. Entweder merkst du dir also zusätzlich noch Translationsvektoren und berücksichtigst die entsprechend, was imo jetzt auch nicht gerade toll ist, oder du packst Schraubentheorie und Dual Quaternions aus. Spätestens da wird es mathematisch sehr elegant und alles andere als trivial.

Abgesehen davon, kann ich auch mit Matritzen um beliebige Achsen rotieren.

Zitat von »Bambi«

Quaternionen wären denke ich auch schneller hier. Gerade wenn man sich mathematisch das Problem der Rotation des Einheitskreises anschaut sieht man Probleme mit Matrizen. Gimbal Lock wäre hier zu erwähnen.

Quaternionen haben in der Tat Vorteile was numerische Stabilität und Rechenaufwand betrifft. Allerdings musst du bedenken, dass du deine Quaternion am Ende wahrscheinlich wieder in eine Matrix umwandeln musst, sofern du nicht z.B. über einen Shader eine Möglichkeit hast, deine Objekte direkt mit einer Quaternion zu transformieren. Wenn du jetzt nicht gerade viele verkettete Rotationen hast oder sowas, zahlt sich das am Ende vermutlich nicht mehr aus. Und die Translation, die du im Allgemeinen wohl auch wirst haben wollen, mit Quaternionen allein aber nicht erreichen kannst, darfst du dabei auch nicht vergessen...

Was du mit "Rotation des Einheitskreises" meinst, ist mir nicht so ganz klar. Gimbal Lock ist jedenfalls kein Problem von Matritzen, sondern ein Problem von Eulerwinkeln. Solange du Eulerwinkel benutzt, wirst du Gimbal Lock haben, egal ob du nun mit Matritzen, Quaternionen oder sonstwas rechnest.

Ich will Quaternionen jetzt nicht schlecht reden. Sie sind doch ein sehr nützliches und elegantes Werkzeug. Aber ich denke nicht, dass es sinnvoll ist, einem Anfänger gleich mit Quaternionen zu kommen, wenn er offensichtlich noch wesentlich fundamentalere Probleme hat, noch dazu wenn sie diese Probleme nichtmal wirklich lösen würden...

Zitat von »Bambi«

Wollte ihm nur eine bessere Richtung andeuten sein Problem lösen zu können.

Nun, ich versteh aber nicht, wie genau man sein Problem mit Quaternionen besser lösen könnte. Wo siehst du da den Vorteil? Sein Problem war, dass sein Code nicht die von ihm gewünsche Rotationssequenz realisiert hat. Ob er die Rotationen nun mit Matritzen oder Quaternionen rechnet, ändert daran doch nichts!?