Assimp - Brainstorming zum Release

[klickverbot]

Ja, damit, dass das Symbol aus irgendeinem Grund mit C++-Name-Mangling exportiert wird, und zwar sowohl unter Windows/MSVC als auch unter Linux/GCC, wenn ich den letzten Stand der Dinge richtig im Kopf habe. Diese Tatsache ist aus meiner Sicht bemerkenswert, denn ein Compiler-Fehler als Auslöser wird dadurch deutlich unwahrscheinlicher.

Ursprünglich bin ich darauf gestoßen, als ich die D-Bindings geschrieben habe. Dort hole ich mir die Adressen der Funktionen der C-API zur Laufzeit, und so ist es nicht weiter verwunderlich, dass das falsch benannte Symbol einen Fehler verursacht. Kürzlich habe ich es aber geschafft, auch bei »normaler« Verwendung, also dem Übergeben der Library beim Linken eines C++-Programms, einen diesbezüglichen Fehler zu erzeugen – der Versuch, das gelinkte Programm auszuführen, erzeugte eine »unresolved symbol«-Fehlermeldung.

Die genauen Umstände habe ich leider nicht mehr im Kopf, aber ich würde es mir so erklären, dass der Compiler beim Verarbeiten der Assimp-Includes der Meinung war, das Symbol würde mit C-Linkage exportiert – was es ja eigentlich auch sollte, aber aus bisher ungeklärten Gründen wird es eben dem C++-Name-Mangling unterzogen.

Edit: Wieso befindet sich pstdint.h eigentlich in include/Compiler und nicht in code? Wenn ich nichts übersehen habe, wird die Datei ja nur intern gebraucht, in den öffentlichen Headern findet sich kein Verweis darauf.

Edit 3: Das Gleiche gilt auch für BoostWorkaround. Oder ist include gar nicht als »öffentliches« Include-Verzeichnis konzipiert?

Edit 2: Was ist jetzt eigentlich die »offizielle« Schreibweise? »Assimp«? »ASSIMP« (wird in der Doxygen-Dokumentation verwendet)? Ist »AssetImporter« auch eine mögliche Form (ist derzeit der CMake-Projektname)? Meiner Meinung nach wäre es gerade vor dem ersten Release nett, sich auf eine »Marke« festzulegen, gerade auch im Hinblick auf Release-Verlautbarungen und deb/rpm/…-Pakete.

[klickverbot]

CMake unterstützt »make install« recht unkompliziert, hier ein erster Patch. Könnte jemand, der CMake unter Windows nutzt, bitte ausprobieren, ob der VC++-Generator noch immer sinnvolle Ergebnisse liefert?

Ich habe übrigens gerade bemerkt, dass es zumindest ein Team gibt, das tatsächlich Assimp mit den D-Bindings benutzt – bei der derzeitigen Größe der D-Community fast schon ein Wunder. ;)

[jgl]

@Assimp
Kann das auch Animationen "darstellen"?
Hat da jemand gute Links/Infos?

LG J...

[klickverbot]

@jgl:
Ganz generell:Bone-Animationen werden unterstützt. Die importierten Animationsdaten zu verwerten, bleibt natürlich dir selbst überlassen.

[Aramis]

Zum `aiGetMaterialProperty`-Kriegsschauplatz: ich habe klickverbot eigentlich nur wenig hinzufügen. Linkerbug nahezu ausgeschlossen. Der einzige Unterschied zwischen besagter Funktion und der direkt darunter deklarierten aiGetMaterialFloatArray besteht in einem 'aiMaterialProperty*' als Parameter. Gut möglich dass es sich dabei um den Auslöser handelt. Leider sieht besagte Struktur auch nicht anders aus als jede andere in Assimp. Rumspielen an der Deklaration bringt auch nichts. Den Sprachstandard habe ich bereits nachgeschlagen - außer Konfusion über die exakte Bedeutung von 'extern C' hat er nur wenig beizusteuern. Das Ergebnis ist unter Linux/GCC wie Windows/MinGW wie Windows/MSVC absolut identisch. nm+grep zeigt dass scheinbar alle aiXX-Funktionen korrekt (Achtung!, Anglizismus) gemangled werden, von unserem Sorgenkind abgesehen.

