Assimp - Brainstorming zum Release

[Aramis]

Oehm weshalb committest du in den 2.0 Branch hinein? Sollte das nicht eher in den trunk gehen?

[kimmi]

Japp, sollte er. Allerdings habe ich auch nur im trunk gearbeitet. Irgend etwas ist da bei meinem Repo scheinbar kaputt. Kannst du das reverten, bitte? Bin gerade im Büro und komme nicht so schnell dazu, das wieder zu korrigieren.

Danke und Gruß,
Kimmi

[kimmi]

Ich schau mir noch mal genauer an, was da schief geht. Einer der Fehler auf unserer Liste ist nun erledigt.

Gruß Kimmi

[Jonathan]

Ich hab hier ein Modell mit mehreren Texturkoordinaten, dass der Collada-Importer nicht fressen will.

Collada: house01.dae - Expected attribute "texcoord" at element "texture".

house01.zip

Collada multi UV Haus

(57.7 KiB) 816-mal heruntergeladen

(Wieso sind keine .dae Dateien erlaubt? Bzw. wieso wird das überhaupt eingegrenzt?)

Vielleicht ist einfach nur der Blender-Exporter falsch, das könnte natürlich auch sein. Aber vielleicht ist es ja auch ein Problem, wo es sinnvoll ist, den Importer zu ändern.

[Schrompf]

Ich sehe keinen Weg, da einen Workaround zu bauen. Die Texturkanal-Zuordnungen in der Material-Zuordnung der Mesh-Instanziierung geben eine ungültige Kanal-ID an. Alle anderen Files, die ich hier habe, geben in der Effekt-Definition für jede Textur auch eine Kanal-Id an - dieses File nicht.

[Mr. S]

Also, ich habe da auch noch ein paar Änderungsvorschläge, die CMake betreffen:

• Um die assimp-Einträge von den CMake etc. besser unterscheiden zu können (Gruppierung) sollten sie mit ASSIMP_ beginnen.
• Die DirectX-Erkennung fürassimp_view funktioniert nicht richtig. Eine nützliche Lösung wäre FindDirectX von OGRE zu verwenden.
• Da die mitgelieferten externen Bibliotheken wie z. B. ZLib veraltet sind verwende ich hauptsächlich eine externe Version. Hierfür verwende ich FindZLIB von OGRE, weil die OGRE-Version auch zwischen Debug und Release unterscheiden kann, d. h. Debug-Zlib zu Debug-Assimp und Release-Zlib zu Release-Assimp.
• Die aktuelle Boost-Version (dev) ist mittlerweile bei 1.50 angekommen, daher sollte Boost_ADDITIONAL_VERSIONS angepasst werden.
• Wofür ASSIMP_BUILD_ARCHITECTURE und ASSIMP_BUILD_COMPILER gut sein sollen habe ich noch nicht ganz begriffen, aber warum wird da nicht einfach CMAKE_CL_64 bzw. CMAKE_GENERATOR verwendet?
• Ich vermisse die Möglichkeit die Debug-Dateien (PDB) von Visual Studio mit zu installieren.
• comctl32.lib muss eigentlich nicht extra gesucht werden. Es reicht die Bibliothek bei den Standardabhängigkeiten aufzulisten da sie zum Platform-SDK gehört.
• Ich kann bei MSVC10 assimp auch ohne VC10_STDINT_FIX erfolgreich verwenden. Vielleicht sollte man die Option entfernen, oder wenigstens bei Nicht-MSVC10 ausblenden.

In dem angehängten Patch habe ich die Änderungen als Vorschlag eingebaut.

Noch ein paar "CMake-Änderungswünsche" ohne Patch:

• Die CMake-Dateien im Verzeichnis SDK\lib\cmake\assimp-2.0 liegen ein bisschen ungünstig, finde ich. Besser wäre eine FindASSIMP.cmake in SDK\cmake. So passt es dann zu dem meisten anderen Programmen, die CMake so verwenden.
• Warum wird alles in das Hauptverzeichnis installiert? Es gibt keine Unterverzeichnisse für Debug, MinSizeRel, Release und RelWithDebInfo.
• Eine aktuelle GLUT-Version gibt es im Cg-Toolkit von nVidia, welches auch 32- und 64-Bit-Versionen bereit stellt. Die Version im Verzeichnis samples\glut ist schon "etwas" älter und nur für 32 Bit.

[kimmi]

Danke dafür. Ich werde mal zusehen, dass wir diese Woche den 3.0 Release auf die Reihe kriegen und dann mal schauen, wieviel von deinen Änderungen mit dabei sein werden. Auf jeden Fall danach :), sofern sie für uns Sinn machen ...

Danke und Gruß,
Kimmi

[Mr. S]

Jo, kein Problem. ;)

Ich werde weiterhin Verbesserungsvorschläge machen und gerne auch mit Patches mithefen.

[Mr. S]

Noch eine Kleinigkeit ;)

In dem Template assimp-config-version.cmake.in wird wieder PACKAGE_VERSION an Stelle von ASSIMP_PACKAGE_VERSION verwendet. Das ist ungünstig, wenn man assimp per cmake in ein eigenes Projekt einbindet, da man bei vielen Bibliotheken den Überblick verliert zu welchem Projektteil PACKAGE_VERSION gehört. Achja, vielleicht wäre es auch nicht verkehrt neben der Versionsnummer auch zu speichern ob die Bibliothek statisch oder dynamisch erstellt wurde. Das spart ggf. die Suche nach der DLL.

[kimmi]

Guter Hinweis, werde ich nachziehen. Danke für die Mühe!

Gruß Kimmi

[Aramis]

Wie ist denn jetzt eigentlich der aktuelle Stand - sorry, ich bin mal wieder leicht abgehaengt.

[kimmi]

Source-Release ist draußen, ich hab allerdings die Änderungen noch nicht zurück gemergt auf den Trunk. SDK muß noch gebaut werden, da fehlte mir die Zeit in der letzten Woche. Release-Notes fehlen ebenfalls.

Gruß Kimmi

[Aramis]

Soll ich SDK und Binaries erstellen und hochladen?

[kimmi]

In Anbetracht, dass ich grad zu gar nichts komme: Das wäre so was von super, dass ich das gar nicht in Worte fassen kann :) !

Gruß Kimmi

[Aramis]

Ok - vielen Dank dir fuer den Einsatz in den letzten Wochen!

Ich gucke dass ich die Faeden zusammenfuehre und das Release abschliesse.

[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