Assimp - Brainstorming zum Release

[Schrompf]

Kurze Meldung meinerseits: habe letzte Woche den letzten mir bekannten Collada-Bug geplättet. Von meiner Seite aus steht dem Assimp-Release nix mehr im Wege. Ich habe gestern den FBX-Loader angefangen, aber an dem bastle ich nur in Halb-Stunden-Portionen auf Arbeit, während mein Rechner kompiliert. Es wird also noch Wochen dauern, ehe da die ersten Ergebnisse sichtbar sein werden. Und das FBX-Format ist (absichtlich) nirgends dokumentiert. Das wird also eine langwierige Übung in Reverse Engineering, bei der auch in Jahren noch kleine Details auftauchen, die es zu korrigieren gilt.

Soweit ich das bislang aber bewerten kann, ist die innere Struktur eine sehr logisch konsequente Struktur aus Objekten mit Properties... ich habe die Hoffnung, dass sich nach Schaffung einiger Grundlagen zumindest bei statischen Szenen bald Ergebnisse zeigen.

[Aramis]

Naja, und ich räume grade auf, wie am Commitlog zu sehen ist. Ziemlich nervtötend all den kleinen und großen Bugs, Unschönheiten und Inkonsistenzen nachzurennen, die sich so über die Jahre - das kann man ja wohl langsam sagen :-) - angesammelt haben. Schreibt mir bitte einfach via ICQ/Skype/PM wenn ich etwas, das ich mal versprochen habe, vergessen sollte :-)

Grade eben ein etwas größerer Patch: BaseImporter::GetExtensionList() refaktorisiert. Sammelt jetzt alle Dateierweiterungen sauber in einem std::set, womit Assimp jetzt keine Duplikate mehr auflistet. Ich hab alle Importer dahingehend abgeändert. Ihr werdet aber leider bei euren, sich in Arbeit befindlichen und noch nicht eingecheckten, Loadern selber Hand anlegen müssen. Ich hoffe es ist verkraftbar.

[klickverbot]

Ich habe jetzt wie vereinbart im Repository gewütet, Einzelheiten könnt ihr dem Commit-Log entnehmen. Ich würde euch bitten, möglichst alle Konfigurationen schnell zu testen, ich habe die .vcproj-Dateien mit einem Texteditor angepasst…

Mein aktueller Stand SWIG betreffend wird heute auch noch ins SVN wandern, wie in #zfx abgesprochen.


Edit: Etwaige Steinigungen bitte erst nach dem Release ;)[/i]
Edit 2: Die SWIG-D-Bindings kommen morgen, vorher muss ich noch mein D-SWIG-Modul verbessern…

[Aramis]

Ich hab heute den ganzen Tag keine Probleme bemerkt (weder mit vc8 noch mit vc9). Scheint also alles in Ordnung zu sein ;-)

