Zusammenhänge zwischen Animationen, Bones, Mesh

[Eisflamme]

Hi,

Ich wühle mich gerade durch den AssimpView-Code, durch den Debugger und die Doku, aber leider komme ich nicht so ganz voran bzw. nicht zu tollen Erkenntnissen.

Da ich jetzt gerne Animationen verwenden würde, stellt sich mir die Frage, wie ich das gescheit mache. Die aiScene hat Animationen, ein Node und ein oder mehrere Mesh. Die Animationen haben Channels und Channels beziehen sich auf Bones. Und wie sich das bewegt, wird halt durch die ganzen Keys dargestellt. Und die Bones hängen wiederum in einem Mesh und merken sich, an welchen Vertices die beteiligt sind.

So weit, so gut.

Aber jetzt haben wir das gesamte Model ja auch noch in diesem Rootnode. Das hat Children etc. Aber oft ist das referenzierte Mesh nullptr und die Animationen beziehen sich ja eh auf Bones, also wozu dieser Graph? Oder ist der unabhängig von Animationen? Aber wenn ja, was bringen Children, die sich auf keinen Mesh beziehen, überhaupt?

Ja, das sind so ein paar offene Fragen. Würde mich wie immer sehr über Antworten freuen! :)

Danke und Gruß

[Schrompf]

AAAAlso. Allen voran: ich habe das Thema jetzt schon xmal beschrieben. Meinen letzten "Komplett"-Versuch findest Du unter http://sourceforge.net/projects/assimp/ ... ic/3880745

Bones und Animationen sind zwei getrennte Gebiete. Man braucht allerdings üblicherweise beide, um in einer 3D-Engine skelett-animierte Modelle zu benutzen. Die beiden Teile sind:

a) Node Animation: die Bewegung von Scene Nodes über eine gewisse Zeit hinweg. Die Nodes müssen nicht zwangsweise ein Teil eines Skeletts sein, auch wenn das die übliche Anwendung ist. Man könnte auch einen Kameraflug damit bauen, indem man den Node animiert, an dem die Kamera hängt.

b) Skinning bzw. Rigging: die Deformation eines Meshes anhand eines Skeletts. Und ein Skelett ist eine Hierarchie aus Nodes. Da begegnen sich die beiden Themen.

Ein Skelett ist also ein Graph aus Nodes. Darin steht, welche Bones welchen anderen Bones untergeordnet sind. Wenn Du zum Beispiel den Oberarm eines Menschen bewegen willst, soll sich der Unterarm und darunter die Hand und darunter die Finger mitbewegen. Diese Zusammenhänge werden durch die Node Hierarchy beschrieben.

Eine Animation besteht aus einem Rudel Animationskanälen. Jeder Kanal beeinflusst genau einen Node und enthält eine Serie aus Zeit-Wert-Paaren, die angeben, zu welcher Zeit der Node wie positioniert und rotiert ist. Wenn Du ein Animationssystem schreiben willst, wäre der erste Schritt für Dich, diese Animationskanäle auszuwerten.

Für alle Animationskanäle:
* Ermittle anhand des Node-Namens, welcher Node von diesem Kanal beeinflusst wird.
* Ermittle, welches Position-Zeit-Paar für den aktuellen Zeitpunkt wirksam wäre
* Ermittle, welches Rotation-Zeit-Paar für den aktuellen Zeitpunkt wirksam wäre
* Skalierung können wir knicken, wird praktisch nie verwendet
* Optional: interpoliere Position und Rotation mit dem nachfolgenden Zeit-Wert-Paar
* Konstruiere aus aktueller Position und Rotation eine Transformationsmatrix
* Überschreibe die Trafo-Matrix des Ziel-Nodes mit der ermittelten Trafo-Matrix

Das muss erstmal funktionieren. Zeichne Dir behelfsweise die Nodes mit kleinen Hilfslinien, so dass Du siehst, wenn sie sich bewegen und rotieren. Und dann bau die Animationsauswertung wie eben beschrieben und mach nicht weiter, bis Du siehst, dass die funktioniert! Benutze dafür nach Möglichkeit Ausgangsdaten, von denen Du weißt, dass sie korrekt sind, da auch viele Exporter Müll bauen können.

