Assimp - Brainstorming zum Release

[kimmi]

Eine Dinge, die mir aufgefallen sind / ich mich gefragt habe, sprich ein Lessons-Learned von meiner Seite:

• Haben wir eine Liste aller supporteted Compiler? Ich wurde da was wegen einer etwas älteren GCC-Version gefragt und da wäre die Info interessant. Außerdem macht das SDK-Bauen wesentlich einfacher.
• Wenn wir die Liste zusammengestellt haben, werde ich mich für 4.0 mal daran machen, dein Plattform-spezifische Build-SDK zusammen zu nageln. Einer der gründe, dass ich damit nicht fertig wurde, was einfach darauf zurückzuführen, dass ich zwar das Skript zum SDK-Bauen, nicht aber alle notwendigen Schritte kannte.
• Ich habe eine Announcments-ML generiert, wo wir den Release des SDK's promoten können.

Feel free to add your own stuff :)...

Gruß Kimmi

[CodingCat]

Wo ich gerade ins SVN schaue, hat es einen Grund, dass das Property Sheet "FastSTL" nur bei den x86-Versionen gesetzt ist?

Nachtrag: debug x64 hat außerdem das Sheet "LibShared" nicht gesetzt, und release Win32 möglicherweise ein falsches Intermediate Output Directory?

Fun Fact: "Microsoft.Cpp.x64.user" setzt für Librarian -> Target Machine kein x64, weshalb assimp debug x64 versucht, für 32 Bit zu kompilieren, und dann fehlschlägt. Hilft wohl nur manuelles Überschreiben in den Property Pages der Projektkonfiguration, denn diesen Defizit wird "Microsoft.Cpp.x64.user" wohl auf allen neu aufgesetzten Visual-Studio-Systemen haben. (Alternativ ginge auch ein LibShared.x64-Sheet.)

[CodingCat]

Nachtrag 2: Einige assimp-Konfigurationen haben Post-Build-Events, die sich auf $(SolutionDir) beziehen. Da ich die Projekte von Abhängigkeiten mit Source Code gerne noch in meine eigenen Solutions mit einbinde, und es anderen vielleicht ähnlich geht, wäre es möglicherweise hilfreich, diese Bezüge zu $(ProjectDir) zu ändern.

[CodingCat]

Nachtrag 3: Selbes gilt für die Ausgabeverzeichnisse der statischen Hilfsbibliotheken zu den Dll-Varianten unter Linker -> Advanced, die btw. vermutlich in DllShared gut aufgehoben wären.

[kimmi]

@CodingCat: Gilt das für die CMake-generierten Projektfiles? Oder meinst du die anderen?

Gruß Kimmi

[CodingCat]

Die liegen im SVN unter "workspaces/VC9", keine Ahnung woher die kommen. ;)

[Aramis]

Ich denke, da ist eine Menge durcheinander gekommen.

Die verschiedenen Project-Sheets waren urspruenglich mal meine Strategie um der kombinatorischen Explosion der zu pflegenden Build-Settings Herr zu werden.

Hast du all diese Dinge bei dir schon gefixt? Wenn ja, dann poste doch bitte das diff und ich committe es gleich. Ansonsten setze ich das auf meine Release-Todo-Liste :-)

Der einzige Grund weshalb immer noch die handgepflegte vc9-Konfig im Repository liegt ist, dass der CMake-Build unzureichend optimierte MSVC-Configs ausspuckt - ganz davon abgesehen dass einige Menschen anscheinend zu doof sind, CMake zu bedienen (jedenfalls kriege ich pro Woche durchschnittlich eine Mail deshalb). Ein Argument fuer die haendischen Configs ist das aber nicht, wir koennten ja auch einfach von CMake generierte VC-Solutions mit einchecken.

Kurz: eigentlich sollte man sich mal darum kuemmern, CMake vollstaendig einzubinden. Steht auch auf der Liste, aber nicht mehr fuer 3.0. Fixes fuer workspaces/vc9 wuerde ich aber noch ins 3.0er einschleusen, denn das schafft keine Inkompatibilitaet zu den bereits releasten 3.0-Paketen fuer Debian und Ubuntu.

[CodingCat]

Ich habe hier leider nur VC10 Solutions. Property Sheets finde ich gut, sollten mehr Projekte benutzen, macht die lokale Konfiguration extrem einfach. Ich nehme inzwischen nur noch ganz wenige Einstellungen direkt in den Project Pages vor. CMake habe ich selbst bisher nur ein Mal mit geringem Erfolg benutzt, ich weiß schon nicht mehr, bei welchem Projekt. ;) Ich weiß nur noch, dass da am Ende ziemlicher Mist rauskam, mit massig absoluten Pfaden (sogar in Makros für relative Pfade, die ich brauchte, weil der VC++-Compiler noch immer keine gleichnamigen CPP-Dateien in verschiedenen Ordnern verarbeiten kann) ...

[CodingCat]

