Ich möchten den CPU so gut wie möglich nicht benutzen.
Ein grosse Entlastung für die CPU ist dies nicht, dafür hat die GPU richtigen Stress. Nehmen wir mal ein einfaches Dreieck an. Wen du die Matrix mit der CPU berechnest, muss die Matrix einmal berechnet werden, in der GPU 3 mal. Bei einem Würfel sind es schon 36 mal in der GPU, bei der CPU immer noch einmal.
Zitat:
Wie sehen dann die Rechenregeln für die Reihenfolgen aus?
Registriert: Di Dez 16, 2014 10:18 Beiträge: 32
Programmiersprache: C++
ja das werde ich morgen mal versuchen: also die Matrix als uniform Variable im Shader und dann eine Rotationsmatrix mithilfe glm erstellen und "hochladen".
Registriert: Di Apr 29, 2008 18:56 Beiträge: 1213
Programmiersprache: Delphi/FPC
Hey,
das mit der Performance ist so nicht ganz richtig. Natürlich ist es besser so wenig Berechnungen wie nötig im Shader zu machen, aber Matrizen müssen so oder so auf jeden Vertex angewendet werden, also is es durchaus sinnvoll das vom GPU machen zu lassen. Die Matrix im Shader sollte allerdings eine Konstante oder globale Variable sein, dann wird die nur einmal initialisiert. Wenn die Matrix in der Main-Method erstellt wird, dann hat mathias Recht, das wäre mehr als unperformant, da die matrix dann für jeden Vertex neu ausgerechnet werden müsste. Könnte aber auch seni das der Compiler so schlau ist und das selbst rausrechnet, wenn die genutzten Variablen in der Matrix selbst nur Konstanten sind, aber drauf verlassen würde ich mich drauf nicht.
Zum eigentlichen Problem: Vector * Matrix geht soweit ich weiß gar nicht, da hätte ich vom Compiler jetzt ein Fehler erwartet. Wenn man einen Vector mit einer Matrix manipulieren möchste, dann ist das immer ResultVector = Matrix * Vector. Die Formel für deine Rotationsmatrix sieht soweit ich das seh richtig aus. Was genau hat sich denn bei dir falsch gedreht. Bzw. was hast du erwartet wie es sich dreht? Vlt auch mal mit konkreten Werten. Wie rechnest du mit rPoint weiter? Vlt ist der Fehler auch wo anders im Code. Wäre gut wenn du den ganzen Ausschnitt mal posten könntest.
Registriert: Di Dez 16, 2014 10:18 Beiträge: 32
Programmiersprache: C++
Danke für den Hinweis. Ich werde morgen mal jegliche Varianten ausprobieren, dokumentieren und hier präsentieren.
Das genaue Problem sieht wie folgt aus:
Ich habe mehrere Koordinaten die um eine gewisse Achse rotiert werden. Die Koordinaten liegen in einem VBO und ich wollte alle mithilfe eines VertexShaders rotieren lassen und mithilfe des Transform Feebacks wieder auslesen, da ich die "neuen" Koordinaten für weitere Berechnungen am CPU benötige.
Betrachte ich in diesem Beispiel den Punkt (1.0, 0.0, 0.0).
Nach der Rotation hat der Punkt die neuen Koordinaten: (0.0, 0.0, -1.0). Soweit die Theorie und Praxis mit dem CPU.
Mit dem Shader (Matrix * Vektor) bekomme ich jedoch diese Koordinaten zurück: (0.0, 0.0, +1.0). Als ob der Rotationswinkel das negative Vorzeichen besitzt. Ich habe jedoch die Übergabe der Rotationsgerade und des -winkels bei der glUniform-Übergabe überprüft und diese sind korrekt.
Wenn ich nun im Shader jedoch die Reihenfolge der Multiplikation vertausche (also Vektor * Matrix), bekomme ich die korrekten Koordinaten.
Und dies entrspricht meiner transponierten (!!) Rotationsmatrix. Daher auch der "falsche" Drehsinn und daher auch das richtige Ergebnis bei der geänderten Reihenfolge!
Ist die Rotationsmatrix demnach in der Quelle falsch?
Mitglieder in diesem Forum: 0 Mitglieder und 10 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.