ZFX + Developia

Hallo zusammen,

nach nunmehr 1 1/2 Jahren stetiger Weiterentwicklung habe ich gestern abend die Version 3.1 der Asset-Importer Library in Github released. Release Notes sind gerade in Arbeit. Es hatte sich in dieser Zeit einfach zu viel getan, als dass ich das wirklich in einer Stunde zusammendampfen könnte.

Inhalt der neuen version sind unzählige Fixes in der Library, dem Build-Prozess, der Doku und auch sonst überall.

Vielen Dank an alle, die uns geholfen haben, diesen Zustand zu erreichen.

Gruß Kimmi

Mist, hätte ich früher nochmal in den Tangent Space-Code reinschauen sollen. ;) Nein Spaß, super & vielen Dank an euch, dass ihr euch schon so viele Jahre so zuverlässig um die Unterhaltung des Projekts kümmert. Insbesondere eure schnelle Bearbeitung von Pull Requests macht das Arbeiten sehr viel einfacher, weil man nicht wie bei anderer Software monatelang um Probleme herumbauen muss. So stelle ich mir die Softwareentwicklung der Zukunft vor - auf dass in 20 Jahren alles über GitHub o.ä. Portale läuft! :)

Manchmal würde ich mir mehr Nachtschlaf wünschen :). Mit Familie wird das in der Tat alles etwas herausfordernder!

Kimmi

Kudos an Kimmi - dieses Release ist vollstaendige seine Leistung und Zeit!

That said, wir sollten neue Pakete fuer SF.net etc bauen. Das kann ich uebernehmen, seit dieser Woche hab ich wieder Zeit.

Ein Daumen Hoch von mir. Auch ich war daran praktisch nicht beteiligt. Da hat Kimmi richtig was geleistet!

So wie jeder von euch davor :). Gern geschehen, kenne das ja mittlerweile aus meinen Job ganz gut :).

Kimmi

Ach, GitHub. Und ich habe immer auf SourceForge gestarrt :?

Ich werde die neue Version mit Freude in den nächsten Tagen ausprobieren – vielen Dank auch von mir! :)

Ich habe Probleme mit zlib. zconf.h existiert nicht; und die zconf.in.h, die dem Projekt beiliegt, enthält nicht nötige Bezeichner wie z_const. Ich nutze jetzt erstmal die alte zlib-Version. Heute abend werde ich mal probieren, die Aktuelle Version zu nutzen.

Mir ist aufgefallen, dass gegenüber 3.0 ein .m3-Dateiformat rausgeflogen ist?

Ich habe zlib 1.2.8 von www.zlib.net gezogen, in Assimps contrib-Verzeichnis ersetzt, und es funktioniert auf Anhieb :)

Hattest du den CMake-Build benutzt? An sich sollte die Datei generiert werden.

Zieh-Mäh-Was?! Ich habe die Visual C++-Projektdatei benutzt, die beilag.

3.1.1 ist als Patch oben. Nun auch mit Paketen auf SF.net.

Schlechte Neuigkeit fuer dich: die vc9-Solution habe ich entfernt. Es wird auf Dauer einfach zu viel Maintenance-Aufwand.

Von nun am also nur noch CMake, oder die Prebuilt-Binaries.

PS:

Ich hoffe, es funktioniert alles. Release-Engineering machen wir uebermorgen.

Schon in Ordnung; ich stelle mir die Dateien selber zusammen :) Die Versionsinformation für die Visual C++-Version zeigt auch noch (c)2010 …

P.S.: Bitte ändert AssimpPCH.cpp(66) zu #include "../revision.h" – nicht jeder fügt alle Pfade den Projekteinstellungen hinzu :)

P.P.S.: Hier sind meine Visual C++-2012-Projektdateien für eine Windows-DLL – ohne Precompiled Headers oder Ressourcen, dafür mit meinem Region Allocator. Vielleicht nützen sie ja irgendwann irgendwem.

