[Assimp] Animationen, mal wieder...

[mOfl]

Hallo Menschen,

leider scheitere ich an der Verwendung von Bone-Animationen mit Assimp. Das liegt nicht zuletzt daran, weil ich leider kein Demo-Programm gefunden habe, das die Verwendung von Animationen erklärt. Ich habe versucht, das aus den Foren und dem Assimp Viewer-Code so gut wie möglich zu rekonstruieren, aber leider kommen da ein paar hässliche Fehler (http://www.youtube.com/watch?v=wsgrzl6i3GA). Bevor ich jetzt aber einen ausführlichen Post schreibe, in dem ich mein Leiden mit Code und Debug-Output darlege, weil ich die ganze Zeit auf dem falschen Dampfer war, will ich vorher mal fragen: Gibt es eine kleine Demo-Anwendung, die die Verwendung von Bone-Animationen zeigt? Also was ich realisiere, ist ein Loader von einzelnen Objekten (keine komplexen Szenen), die animiert sind und in verschiedenen Verfahren vorliegen können, hauptsächlich aber als Collada-Files. Die Animationen der Models sollen korrekt abgespielt werden. Im Viewer klappt das ja ganz fein, aber wenn ich den relevanten Code adaptiere, kommt es zu den Anzeigefehlern. Ich würde mich sehr freuen, wenn mich einer mit einer kleinen, funktionierenden Beispielanwendung überraschen könnte. Ansonsten werde ich die nächsten Tagen mal ausführlich meinen Code posten. :?

Gruß
mOfl

[Schrompf]

Moin Mofl,

sorry für die späte Reaktion, Dein Thread war bei mir irgendwie hinten runtergefallen.

Was Dein Problem angeht, sieht es für mich aus, als würdest DU nur einen Bruchteil der Animkanäle auswerten oder anwenden. Hast Du mal alle Nodes mit Hilfslinien oder sowas dargestellt, um zu sehen, ob Deine Animauswertung funktioniert? Ich würde nämlich anhand des Videos tippen, dass Dein Skinning-Shader nicht funktioniert. Falls die Nodes schon nicht korrekt animieren, weißt Du ja schon genauer, wo Du suchen musst. Leider kann da ne Menge schiefgehen, was man von außen nicht sehen kann... allen voran die Matrixorientierung, Koordinatensysteme oder die Quaternion-Implementation, die Du und nur Du genau kennen kannst. Falls es die Animauswertung sein sollt, step mal mit dem Debugger durch die Mathematik und schau, ob an einer Stelle die Werte explodieren.

[mOfl]

Herzlichen Dank für deine Antwort, Schrompf! Ich musste das Problem für eine ganze Weile beiseite schieben, weil andere Probleme dringender waren, aber jetzt habe ich wieder die letzten 3 (vollen!) Tage damit verbracht, die Animation zum Laufen zu bringen. Ich hab schon angefangen, Codeschnipsel zu sammeln, Videos zu machen etc., um den Fehler möglichst gut zu beschreiben und auf einmal... funktioniert es. Unglaublich frustrierend, weil ich nur einen einzigen kleinen Buchstaben geändert habe.

Mein Gefühl hat mich von Anfang an nicht getäuscht, das Problem lag nicht an falschen oder fehlenden Transformationen, sondern an falschen Datentypen. Ich verwende OpenGL 2.1 (eine neuere Version kam wegen Abwärtskompatibilität und Kompatibilität mit dem restlichen Code leider nicht in Frage) mit GLSL 1.20, der AssimpViewer läuft (leider?) über DirectX, also konnte ich ausgerechnet beim komplizierten Part nicht spickeln.

Das Mysterium: Die als unsigned int gegebenen Indizes in das Bone-Matrizen-Array lese ich pro Vertex in einen uint-Vektor und übergebe sie an an den Vertex-Shader auch als GL_UNSIGNED_INT. Wenn ich damit im Shader selbst aber in das Array greifen will, kommen sehr wirre Sachen heraus (siehe Video aus dem ersten Post). Viel Rumprobieren mit verschiedensten Datentypen, Casts, Workarounds etc. hat mich dann schließlich vorhin zu dem Versuch geführt, im Vertex Shader aus dem uvec4 für die Indizes einen ivec4 zu machen. Damit kompiliert der Shader unter GLSL 1.20 nicht, aber Google hat dann hervorgebracht, dass "#extension GL_EXT_gpu_shader4: enable" das ändern soll. Und siehe da, der Zwerg wackelt mit der Axt, als hätte er nie was anderes getan! Andere Versuche, z.B. gleich mit int-Daten hochzuladen, führen zu falschen Ergebnissen.

Ich bin zwar noch frustriert, aber doch sehr erleichtert, dass es jetzt funktioniert. Ich finde es zwar seltsam, dass ich die Werte als unsigned int hochlade, dann aber als int verwende, aber solange es funktioniert, will ich nicht klagen... =)

