YAAQ - Yet another assimp question

[Top-OR]

Hallo ASSIMPler!

Ich habe mal wieder ne Frage zu Assimp.
Mein letztes Problem (Alter Compiler + Seltsame Preprozessor-Effekte) habe ich lösen können. Zum Teil benutze ich nun die Binaries bzw. benutze auf anderen Rechnern nun einen halbwegs aktuellen Compiler.

Zur Zeit spiele ich mit IrrEdit/CopperCube 5 rum und habe folgende Probleme/Effekte:

A) Erstes Problem: Assimp Library (precompiled binary) lädt "irr"-Szene nicht, Assimp-Viewer schon:
Ich habe eine einfache Szene genbaut, welche welche um Grunde nur 6 Meshes (Cubes) enhält. Nun exportiere ich das ganze aus dem Irrlicht-Editor mit als Irrlicht-Szene.
Das Ergebnis ist ein Haupt-File (XML: *.irr), welches im Grunde auf die 6 Meshes verweist, welche in einem Unterverzeichnis ebenfalls als XML-Files (*.irrmesh) abgelegt sind.

Versuche ich das ganze mit meinem eigenen Tool zu laden, welches den Assimp-Importer benutzt, bekomme ich eine Szene geladen, welche "HasMeshes() == false" zurückgibt.
Lade ich die selbe(!) Datei mit dem Assimp-Viewer, läd er das ganze Konstrukt und ich sehe wieder meine Klötzchen.

B) Hilflösung zu A): Zusätzlicher Umweg über OBJ-Export im Assimp-Viewer:
Ich kann nun, wenn ich das Ganze im Assimp-Viewer sehe, als OBJ exportieren. DANACH kann ich das OBJ mit meinem eigenen, Assimp-Lib basierten Tool nun auch lesen und in meine Engine laden.
Ich muss aber immer den manuellen Konvertierungsschritt gehen, was ziemlich nervt, zumal es 2x über Assimp geht, wobei ja einmal reichen sollte.
Hier nochmal die Pipeline: 1) Coppercube/IrrEdit Szene -> 2) export als *.IRR-Szene -> 3) laden im Assimp Viewer -> 4) export aus Assimp-Viewer als *.OBJ -> 5) laden im eigenen Assimp-basierten Tool -> 6) konvertierung ins eigene Format -> 7) laden in die eigene Engine

Nun meine erste Frage/Problem:
Ich würde mir gerne Schritt 3 und 4 sparen, zumal Schritt 5 ja auch Assimp ist. :-/ Was kann ich tun? Fehlt in meinem eigenen Loader ein Parameter für den Assimp-Importer? Es meldet mir halt eben sang und klanglos ein HasMeshes() -> false zurück.

C) Zweites Problem - Verkehrte Welt:
Nun gibts an der aktuellen Verfahrensweise noch ein weiteres Problem:
Wenn ich die Szene im Assimp-Viewer ansehe, sehe ich, dass er mit der Positionierung bzw. Rotation eines Cubes nicht klar kommt. Man sieht im Bild (Szene im Coppercube), das die "Rampe" von der Mitte des Bodens hoch zur Seitlichen Wand geht. Im Assimp ist es eher so, dass sie Rampe vom Rand unten in die Mitte des Raums hochsteigt. Alle anderen Relationen sind davon aber nicht betroffen. Sowohl der Boden bleibt "unten" und auch die anderen Wände bleiben, wo sie sind. Ich habe bereits versucht, nach dem Laden durch Assimp (mit "OBJ-Umweg") Koordinaten an verschiednene Achsen zu spiegeln, um den Effekt auszugleiche. Ohne Erfolg. Ich denke, dass da eher eine Rotation falsch interpretiert wird, oder? Die Rampe ist das einzige Objekt, was eine Rotation hat. Alle anderen Objekte sind haben ihre entsprechende Form und sind lediglich Axis aligned angeordnet.

Wenns ichs dann vom OBJ im mein Format konvertiere, wirds dann auch so falsch, wie im Assimp-Viewer dargestellt, in der eigenen Engine angezeigt.