Der Trick mit CMake: es erstellt dir deine Projekt-Dateien. Deswegen haben wir das vor Jahren einmal umgestellt und nun das Ganze glatt gezogen. Der Arena-Allocator heißt Arena weil? Auf jeden Fall super, dass du das zur verfühung stellst, vielen Dank!

Kimmi

Ja und warum muss ich mir dann Software installieren und mir davon die Projektdateien erstellen lassen wenn es jemand anders (ihr) für mich tun kann? ;) „Arena“ weil … es Synonym mit „Region“ ist und mir gerade einfiel. Ist behoben :)

Dann saufen wir in Arbeit ab, weill alle Projekt-Dateien ständig nachgezogen werden müssten ( für jeden Compiler auf gefühlt 4 Plattformen wohlgemerkt ). Ich habe bereits gcc, Vissual-Studio 2013 und 2012 zu testen da und trotz dessen geht da gerne etwas schief.

Allerdings kann man so etwas machen wie andere Projekte: ein Batchfile anbieten, cmake einchecken und dann mit einem Knopfdruck das Ganze zur Verfügung haben.

Gruß Kimmi

Ich weiß ja, dass das eine weitere Exzentrik von mir ist, kein cmake benutzen zu wollen. Ich finde nur, dass gewisse Dinge einmal der Anbieter erledigen sollte statt jeder Nutzer einzeln, und dass eine Abhängigkeit von einem Drittprogramm (egal, wie weit verbreitet) die Nutzung immer erschwert. Nehmt mein Gestänker nur nicht als Änderungszwang; es hat ja bisher auch immer gut funktioniert :)

Kein Zwang, aber Change Reqests zur Steigerung der Begeisterung unserer User, die so billig zu haben sind, mach ich gerne ;).

Gruß Kimmi

Krishty: Das Problem bei der Sache ist ja das es unzählige IDEs bzw. Buildsysteme gibt deren Eingaben (Projekte, Makefiles,...) ggf. Platform/Konfigurations-Abhängig erzeugt werden. Wenn dann ein neues VS raus kommt oder was an CMake gemacht wird, müsste "der Anbieter" alle Projekte für alles neu generieren und testen. Den Aufwand kann man eigentlich keinem freiwilligen Entwickler zumuten. Deshalb finde ich es schon ok wenn sich die Nutzer halt noch ein zusätzliches Tool installieren und ein paar Anweisungen befolgen müssen bevor sie los legen. Zu guter letzt ist CMake ja auch recht verbreitet.

Vorher:

• Anwender lädt Assimp
• Anwender führt cmake aus
• Anwender erhält ein ungetestetes Projekt, das vielleicht funktioniert (denn der Testaufwand kann, wie du sagst, keinem freiwilligen Team zugemutet werden)

Nachher:

• Anwender lädt Assimp
• Anwender hat ein ungetestetes Projekt, das vielleicht funktioniert

(Und wenn eine neue Version einer Entwicklungsumgebung rauskommt, die dem Paket nicht beiligt, ist es für den Anwender noch genau wie vorher.)

IMHO ist der einzige Unterschied, dass eine Abhängigkeit entfernt wurde weil cmake nun nur auf einem System ausgeführt werden musste statt auf 2000.

P.S.: Ich glaube, dass der Hund wo anders begraben liegt: Ich habe gesehen, dass cmake einige Header (z.B. für zlib) neu generiert. Könnte es sein, dass da je nach Build-Umgebung unterschiedliche Variationen benötigt werden? Dass also der selbe Quelltext nicht mit allen Umgebungen funktioniert, und man deshalb bestimmte Dateien erst auf dem Zielsystem erzeugen kann?

Ja das kann sein. Das meinte ich auch miter zweiten Hälfte meines ersten Satzes. Allerdings machen davon nicht alle Projekte gebrauch. Manche könnten es also theoretisch so machen wie du es gern hättest (ich hab das auch bereits gesehen).

