[Assimp] Ogre 3D

[Jonathan]

Animationen werden ziemlich lustig. Naja, vom groben drübergucken sehen die in Ogre und Assimp relativ ähnlich aus, aber wenn das einfach auslesen und wieder in Assimp einfügen alles sein sollte, wäre ich ein wenig erstaunt.
Naja, ich versuch es schnell hinter mich zu bringen.

[Jonathan]

Ha, die Sache mit den Materialien wird doch noch lustig. Bisher kannte ich Materialien wie das hier:
http://www.pasteall.org/7595
Aber es geht auch so:
http://www.pasteall.org/7596
tja^^

[Jonathan]

Es gibt offensichtlich die Möglichkeit custom materials zu exportieren die man dann ziemlich einfach auslesen kann. Die Sache ist aber dass man nicht an sehr viele sinnvolle Informationen herankommt und ich habe keine Ahnung ob diese Materialien dann Blender Exporter spezifisch sind.
Insgesamt halte ich das aber für eine gute Lösung. Man muss halt beim modellieren in Blender ein paar einfache Dinge beachten, dann funktioniert das ganze schon. Desweiteren kann man sich eben alle Texturen hohlen, da diese in Blender (nicht im Dateisystem) eh relativ feste Namen haben müssen, kann man sich daraus auch überlegen, ob es jetzt eine Normalmap oder eine Colormap ist. Darüberhinaus gibt es halt noch so tolle Infos wie Materialfarbe, Glanz und so. Man kann auch quasi beliebige Eigenschaften in Blender definieren und exportieren, das aber dann eben in einem relativ allgemeinen Dialog, also nicht ganz so benutzerfreundlich.
Aber hey, wie viele Materialinformationen benötigt man wirklich in einem 3D Spiel? Das andere ist halt die Frage ob andere Exporter ähnliche Custom-Materials erzeugen, die hab ich aber nicht und die dazugehörigen Programme erst recht nicht.

Also, ein paar Einschränkungen, die mir persönlich in der Praxis aber keine Probleme machen werden. Diese komplexen Materialien sind halt schwer zu lesen und so auch gar nicht in Assimp abbildbar, also wird man eh Kompromisse eingehen müssen, und dieser ist denke ich ein guter.

[Schrompf]

Ja, das passt. Die meisten Engines werden sowieso eigene Materialstrukturen haben und nur einen kleinen Teil der Assimp-Angaben umsetzen können. Von daher: wurscht. Hauptsache, es liest zuverlässig, und die grundlegenden Einträge wie Diffuse und Normal Map sind da.

[Jonathan]

Wie man sieht, lese ich jetzt auch die Skelettdatei aus. Gut, das gerenderte Skelett sieht wirklich mal anders aus, als noch in Blender, aber da sind ja auch noch ein paar IK Knochen im Spiel, woher allerdings der Strich zwischen den Beinen kommt, weiß ich nicht so genau.
Wie dem auch sei, meiner Meinung nach sieht das sehr richtig aus, da ja das Skelett recht gut in den Körper passt. Sicher sein kann ich mir zwar wohl erst, wenn auch Animationen abgespielt werden, aber dennoch seh ich das ganz optimistisch.

[klickverbot]

Hallo Jonathan,

im Dokumentationskommentar zu AI_CONFIG_IMPORT_OGRE_MATERIAL_FILE sollten wohl noch Typ und Standardwert angegeben sein (und das Englisch könnte – nicht böse gemeint – auch noch den ein oder anderen Blick vertragen). Da ich fürs erste nicht ungefragt in deinem Code herumpfuschen will:

Code: Alles auswählen

--- a/include/aiConfig.h
+++ b/include/aiConfig.h
@@ -567,6 +567,7 @@ enum aiComponent
  * Ogre Mehs contain only the MaterialName, not the MaterialFile. If there
  * is no material file with the same name as the material, Ogre Importer will
  * try to load this file and search the material in it.
+ * Property type: string. Default value: "Scene.material".
  */
 #define AI_CONFIG_IMPORT_OGRE_MATERIAL_FILE "IMPORT_OGRE_MATERIAL_FILE"

[Jonathan]

Ich arbeite immer noch an den Animationen und weiß so langsam nicht mehr weiter. Ich lese ja einfach nur die Daten und packe sie ins Assimp Format, nach ein paar Wochen immer die selben Zeilen lesen nervt das ein wenig. Vor allen Dingen da ich nicht mal genau weiß, was falsch ist, es ist ja einfach ein Rechenfehler, den man mit keinem Debugger dieser Welt finden kann...

Aber ich bin schonmal so weit:

Wie man sieht hat man den Dino und sein Skelett (beides nur halbseitig, aber das ist ja ok), und beide passen im Prinzip aufeinander. Allerdings steht das Skelett auf dem Kopf, es ist entlang der Hochachse gespiegelt oder so (evtl. auch komisch gedreht). Desweiteren ist der Dino nicht in der Mitte, obwohl er das in Blender ist. Shaut man sich das Skelett an, sieht man die Verbindung vom Ursprung zum rootbone des Dinos. Wäre das Skelett richtig herum, würde es von da also wieder nach unten gehen, und das Mesh müsste auch schön in der Mitte sein.


Interessant wird es, wenn man die Animation abspielt. Wie man vielleicht am Skelett erkennen kann, soll der Dino sich aufstellen. Da das Skelett aber am Kopf steht, geht er eben nach unten, folgt also den Bones. Außerdem macht das Maul etwas komisches, was ich anhand des Skeletts nicht nachvollziehen kann.

Das Problem ist jetzt: Die Node Transformationen für das Skelett auszurechnen ist eigentlich simpel, ich kriege von Ogre eine Position und eine Rotation die ich einfach so zu einer Matrix kombiniere und die dann als Transformation benutze. Wirklich falsch kann es ja auch nicht sein, das Skelett passt ja auf den Dino, ist aber halt an genau einer Stelle gedreht. (Wäre es komplett gespiegelt, müsste ja eigentlich die Urprung-zu-RootBone Verbindung auch in die andere Richtung gehen, und das Modell wäre wieder im Ursprung nur halt gespiegelt).

Naja, vielleicht hat ja einer einen Tipp, wo ich suchen sollte. Der Code ist in der aktuellen Version auch im SVN, falls da jemand gucken will.

[Aramis]

Naja, wir haben uns ja schon mehrfach drueber unterhalten, die ultimativen Tipps hab ich nicht mehr.

Nur einer: sowohl beim MD5 als auch beim MS3D Loader bestand waehrend der Reifungsphase *exakt* das gleiche Problem. Meshes in Ordnung, Hierarchie und rote Linien im Viewer auch, bloss passt beides nicht zusammen. Gespiegelt, oder rotiert. Guck bitte mal in die letzten Revisionen des MS3D Loaders, ich vermute ich hab den Fix im Commitlog vermerkt. Vermutlich ist es die gleiche Stelle gewesen an der bei dir auch der Fehlerquelle liegt.

Vielleicht hat Thomas als Author der beiden anderen animierten Loader (x und Collada) noch ein paar Ideen.

Gruß, Alex

[Jonathan]

Naja, ultimativ müssen die TIpps ja nicht sein, ich hab auch mit normalen Hinweisen schon eine Menge Fehler gefunden :)

Allerdings kann ich mit den MS3D Änderungen wenig anfangen. So wie ich das sehe, hast du einfach einmal eine inverse Matrix benutzt und einmal versucht, einen Quaternionbug zu umgehen. Das kann ich aber nicht übernehmen, da ich nie Eulerwinkel habe sondern direkt die 4 Werte für die Quaternion in den Dateien habe.
Wenn ich davon zum Beispiel einfach mal irgendwelche Werte negiere, ist direkt das ganze Skelett kaputt, und eigentlich muss es ja nur an ungefähr eine Stelle geändert werden (andere Testmodelle sehen noch ein wenig anders aus).
Hast du da einfach rumprobiert, oder kannst du sagen, was genau in MS3D den Fehler verursacht hat? Wenn ich die Ursache statt die Lösung kenne, könnte ich das vielleicht besser übertragen.

[Jonathan]

Ok, ich bin einen Schritt weiter:
Das Skelett stimmt so schon, aber es ist an der falschen Position und rotiert.

Da man im Assimp Viewer nicht scrollen kann (oder kann man?) gehe ich davon aus, dass die Mitte immer der Ursprung ist. Die Füße des Modells sind auch im Ursprung. Der root-Knochen des Skeletts ist die Hüfte, die Transformationsmatrix ist

Code: Alles auswählen

-1.000000 -0.000000 -0.000003  0.000000
 0.000000  0.999992 -0.003489  94.797600
 0.000003 -0.003489 -0.999994  0.427347
 0.000000  0.000000  0.000000  1.000000

Die Translation um 95 macht Sinn, wenn das cm sind, könnte da ungefähr die Hüfte sein. Jetzt sieht man am Bild ja auch, dass es 3 Beine gibt, das in der Mitte ist dann halt die Verbindung vom Ursprung zum ersten Knochen. Aber wieso fängt diese Linie soweit unten an? Also, wenn der erste Knochen die oben angegebene Transformation hat, sollte dann nicht die Linie auch im Ursprung (Bildmitte) starten und korrekt nach oben gehen?
Da das Skelett ja zu dem Modell passt, gehe ich davon aus, das soweit alles stimmt, bis auf die erste Transformation. Hat jemand eine Idee, woran das liegen könnte?