Schritt 2: Die Deformation eines Meshes anhand eines Skeletts. Der Mesh, falls geriggt, enthält ein Array aus Bones. Jeder Bone besagt anhand des Node-Namens, auf welchen Teil des Skeletts er sich bezieht. Daher weißt Du, wie die Bones hierarchisch zueinander stehen. Jeder Bone besagt außerdem, welche Vertizes er beeinflusst. Also quasi, welche Teile des Meshes sich mitbewegen, falls der Bone sich bewegt. Und wie immer, wenn man im 3D-Raum irgendwas bewegt, benutzt man dafür eine Transformationsmatrix.

Du stellst als erstes also pro Bone eine Transformationsmatrix auf, die sogenannte Bone Matrix. Die Bone Matrix beschreibt (im Koordinatensystem des Meshes), wie sich die vom Bone beeinflussten Vertizes verändern. Verändern heißt: sie bewegen sich weg von ihrer Ausgangsposition. Diese Ausgangsposition heißt Bind Pose. Wenn Du den Mesh ohne Deformationen einfach wie ein normales statisches Modell renderst, siehst Du den Mesh in Bind Pose. Das ist die Haltung, in der der Mesh modelliert und an das Skelett angebunden wurde. Wenn das Skelett dazu sich ebenso in der Ausgangshaltung (Bind Pose) befindet, sollte Dein Mesh auch mit Deformation aussehen wie ohne. Oder anders ausgedrückt: keine Vertizes bewegen sich von ihrer Ursprungsposition weg, alle Bone Matrizen sind demzufolge Einheitsmatrix.

Die Bone Matrix berechnet sich nun aus der Offsetmatrix des Bones und aus den aktuellen Transformationen der Nodes. Die Offsetmatrix transformiert aus dem Mesh-Koordinatensystem in das lokale Bone-Node-Koordinatensystem. Und wenn Du vom jeweiligen Node aus die Transformationen des Nodes und all seiner Eltern verkettest, bekommst Du den Rückweg: die Transformation vom lokalen Bone-Node-Koordinatensystem zurück zum Mesh-Koordinatensystem. Der Trick dabei ist, dass die Offsetmatrix des Bones immer die Trafo in Bind Pose, also in der Ausgangshaltung beschreibt, während die Transformationen der Nodes im Skelett zusammen die Trafo in aktueller Haltung beschreibt. Solange das Skelett, also die Node Hierarchy, in Bind Pose bleibt, heben sich die beiden Trafos genau auf und Du bekommst als Bone Matrix die Einheitsmatrix. Wenn nun aber das Skelett animiert wird, verändern sich die Trafos der einzelnen Nodes. Und dann enthält die Bone Matrix quasi die Differenz zwischen Ausgangshaltung und aktueller Haltung.

Du hast jetzt pro Bone die aktuelle Bone Matrix bestimmt. Nun ist es an der Zeit, die Vertizes anhand dieser Matrizen zu bewegen. Das macht man üblicherweise im VertexShader, indem man pro Vertex eine Liste von Bones und deren jeweiligem Einfluss (== Weight) aufstellt. Dann berechnest Du anhand der Bone Matrix pro Bone-Einfluss, welche Position/Normale/Tangente der Vertex unter Einfluss dieses Bones hätte. Die gewichtete Summe aller bone-beeinflussten Positionen usw. ist die Ergebnisposition des Vertex.

[Eisflamme]

Hi,

Wow, zum wiederholten Male vielen Dank für die Mühe!

Das klingt sehr gut,. :) Na dann hab ich ja einiges zu tun, ich werde mich daran Mal versuchen und bei Rückfragen wieder hier als Schiffbrüchiger vor die ZFX-Küste gespült werden.

Mann, bin ich heute metaphorisch! Danke nochmals.

[Eisflamme]

Hi,

Kurze Frage: Du sagst, Bones sind Nodes zugeordnet. aiBone hat aber kein Node-Attribut, nur mName als Name des Bones. Wie komme ich an die Node-Bone-Verknüpfung?

