Nachdem der Ogre-Importer jetzt läuft, habe ich angefangen, Animationen in mein Spiel zu implementieren. Nach zahlreichen einfach nur falschen Transformationsketten, habe ich das ganze nochmal komplett aufgezeichnet. Sollte das so richtig sein (oder hab ich noch einen Fehler drin?) wäre das ja vielleicht auch was für die Assimpdoku.
Jetzt habe ich aber noch eine Frage: Wieso sind die Offset-Matrizen Mesh-spezifisch? Hängt das davon ab, wo das Modell in der Node-Hierarchie steht? Weil so ganz kann ich das noch nicht nachvollziehen, wieso die für verschiedene Meshes unterschiedlich sein sollten.
FinalTranform sollen übrigens die Matrizen sein, die man dann später im VertexShader benutzt (wie hier: http://zfx.info/viewtopic.php?f=5&t=2232).
Das Bild kommt so hin. Ich weiß aber nicht, ob die Matrix-Mulitplikationsreihenfolge für Deine Matrix-Klassen stimmen. Je nach Speicher-Layout kann es auch umgedreht sein, aber mein fehlender mathematischer Hintergrund erlaubt mir da keine Bewertung.
Offset-Matrizen werden pro Mesh gespeichert, weil sie je nach Mesh-Koordinatenursprung abweichen können. Stell Dir vor, Du legst Deinem Character eine Halskette um. Die sollte, da sie sich über einige Brust- und Schulterbones erstreckt, vom Skelett mit deformiert werden. Der Mesh könnte aber einen Koordinatenursprung irgendwo im Halsbereich haben, während der vom Körper üblicherweise irgendwo in der Hüfte liegt.
Außerdem: wo sollte man die Matrizen denn sonst speichern :-) In die Nodes gehören sie nicht, meiner Meinung nach.
Wegen der Reihenfolge:
Ich habe nochmal nachgedacht und bin zum folgenden Schluss gekommen: Meine Reihenfolge hatte ich so gewählt, da ich gerne von links nach rechts lese und demnach die Transformationskette auch in dieser Reihenfolge haben wollte. Weil man eben die Offset Transformation ganz am Anfang macht und nicht am Schluss, deswegen fand ich es schön sie vorne zu haben.
Allerdings heißt es ja bekanntlich Matrix * Vektor und nicht andersherum (ginge natürlich, man müsste aber beides transponieren und hätte dann einen Zeilenvektor statt einem Spaltenvektor). Da das Kommutativgesetzt aber nicht gilt und der Vektor immer ganz rechts stehen muss, gäbe es bei dieser Reihenfolge keine Möglichkeit, zuerst die OffsetTransformation anzuwenden. Man braucht also (Node2 * (Node1 * (Offset * Vektor) ) ), was zu (Node2 * Node1 * Offset) * Vektor wird. Um es kurz zu machen: Wenn man auf Matrix*Vektor besteht, muss man die Transformationen wohl leider rückwärts lesen, ich werde das also in Zukunft auch so handhaben.
Zu den Offsetmatrizen:
So wie ich das sehe, lassen die sich doch immer sehr einfach aus der Nodehierarchie berechnen, falls das Mesh- und das Skeleton-Koordinatensystem identisch sind. Falls nicht, würde es reichen, das Mesh mit einer einzelnen Transformation "an die richtige Körperstelle" zu bringen und dann wieder die Standardoffset-Matrizen, berechnet aus der Nodehierarchie, zu benutzen. So werde ich es denke ich auch umsetzen. Der Vorteil von der Assimplösung ist wohl, dass eine Matrixmultiplikation entfällt. Das Nachteil ist, dass man sehr viele Offsetmatrizen hat und Probleme kriegt, wenn man Beispielsweise die Halskette aus einer ganz anderen Datei laden möchte (so wie ich es auch tun würde). Dann muss man statt einer einzelnen Transformationsmatrix für alle eventuell benutzen Knochen eine Offsetmatrix berechnen.
Oder kann es sonst noch einen Fall geben, bei dem die Offsetmatrizen bis auf diese eine, schon zusätzlich einberechnete, Meshpositionierungstransformation nicht jeweils identisch sind?
Nunja... die Offsetmatrizen enthalten den Mesh-Ursprung und die Inverse Bind Pose aller Nodes in der Transformationskette. Denkbar ist also auch, dass man verschiedene Teile eines Modells in verschiedenen Bind Poses modelliert. Wird aber eher selten der Fall sein, da gebe ich Dir Recht.
Ich frage allerdings nochmals, wo Du denn die Offsetmatrizen speichern wollen würdest, wenn nicht im Mesh. Ich sehe da keine Alternative, daher finde ich die Diskussion müßig.
