Assimp - Brainstorming zum Release

[Aramis]

Die Änderungen am Exception-Handling sind jetzt committed, siehe r617. Bitte haltet Ausschau nach dadurch entstandenen Problemen.

Für alle sich in Arbeit befindlichen Importer sollte es ausreichend sein throw new ImportErrorException durch throw DeadlyImportError zu ersetzen. Aufgrund des geänderten Namens wird der Compiler weitere Fälle sicherlich freundlichst aufdecken :-)
Edit Laut Testsuite ist alles in Ordnung.

[Aramis]

- Habe adario, der seit einiger Zeit ganz nette LWO&Mac Patches liefert, zum Projekt hinzugefügt damit er seine Fixes direkt einchecken kann. Hoffe niemand hat was dagegen, in dem Fall wäre ich zu voreilig gewesen :-)

[Matthias Gubisch]

Hallo zusammen

hab leider schlechte Nachrichten...

da sich heute morgen die grafikkarte meines notebooks verabschiedet hat, und ich deshalb momentan keinen brauchbaren rechner habe
wird das mit den C# bindings leider definitv nichts bis zum angestreben release termin....

Grüße
Matthias

[Aramis]

… Die schwerste Frage des Universums wartet noch auf uns. Welche Versionsnummer soll dieses Release tragen?

Assimp gibt sich aktuell als 0.5 aus (aiGetVersionMajor,aiGetVersionMinor). Das allererste Release war 1.0.
Ich schlage vor, von nun an etwas einheitlicher vorzugehen. 1.1? Oder sind wir mutig und sagen 2.0?

(Eine Stimme für 1.1)

[kimmi]

Ich schlage 1.1 vor.

Gruß Kimmi

[Aramis]

boost.format ist mir ein Dorn im Auge. Der Workaround führt aktuell keine Substitution durch, eine Implementierung ist unrentabel. Die Boost-Implementierung zu entkoppeln und mit auszuliefern nicht praktikabel. Auf den Workaround zu verzichten frustriert die Hälfte der User. Mein Vorschlag ist, boost.format durch sowas zu ersetzen. Ein simpler Bequemlichkeits-Wrapper um stringstream's :-)

Das betrifft hauptsächlich deine Importer, Thomas. Ich würde das Refactoring übernehmen wenn du damit einverstanden bist. Bei der Gelegenheit flögen dann auch gleich alle sprintf's, die ich jemals verursacht habe, raus.

Von meiner Seite passt der 3.4. als Freeze-Day nach wie vor.
Vermutlich werde ich vorher neben einigen Refactorings noch einen halbwegs funktionstüchtigen COB (TrueSpace)-Loader einchecken und dann während der RC-Phase reifen lassen. In Anbetracht des Ausbleibens weiterer Meinungen zum Versionierungsproblem würde ich damit sagen dass das Release Assimp 1.1 sein wird :-)

[Jonathan]

Jo, hört sich ok an. Ich habe boost::format auch ein paar mal benutzt, aber nicht sehr oft, es sollte nicht sehr schwer sein, das alles zu ändern.
Ansonsten habe ich so noch genug zu tun, ich glaube nicht, dass die Animationen für Ogre mit allen Sonderfällen bis zum Release so gut funktionieren werden, dass man sie als stabil bezeichnen kann. Ich würde dafür wahrscheinlich die entsprechenden Teile auskommentieren und dann noch ein wenig nach Fehlern im Rest vom Loader suchen, damit der wenigstens stabil ist.
Animationen kommen dann halt irgendwann später, aber was solls.

[Schrompf]