Es ist in jedem Fall eine dämliche Kleinigkeit die von niemandem der Beteiligten wohl jemals wieder vergessen werden wird, sobald wir sie dann mal kennen :-)
aiMaterial.h:1190

Edit: Wieso befindet sich pstdint.h eigentlich in include/Compiler und nicht in code? Wenn ich nichts übersehen habe, wird die Datei ja nur intern gebraucht, in den öffentlichen Headern findet sich kein Verweis darauf.

Edit 3: Das Gleiche gilt auch für BoostWorkaround. Oder ist include gar nicht als »öffentliches« Include-Verzeichnis konzipiert?

Eigentlich schon als öffentliches Verzeichnis. Du hast Recht, sowohl stdint als auch boost-workaround gehören eigentlich nach ./code. Wenn niemand Einspruch erhebt, sorge ich für's Verschieben.

Edit 2: Was ist jetzt eigentlich die »offizielle« Schreibweise? »Assimp«? »ASSIMP« (wird in der Doxygen-Dokumentation verwendet)? Ist »AssetImporter« auch eine mögliche Form (ist derzeit der CMake-Projektname)? Meiner Meinung nach wäre es gerade vor dem ersten Release nett, sich auf eine »Marke« festzulegen, gerade auch im Hinblick auf Release-Verlautbarungen und deb/rpm/…-Pakete.

Ich bin für 'Assimp' als Produktkürzel, 'Open Asset Import Library' als voller Name und 'assimp' als Paketname für die alle linuxoiden Paketmanager. Sollten wir drüber abstimmen sofern mehrere Meinungen existieren.

Ich habe übrigens gerade bemerkt, dass es zumindest ein Team gibt, das tatsächlich Assimp mit den D-Bindings benutzt – bei der derzeitigen Größe der D-Community fast schon ein Wunder

Freut mich zu hören :-) Dann wird es zugleich aber immer dringender endlich mal ein Release herauszubringen das auch die D-Bindings enthält.

[Krishty]

Ist es gewollt, dass aiGetMaterialProperty() mit aiTextureType type deklariert, aber mit unsigned int type definiert ist? Bei aiGetMaterialFloatArray() ist es jedenfalls nicht so.

Falls es das ist, waren das die drei produktivsten Minuten meines Tages.

[Aramis]

Jepp, that's it. Unglaublich deprimierend - gut, dass du es gesehen hast. Ich schulde dir ein Bier, sollten wir uns mal über den Weg laufen.

Der Beweis:

Code: Alles auswählen

acg@acg-laptop:~/dev/assimp/trunk/bin/gcc$ nm libassimp.so | grep -E 'T ai\w+'
000000000009ef80 T aiApplyPostProcessing
00000000000a0790 T aiAttachLogStream
000000000009e330 T aiCreateQuaternionFromMatrix
000000000009faf0 T aiDecomposeMatrix
000000000009ecf0 T aiDetachAllLogStreams
000000000009e620 T aiDetachLogStream
000000000009e5f0 T aiEnableVerboseLogging
00000000000a1cb0 T aiGetCompileFlags
000000000009daf0 T aiGetErrorString
000000000009e580 T aiGetExtensionList
00000000000a1c80 T aiGetLegalString
000000000013de80 T aiGetMaterialColor
000000000013dae0 T aiGetMaterialFloatArray
000000000013e0e0 T aiGetMaterialIntegerArray
000000000013d010 T aiGetMaterialProperty
000000000013deb0 T aiGetMaterialString
000000000013e480 T aiGetMaterialTexture
000000000013cf80 T aiGetMaterialTextureCount
000000000009ef10 T aiGetMemoryRequirements
000000000009e6f0 T aiGetPredefinedLogStream
00000000000a1ca0 T aiGetVersionMajor
00000000000a1c90 T aiGetVersionMinor
00000000000a1cc0 T aiGetVersionRevision
000000000009e2c0 T aiIdentityMatrix3
000000000009e2f0 T aiIdentityMatrix4
00000000000a0460 T aiImportFile
00000000000a0140 T aiImportFileEx
00000000000a0470 T aiImportFileFromMemory
000000000009ed80 T aiIsExtensionSupported
000000000009e120 T aiMultiplyMatrix3
000000000009dc90 T aiMultiplyMatrix4
000000000009f040 T aiReleaseImport
000000000009f680 T aiSetImportPropertyFloat
000000000009f470 T aiSetImportPropertyInteger
000000000009f0f0 T aiSetImportPropertyString
000000000009db80 T aiTransformVecByMatrix3
000000000009dc00 T aiTransformVecByMatrix4
000000000009db00 T aiTransposeMatrix3
000000000009db30 T aiTransposeMatrix4

 