Mit Seitenverkehrtkeit kann ich gut leben, aber nicht, wenn er Rotationen im Verhätnis zu anderen Entities in der Szene so falsch schluckt und Objekte falsch dreht bzw. platziert.

Anbei noch ein paar Bilder, um das besser zu illustrieren. Man beachte die "gelbe Rampe"..
Kann ich da was machen, um A) das Model direkt mit der Assimp-Lib zu laden und B) die Rotation richtig gefressen wird? Hat jemand ne Idee?

Besten Danke schonmal für Hinweise,
Top-OR

PS: Ich kann die Irrlicht-Szene-Datei(en) auch gerne zur "Ausprobieren" rumschicken bzw. attachen. Sagt bescheid, wenn das sinnvoll erscheinen sollte.

Edit: habe mal ein paar Typos korrigiert.

[Top-OR]

Weitere Info zum Rotationsproblem.

In dem Szene-Meta-File, welches die Meshes referenziert (das *.IrrMesh), gibts einen Eintrag beim Einbinden des besagten Rampen-Meshes mit:

Code: Alles auswählen

<vector3d name="Rotation" value="0.0, 0.0, 35.0" />

Also eine Rotation um 35° um Z.
Wenn ich diese Rotation umkehre, indem ich die 35° von 360°/0° abziehe (also 360°-35° = 325°), also sowas ins XML manuell reineditiere ...

Code: Alles auswählen

<vector3d name="Rotation" value="0.0, 0.0, 325.0" />

... dann stimmt das Weltbild wieder und die Rampe sitzt korrekt.

Gibts da nen Parameter für den Assimp-Loader, mit dem man das kompensieren könnte oder ist das ein Bug, den ich auch jetzt so nicht weg bekomme?
Ich will jetzt nicht jedes Mesh auch noch manuell intakt-editieren müssen...

[Schrompf]

Zu A): ich vermute, der Assimp Viewer saugt einfach ne andere Binary der Assimp-Lib an als Du. Einer der vielen Freuden, die man hat, wenn man DLLs nimmt. Meine Empfehlung lautet daher wie seit Anbeginn der Zeiten: nimm Assimp in Dein Projekt auf und bau es als statische Linkerlib mit wie alle anderen Libs auch. Diese Lösung ist allerdings zugegebenermaßen kompliziert geworden, seit der Mist über CMake läuft und noch irgendne dämliche Include-Datei mit ner Versionsnummer erzeugt wird. Was vermutlich notwendig war, um in Linux-Distris aufgenommen zu werden, so dass ich nichtmal jemanden für Schuld erklären kann. Mein Weltbild verträgt keine komplexen Zusammenhänge.

zu C) Meine spontane Vermutung wäre ein Bug im Irrlicht-Loader, weil Du nach meinem Wissen der erste bist, der den benutzt. Bau mal eine Testszene, die nicht rotationssymmetrisch ist, um herauszufinden, ob es wirklich die Auslegung der Rotationsdaten ist, die das Problem ist.

[Top-OR]

Moin Schrompf,

danke für den Hinweis. Ich werde heute Abend mal versuchen, sicherzustellen, dass immer die korrekte/selbe DLL geladen wird.

Dann werde ich mal eine Szene bauen, der man besser ansieht, wo was hingeladen wird (und die nicht rotationssymetrisch ist).

Ich habe in der Vergangenheit bereits festgestellt, dass Assimp (oder Assimp im Zusammenspiel mit einer anderen Komponente in der Toolchain bzw. bei manchen Formaten) dazu neigt, Modelle (bzw. Szenen) gespiegelt darzustellen (im Vergleich zu den Editoren, aus denen sie rausgepurzelt sind). Bisher hats mich aber (noch) nicht gestört, ob "der Oger die Keule nun links oder rechts in der Hand hat", solange "der Kopf oben" war.

Wie gesagt, ich melde mich mit einer aussagekräftigeren Szene heute Abend (oder morgen) wieder.

Danke soweit.

[Schrompf]

Gespiegelte Szenen wären aber ein ernstzunehmender Bug. Bist Du sicher, dass Du die richtigen Konvertierungsflags benutzt, um am Ende eine linkshändige oder rechtshändige Szene zu bekommen, die zu Deinem Koordinatensystem passt?