Krishty hat geschrieben: IMHO ist der einzige Unterschied, dass eine Abhängigkeit entfernt wurde weil cmake nun nur auf einem System ausgeführt werden musste statt auf 2000.

Vorallem muss man nur ein make-File bearbeiten, anstatt zig make-/Projektfiles für jede unterstützte Platform. Ich arbeite selber schon länger mit CMake und man muss sich daran gewöhnen aber wenn ein CMake Makefile ordentlich gemacht ist, spuckt es für alle unterstützten Platformen funktionierende Projektdateien oder Makefiles aus. Das nenn ich arbeitsersparnis.

Changelist gibt es nun auch (Sorry): https://github.com/assimp/assimp/blob/master/CHANGES

Re CMake: die Idee, die wichtigsten Plattformen vorzugenerieren ist schwer umzusetzen. Z.b. wird der Pfad auf das DX SDK (fuer AssimpView) iirc von CMake aufgeloest und ist danach in der Solution hardkodiert.

Man kann ein vereinfachtes Batch-Skript für Windows / Linus vorbereiten, welches die Workspaces generiert. Vielleicht erhöht das die Akzeptanz. Danke für das Changelog und noch mehr Danke für den Release 3.1.1 :).

Kimmi

Aramis hat geschrieben:Changelist gibt es nun auch (Sorry): https://github.com/assimp/assimp/blob/master/CHANGES

Merci beaucoup :)

Re CMake: die Idee, die wichtigsten Plattformen vorzugenerieren ist schwer umzusetzen. Z.b. wird der Pfad auf das DX SDK (fuer AssimpView) iirc von CMake aufgeloest und ist danach in der Solution hardkodiert.

Du meinst für andere Entwicklungsumgebungen als Visual C++ (das dafür ja $(DXSDK_PATH) hat)? Das ist tatsächlich ein Showstopper; dicke Wurst :(

Krishty hat geschrieben:Du meinst für andere Entwicklungsumgebungen als Visual C++ (das dafür ja $(DXSDK_PATH) hat)? Das ist tatsächlich ein Showstopper; dicke Wurst :(

Nein. Auch für VS wird der Pfad aufgelöst. CMake holt sich den über sein DX Findskript aus der Umgebungsvariablen zu DX den Pfad AFAIK.
Ich verstehe jetzt nicht was daran ein Showstopper ist?

Weil das DirectX SDK nicht mit Assimp ausgeliefert wird, kann man auch keine im Voraus erzeugten Projektdateien ausliefern – weil die ja vorher wissen müssten, wo der Benutzer sein DirectX SDK installiert hat.

Ok, hatte das anders verstanden. Ich dachte du meinst es ist ein Showstopper für den Einsatz von CMake. Aber egal, habs kapiert.

Das Problem mit CMake ist tatsächlich, dass es de facto nicht im Stande ist, ortsungebundene Projektdateien zu generieren. Pfade werden grundsätzlich ALLE zu absoluten Pfaden aufgelöst; schon wenn du die Sources in ein anderes Verzeichnis verschiebst, müssen die Projekte neu generiert werden. Die unglaubliche Frechheit einiger CMake-Skripte, Source-Dateien je nach Konfiguration noch umzuschreiben, tragen dann ihr übriges zum absoluten Chaos bei. Damit ist CMake eine Alles-oder-Nichts-Option, Vorgenerieren ist nicht, nicht mal mit standardisierten Umgebungsvariablen.

Am Ende ist es leider wie immer: CMake ist grausiges Konstrukt, aber die schiere Menge an getesteter Funktionalität für praktisch alle relevanten Plattformen und Compiler rechtfertigen die Benutzung als etabliertes Standardtool.

Dieser Eintrag in der FAQ scheint veraltet...

Is ASSIMP able to export models?
No. ASSIMP is an import library. It is intended to import assets, ...