Ein einwandfreier C-Export :-) Mir fallen keine weiteren fehlenden Funktionen auf.
EDIT - Ist eingecheckt.

[kimmi]

@klickverbot:
Vielen Dank für den Patch, werde den unter Windows mal probieren.

Gruß Kimmi

[klickverbot]

Jepp, that's it. Unglaublich deprimierend […] Mir fallen keine weiteren fehlenden Funktionen auf.

In der Tat ist es etwas belustigend, dass auch ich den Fehler bisher einfach überlesen habe – naja, wenigstens ist das Problem jetzt behoben. Die neue Revision der D-Bindings, die ich gerade eingecheckt habe, sollte nun die C-API komplett abbilden, weitere fehlende Funktionen wären mir wahrscheinlich aufgefallen.

Bezüglich der Namensfragen: Auch in meinen Augen wirkt »Assimp«/»Open Asset Import Library«/»assimp« am schönsten. Allerdings glaube ich mich zu erinnern, ob nicht manche Distributionen (Debian?) einen »lib«-Präfix für Pakete von Bibliotheken fordern oder zumindest empfehlen – hier auf Arch Linux ist es jedenfalls nicht so. Im Lizenztext wird das »ASSIMP Development Team« stets in Großbuchstaben geschrieben – Absicht?

Da die D-Bindings jetzt komplett sind, steht einem Release von meiner Seite aus nur noch der fehlende CMake-Install-Support im Wege. Der Patch von oben scheint hier auch unter Windows problemlos zu funktionieren, aber mit dem Einchecken möchte ich noch warten, bis die Frage mit dem Include-Verzeichnis und der Namensgebung geklärt ist.

[kimmi]

Unter Linux hat sich als Präfix lib in der Tat eingebürgert, das ist meines Wissens nach distributionsunabhängig. Von da aus könnte man das im Skript vorsehen. Das beinhaltet dann aber noch eine Änderung des GNU-Makefiles.
Und von so einem Fehler sollte man sich nicht deprimieren lassen. Viele dicke Hunde, die ich im Job gesehen habe, wurden durch so etwas ausgelöst.

Gruß Kimmi

[klickverbot]

Unter Linux hat sich als Präfix lib in der Tat eingebürgert, das ist meines Wissens nach distributionsunabhängig. Von da aus könnte man das im Skript vorsehen. Das beinhaltet dann aber noch eine Änderung des GNU-Makefiles.

Ich komme da nicht ganz mit, was man da am Makefile ändern müsste – das Paket zu benennen ist doch Sache der Packager. Ich habe gerade das Arch-Linux-Repository durchgeblättert, dort werden die Pakete immer nach dem Projektnamen benannt, ob dieser nun ein »lib« beinhaltet oder nicht. In Debian-artigen Distributionen scheint der Präfix hingegen üblich zu sein. Aber das sollte wie gesagt nicht jetzt nicht unser Problem sein, oder übersehe ich etwas?

Apropos Makefile: Aus welchem Grund werden die Header und Bibliotheken im »install«-Target von code/makefile standardmäßig nach /usr/bin/assimp/{lib,include} installiert? Nach FHS/LSB wäre /usr/local/{lib,include} das Standardverzeichnis der Wahl. Außerdem werden die »Compiler«-Includes nicht mitkopiert, die auch für die öffentlichen Header nötig sind.

