[Assimp] 3D-Modell-Animationen nicht ladbar?

[Eisflamme]

Hi,

Ich versuche gerade mit Assimp ein paar animierte Modelle zu laden, die im 3DS-Format vorliegen.

Leider ist in dem aiScene-Objekte mNumAnimations immer leer. :(
Das hier ist mein Ladecode:

Code: Alles auswählen

		// Read Model Data from File

		temporaryScene_ = importer_.ReadFile(	filename,
												aiProcess_CalcTangentSpace       | 
												aiProcess_Triangulate            |
												aiProcess_JoinIdenticalVertices  |
												aiProcess_SortByPType			 |
												aiProcess_PreTransformVertices	 |
												aiProcess_GenSmoothNormals		 |
												aiProcess_JoinIdenticalVertices	 |
												aiProcess_GenUVCoords);

Modelle nutze ich gerade von http://www.turbosquid.com/.
Meine genaue Suchmaske ist einfach: http://www.turbosquid.com/Search/Index. ... a_typeid=2
Da gibt es nur so eine Seite von Modellen und ich habe so 5-6 probiert. Werden 3DS-Animationen von Assimp nicht unterstützt, sind die Modelle "schlecht" modelliert oder habe ich etwas falsch gemacht?

Vielen Dank!

[Eisflamme]

Sorry, lese gerade, dass PretransformVertices böse ist.

[Aramis]

Selbst wenn: 3DS-Animationen werden nur unzureichend unterstuetzt. Das liegt u.a. daran, dass ich es einfach nie richtig hinbekommen habe und 3DS-Modelle mit komplexen Animationen auch eher selten sind. Einfache Animationen funktionieren aber zuweilen.

Sorry, lese gerade, dass PretransformVertices böse ist.

Korrekt, er mag naemlich keine Animationen :-)

[Eisflamme]

Ok, alles klar. Sind denn .obj und .dae in Ordnung oder was bietet sich dann so an?

[Aramis]

Obj unterstuetzt ueberhaupt keine Animationen -- fuer Anmationen wuerde ich Collada oder X probieren. Evtl. Md5 wenn es um Skinning geht und entsprechende Exporter verfuegbar sind.

[Eisflamme]

Ups.

Collada ist super. Vielleicht kann ich ja fremde Formate mit Blender importieren und in Collada exportieren *schulterzuck*

Danke jedenfalls!

[Eisflamme]

Jetzt habe ich in Blender ein schönes bone-animiertes Modell und will das in .dae exportieren. Hab den beiliegenden Exporter für 1.4 probiert und auch andere Modelltypen. Assimp kann aber nichts davon laden, ReadFile liefert immer 0 zurück. :(

Hat jemand eine Idee, welches Format ich noch probieren kann oder was ich tun kann? Oder einfach ein Ansatz, wie ich jetzt weitermachen kann? ;) Ich bin an der Stelle, kein brauchbares Animationsmodell zu haben, daher kann ich Animationen nicht implementieren, weil ich nix testen kann. Und ich kann mich nicht an Programmer's Art 3D-Modellen mit Animationen probieren, weil ich nicht weiß, was ich beachten muss, damit ich das in die Engine stecken kann.

Hilfe!

[Schrompf]

Wenn keines der Formate geht, dann ist wohl was am Modell falsch. Allerdings ist ein "Geht nicht" keine Fehlerbeschreibung, weswegen ich das nicht mit Sicherheit sagen kann. Wie genau sieht Dein Modell aus? Welche Formate hast Du probiert? Bekommst Du Fehlermeldungen beim Exportieren? Bitte getrennt nach Format, in welches Du exportiert hast. Welche Nachrichten gibt AssimpView aus, wenn Du die exportierte Datei zu laden versuchst? Ebenso getrennt nach Format, in welchem die Datei vorliegt.

Ich persönlich habe bei Blender nur Erfahrungen mit dem Direct3D .x-Format. Und da weiß ich, dass ich bereits erfolgreich Dateien davon lesen konnte. Wenn Du ein korrektes Collada-File hast, von dem Du sicher bist, dass es lesbar sein müsste (z.B. weil Du es in einem anderen Collada-Viewer getestet hast) dann schicke es mir bitte zu, damit ich den Loader korrigieren kann.

[Eisflamme]

Ah, die Fehlermeldungen sind sehr hilfreich! Vielleicht kann ich damit alle Probleme lösen.