Nun, ich mag boost::format. Die Möglichkeit, inline eine formatierte Textausgabe mit Parametern zusammenzubauen, finde ich sehr wertvoll. Allerdings habe ich inzwischen auch bemerkt, dass es da draußen genügend lernresistente Querköpfe gibt, die so dermaßen gegen Fremdbibliotheken sind, dass sie sogar das Einrichtung eines Include-Pfads in das boost-Verzeichnis als unzumutbare Beleidigung empfinden. Und mehr ist ja nicht nötig... das einzige, was tatsächlich eine ordentlich kompilierte Boost-Version erfordert, sind die Threads. Und die kann man ja separat abschalten. Alles andere ist ne reine Header-Geschichte - Boost.zip entpacken und den Include-Pfad einstellen, mehr ist nicht nötig. Aber das scheint ja schon zuviel zu sein...

Pff. Macht doch, was ihr wollt. Nebenbei: im FBX-Loader hab ich jetzt auch noch boost::lexical_cast eingesetzt. Nänänänä!

[kimmi]

Ich plädiere hier auch mal für den Einsatz von Boost. Natürlich können wir den Thread-Kram auf eine andere Library umstellen ( es gibt diesbezüglich ein Posting im Assimp-Forum ), allerdings wissen wir Null, wie die Qualität der jeweiligen Third-Party-Libs sind. Boost ist dafür bekannt, daß sie Qualität ausliefern und das der Code ziemlich gründlichen Prüfungen ausgesetzt war. Und so etwas ist für die Zuverlässigkeit nicht ganz unwichtig, gerade bei Thread-Sicherheit. Und ich gehe davon aus, daß wir in der Richtung in Zukunft auch noch etwas tun werden.
Wir könnten versuchen, eine Boost-Light-Version in den Third-Party-Kram einzubauen ( angelehnt an den Cppunit-Kram ). Boost komplett zu streichen halte ich aus Gründen der Wartbarkeit für keinen guten Weg. Irgendwann haben wir so viele Nachbauten von Boost-Konstrukten, die alle erst einmal reifen müssen, daß wir uns in meinen Augen völlig überflüssige neue Baustellen aufmachen.
Boost kommt übrigens mit einem CMake-Port daher *unschuldigguck*...

Gruß Kimmi

[Jonathan]

Oh, wenn wir jetzt darüber diskutieren: Ich bin auch dafür, boost als feste Abhängigkeit zu haben. Man muss ja nicht unbedingt irgendwelche Bibliotheken von boost nehemn, die man aufwändig kompilierne muss, aber es gibt da so viele kleine feine headeronly libs und wenn man die Freiheit hätte, die alle zu benutzen, das wäre schon nicht schlecht.
WIe schon gesagt, boost beinhaltet so ziemlich die besten C++ Bibliotheken, und jeder der kein Interesse daran hat, sich damit zu beschäftigen ist eigentlich unvernünftig.

[Aramis]

Leider ist es halt die Ist-Situation dass viele User von Assimp Boost *nicht* nutzen. Das zu ignorieren wäre imho ein Fehler.

Alles andere ist ne reine Header-Geschichte - Boost.zip entpacken und den Include-Pfad einstellen, mehr ist nicht nötig. Aber das scheint ja schon zuviel zu sein...

Wenn Projekte Boost nicht verwenden (es gibt ja immerhin auch noch einige andere eierlegende Wollmilchsäue für C++, auch wenn Boost sicherlich am profiliertesten ist), ist es kaum zumutbar dass sie nur für Assimp sich so eine riesige Abhängigkeit zumuten sollen. Dabei geht es nicht nur um 'scheint für manche zu viel zu sein'. Der boostpro-Ordner auf meiner Platte ist 724 MiB groß. Im Vergleich zu Assimp ist das absolut unverhältnismäßig. Ich hab Leute schon ganz boost als svn:external ihr Repository eintragen sehen, *nur* wegen uns. Aua.

Pff. Macht doch, was ihr wollt. Nebenbei: im FBX-Loader hab ich jetzt auch noch boost::lexical_cast eingesetzt. Nänänänä!