Gruß
mOfl

[Schrompf]

Ok, freut mich zwar, dass es jetzt funktioniert, aber eigentlich ärgert mich sowas immer: ich krieg regelmäßig Post von Leuten, die Probleme mit Assimp haben, und am Ende liegt es dann doch an irgendeinem OpenGL-Gurkenmist, der mit Assimp gar nix zu tun hat. Was soll ich da noch tun? Es gibt Gründe, warum kaum jemand OpenGL verwendet.

[Eisflamme]

Vielleicht wäre es nicht dumm, die Erkenntnisse irgendwo zu sammeln. Ich hatte jetzt ja viel Spaß mit CG... Das hat zwar nur im weitesten Sinne mit Assimp zu tun, aber für das VertexSkinning braucht man ja so ne Sprache oder eben direkt GLSL. Und wenn du sagst, du kriegst haufenweise Mails, werden sich doch wohl gewisse Probleme auch überschneiden, oder?

[mOfl]

Es gibt Gründe, warum kaum jemand OpenGL verwendet.

Naja, ich würde behaupten, OpenGL 3.2 ist schon recht komfortabel und leistungsfähig, nur eben bei den vorigen Versionen muss man häufig mit irgendwelchen Extensions rumtricksen und pfuschen. DirectX kam bei meiner Anwendung leider nicht in Frage, weil ich bestehenden Code erweitere. Und ich glaube, viele Menschen haben auch eine Aversion gegen Microsoft oder denken, DirectX sei zu professionell oder schwierig oder sonst was.

Ich denke mal, dass es viele Fragen bezüglich der Umsetzung in OpenGL gibt hängt damit zusammen, dass es da kein vollständiges Sample dazu gibt. Da es jetzt bei mir läuft, wäre das kein allzu großer Schritt mehr, daraus ein sauberes OpenGL 3.x-Sample zu machen. Bestünde da Interesse? Würde dann zwar noch eine Weile dauern, weil ich gerade noch viel zu tun habe, aber ich glaube, das könnte einigen Leuten helfen.

Gruß
mOfl

[Schrompf]

Ok, das über OpenGl war etwas stark generalisiert. Das aktuelle OpenGL soll ganz ok sein, und noch cooler wird es wohl mit den NVidia-spezifischen DirectIrgendwas-Extensions.

Der letzte Herr, der mich angemailt hatte, hat leider nicht die Adresse seines Blogs mitgeschickt, auf dem er seine Demo posten wollte. Eisflamme hat das Problem jetzt ja auch gelöst, vielleicht hat er Beispielcode rumliegen. Ansonsten wäre eine Demo eine feine Sache - auch die Leute aus dem großen WieGehtDasEigentlich-Thread auf Sourceforge haben ihr Ergebnis nie öffentlich gezeigt.

[Eisflamme]

Meine "Engine" soll auf Dauer ja sowieso OpenSource werden, allerdings ist diese natürlich etwas überladen. Der Loader ist ausgelagert und die Modelldarstellung bereits in 3-4 Klassen ausgegliedert (Mesh, Model, ModelInstance, Renderer). Wenn's hilft, kann ich das, wenn ich irgendwann Mal Zeit hab, evtl. abspecken, dann gäb's eine CG und eine OpenGL-Version für VertexSkinning von Assimp-geladenen Modellen, das würd doch schon was bringen. Nur komm ich wohl demnächst zu gar nix weil Bachelorarbeit :<

So, FWIW hab ich Mal alle meine Dateien hochgeladen (FWIW: wohl nicht besonders viel, da man die Projekte zu SDL/GLEW/BOOST/ASSIMP/CG linken muss, aber man sieht vll. ein paar Codings und die CG-Shader sind im SimpleDemo-Verzeichnis):
http://sourceforge.net/projects/elypson3d/files/

Ansonsten gibt es halt den AssimpLoader, der alle Daten in eine neu erzeugte Model-Instance steckt, d.h. hier hat man ne Routine und vll. hilft das manchen Leuten auch zu sehen, wie man Bones/Nodes aus ner aiScene ziehen kann und diese in die entsprechenden OpenGL-Vertex/IndexBuffer steckt und rendert... aber ist natürlich keine bemerkenswerte Leistung und ich garantiere nicht für sauberen Code und habe auch nicht viele Kommentare gemacht. Die Shader werden dann in Renderer verwendet (wobei ich die CG-Shader wiederum gekapselt habe) und "animator.cg" (der VS) und "light.cg" (PS=FS) liegen im Simpledemo-Verzeichnis.