Und es kann gut sein, dass Blender nur schlechte Exportskripte hat, die funktionieren sowieso irgendwie immer nur in einem Bruchteil der Fälle (und das betrifft leider alle :( .x exportiert die Texturnamen z.B. nicht richtig und irgendwelche im Internet gesuchten funktionieren aus irgendwelchen Gründen auch nicht).

Ok, also da .DAE ja textuell ist, habe ich ein paar Dinge rausgefunden:

* Er hatte gesagt "expected end of init_from" und nach Löschen eines "<init_from></init_from>" war der Fehler weg. Parser scheint also keine leeren Tags zu erkennen?
* Irgendwo war auf ne Textur verwiesen, die ich aber auch in Blender nicht sah, da ist Assimp nicht Schuld

Ach und generell kann ich mit dem Loader ein Modell nicht laden, nachdem:
* ich es geladen hatte (mit Fehler)
* ich die Datei in eine ".dae.txt"-Datei umbenannt hatte
* was drin geändert hatte
* sie wieder in ".dae" umbenannt hatte

Dann tut sich nämlich einfach nichts und ich muss den Viewer neustarten.

Hm... der Viewer zeigt dann die Animation nicht an, wenn ich auf Start drücke und die Bones sehen auch... komisch aus. Also zum Teil scheint das zum stimmen, zum restlichen Teil nicht, da spreizen sich die Bones seltsam ab. Der Playknopf geht wie gesagt, aber führt zu keiner visuellen Änderung.

Der Versuch das Modell über Blender wieder zu importieren scheitert ebenfalls komplett. "Import successful" aber ich sehe nichts...

Und wenn ich debugge, sehe ich eine Animation in der geladenen Szene mit 12 Channeln und die haben jeweils auch Positionen/Rotationen/etc. alles drin, wird also an sich schon geladen.

[Schrompf]

Der Collada-Loader hatte mal ein Problem mit leeren Tags an manchen Stellen. Das müsste aber schon seit einer Weile behoben sein. Benutzt Du das letzte Binärpaket, das zum Download angeboten wurde? Wenn ja, dann schnapp Dir mal Subversion und aktualisiere auf die neueste Version. Dann müsste das Problem gegessen sein.

Zum Rest kann ich nichts sagen. Man kann bei Skelett-Modellen auch beim Modellieren viel falsch machen, das habe ich bisher immer den Grafikern überlassen.

[Chromanoid]

btw DAE Loader: im dae loader steht, dass keine leeren texture channel unterstützt werden. ich bin auf einige modelle gestoßen, die leere channel haben bzw. wo der erste textur channel 1 und nicht 0 war... Ich hab das per Hand in den DAEs geändert, aber wenn du dich irgendwann nochmal dran setzt, wäre das vielleicht auch etwas, was man ändern könnte :).

@blender: also zumindest die neuste beta scheint auch irgendwie ein nicht sehr übliches export verhalten zu haben. ich konnte mit anderen 3d tools fast nie was mit blender exportiertes importieren. papervision3d hatte erstaunlicher weise bei meinen versuchen bisher die beste import quote :)

[Schrompf]

Dann schicke mir das File mal bitte (in der rohen, nicht von Dir bearbeiteten Version). Mal schauen, ob ich da was machen kann.

[Eisflamme]

Alles klar, hab Dir ne PN geschickt! Allerdings habe ich noch einen neuen DAE-Exporter geladen, damit exportiert und nach Beseitigung der zwei angesprochenen Probleme in der Datei sagt er "Unable to resolve library reference: cube-skin-joints": http://mihahome.de/elypson/Downloads/othu0000022.dae

Hier der Link zum Exporter: http://colladablender.illusoft.com/cms/ (Version 3.159)

Interessant ist auch der Animation Support: http://colladablender.illusoft.com/cms/ ... ory/20/30/

Testen tu ich btw. mit dem neusten AssimpViewer, unter About steht aber keine Version oder so.

Ich weiß ja nicht, was es für Arten von Animationen gibt, ich dachte ein paar Keyframes mit Matrizen wären umsetzbar, aber anscheinend ist das alles komplizierter. :)

----

Ich weiß nicht, ob der Exporter das kann. Wenn Du sagst, Du hast mit .x gearbeitet und Animationen funktionieren da anständig, dann wäre ich damit natürlich auch zufrieden. Ich will nur endlich Animationen einbauen, egal wie. ;) Hast du denn vll. einen Link zu deinem .x-Exporter? Der mitgelieferte hat wie gesagt Textur-Exportier-Probleme, scheint es.