[Top-OR]

Gespiegelte Szenen wären aber ein ernstzunehmender Bug. Bist Du sicher, dass Du die richtigen Konvertierungsflags benutzt, um am Ende eine linkshändige oder rechtshändige Szene zu bekommen, die zu Deinem Koordinatensystem passt?

Ich werde mal genauer beobachten, wie er sich bei bestimmtem Models verhält:
Ich habe einen Sack von gekauften Bone-Models und werde mal verbindlich nachvollziehen,wann was wo wie mit welchen Assimp-Flags rauskommt und aussieht.

In meiner Toolchain gibts auch noch genug Logik, die da vielleicht was verursachen könnte und die "Schuld" sein könnte. Ich habe eh ein abgefahrenes KoordinatenSystem (X: west<->ost, Y: unten<->oben, Z:nord<->süd) und muss oft zumindest drehen.

Bisher wars aber noch nicht genug im meinem Focus, um da genau nachzuforschen. Ich schaue es mir mal an - sowohl den Rampe-steht-falsch-Effekt, als auch den Oger-ist-plötzlich-Linkshänder-Effekt.

Ist nur son Bauchgefühl, was ich demnächst mal untersuchen werde. Will da jetzt keinen Staub aufwirbeln... ;-)

Beim Rampen-Effekt sehe ich aber auch schon den "Fehler", bevor meine Logik auch noch alles kaputt-dreht und -spiegelt und das Model überhaupt anfasst ... deswegen vermute ich hier auch nen Assimp-Effekt.

"Isch gucke" ...

[Top-OR]

Moin Schrompf,

ich habe nachgeforscht.

1) Gut: Du hattest Recht, mein Converter-Tool und mein Assimp-Viewer ziehen wirklich verschiedene DLLs an bzw. sind sogar verschiedene ASSIMP-Versionen. Daher das unterschiedliche Verhalten. Dieses Mysterium ist also gelöst.

2) Schlecht: Der Viewer, in dem es, wenn auch etwas verkehrt, ging, ist Assimp Version 3.0.
Meinem Tool ist Assimp-Lib 3.1.1. Wenn ich den 3.1.1. precompiled Viewer benutze, zeigt er das Gleiche verhalten, wie mein Converter: Es werden keine Meshes mehr angezeigt. Mimimimi. Assimp hat sich also wieder etwas zurückentwickelt... evolutionär gesprochen.

3) Verbesserungswürdig (??):
Ich habe eine Szene erstellt, die die nicht Rotationssysmetrisch ist. Es handelt sich um vier Pfeiler mit unterschiedlicher Größe, die im Viereck angeordnet sind. Auch hier habe ich wieder einen rotierten Cubus, der im Grunde auf der X-Achse vom kleinen Pfeiler zum großen hoch geht.

Vergleiche hierzu die Abbildung vom Coppercube. Das Coppercube-Koodinatensystem ist im Screenshot auch angedeutet. Roter Pfeil = PlusX, Grüner Pfeil = PlusY und Blauer Pfeil = PlusZ. (Es entspricht im Grunde dem Koordiatensystem meiner Engine, nur dass meine "Z-Achse" entgegengesetzt verläuft. Aber das ist an der Stelle auch nocht nicht wichtig.)

Im Screenshot vom Assimp-Viewer 3.1.1 sehen Sie, dass Sie nichts sehen.

Im Screenshot vom Assimp-Viewer 3.0.0 sieht man, dass die Szene im Grunde an Z gespiegelt ist.
Man sieht aber auch schön, dass die kleine Balken in der Mitte (die Nicht-Säule) "im falschen Maß rotiert ist, wenn man die Position der anderen Elemente akzeptieren möchte" bzw. "der Rest der Elemente falsch platziert ist, wenn man die Rotation akzeptieren möchte" (wie auch immer du das sehen möchtest).

Auf jeden Fall stimmt die relative Anordnung der Klötzchen, sobald Rotationen (bzw. eine solche Rotation) ins Spiel kommen, nicht mehr.

Die Rotation des Mini-Klötzchens ins übrigens 320°um Z, also kein "komischer negativer Wert", der die Logik zu sehr durcheinanderbringen sollte.