Viele Grüße und danke!

[Schrompf]

Es gibt in aiBone einen mNodeName. Anhand dieses Namens suchst Du aus der Node Hierarchy den passenden Node raus. [edit] Ich sehe gerade, der NodeName heißt nur mName. Hm. Und die Doku dazu ist auch nicht gerade klar. Das könnte der Grund sein, warum in den letzten Wochen soviele Leute danach gefragt haben... eine Doku-Überarbeitung täte echt mal Not.

[Eisflamme]

Ah! Ok, wenn das der Nodename ist, steht das in der Doku halt falsch, weil da steht "Name of the Bone". Ich hätt eigentlich Mal debuggen können, dann wär mir das wohl auch aufgefallen. Danke :)

Ach und noch ne andere Frage: Was bringt der NodeGraph ohne Bones? Wir haben ja kein Mapping von Nodes zum Mesh, also können wir damit nichts hierarchisch rendern.

[Schrompf]

Na aber wohl! Jeder Node hat eine Liste von Mesh-Instanzen. Stell Dir einen Wald vor, der aus zehn Bäumen besteht. Du hast also den Scene Root Node, der zehn Child Nodes hat. Jeder dieser Nodes hat mNumMeshes == 1 und enthält einen Meshindex. Da die Szene drei verschiedene Baummodelle enthält, ist jeder dieser MeshIndices in den Nodes eine Zahl zwischen 0 und 2. Damit weißt Du, an welcher Stelle in der Szene Du welche Meshes rendern musst. Außerdem haben zwei der zehn Bäume noch einen abbrechbaren Ast als separates Modell. Also haben zwei der zehn Baum-Nodes noch je einen Child Node, welcher wiederrum einen Mesh hat - das wäre dann wahrscheinlich MeshIndex 3. Das ist auch eine Node Hierarchy, komplett ohne Bones und trotzdem nicht zu ignorieren.

Die Nodes sind nicht nur für Skelette von animierten Charakteren nützlich :-) Man kann damit auch komplexere Szenen aus mehreren Modellen darstellen. Wir benutzen das in den Splitterwelten z.b. für Gebäude (Außenwände, Dach, Innenwände, Möbel-Instanzen, bewegliche Türen und Fenster und sowas) oder für das Luftschiff (ein Monster auch 1500 Instanzen von etwa 100 Meshes, das wir nach dem Import aber aus Performance-Gründen auf etwa 100 Modelle zusammengefasst haben).

[Eisflamme]

Achso! Also kann ich meine gesamte Szene stets durch den Tree rendern, wobei der Tree einfach nur die Organisation von Mesh-Instanzen übernimmt!?

Und es ist auch immer möglich, über den Tree zu rendern? Laut Doku ist ja bei jedem Modell mindestens der RootNode da. Wozu dienen denn dann SubNodes, die Mal kein Mesh haben, wenn diese nicht mit Bones verknüpft sind? Oder gibt's das nicht?

[Schrompf]

Achso! Also kann ich meine gesamte Szene stets durch den Tree rendern, wobei der Tree einfach nur die Organisation von Mesh-Instanzen übernimmt!?

Ja klar. So macht es auch der AssimpViewer und nach meinem Wissen auch das OpenGL-SimpleExample.

Und es ist auch immer möglich, über den Tree zu rendern? Laut Doku ist ja bei jedem Modell mindestens der RootNode da. Wozu dienen denn dann SubNodes, die Mal kein Mesh haben, wenn diese nicht mit Bones verknüpft sind? Oder gibt's das nicht?

Doch, es kann auch leere Nodes geben, die gar keine Funktion haben. DIe benutzt man manchmal zur Gruppierung von Szene-Teilen oder für organisatorische Spezialzwecke. Bei den Splitterwelten nehmen wir z.B. leere Nodes als Platzierungshelfer, wenn es darum geht, Waffen in Händen oder den Helm auf dem Kopf eines Charakters zu platzieren. Dazu packt man halt einen Helfernode unter einen passenden Node des Skeletts und gibt ihm einen speziellen Namen, so dass man ihn wiederfindet. Wenn der Charakter dann z.B. einen Helm bekommt, wird der einfach als Subnode des Helfer-Nodes untergeordnet und bekommt so automatisch die richtige Position und Rotation am Charaktermodell. Und durch die Unterordnung unter einen Node des Skeletts bekommt der Helm auch die Transformationen der sonstigen Skelettteile mit, wird also korrekt mitbewegt, wenn der Charakter auf- und abhüpft oder den Kopf dreht.