[Schrompf]

Ich schau mir die Collada-Files mal an. Wird mal wieder Zeit für eine dicke Debug Session. Mäh :-(

Ich habe Blender nie benutzt. Ich kenne nur ein paar Testfiles, für die ich Workarounds in den XFile-Loader einbauen musste, damit sie korrekt lesbar sind. Daher bin ich recht sicher, dass dieser Pfad funktioniert, aber ich habe keine Ahnung von den involvierten Exportern.

[Eisflamme]

Cool, dass Du das machst, danke! ;)

Hm... so langsam hab ich das Gefühl, die schnellste Variante an ein animiertes Modell zu kommen, ist selbst Exporter nebst Importer zu schreiben, obwohl ich von Animationen bisher null Ahnung hab. ;)

Dann braucht es aber ne Riesenzeit, bis ich endlich Mal was laden kann. Ist es so schwierig, ein kleines 3D-Spielchen zu machen, wenn man nicht gerade ne fremde Engine nutzt? Das Problem muss doch uralt sein, in nem 3D Person Shooter oder so nutzt doch kein Mensch fixe Modelle und auch sonst gibt es imo einen Haufen 3D-Spiele, wo man animierte Modelle braucht. Aber was die Dateien angeht hab ich das Gefühl, dem Problem hat sich bisher kaum jemand gestellt. Wo ist mein Denkfehler? Wenn ich weiß, was ich tun kann, tu ich's ja gern, aber ich will so langsam Mal durchstarten. ;) Also das ist keine Kritik an Assimp, ich leite nur gerade das Topic um. Falls wer Ideen hat... :)

[Schrompf]

Ich glaube, das ist nur ein Problem von Anim-Neulingen. Wir benutzen aktuell .x und .dae (und .3ds / .obj in diversen Ausnahmefällen), je nachdem, was halt funktioniert und wo wir am besten die Daten rausbekommen. Die Assimp-Seite ist inzwischen recht verlässlich, die Exporterseite ist seeehr divers. Ich weiß aber inzwischen auch, dass ich mich auf die Importseite, also die Engine, verlassen kann. Wenn Du gerade versuchst, Bone Animations in Deine Engine einzubauen, dann musst Du alle drei Seiten - Export, Import, Verwendung - gleichzeitig debuggen. Das ist eine mächtige Aufgabe, weil Du ja selbst noch gar nicht weiß, wie die Daten "richtig" aussehen müssten.

[Eisflamme]

Hi,

Genau. Vielleicht versuche ich dann Mal .x zum Laufen zu bringen und ignoriere die Texturen halt erstmal. Und wenn's klappt, kann ich das ja immer noch lokal bereinigen. Hm... hast Du vielleicht irgendein funktionierendes .x oder .dae-Modell für mich, was ein paar schlichte Animationen hat oder eine Seite, wo es solche Modelle gibt? Dann könnte ich das schon Mal in meinem Programm einbasteln, das wäre bereits ein guter Schritt nach vorne + ich könnte eine valide Datei analysieren. :)

Auf den öffentlichen Seiten, wo es freie Modelle gibt, kriege ich dann halt nur so Modelle, die sich nicht importieren lassen...

Viele Grüße und danke so weit!

[Schrompf]

Auf den öffentlichen Seiten, wo es freie Modelle gibt, kriege ich dann halt nur so Modelle, die sich nicht importieren lassen...

Das klingt für mich mehr nach ner Ausrede. Sorry. Wenn Du tatsächlich ein Modell hast, das in AssimpView faul oder gar nicht angezeigt wird, schicke mir bitte das File oder einen Link dazu.

Bzgl Testdateien: im Assimp-Verzeichnis kommen unter /test/models auch all unsere Testmodelle mit. Darunter unser tapferes Splitterwelten-Wuson mit einer Laufanimation oder der Zweg mit seinen reichlich mathematisch dreinschauenden Anims. Alternativ findest Du im DirectX-SDK die gute alte Tiny.

[Eisflamme]

Ausrede ist ein etwas böse klingendes Wort. Ich habe mich stundenlang online nach animierten Modellen umgeschaut. Und wenn ich welche hatte, waren die meistens im 3DS-Format, wo ich ja noch nicht wusste, dass es nicht funktioniert (allerdings mea culpa, dass ich die Doku halt nicht gelesen hatte ;)). Mag sein, dass ich .x und .dae nicht oft gefunden habe, bei freien Modellen findet man halt auch einfach häufiger .3ds.