Desweiteren habe ich soeben ein neues Verzeichnis namens `packaging´ im Root-Folder angelegt. Aktuell sind da nur die Batch-Dateien um die Release-ZIPs unter Windows zu generieren (ehemals `mkutil´). Für weitere Distributionsvarianten (z.B. `echter´ Installer, Debian-Pakete, …) hier einfach einen neuen Unterordner anlegen.

Für den Rest der Änderungen siehe Commitlog.

[Aramis]

Die lange angekündigte Testsuite ist nun erstmals im Repos zu finden … zusammen mit einem halben Dutzend Fixes für Bugs, die nur aufgrund ihr entdeckt wurden - insofern scheint die etwas unmotivierende Arbeit sich teilweise bereits gelohnt zu haben.

Im Verzeichnis ./test/regression/ findet ihr ein README, ich bitte euch alle, es zu lesen und den darin enthaltenen Instruktionen zu folgen. Idealerweise sollte nach kritischen Commits die Suite neu durchlaufem werden (run.py), nach Beseitigung aller neu auftretenden Regressionen muss dann die ganze Testdatenbank mit MSVC/fp:precise neu erstellt - und eingecheckt - werden (gen_db.py).

Ein Fehlerbericht sähe beispielsweise so aus:

Code: Alles auswählen

assimp dump: Wrote output dump ../results/tmp/Koerper.mesh.xml_0xac63afcd/ACTUAL
assimp cmpdump --------------------------------------------------------------------------------
Files are different at aiNodeAnim.mRotationKeys.<minimum-value>.x.
Error is: Expected -3.68935e+19, but actual is -2 (delta is 3.68935e+19).
Current position in scene hierarchy is 
aiAnimation(Index: 5)
  aiScene(Index: 0)
    ---(Index: 0)

(das ist übrigens ein reallife-Beispiel, der Ogre-XML Importer scheitert unter GCC an allen Tests, die unter Windows/MSVC klappen - ich tippe auf uninitialisierte Daten o.ä.).

Die unvermeidbaren Ungenauigkeiten durch Compiler-Optimierungen im Fließkommabereich sind beim Vergleich der Mini-Dumps durch ein geeignetes Epsilon berücksichtigt. Was dabei aber auch herauskam: fp:fast vs. fp:precise hat weitaus weitreichendere Auswirkungen als angenommen (gleiches gilt für verwandte g++-Optimierungsflags) … wenn es nur die hintersten Nachkommastellen der Vertexnormalen wären, so wäre ja alles in Ordnung … leider verändern sich bei einzelnen Files die Vertex- sowie Dreiecks-Zahl und -Reihenfolge, was natürlich nicht tolerierbar ist. Verantwortlich sind nach jetzigem Stand JoinIdenticalVertices, Triangulate sowie FindDegenerates. Ich bin auf der Suche nach einer Lösung.

Das Ziel, dass *alle* 570+ Tests auf allen Plattformen erfolgreich durchlaufen werden (sprich, dass Assimp's Ausgabedatenstruktur mit der Testdatenbank übereinstimmt, für alle Modelle im Repos), wird wohl nicht zu erreichen sein. Mit den Fixes der letzten Tage konnte ich die Zahl der Fehler wenigstens in den unteren einstelligen Prozentbereich drücken. Wenn sich die oben erwähnten Probleme in den Griff kriegen lassen, liegt vermutlich noch mehr drin.

[Jonathan]

(das ist übrigens ein reallife-Beispiel, der Ogre-XML Importer scheitert unter GCC an allen Tests, die unter Windows/MSVC klappen - ich tippe auf uninitialisierte Daten o.ä.).

Ich behalte es im Hinterkopf und werde mir die Sache mal angucken, aber ich denke, erstmal kümmere ich mich um die falschen Transformationsmatrizen.

[Aramis]

Ahoi!

Der MS3D-Loader sollte nun einsatzbereit sein. Alle meine Testfiles laufen, auch wenn da sicherlich noch einige Animationsprobleme auftauchen werden.
An sich denke ich, dass wir langsam mal ein fixes Datum für unser Release ins Auge fassen sollten.

Vorschlag: am Samstag, den 3. April 2010 Feature-Freeze. Vorläufige Pakete hochladen („RC“). Dann nur noch Bugfixes & ungefährliche Schönheitskorrekturen. 2 Wochen später, am 17. April 2010 dann das Release. Pakete ggf. nochmals aktualisieren, in den üblichen Foren Newsmeldungen einstellen, Ansturm an Jammer- und Meckerern abwarten.

Was haltet ihr davon?

[klickverbot]

Wie so oft kommt bei mir gerade alles ganz anders als gedacht, was leider unter anderem zur Folge hat, dass ich in unmittelbarer Zukunft nur wenig Zeit für Assimp und SWIG haben werde. Sofern nicht von anderer Seite für Java/C# dran gearbeitet wird, müsste bitte jemand die halbfertigen Bindings vor dem Erstellen des RC aus dem Repository entfernen oder eventuell in einen eigenen Branch verschieben.

[Jonathan]

Hört sich nett an. Der Ogre Loader sollte auch bald gehen, ich habe in den letzten Tagen 3 große Denkfehler entdeckt (so langsam beginne ich zu verstehen, wie Animationen funktionieren, hehe) ich hoffe dass es jetzt bald reicht. Naja Semesterferien und so, da muss ein halber Monat reichen um es fertig zu stellen und ausreichend zu testen.
Und naja, dann einen (hoffentlich) stabilen Release zu haben wäre auch klasse, da ich Assimp ja in meinem Spiel nutzen will, und damit weiter mache, sobald der Ogre Importer läuft.

[Schrompf]

Der FBX-Loader lädt momentan statische Meshes, aber mehr auch nicht. Ich unterstütze den Termin für den Feature Freeze - wenn der Loader bis dahin noch nix sinnvolles kann, kommt er halt nicht mit ins Release.

[Aramis]

Auch statische Meshes sind ja was, für die meisten User ausreichend - sollte man ihnen also nicht vorenthalten, denke ich :-) Geht es eigentlich um das binäre FBX-Format, das textbasierte oder beide?

[Schrompf]

Momentan nur text-FBXe. Nur statische Meshes ohne Trafos und ohne Parent-Child-Relations. Alle Geometrie klumpt sich also im Koordinatenursprung.

Bis zum Termin sind's noch zwei Wochen. Wenn ich bis dahin komplette statische Szenen aus Nur-Text-Files lesen kann, dann würd ich den Loader mit ins Release nehmen. Ansonsten halt nicht.

[kimmi]

Ich werde mal zusehen, ob ich bis dahin den Q3-BSP-Loader hinkriege, allerdings sieht das gerade zeitlich mal wieder etwas mau aus. Ich habe schon: einen Zip-Loader für das BSP-Format, Laden der statischen Geometrie.
Da da noch viele Baustellen offen sind, glaube ich nicht, daß ich dsa rechtzeitig fertig kriege.

Gruß Kimmi

[Matthias Gubisch]

Ich hoffe mal dass die Java/C# Bindings bis dahin auch werden

Ich hab den fuer diese Bindings relevanten Teil von klickverbots swig files uebernommen was den Fortschritt brachte dass die arrays und templates jezt vernuenftig funktionieren.

Heist auf der C#-Seite muessten noch ein paar Warnungen des SwigWrappers gefixed werden, aber die groebsten Sachen scheinen zu passen.

Aramis: Bei Java muesste das aehnlich aussehen oder? Die beiden Sprachen sind sich ja doch ziemlich aehnlich. Denk mal dass einige Warnings einfach fuer beides gefixed werden koennen.


Das groessere Manko ist dass ich es bis April wohl nicht mehr auf die Reihe bekommen werde die C#-Bindings vernuenftig zu testen....
Sollte da jemand Zeit dafuer haben waer des super

Gruesse
Matthias

[Chromanoid]

ooh ich hatte immer gedacht die java variante wäre kein binding sondern pure java :/ naja für java bindings würde ich immer JNA benutzen...

[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