Pff, jetzt hab dich mal nicht so :-) Und ich hab aktuell einige shared_ptr's im Einsatz. Beides gut mit dem Workaround machbar. boost.format halt nicht mehr so einfach. Bislang hab ich den Workaround gepflegt. Ich hab nicht das geringste Problem damit, dass ich damit eurem Code immer hinterherworkarounden muss, wäre aber wirklich dankbar wenn ihr beim Einsatz von boost nur Zeugs benutzt, wo ich auch eine Chance hab. Mit C++0x wird ja sowieso eine Menge von dem was wir bislang verwenden in die Standardbibliothek einziehen. Können wir dann ja auf C++0x-Compilern verwenden (das TR1-Zeugs theoretisch auch schon jetzt).

Wir könnten versuchen, eine Boost-Light-Version in den Third-Party-Kram einzubauen

Wenn es nur um die Header für die bislang verwendeten Boost-Sachen geht – kann man vermutlich realisieren wenn man das ganze boost.config-Zeugs isoliert, aber vielleicht besser nach dem Release …?

Natürlich können wir den Thread-Kram auf eine andere Library umstellen ( es gibt diesbezüglich ein Posting im Assimp-Forum ), allerdings wissen wir Null, wie die Qualität der jeweiligen Third-Party-Libs sind.

Jupp. Dieses hier. Ich stehe dem generell positiv gegenüber, würde aber unbedingt noch abwarten wollen, schließlich ist die vorgeschlagene Bibliothek ziemlich neu und wenig praxiserprobt. Als allererster Testballon müssen wir nicht unbedingt dienen.

[kimmi]

Hi,
ich kann das Problem mit dem Boost-Klumpfuß durchaus nachvollziehen. Allerdings habe auch ich keine Lust, auf mehrere schlankere Libs auzuweichen, wo wir dann Probleme bekommen und analysieren, die nicht auf uns zurückzuführen sind. Und irgendwann einmal wird die Anzahl der andern schlankeren Libs auch größer werden. Boost besteht doch eh aus verschiedenen Libs. Warum machen wir nicht einfach Cherrypicking?
Und ich habe kein so großes Problem mit Boost als Plazfresser auf der Platte. Lieber nehme ich eine Lib, die qualitativ gut ist als daß ich 10 andere kleinere Libs benutze, die ich dann mit warten und aktualisieren darf. Das ist nun mal auch kein kleiner Zeitfresser, was ich für kritischer erachte :).

Pff. Macht doch, was ihr wollt. Nebenbei: im FBX-Loader hab ich jetzt auch noch boost::lexical_cast eingesetzt. Nänänänä!

Ein überaus wichtiger Beitrag, dessen Argumentationskette kaum zu schlagen sein dürfte :P. Das kann ich auch:
TinyThread++ ist doof ;)...

Gruß Kimmi

[Aramis]

Als ersten Testballon habe ich soeben ein erstes Paket hochgeladen, ein mit InnoSetup erstellter Installer fuer Windows. Der gibt sich nun als 1.1rc aus und entspricht SVN Revision 638. Versionsinformationen der Assimp-Binaries sind aktuell aber noch nicht aktualisiert. Enthalten sind PyAssimp und die D-Bindings. Ich bin aber noch nicht dazu gekommen die ganze Geschichte gruendlich zu testen. Falls jemand zufaelligerweise Lust hast zu testen ob der Installer auch nichts vergisst, waere das super … andernfalls werden es hoffentlich die ganzen User da draussen merken.

Uebrigens steht im Quelltext ueberall noch was von © 2006-2009. Wird Zeit das zu aendern ;-)

[klickverbot]

Ich habe ja wie gesagt im Moment leider nicht viel Zeit für Assimp, daher nur ein kleiner Kommentar die D-Bindings betreffend: Bitte im gleichen Commit, in dem die Versionsnummer in AssimpPCH.cpp angepasst wird, auch die entsprechenden Konstanten in port/dAssimp/assimp/loader.d aktualisieren:

Code: Alles auswählen

const uint ASSIMP_BINDINGS_MAJOR = 0;
const uint ASSIMP_BINDINGS_MINOR = 5;

Für mich spricht nicht wirklich etwas gegen 1.1, mal abgesehen davon, dass ich nicht wusste, dass es überhaupt schon ein Release gab. ;) Bei künftigen Releases müsste eventuell der jetzige Loader-Code der D-Bindings abgeändert werden, da er bis jetzt davon ausgeht, dass innerhalb einer Major-Version die C-ABI-Kompatibilität gewahrt bleibt.

Übrigens sind die D-Bindings bisher nur auf 32bit-Plattformen getestet. Ich werde mir eventuell auch nach dem Freeze erlauben, eventuelle 64bit-Korrekturen an den Bindings vorzunehmen, wenn ich die nächsten Tage doch einmal zum Testen kommen sollte…

[kimmi]

Wo hast du den hinterlegt ( Link )? Ich habe im Download-Bereich nichts dergleichenesgefunden und der Get-It-Button hat mir leider auch nicht weiterhelfen können. Danke!

Gruß Kimmi

[Aramis]

Siehe SourceForge-Projektseite. Ich hab allerdings vergessen den Link auf der eigentlichen Homepage anzupassen. Mist. Nunja, deswegen heisst es ja RC. Ich bin dann auch mit dem ZIP-Release fuer alle anderen Plattformen sowie fuer alle Installer-Ablehner so gut wie fertig, werde wohl nachher hochladen. Ich schreibe dann auch eine ZFX-News.

[kimmi]

Ah, da ist der. Habe ihn gerade gefunden, danke!

Gruß Kimmi

[Aramis]

ZIP nun auch hochgeladen. Erstellt von ./packaging/windows-mkzip. Enthaelt einen nahezu kompletten Checkout sowie vorkompilierte Binaries und Importbibliotheken fuer Windows. Ist auf SF.net nun fuer alle Plattformen ausser Windows der Defaultdownload.

[kimmi]

Super, das doch klasse :). Ich für meine Teil bin gut begeistert. Ich fang dann mal an zu testen.

Gruß Kimmi

[kimmi]

Eine Sache: sollten wir die PDB's nicht mit ausliefern? Das macht anderen das Debuggen leichter.

Gruß Kimmi

[Aramis]

Oh, Debug-Builds und PDBs fehlen tatsaechlich ganz. Du hast Recht, die muessen unbedingt mit.

[Aramis]

Website aktualisiert. Downloads direkt verlinkt, Farbschema etwas angepasst und ein bisschen umformuliert und aufgeraeumt.

[klickverbot]

Bezüglich der SVN-Revision-Sache: Was spricht eigentlich dagegen, die revision.h vom Build-System generieren zu lassen? Wenn Subversion nicht installiert ist, dann gibt es eben bloß eine Warnung und Revision 0, mit der Option, das händisch anzupassen. Zumindest mit CMake sollte das kein Problem sein, und Visual C++ unterstützt meines Wissen ja auch Prä-Build-Ereignisse.

[Schrompf]

Zur Revision: TortoiseSVN bringt eine SubWCRev.exe mit, die Informationen wie die Revision aus einem Repository extrahieren und in Dateien einfügen kann. Wir benutzen das bei Splitterwelten, um aus einer Vorlage

Code: Alles auswählen

// Revision.h.template

const std::string gVersion = "Splitterwelten R$REV$";

oder so einen Header zu erzeugen, bei dem das Schlüsselwort durch die Revision ersetzt wird. Das ist dann bei Visual Studio als Custom Build Step integriert und klappt größtenteils prima. Das Problem ist nur, dass die Exe sich von SVN-Version zu SVN-Version unterscheidet. Man muss also auf jedem Client die jeweils eigene SubWCRev.exe extrahieren und an einen Ort legen, wo der Custom Build Step sie findet. Das ist für eine öffentlich verteilte Bibliothek wie Assimp doch ein ziemliches Hindernis.