Das sind zugegebenermaßen reichlich spezielle Anwendungen, aber es gibt halt Sonderfälle. Und Du darfst nicht vergessen, dass anstatt bzw. zusätzlich zu Meshes auch Lichtquellen oder Kameras an Nodes gehängt werden können. Wenn Du einen Node mit einer Kamera hast, wird diese Kamera ja auch mitbewegt, wenn Du den Node per Node Animation umherbewegst oder rotierst. Ist auch ein seltener Fall, aber ebenso möglich.

[Eisflamme]

Wow, sehr gute! Verstehe.

Na dann versuch ich Mal weiter mein Glück.

[Eisflamme]

Hi,

Mittlerweile kann ich zumindest das Nodeskelett darstellen, aber noch nicht animieren. ;)

Frage: Es gibt pro Channel ja Rotationen und Translationen, die aber verschiedene Anzahlen haben können. Ich würde eigentlich gerne beim Importieren alles direkt in Matrizen packen. Sagen wir Mal, es gibt zu t0, t2, t4 Rotationen. Und zu t1, t3, t5 hab ich Bewegungen. Das heißt ja, dass ich 6 Matrizen bräuchte, wobei die zu t_gerade ja jeweils auf der Position stehen muss und die zu t_ungerade die Rotationen auch beinhalten muss. Ist das so richtig interpretiert oder gleichen sich die Zeitpunkte der Rotationen und Bewegungen normalerweise?

[Schrompf]

Nein, Du kannst nichts voraussetzen oder erwarten. Die Rotations-Sequenzen sind meist sehr feingliedrig, die Positionsequenzen dagegen dünn, meist sogar nur zwei oder nur ein einziger Key. Wenn Du das zu einer Sequenz zusammenfassen willst, musst Du halt an jedem der beiden Zeitpunkt-Serien jeweils einen Key setzen und die jeweils andere Komponente für diesen Zeitpunkt interpolieren.

[Eisflamme]

Hi,

Interpolieren, hm. Bisher mache ich es so (es klappt btw. für die reine Skelett-Animation *freu* :)), dass ich für jeden Zeitpunkt, wo der jeweils andere Key nicht gesetzt ist, einen gemeinsamen mache, aber die Werte vom anderen nur übernehme. Beim Abspielen der Animation interpoliere ich dann zwischen den Matrizen. Aber das müsste theoretisch natürlich recht kantig sein. Findest Du es denn empfehlenswert alle Matrizen im Voraus zu berechnen? Klar, wir haben ein wenig mehr im Speicher, dafür müssen wir aber später halt nur noch zwischen Matrizen interpolieren und das dürfte doch der Performance schon etwas helfen, oder? Euer Viewer merkt sich ja einfach die Rotationen und Positionen, aber muss halt die Matrizen dann immer wieder zusammenstellen. Generell frage ich mich, ob diese Animationen die Performance nicht zu sehr belasten...

Lg

[Schrompf]

Nein, im Gegenteil: Matrizen zu interpolieren sieht Scheiße aus - die Basisvektoren sind dann nicht mehr orthonormiert. Eine der großen Vorteile von Quaternions ist ja, dass man sie mathematisch sauber interpolieren kann. Die Rechenzeit müsste auf heutigen Prozessoren, wo sin() und cos() als Prozessor-Befehle zur Verfügung stehen, für beide Lösungen die selbe sein.

Du kannst natürlich die Keys synchron ziehen. Machen wir in den Splitterwelten z.B. auch so. Allerdings spart man sich damit nur eine bzw. zwei Suchen nach dem passenden Key zur Zeit. Und das kostet ja kaum Rechenzeit, wenn man vom letzten bekannten Key ausgeht. Dafür investiert man halt etwas mehr Speicher. Hat alles seine Vor- und Nachteile.