Falls das IRGENDETWAS nützt, kannst Du das jdf. verlinken, ich sehe nicht, wieso ich das bei SF löschen sollte in einiger Zukunft. Vll. mach ich's irgendwann schnell kompilierbar für Leute, die sich das echt Mal laden, indem ich die Bibliotheken einfach dran hänge oder kA was da sonst noch nötig ist...

[mOfl]

Hallo miteinander,

das hat jetzt zwar eine ganze Weile gedauert, weil ich anderweitig noch sehr beschäftigt war, aber heute Nacht hatte ich mal ein wenig Zeit, die versprochene Demo zu machen. Es ist eigentlich eine Minimaldemo, die die Verwendung von Animationen mit Assimp unter OpenGL zeigt. Grundbeleuchtung ist auch dabei, aber sonst ist es das. Zu finden ist das Ganze hier: http://www.drivenbynostalgia.com/files/ ... GLDemo.rar, hat gepackt knapp 2 MB. Enthalten sind Source Code (C++) und Visual Studio 2008-Projekt, Binaries und die benötigten Libraries und Includes für Assimp, SDL, GLEW und GLM.

Man darf da auch gerne direkt drauf verlinken, an dem Pfad wird sich in absehbarer Zeit nichts ändern. Irgendwann - geplant eigentlich jetzt über den Sommer - ist dann unter der Domain eine Website erreichbar, wo ich die Demo selbst verlinke und man sie dann vielleicht auch per Google findet.

Gruß
mOfl

[Aramis]

Laeuft out-of-the-box bei mir. Spitze.

Bis heute gibt es ausser dem Assimp Viewer kein wirkliches Sample zu Animationen. Wenn man ein bisschem rumgooglet, findet man etliche Threads in denen sich Leute ueber ihre Probleme mit Assimp Animationen austauschen, es handelt sich also wirklich um eine Luecke.

Wenn es dich nicht stoert, werde ich also in Zukunft auf deine Demo verlinken. Evtl. kann ich auch direkt aus dem README im ./samples-Verzeichnis drauf hinweisen. Theoretisch koennte man die Demo uebrigens auch im Repository hosten, nur muessten wir dann noch ein passendes CMake Buildskript basteln.

Gruss, Alex

[mOfl]

Stört mich gar nicht, im Gegenteil. Ich stand ja vor dem selben Problem, dass ich mich nächtelang durch den Assimp Viewer-Code gewurstelt habe, um das ganze verstehen zu können. Wenn die Demo das für andere Leute vereinfacht, umso besser. In dem Archiv befinden sich zwei abgeänderte Dateien aus dem Assimp Viewer (Animator.cpp / .hpp, sind ein Resultat aus animEvaluator.cpp / .hpp und sceneAnimator.cpp / .hpp ohne Boost und mit GLM), wo die Assimp-Lizenz gilt, sowie ein Memory Leak Tracker, der ohne jedwede Lizenzangaben veröffentlicht wurde. Das Zeug, das von mir kommt, kann frei verwendet werden für was auch immer. Also falls ihr das ins Repository nehmen wollt (den Memory Leak Tracker kann man ja auch entfernen), gerne.

Gruß
mOfl

[Aramis]

Ja, den Leak-Tracker wuerde ich schon alleine deshalb entfernen wollen weil er fuer die eigentliche Funktionalitaet nicht noetig ist und somit nur die Komplexitaet des Samples erhoeht.


Assimp-Team:

Ggf. waere es sinnvoll, AnimEvaluator und SceneAnimator als separates Tool zu fuehren (z.b. als tools/animtool). Damit wuerden erstens mehr Leute von ihrer Existenz erfahren und zweitens waere der Code nicht mehrfach dupliziert.

Ich werde evtl. am Wochenende Zeit haben, fuer CMake-Support zu sorgen und das Sample auf weiteren Plattformen zu testen.

[mOfl]

Ich habe das Archiv eben neu hochgeladen ohne Memory Leak Tracker und ohne windows.h-Include, damit sollte es auf anderen Plattformen besser laufen... ;)

[Schrompf]

Ich würde keine zusätzliche Abhängigkeiten über Verzeichnisse hinweg erzeugen, nur um zwei Code-Dateien nicht duplizieren zu müssen. Immerhin hängen da ja neben CMake auch noch weitere Projektfiles dran. Aber da Du den Baukram machst, ist es mir auch relativ schnuppe.