Und wie schaut es mit dem Rest von workspaces/ aus? Sind die Dateien für SCons und XCode noch aktuell? Ich persönlich wäre übrigens dafür, alles außer CMake zu entfernen, oder zumindest eine Variante als »offiziell« zu deklarieren, das würde die Wartung wesentlich einfacher machen (allerdings weiß ich nicht, ob die von CMake generierten VC++-Projekte brauchbar sind).

[kimmi]

Präfix: ich bin bezüglich Packager unter Linux aufgrund langer Abstinenz nicht mehr auf der Höhe. Wenn die das selber machen: um so besser. Im Make von Ankon hatte er die meines Wissens bei der Benutzung von Automake mit so einem Präfix von Hand versehen.

Da ich den FHS/LSB nicht kenne, habe ich das an die falsche Ecke kopiert. Und was ist der FHS/LSB überhaupt? Ich hatte noch nie viel mit der Vorbereitung von Packages unter Linux zu tun und kenne mich da nicht besonders gut aus.
Und gut zu wissen, daß die Compiler-spezifischen Header da noch mit müssen. Daran hatte ich nicht gedacht. Da du dein Linux scheinbar öfter an hast als ich das meinige: kannst du bitte die Anpassungen vornehmen? Ich komme gerade nicht zu so besonders viel und wäre froh, wenn die Makes sauber ist. Danke schon mal im Voraus ;).
Der Scons-Build war der Linux-Make-Versuch vor CMake. Da CMake sich größerer Beliebtheit erfreut, würde ich Scons rausschmeißen. Der XCode-Kram kann meines Wissens ebenfalls per CMake erstellt werden. Wenn den keiner mehr benutzt, sollte der auch entfernt werden können.

Und Danke für die Hilfe!

Gruß Kimmi

[klickverbot]

Bei FHS handelt es sich um den Filesystem Hierachy Standard und bei LSB um die Linux Standard Base, sie legen unter anderem eine Standard-Verzeichnisstruktur fest. Mit der Vorbereitung von Packages unter Linux hatte ich leider bisher auch nicht gerade viel zu tun.

Ich bin mir nicht sicher, ob wir die Makefiles überhaupt behalten sollen, denn CMake kann die Aufgaben mindestens gleich gut erfüllen und ist mittlerweile schon so weit verbreitet, dass ohnehin niemand drum herumkommt, der ab und an mal ein Open-Source-Projekt selbst kompiliert. Wenn gewünscht, kann ich mich einmal dahinterklemmen und das CMake-Skript etwas aufhübschen (Boost-Erkennung, Single-Threaded-Builds, …), dann könnten wir die Makefiles ganz streichen – toll, oder? ;) (Ich konnte mich persönlich nie mit der Syntax anfreunden, ja…)

[Aramis]

Meine Meinung: CMake als offizielles Buildsystem - ja. Scons raus - ja. XCode - ist schon eine Notiz dabei dass es veraltet ist. Man muss aber anscheinend nur ein paar fehlende Units nachtragen, das sollte menschenmöglich sein. Bin dafür es im Repos zu lassen, aber für Releasepakete zu entfernen. Make raus - Nein. Es muss stets ein funktionstüchtiges makefile in code/ verbleiben (das kann aber gerne über andere Meta-Buildsystemen generiert werden). Zur Verbreitung von CMake kann ich nichts sagen, nur dass man es tatsächlich immer häufiger zu sehen kriegt. Ein ganz normales 'make && make install' ist aber imho noch eine Spur gängiger und auch idiomatischer ... Ebenfalls drin bleiben müssen vorgenerierte VC Workspaces. Unter Windows gibt es einfach nichts besseres.