[Eisflamme]

Oh, da hab ich bei der Theorie wohl etwas geschwänzt. Aber das Interpolieren sieht eigentlich ganz in Ordnung aus bei dem testwuson. Egal, dann stell ich's wieder um. ;)

[Schrompf]

Die Wirkung siehst Du erst, wenn Du eine Animation mit nur wenigen und weit auseinanderliegenden Rotationskeys hast. Wenn also die Matrixinterpolation für Dich klappt - bitteschön. Du wirst nur evtl. später nochmal alles umstellen müssen, wenn Du mal von einem neuen Grafiker eine Anim bekommst, die mit einem selteneren Exporter produziert wurde.

[Eisflamme]

Verstehe. Ich stell's trotzdem jetzt um. Später ginge das zwar theoretisch auch noch ohne Probleme, aber besser ist das so. Dankö :)

Ich weiß nicht, ob ich schon Mal gefragt habe: Aber woher weißt Du das alles eigentlich? Nur durch Foren, Tutorials und eigene Erfahrungen so viel wissen zu sammeln muss doch einige Jahre intensiven Studiums bedeuten. Oder hattest Du gute Bücher, die ein paar Rundumschläge gemacht haben? Kann mir kaum vorstellen, dass es dafür besonders gute Bücher gibt oder irre ich?

[Schrompf]

Weil ich es geschrieben habe? :-) Zumindest den Assimp-Teil - der ganze Kram rund um Bone Animations ist auf meinem Mist gewachsen. Ich habe mir damals anhand eines selbstgeschriebenen XFile-Loaders die Grundlagen der Bone-Animationen erarbeitet. Allerdings wurde meine Vorstellung davon in den Jahren mehrfach drastisch korrigiert, so dass ich inzwischen auch eine gewisse Vorstellung davon habe, auf was für Irrpfade man dabei treten kann.

[Eisflamme]

Hi,

Jetzt bin ich wieder am hängen. Ich habe nun erfolgreich auf Quaternionen + Vektoren umgestellt und interpoliere fleißig. Jetzt wollte ich am Ende der Animation natürlich auch eine Interpolation mit dem Anfang der Animation einfügen.

Problem: Beim testwuson ist die Geschichte ja 4640 ticks lang. Bei 0 ist jetzt ein Animationframe und bei 4640 ist ja auch eins. Dementsprechend habe ich keinen Spielraum für Interpolation. Wenn ich die Animation künstlich auf 4800 verlängere, sieht es hingegen super aus. Wie löst ihr das?

[Jörg]

Höhö, super Frage :) Zumal es auch noch darauf ankommt, ob man die Animation immer oder nur manchmal loopen moechte....

Ich bin fuer: End-Key = Start-Key, ohne Interpolation zwischen beiden. Dann kannst Du die Animation einzeln oder geloopt spielen, und der Code sieht recht sauber aus.

[Eisflamme]

Wie End = Start-Key? Meinst Du, ich soll den letzten Schritt überschreiben oder einfach keine Interpolation einbauen? Ohne letztere ruckelt das Wuson.

[Jörg]

"Das Wuson" sollte ja nicht die Referenz sein. Egal, wie du es machst, mach es einheitlich. Und ich fand es wirklich simpler dafuer sorgen zu lassen (Animations-Designer & Exporter), dass eine Animation, welche geloopt werden soll, mit den gleichen Werten endet, wie sie beginnt. Sonst hast Du, wie bemerkt, keine Ahnung, wie gross die zeitlichen Abstaende zwischen Ende und Anfang sind, die du verblenden willst (bei mir gabs keine konstanten Zeitschritte).

[Eisflamme]

Ja nunn, aber ich denke, der AssimpViewer macht es auch einheitlich und da sieht das halt gut aus, also frag ich mich, wie.

[Schrompf]