Wie auch immer, gerne schicke ich fehlerhafte Modelle vorbei, falls ich welche finde. Und die Modelle von Assimp sind natürlich perfekt!

Hm, jetzt habe ich wieder ein neues Problem. Ich sitze gerade an meinem neuen Alienware 64 Bit Win 7 mit DX11 (laut dxdiag). Wenn ich versuche die vorkompilierte (1.1) AssimpViewer.exe zu starten, meldet er "Failed to initialize DirectX9 (2)". Das zeigt er auch im Kompatibilitätsmodus zu Vista an bzw. bei der x86-Version im normalen und Kompatibilitätsmodus zu XP. Ich lade mir Mal das Assimp SDK und versuche selbst zu kompilieren, vll. ändert das irgendwas.

[Aramis]

Dir fehlt evtl. die benoetigte D3DX-DLL. Das aktuelle DX Redistributable sollte helfen. Selber-Kompilieren auch.

[Eisflamme]

Jep, das half, vielen Dank. :)

[Schrompf]

Ja, ich weiß: das Suchen in freien Quellen im Internet ist mehr als mühsam... da findet man auch viel Mist. Auch das Exportieren will gelernt sein und braucht ein paar Einstellungen - wenn der orginale Autor sich nie die Mühe gemacht hat, vor dem Hochladen seine exportierten Dateien mal testzuladen, hat man verloren.

Und ja, die Modelle aus der Assimp-Testsammlung gehen natürlich alle :-) Aramis hat da sogar ein schlaues Skript geschrieben, das die alle vollautomatisiert durchackert und gegen das erwartete Ergebnis vergleicht. Sehr nützlich, sowas.

[Schrompf]

So, Collada-Bugs zum Dritten, und zum Vierten: ich habe die beiden Files untersucht, die Eisflamme mir geschickt hatte. Dazu im Detail:

a) Man0.7.dae aus othu0000021.rar
Da war in der Tat ein hässlicher Bug im XML-Ladecode drin. Bzw. eigentlich ein Konzeptproblem in irrxml - wie geht man in einem SAX-Parser mit so einem Konstrukt um:

Code: Alles auswählen

<init_from></init_from>

Es ist kein Leer-Element <init_from/>, also muss man den Inhalt lesen. Man merkt aber erst, wenn man das schließende Tag schon gelesen hat, dass da gar kein Inhalt kommt. Zu spät, der schließende Tag wurde bereits gefressen. Wer auch immer danach als nächstes Read() aufruft, bekommt bereits Unsinn. Und ein Zurückpacken des Tokens, was die klassische Lösung für Parser wäre, bietet irrxml nicht an. Hm.

Ich habe jedenfalls einen kleinen Workaround eingebaut, der aber natürlich nur in Collada-Files funktioniert. Danke an Eisflamme für den Fehlerbericht!

Das File ist aber auch darüberhinaus noch ungültig: es enthält ein Rudel Anim-Channels, die jeweils Transformationen in der Node-Hierarchie adressieren, die es gar nicht gibt. Mir scheint, der Exporter produziert Mist.

b) othu0000022.xml
Hierfür gilt dasselbe: das File ist ungültig nach Collada-Spec. Verschiedene Accessors im Skeleton Controller verweisen auf Datenfelder, die es nicht gibt. Die richtigen Datenfelder heißen stattdessen subtil anders - z.B. "Cube-skin-joints-array" anstatt "Cube-skin-joints". Ich glaube nicht, dass das jemand manuell geändert hat, daher lautet mein vernichtend finsteres Urteil: der Exporter macht Grütze.

Für die Sachen kann ich nichtmal einen Workaround einbauen... die sind einfach nur falsch. Sorry, aber Du musst einen anderen Weg finden, animierte Modelle aus Blender rauszukriegen.

[Eisflamme]

Hi,

Kein Problem. Ich werde mit .x experimentieren, denn eine falsche Texturzuordnung kann ich wohl hinkriegen. Auch praktisch ist, dass ich gesehen habe, dass assimp anbietet, Texturen aus ner Datei herauszuladen und extern zu speichern, sehr gut. :)

Viele Grüße

[Eisflamme]