Nur so nebenbei: Ich sehe hier nur den (vermutlich uralten) NFF-Importer, aber kann es sein, dass assimp bei Ausnahmen (DeadlyImportError) an einigen Stellen Speicher leckt? Nicht dass es mich stören würde, ich nutze die Bibliothek ohnehin nur in einem winzigen Einweg-Konsolen-Utility.

[Aramis]

Ja, das kann sein. Es gab Zeiten zu denen darauf schlicht und einfach nicht geachtet wurde. Die neueren Importer sollten davon nicht betroffen sein - die sind allerdings auch daran zu erkennen dass sie in sinnvollem C++ geschrieben sind.

Es gibt einen NFF-Importer in Assimp und er liest sogar gleich 2 Formate, die diese Dateierweiterung verwenden. Deines ist ein anderes, oder? Da waere es sinnvoll, einfach einen neuen Importer anzufangen und dessen CanRead()-Methode nur genau dieses Subformat akzeptieren zu lassen.

[Aramis]

So,

Downloads fuer 3.0 sind oben:

https://sourceforge.net/projects/assimp ... ssimp-3.0/

koennt ihr bitte mal gucken ob die so in Ordnung sind, ob alles compiled, die Doku in Ordnung ist, die Windows-Installer funktionieren, nichts offensichtlich vergessen wurde etc. … ? :-)

Website ist bereits aktualisiert, wenn die Pakete soweit ok sind, koennen wir das Release ankuendigen.

[kimmi]

Super, vielen Dank für den Einsatz!
Wegen Ankündigung: Dafür habe ich eine Announcements-ML angelegt. Erst einmal sollten wir natürlich den üblichen Weg gehen, aber mittelfristig sollte Announcements für so etwas besser geeignet sein. Noch einmal die Bitte: Kannst du den Prozess für das SDK noch mal etwas dokumentieren ( welche Targets werden gebaut, welche Compiler braucht man etc. ), gern auch hier?

Danke und Gruß,
Kimmi

[kimmi]

Doku-Bug: Bei der Liste der Loader fehlt M3 ( experimental ).

Gruß Kimmi

[Matthias Gubisch]

Installer für Windows SDK und Viewer funktionieren hier bei mir Win7 x64

Exportfunktion find ich super :)

[kimmi]

Bei mir ebenfalls, Exportfunktion habe ich noch nicht probieren können :).

Kimmi

[CodingCat]

Wunderbar, und vielen Dank für die verbesserte Solution-Konfiguration.

Es gibt einen NFF-Importer in Assimp und er liest sogar gleich 2 Formate, die diese Dateierweiterung verwenden. Deines ist ein anderes, oder? Da waere es sinnvoll, einfach einen neuen Importer anzufangen und dessen CanRead()-Methode nur genau dieses Subformat akzeptieren zu lassen.

Genau. Habe ich nun soweit einsatzbereit, allerdings aufbauend auf dem original "vanilla C" BART-Parser-Skelett und damit momentan in keiner Weise bibliotheksgerecht. exit() bei Fehler und Memory Leaks in der Animation, weil ich ich diese zur Zeit noch gar nicht verarbeite. Ich werde versuchen, das demnächst zu vervollständigen.

[Mr. S]

Ich habe einmal meinen Patch aktualisiert, da z. B. der aktuelle Entwicklungszweig von boost die Versionsnummer 1.51 trägt, während in der CMake-Datei "nur" 1.50 als letzte Version unterstützt wird.

Achja, um Installer für alle Systeme zu erstellen eignet sich ja vielleicht CPack (Teil von CMake).

[Aramis]

Danke, das ist wirklich eine gruendliche Ueberarbeitung des CMake-Buildsystems, insbesondere was die Einbindung von ZLIB und DirectX angeht!

Ich habe natuerlich nicht alle Permutationen testen koennen, aber die wesentlichen Sachen funktionieren. Beim Erstellen der Tests kriege ich noch einen CMake-Syntaxfehler, aber die Unittests sind ohnehin Sorgenkind auch von anderer Seite (das betrifft auch nicht deinen Patch, das Problem bestand schon vorher).

Eingecheckt als r1293.

Gruss, Alex

PS: das ist natuerlich CREDITS-wert, hast du einen Namen ausser "Mr. S"? ;-)

[kimmi]

Oha, das nenne ich eine umfangreiche Überarbeitung. Vielen Dank für die Hilfe an dieser Stelle!

Gruß Kimmi

[Mr. S]

Danke, das ist wirklich eine gruendliche Ueberarbeitung des CMake-Buildsystems, insbesondere was die Einbindung von ZLIB und DirectX angeht!

Ich habe natuerlich nicht alle Permutationen testen koennen, aber die wesentlichen Sachen funktionieren. Beim Erstellen der Tests kriege ich noch einen CMake-Syntaxfehler, aber die Unittests sind ohnehin Sorgenkind auch von anderer Seite (das betrifft auch nicht deinen Patch, das Problem bestand schon vorher).