Zur Veröffentlichung: sehr gut! Jetzt geht's ab! Sollten wir jetzt wieder losziehen und die Landschaft mit Werbung zuspammen? :-)

Zum Forum: der MickP geht mir auf die Nerven. Wie kann man nur so ahnungslos und gleichzeitig so großmäulig sein?

[kimmi]

Soweit ich weiß, kann man bei Tortoise-SVN Hooks in den SVN-Prozess einhängen. Ich schau gerade mal nach, ob man auch auf Server-Seite solch einen Hook installieren könnte, der vor jedem Commit die von dir angegebenen Applikation ausführt, wäre das eine Lösung, die unabhängig von lokalen Installationen geht. Ich schau mal, was bei Sourceforge da geht.

Gruß Kimmi

[Schrompf]

Ich fress den Typen noch, wenn der weiter so unverschämt die "ist ja nicht für mich, sondern die Allgemeinheit will das so"-Karte spielt.

[Aramis]

SubWCRev.exe mit so einem Template waere tatsaechlich optimal. Leider kann man wohl auch TortoiseSVN nicht ueberall voraussetzen? Also:

svnversion.exe (so laeuft es aktuell, ist nur nicht im Build mit drin)
SubWCRev.exe

in der Reihenfolge ausprobieren. Das sollte dann auf den meisten Rechnern klappen.
Oder waere es lizenztechnisch moeglich die 32-Bittige SubWCRev.exe mit einzuchecken?

Sollten wir jetzt wieder losziehen und die Landschaft mit Werbung zuspammen?

Unbedingt, aber erst beim wirklichen Release, denke ich. Aber eine ZFX-News und eine Ankuendigung auf der ML und im Assimp-Forum koennen wir ja schonmal machen.

Ich fress den Typen noch

Ich bin dabei.

Was wir allerdings nach diesem Release wirklich mal einfuehren koennten, waere dass Importer auch Vertices im nicht-verbose Format zurueckgeben koennen. Wir haben ja schon den ScenePreprocessor der immer direkt nach dem Importer aufgerufen wird. Wenn die Meshdaten nicht im Verbose-Format sind, koennte der sie ganz einfach darin ueberfuehren. Das wuerde einiges an Code-Duplikation in den Loadern reduzieren.

Zu den Faces - hmpf. Vielleicht die Haelfte der Dateiformate indiziert Texturkoordinaten und Vertices separat. Gut, bei denen gibt es dann minimal duplizierte Vertices. Ich denke die Face-Struktur war eine Designentscheidung an der wir auf keinen Fall ruetteln sollten. Ganz mal davon abgesehen dass ein Face, dass nicht nur einen Satz Indices sondern 20 speichert zum Weiterverarbeiten haesslich wird.

[Aramis]

Wenn wir uebrigens grade dabei sind. Der Typ fragt wie aktiv Assimp ist, und auf der SF.net Startseite verzeichnet das Update-Log gerade mal … 30 Commits in ein paar Tagen? Ich will das Mittelalter und die Inquisition zurueck.

[kimmi]

Hm, das muß ich mir mal selber ansehen.

Darf ich die Daumenschrauben ausprobieren, bitte? ;)...

Gruß Kimmi

[klickverbot]

Ich habe TortoiseSVN gerade entfernt und neu installiert – das bin/-Verzeichnis wird sehr wohl zum systemweiten Pfad hinzugefügt. Oder habe ich dich hier falsch verstanden, Schrompf?

Und wenn der Benutzer auf seinem Entwicklungsrechner weder Subversion noch TortoiseSVN installiert hat, dann muss er die Revision eben händisch nachtragen, das sollte nicht unser Problem sein. Der Build sollte halt nur nicht komplett fehlschlagen, das wäre nervig.