DirectX Drehung um einen Vector
-
Hi!
Gibt es eine andere Funktion als D3DXMatrixRotationX ..Y..Z um Drehmatrizen zu erstellen? Ich habe ein Problem und kriege es irgendwie nicht hin.
Und zwar:
Ich möchte ein Objekt drehen. Man Stellt sich as Objekt als Kopf (vom Menschen) vor. Der Kopf soll zuerst Stirnseitig gedreht werden können. (quasi kopf Nicken). Zusätzlich soll sich der Kopf auch um die Wirbelsäule drehen können.
Also zuerst wird um x gedreht. Dadurch entsteht eine neue Drehachse (von Y ausgehend). um diese Wird danach gedreht.y neu | \ | \ | \ | 0 -------------x / / / /zIch hoffe das ist so anschaulich.
-
Am einfachsten schau dir mal D3DXMatrixRotationAxis an
-
cl90 schrieb:
Gibt es eine andere Funktion als D3DXMatrixRotationX ..Y..Z um Drehmatrizen zu erstellen?
Ja. Aber ich glaube dein Problem ist eher mehrer Transformationsmatrizen zu einer zu verketten, auch da gibts natuerlich Funktionen. Informier dich mal ueber Matrizenrechnung im Allgemeinen, dann wird dir vielleicht klarer wann du was genau brauchst um dein Ziel zu erreichen.
-
Ich bin eben beim Überfliegen der Problematik auf einen Gedanken gekommen.
Einzelne Matrizen sind ja nunmal komplette Abbildungen, da gibt's halt eine Reihenfolge, wie man sie anwenden kann. Kann man die irgendwie mit einem einfachen mathematischen Mittel in ihre "Ableitungen" überführen, so dass Integral[Ableitung(A)*Vektor, 0, 1] = A*Vektor ist? Das müsste doch irgendwie möglich sein? Wie sieht es dann mit Verkettungen aus, kommt es dann überhaupt noch auf die Reihenfolge an? Und könnte man aus den abgeleiteten Matrizen dann irgendwie direkt die Kurve berechnen, die der Vektor vollzieht?
-
Deine Begriffe sind etwas ungenau definiert. Ableitung und Integral einer Konstanten, macht das Sinn? Kurve die ein Vektor vollzieht, was fuer eine "Kurve" denn?
Bei der Verkettung ist natuerlich die Reihenfolge sehr wichtig.
-
Die Frage hat sich mir jetzt aufgeklärt, wenn man für die Matrizen eben Ableitungen bildet wie für jede andere Funktion auch und dann die gängigen Regeln anwendet
Blöd, dass ich hier jetzt so rausgeschossen bin damit
-
Quaternionen, sollten das Problem lösen.
-
Wen ich das richtig versteh, dann reicht hier eigentlich schon eine Rotation um Y gefolgt von einer Rotation um x und fertig...
-
Stimmt, jetzt hab ichs auch erst geraft. Alle deine Drehungen finden im lokalen Kamerasystem statt, also wie Dot gesagt hat, erst x dann y (oder umgekehrt). Schwieriger wirds wenn die Z Orientierung, aufrecht lassen wie willst (so wie es der Mensch es gewohnt ist). Dann Drehst du Z (halb-)global und Y lokal, fertsch.
(lokal bedeutet multipliokation von links, global kann man so nicht sagen, hängt davon ab was zuvor geschehen ist).
-
Ob von links oder rechts für lokale Transformationen hängt von der API ab, die hier noch nicht weiter genannt wurde, oder?
Für DirectX ist Multiplikation von links "lokal"
Für OpenGL ist Multiplikation von rechts "lokal"
-
Es häng von den jeweils verwendeten Konventionen ab, weder OpenGL noch Direct3D machen da irgendwelche Vorgaben...
-
Zu Zeiten von Fixed-Function-Pipelines hatte man aber keine Wahl darüber, von welcher Seite sie auf der GPU multipliziert wurden? Hat sich das inzwischen dahingegen geändert, dass man sich halt in den Shadern aussucht, wie multipliziert wird?
Ich musste mich für Direct2D die letzten Tage wieder daran gewöhnen, von links zu multiplizieren, halte von rechts für natürlicher.
-
Decimad schrieb:
Zu Zeiten von Fixed-Function-Pipelines hatte man aber keine Wahl darüber, von welcher Seite sie auf der GPU multipliziert wurden?
Die Zeiten von Fixed-Function-Pipelines sind aber schon seit mindestens 10 Jahren vorbei...
Decimad schrieb:
Hat sich das inzwischen dahingegen geändert, dass man sich halt in den Shadern aussucht, wie multipliziert wird?
exakt
-
Macht das die Multiplikationseinheiten nicht "komplizierter" und langsamer? Immerhin muss ja dann eine Vertausch-Einheit zwischen Vektor, Matrix und Recheneinheit bemüht werden, was die Latenz für alle solche Produkte steigert, oder nicht? Oder werden für diesen doch überaus oft ausgeführten Rechenschritt keine spezialisierten Vorschalteinheiten vor die Floating-Point-Einheiten geschaltet? Versuche mir gerade vorszustellen, wie das technisch realisiert ist. Für sowas oft genutztes wird doch wahrscheinlich kein flexibles N*N-Programm auf den Shader-Einheiten ausgeführt...
-
Der GPU ist das völlig egal, der Shadercompiler generiert einfach anderen Code. Abgesehen davon basieren moderne GPUs sowieso nicht mehr auf Vektoreinheiten (NVIDIA schon seit der GeForce 8 nimmer, ATI hat's afaik erst vor kurzem aufgegeben)...
Aber ja, je nachdem welche Konvention und welches Memory Layout man verwendet, sind verschiedene Multiplikationsreihenfolgen potentiell unterschiedlich effizient...
-
Naja, ich mein, wenn ein Vektor-Matrix-Produkt keine speziellen Schaltkreise mehr verwendet, sondern ebene über ein Programm ausgeführt wird, dann ist es der GPU natürlich egal. Aber ich kann mir nicht vorstellen, dass man damit nur halbwegs an eine spezialisierte Recheneinheit rankommt Oo
Also ich meine natürlich auch unter dem Gesichtspunkt, dass diese spezielle Steuereinheit etwas Platz wegnimmt für eine unspezialisierte weitere generelle Recheneinheit. Schließlich werden solche Produkte doch wirklich wirklich häufig eingesetzt.
-
Für Vektor Matrix Produkte gab es afaik nie spezielle Schaltkreise, zumindest nicht in Zeiten von Shadern. Ältere Hardware war noch vektorbasiert, da wurden Matrixprodukte dann über Vektoroperationen realisiert, heutzutage arbeiten GPUs aber skalar.
Für die Hardware ist das alles völlig uninteressant. Der Shadercompiler generiert je nach Speicherlayout der Matritzen eben entsprechenden Code, das ist alles...
-
Jau, wie das inner Api umgesetzt ist, ist mir völlig schnuppe. Wenn die api xT*AT (alles klar Zeilenvektoren, wasn müll :D) als Transformation implementiert, gerne. Aber inner Mathematik isses nun mal Ax=y eine Trafo innen andres System. Folgerichtig ist "links der Matrix das Zielsystem und rechts der Matrix das Ursprungssystem".
-
Jap, mathematisch gesehen ist das die einzig richtige Variante.
-
Das verblüfft mich jetzt. CPUs sind doch auf skalarer Ebene absolut unschlagbar ausgelegt und werden für solche Operationen mit jeder SSE- oder AVX-Generation dennoch immer vektorieller ausgelegt (scheinbar ist hier also der Einsatz von Chipfläche für SSE also effizienter, als eine menge kleiner General-Purpose-Einheiten vorzusehen). Wie kann dann eine GPU schneller für solche Operationen sein, wenn sie sie programmweise skalar ausführt?
Das muss ja offenbar ein Tradeoff zwischen Chipfläche/Durchsatz sein, bei dem ich irgendwie noch nicht alle Faktoren überblicke.