Zum `install´-Ziel: Zustimmung zu klickverbot. Unbedingt der Konvention folgen.

[kimmi]

Zum Install-Target: Bin ebenfalls voll für das Halten an die Standards.

Gruß Kimmi

[klickverbot]

Gut, dann lasse ich die code/makefile*s als Minimalvariante bestehen. Ich würde mich dann in den nächsten Tagen einmal um CMake kümmern und SCons anschließend entfernen.

rave3d (wer war das noch gleich) und Aramis, ich verfolge gespannt eure Versuche mit SWIG. Ich habe in einem lokalen Branch schon einen relativ fortgeschrittenen Branch (die Anpassung beziehen sich auf mein eigenes D-Modul, sind also für euch nicht interessant), bin aber nicht recht weit gekommen, ohne händisch Wrapper für alle »Pointer-und-Länge«-Member zu schreiben. Haltet mich bitte auf dem laufenden, auch wenn es der Code nicht in das Repository schaffen sollte.

[Aramis]

Jau, das von dir angesprochene Problem mit den mXXX-mNumXXX-Paaren ist heikel .. sollten wir zu dritt dafür keine brauchbare Lösung finden, kann man SWIG für den Zweck wohl vergessen.

Meine Erfahrung mit maschinell generierten Python3-Wrappern für ein 80KLoc-Projekt war, dass es fast unumgänglich ist SWIG's Input irgendwie maschinell vorzubereiten, schon alleine um Stellen zu umgehen an denen der Parser hängenbleibt (die gibt es in Assimp ja glücklicherweise nicht). Prinzipiell könnte man in unserem Fall alle Pointer+Num-Paare suchen und sie zu _einem_ Member zusammenfügen, den man dann mit passenden Typemaps durchreichen könnte ... liefe also drauf raus per Skript (Python, Perl, WasAuchImmer - wäre ja egal da es ja sowieso bloß beim Neu-Generieren der Wrapper ausgeführt werden muss) die Assimp-Header vorzubearbeiten, alles in eine Datei reinzustopfen und die an SWIG zu verfüttern.

Code: Alles auswählen

struct aiFace {
   unsigned int mNumIndices;
   unsigned int* mIndices;
}

template<typename T> struct AssArray 
{
   unsigned int num;
   T* ptr;
};

struct aiFace {
   AssArray<unsigned int> mIndices;
}

Das ist aktuell eine eher unausgereifte Idee ... aber vielleicht eine mögliche Lösung. Sicherlich fällt einem von euch gleich ein entscheidender Denkfehler daran auf, dann kann man sich die Arbeit sparen es auszuprobieren :-)

@Matthias Gubisch:
Deine SWIG-Konfig liefert auch für Java gute Ergebnisse! Das ganze C-API kann aber raus, denke ich - (aiFileIO.h). NullLogger.h wird eigentlich auch nicht benötigt. Ich schmeiße meine Papierkorb-Konfig von vorhin dann wieder raus und teste/arbeite auch mit der AssimpSwigPort.i. Ich wäre dir aber dankbar wenn wir den Modulnamen einfach auf 'assimp' ändern könnten :-)

[kimmi]

Na dam auch einen kleinen Zwischenstand von mir: ich habe den BSP-Loader angefangen und ringe wie üblich um Zeit, da weiter zu kommen :). Aber da kommt noch was von mir!

Gruß Kimmi

[Matthias Gubisch]

Hi

@Aramis
Also den Modulnamen können wir Problemlos ändern.
Könntest du die Dateien entfernen die deiner Meinung nach nicht benötigt werden?
weil ich hab frühestens am Donnerstag Zeit dafür

Grüße
Matthias

[Aramis]

Ich kam auch erst jetzt dazu. Die verbleibenden Header sollten ausreichen. Wenn ich mir den Output aber genau anschaue verbleibt da noch viel zu tun.

[kimmi]

Der CMake-Install-Patch ist geliefert. Das lief auch soweit bei mir unter Windows. Nicht wundern: in den CMake-Files sind einige Files auskommentiert. Das sind die, die für den BSP-Loader drinn sind, aber noch nicht von mit committed wurden.

Gruß Kimmi

[Aramis]

Hab es nur schnell getestet. Build mit cmake (2.6-p4) lief sauber, install über das generierte makefile scheitert noch wie folgt:

Code: Alles auswählen

acg@acg-laptop:~/dev/assimp/trunk$ sudo make install
.. 
[100%] Built target assimp
Install the project...
-- Install configuration: ""
-- Installing: /usr/local/lib/libassimp.so.1.0.0
-- Installing: /usr/local/lib/libassimp.so.1
-- Installing: /usr/local/lib/libassimp.so
CMake Error at code/cmake_install.cmake:54 (FILE):
  file INSTALL cannot find file "/home/acg/dev/assimp/trunk/code/aiAnim.h" to
  install.
Call Stack (most recent call first):
  cmake_install.cmake:37 (INCLUDE)

make: *** [install] Error 1

.. es sucht scheinbar im falschen Verzeichnis.

[kimmi]

Jupp, da ist was krumm. Ich schau mal!

Gruß Kimmi

[klickverbot]

Ich wollte gerade einen Fix committen, da sehe ich, dass du das schon gemacht hast, kimmi. ;)

[kimmi]

Jupp, ich war schneller ;). Aber Danke für die Mühe ...

Gruß Kimmi

[klickverbot]

Gibt es einen Grund, wieso du im Library-Target die Header explizit aufgelistet hast, anstatt einfach PUBLIC_HEADERS und COMPILER_HEADERS mit aufzunehmen (wie ich in meinem Patch)? Das ganze ist ohnehin nur nötig, um den MSVC-Generator dazu zu bringen, die Header in das Projekt-File aufzunehmen, aber würden die Variablen nicht auch reichen?

EDIT: Welche Boost-Version braucht Assimp mindestens?

[Aramis]

Wunderbar, funktioniert jetzt. Danke!

Damit entstünde die Frage, was wir mit dem alten Makefile in ./code machen. Ich bin dafür es einstweilen zu lassen, es aber als deprecated zu markieren (z.B. als Ausgabe beim Build). Setze ich in der Form um -- wenn niemand Einspruch erhebt.

@BoostWorkaround nach Code - dito.
@BoostVersion: 1.35 (war zum Zeitpuntk der Projektgründung aktuell. foreach und tuple sind die einzigen Boost-Libs, die erst später verwendet wurden. Beide in 1.35 gemäß Versionsgeschichte bereits enthalten).

- Alex

[klickverbot]

@BoostWorkaround nach Code - dito.

Die Arbeit brauchst du dir nicht zu machen, ich habe einen entsprechenden Branch schon in meinem lokalen Git-Repository, der nur noch auf die Freigabe wartet.

Eine Frage zum Thema hätte ich aber noch: Aus welchem Grund sind die Pfade zu den Boost-Workaround-Headern per #ifdef hardgecodet¹? Ob man als Benutzer nun ein Include-Verzeichnis oder eine Präprozessor-Definition zu den Compiler-Optionen hinzufügt, sollte doch wirklich egal sein – erst recht, wenn einem die mitgelieferten IDE-Projektdateien bzw. CMake-Skripte sowieso ersparen, sich mit diesen Details auseinanderzusetzen…

Mein SWIG-D-Port macht übrigens auch Fortschritte. Ich habe mich jetzt einfach entschlossen, die Vorschlaghammer-Methode anzuwenden und alle Zeiger-und-Länge-Arrays als std::vector zu wrappen. Den aktuellen Stand gibt es auf GitHub zu sehen.

¹ Entschuldigt bitte das Deutsch – das kommt davon, wenn man den ganzen Tag lang in Englisch programmiert und schreibt… ;)

[Aramis]

Das stammt noch aus der Zeit als das Buildsystem etwas unausgereift und inhomogen war. Ein einzelnes Define war überall recht leicht umzusetzen (Faulheit ..). Dank deiner und Kimmis CMake-Anstrengungen besteht das Problem grundsätzlich nicht mehr :-) also kann man in der Tat auf einheitliche Includes ohne #ifdef wechseln.

EDIT: Die Boost-Includes sind sowieso etwas ... zu global für meinen aktuellen Geschmack, teilweise gar nicht mehr benötigt. Ich räume da mal etwas auf, in kleinen Etappen.

[Aramis]

Die Arbeit brauchst du dir nicht zu machen, ich habe einen entsprechenden Branch schon in meinem lokalen Git-Repository, der nur noch auf die Freigabe wartet.

Fein!
Das random-Unterverzeichnis im BoostWorkaround wird seit soeben nicht mehr benötigt, insofern kannst du es beim Einchecken gleich weglassen :-)