Jetzt habe ich einen .x-Exporter gefunden, der zumindest nicht zusammen bricht. Er sieht auch professioneller aus und funktioniert nach eigener Angabe mit den neusten Blenderversionen. Assimp hat beim Importieren aber Probleme, da es ein ; erwartet in Zeile 36 bzw. zwei. Ausschnitt:

Code: Alles auswählen

    FrameTransformMatrix {
      1.000000,0.000000,0.000000,0.000000,
      0.000000,-0.000000,1.000000,0.000000,
      0.000000,-1.000000,-0.000000,0.000000,
      -0.000000,0.092654,0.284519,1.000000, // es geht aber eher hier drum
    } // Zeile 36

Das gibt der Exporter aus, aber Assimp mag das nicht.

Code: Alles auswählen

    FrameTransformMatrix {
      1.000000,0.000000,0.000000,0.000000,
      0.000000,-0.000000,1.000000,0.000000,
      0.000000,-1.000000,-0.000000,0.000000,
      -0.000000,0.092654,0.284519,1.000000;; // doppeltes Semikolon klappt
    }

Das akzeptiert Assimp. Ist das zu wenig Toleranz seitens Assimp oder ist das so nicht ok? Ich beginne Mal damit den Exporter umzuschreiben, aber wenn das eigentlich kein Problem sein sollte, wäre es natürlich praktisch, wenn Assimp da keine Probleme hat. :)

Edit:
Okay, jetzt habe ich herausgefunden, dass bei dem AnimationKey-Tag Assimp drei Semikolons erwartet, während der Exporter halt nur zwei ausspuckt. Und bei den übrigen Zeilen ist ;;, statt ;; nötig Also:

Code: Alles auswählen

    AnimationKey { //Rotation
      0;
      3;
      0;4;    -0.561604,-0.089752,0.012046,-0.822435;; // hier hätte Assimp gerne noch ein , danach
      13;4;   -0.566666,-0.006849,-0.033871,-0.823223;; // ibid.
      27;4;   -0.561604,-0.089752,0.012046,-0.822435;; // hier hätte Assimp gerne ein ; mehr (Edit2: ein , geht auch!)
    }

Danke!

Edit 3:
Also ich konnte ein animiertes .blend-Modell jetzt erfolgreich mit Blender 2.49 unter Verwendung von Python 2.6 exportieren, sodass ich es mit AssimpView laden und animieren kann. Ich habe einfach ein Skript bissel abgeändert und et voila (mit Akzent auf irgendeinem Buchstaben). Wenn das jemand gerne haben möchte, kann er mir schreiben. Das Copyright liegt nicht bei mir, ich habe es nur geändert. Oder meint ihr, keiner sagt was, wenn ich das hochlade? Jedenfalls ist die Originalquelle die folgende: http://forum.thegamecreators.com/?m=for ... 166987&p=0

Edit 4:
Und jetzt hab ich ein .x-Modell (von .blend exportiert), was bei AssimpView zu folgender Fehlermeldung führt:
" Error, T5724: Validation failed: aiNodeAnim::mPositionKeys[0].mTime (4294967296.00000) is larger than aiAnimation::mDuration (which is 159.00000) "
In der Datei selbst hab ich keine Zeitangabe gefunden, irgendwo scheint ein Überlauf statt gefunden zu haben. Hier ist der Link: http://mihahome.de/elypson/Downloads/othu0000023.x

[Schrompf]

Du ahnst gar nicht, wieviel Toleranz bereits im XFile-Loader drinsteckt. Gerade, was Blender angeht, sind wir da echt Kummer gewohnt. Das File, was Du da hochgeladen hast, ist da leider auch keine Ausnahme. Es listet für manche Nodes den Anim-Keyframe für Zeit "5" dreimal hintereinander, einige der letzten Anim-Sequenzen starten bei "-1", und die Trennzeichen setzt er anscheinend auch wahlfrei. Ich sollte bei Gelegenheit den XFile-Loader umschreiben, dass er alle Trennzeichen einfach ignoriert. Ich weiß nicht, ob XFiles danach noch eindeutig parsable sind, aber einen Versuch wär's wert.

Drecks-Blender. Aus mir unerfindlichen Gründen sind alle Files, die aus Blender so rauskommen, mit die schlimmsten ihrer Gattung. Egal, welches Format.

[Eisflamme]

Oje, da hört man viel Frust raus. ;) Nagut, ich werde dann einfach Mal schauen, dass ich zusehe, das Format zu verstehen und dann lässt sich das .x ja mit wenig Aufwand ins richtige Format bringen. :)