PS: das ist natuerlich CREDITS-wert, hast du einen Namen ausser "Mr. S"? ;-)

Die Tests benutze ich nicht, damit stehe ich auf Kriegsfuß. ;-) Z. B. funktionieren die bei OpenRTI wunderbar, aber es ist schwer funktionierende Beispiele zu erstellen.

Im Forum von OGRE bin ich noch als "Transporter" unterwegs, daher kommt auch der Patch. Ich aktualisiere und erstelle mein OGRE-Packet mit allen Tools automatisch mit Batch-Dateien & CMake. Nur bei Assimp hat der Fehler bei DirectX immer Handarbeit erfordert. Daher der Patch. Assimp hat außerdem mit dem Konverter (http://www.ogre3d.org/forums/viewtopic.php?f=11&t=65993) nicht so prickelnd gepasst, also habe ich beide CMake-Dateien gepatched.

Oha, das nenne ich eine umfangreiche Überarbeitung. Vielen Dank für die Hilfe an dieser Stelle!

Kein Problem, immer wieder gerne!

Die Tests müsst ihr selber patchen, aber bei anderen Sachen melde ich mich wieder wenn es Neuigkeiten gibt. 8-)

[Mr. S]

Mir ist bei dem patch ein kleiner Fehler unterlaufen. Hier der Korrekturpatch:

Index: test/CMakeLists.txt
===================================================================
--- test/CMakeLists.txt (Revision 1294)
+++ test/CMakeLists.txt (Arbeitskopie)
@@ -220,7 +220,7 @@

IF( WIN32 )
FIND_PACKAGE(DirectX REQUIRED)
-+ENDIF( WIN32 )
+ENDIF( WIN32 )
SET_PROPERTY(TARGET assimp PROPERTY DEBUG_POSTFIX ${ASSIMP_DEBUG_POSTFIX})

# TODO: Port to non-Windows platforms.

Vor dem ENDIF( WIN32 ) ist ein + "übrig" geblieben.

[Aramis]

Danke, ist gefixt.

[Mr. S]

Ich habe noch etwas für Assimp. Beim Ogre-Projekt hat jemand das FBX-Format implementiert: http://www.ogre3d.org/forums/viewtopic.php?f=8&t=71332

Leider habe ich im Augenblick keine Zeit einen Reader für Assimp zu schreiben.

[Schrompf]

Schöne Entdeckung! Bei Assimp ist Aramis im Begriff, FBX zu implementieren... weiß nicht, wie weit er damit ist, aber er ist sicher über eine weitere Quelle an Informationen dankbar.

[Aramis]

Auch das Tool benutzt wenn ich das richtig sehe nur das FBX SDK. Assimp hat das neuerdings nicht mehr noetig, ich habe den Loader im Prinzip einsatzbereit :-)


Kimmi: mir kamen Berichte zu Ohren dass der M3-Importer angeblich des oefteren crashed? Wie stabil ist der? Wir haben ihn immerhin mit-released :-)

[kimmi]

Mir bisher nicht, was aber nichts heißt. Wenn ja, wären Fehlerreports zum Stabilisieren recht hilfreich. Nicht ohne Grund war der als experimental markiert.

Gruß Kimmi

[Aramis]

Hab Assimp.NET mal wieder aktualisiert.

[Aramis]

Hab soeben meinen FBX-Branch vom letzten Google Summer of Code in Assimp gemerged. Damit haben wir nun so halbwegs funktionstuechtigen FBX Support. Unterstuetzt werden ASCII und Binaerfiles. Animationen werden teilweise unterstuetzt. Skinning ist so verbuggt dass es quasi nicht funktionsfaehig ist, aber vielleicht kriege ich das in der naechsten Zeit hin :-)

Der Vollstaendigkeit halber: ich werde von nun an nur noch den Github bedienen (Website und Bugtracker auf SF.net verbleiben natuerlich). Klickverbot, wie machen wir das mitdem SVN-Mirror auf SF.net am besten?

[CodingCat]

Sehr schön! Wie weit bist du eigentlich mit der Blender/Assimp-Integration gekommen?

[Mr. S]

Der Vollstaendigkeit halber: ich werde von nun an nur noch den Github bedienen (Website und Bugtracker auf SF.net verbleiben natuerlich). Klickverbot, wie machen wir das mitdem SVN-Mirror auf SF.net am besten?

Da habe ich der Vollständigkeit halber auch mal eine Frage zu: Ist jetzt SVN oder GIT die offizielle Codeverwaltung? Sowohl auf der Gitcode-Seite

In this repository, you can find an inofficial Git clone of the Assimp SVN repository hosted at Sourceforge. It is read-only, the latest commits are pulled in from SVN every 15 minutes.

als auch auf der Webseite

A automatically updated git clone can be found on Github.

steht das Git nur eine Kopie von SVN ist. Dabei sind die Commits auf Github wesentlich aktueller. Vielleicht sollten mal die Webseiten aktualisiert werden. ;)