Man kann nicht zwischen Endkey und Startkey interpolieren, wie Du ja schon richtig festgestellt hast, weil einem dazu ja die Zeitdifferenz zwischen den beiden fehlt. Ohne das jetzt nachprüfen zu können, behaupte ich, dass ich in meinem privaten Animcode einfach Endkey == Startkey voraussetze und man die Zeit demzufolge einfach wrappen kann - also modulo Animdauer, meine ich. Wenn es im Viewer korrekt aussieht, kannst Du ja mal in AnimEvaluator.cpp schauen, wie der das macht.

[Eisflamme]

Oje, dann hab ich mir die Mühe ja ganz umsonst gemacht. :P

Ja und jetzt, wo ich es einfach drei Mal so schnell abspiele, sieht man auch keinen kantigen Übergang mehr, na herrlich, hehe...

Dankeschön!

[Eisflamme]

Hi,

Ich muss nochmal nachfragen:

Die Offsetmatrix transformiert aus dem Mesh-Koordinatensystem in das lokale Bone-Node-Koordinatensystem. Und wenn Du vom jeweiligen Node aus die Transformationen des Nodes und all seiner Eltern verkettest, bekommst Du den Rückweg: die Transformation vom lokalen Bone-Node-Koordinatensystem zurück zum Mesh-Koordinatensystem.

Also Moment. Ich verkette alle Nodes hierarchisch wie ich das ja auch für die Skelettanimation schon gemacht habe. Die resultierende Transformation wäre ja jetzt schon ganz nett. Bei mir rendere ich jetzt alle Meshs auf einmal, die liegen in einem Index- bzw. Vertexbuffer, ich bin aber nicht sicher, ob das was für mich ausmacht. Jedenfalls weiß ich jetzt nicht, wofür ich die Offsetmatrix brauche bzw. wie ich die verrechne. Könntest Du mir da vielleicht wieder Mal nen Wink mit nem Zaunpfahl geben?

[Schrompf]

Die Offsetmatrix steht in aiBone, die ist also nur für VertexSkinning relevant - also wenn Dein Mesh Bones hat.

[Eisflamme]

Hi,

Ja, genau, so weit verstehe ich das ja auch. :) Genau das mit dem Vertexskinning möchte ich jetzt genau machen, aber ich bin nicht sicher, was ich meinem Shader genau mitgeben muss, was er dann auf die Vertices anwenden kann. Das mit den Weights habe ich an sich verstanden, die nodeverkettung nebst ihrer Animation klappt auch. Nur die resultierende Bonematrix ist die übrig gebliebene Frage. Muss ich diese Offsetmatrix mit der Nodematrix (bzw. der Nodematrix, die mit all ihren Eltern verknüpft ist) einfach multiplizieren? Ich muss doch eigentlich ins Mesh-System kommen und nicht ins Node-Bone-System, richtig? Daher hab ich im Kopf, ich muss die inversen oder so...

[Schrompf]

Die Formel for die BoneMatrix ist

Matrix = OffsetMatrix * NodeTransform * ParentTransform * usw.

das hängt allerdings von Deiner Matrix-Notation ab, evtl. ist es genau andersrum. Das kannst nur Du selbst wissen, weil nur Du selbst Deinen Matrix-Code kennst. Und die Formel hat eventuell einen festen Offset, der für alle Bones der gleiche ist, falls die Node-Hierarchie des Skeletts in der Gesamtstruktur nicht Kind des MeshNodes ist, sondern daneben liegt. Manche Exporter schreiben solche Strukturen. Das kann Dir aber *eigentlich* wurscht sein, weil mir bisher noch kein Modell begegnet ist, dass an der Stelle noch eine Zusatztransformation einschiebt.

Auf die oben beschriebene Art bekommst Du jedenfalls ein Array aus Matrizen, das pro Bone beschreibt, wie sich die Vertizes bewegen/drehen. Die Matrix ist im lokalen MeshSpace, Du musst im Shader also nach Anwendung noch ganz normal die Model-, View- und Projection Matrix anwenden.

[Eisflamme]

Hi,

das klingt machbar und logisch, danke. :) Vielleicht schaffe ich es dann endlich bald ein animiertes Modell zu haben. Yeah! Danke nochmals ^^