Assimp - Brainstorming zum Release

[klickverbot]

Gut, dann lasse ich die code/makefile*s als Minimalvariante bestehen. Ich würde mich dann in den nächsten Tagen einmal um CMake kümmern und SCons anschließend entfernen.

rave3d (wer war das noch gleich) und Aramis, ich verfolge gespannt eure Versuche mit SWIG. Ich habe in einem lokalen Branch schon einen relativ fortgeschrittenen Branch (die Anpassung beziehen sich auf mein eigenes D-Modul, sind also für euch nicht interessant), bin aber nicht recht weit gekommen, ohne händisch Wrapper für alle »Pointer-und-Länge«-Member zu schreiben. Haltet mich bitte auf dem laufenden, auch wenn es der Code nicht in das Repository schaffen sollte.

[Aramis]

Jau, das von dir angesprochene Problem mit den mXXX-mNumXXX-Paaren ist heikel .. sollten wir zu dritt dafür keine brauchbare Lösung finden, kann man SWIG für den Zweck wohl vergessen.

Meine Erfahrung mit maschinell generierten Python3-Wrappern für ein 80KLoc-Projekt war, dass es fast unumgänglich ist SWIG's Input irgendwie maschinell vorzubereiten, schon alleine um Stellen zu umgehen an denen der Parser hängenbleibt (die gibt es in Assimp ja glücklicherweise nicht). Prinzipiell könnte man in unserem Fall alle Pointer+Num-Paare suchen und sie zu _einem_ Member zusammenfügen, den man dann mit passenden Typemaps durchreichen könnte ... liefe also drauf raus per Skript (Python, Perl, WasAuchImmer - wäre ja egal da es ja sowieso bloß beim Neu-Generieren der Wrapper ausgeführt werden muss) die Assimp-Header vorzubearbeiten, alles in eine Datei reinzustopfen und die an SWIG zu verfüttern.

Code: Alles auswählen

struct aiFace {
   unsigned int mNumIndices;
   unsigned int* mIndices;
}

template<typename T> struct AssArray 
{
   unsigned int num;
   T* ptr;
};

struct aiFace {
   AssArray<unsigned int> mIndices;
}

Das ist aktuell eine eher unausgereifte Idee ... aber vielleicht eine mögliche Lösung. Sicherlich fällt einem von euch gleich ein entscheidender Denkfehler daran auf, dann kann man sich die Arbeit sparen es auszuprobieren :-)

@Matthias Gubisch:
Deine SWIG-Konfig liefert auch für Java gute Ergebnisse! Das ganze C-API kann aber raus, denke ich - (aiFileIO.h). NullLogger.h wird eigentlich auch nicht benötigt. Ich schmeiße meine Papierkorb-Konfig von vorhin dann wieder raus und teste/arbeite auch mit der AssimpSwigPort.i. Ich wäre dir aber dankbar wenn wir den Modulnamen einfach auf 'assimp' ändern könnten :-)

[kimmi]

Na dam auch einen kleinen Zwischenstand von mir: ich habe den BSP-Loader angefangen und ringe wie üblich um Zeit, da weiter zu kommen :). Aber da kommt noch was von mir!

Gruß Kimmi

[Matthias Gubisch]

Hi

@Aramis
Also den Modulnamen können wir Problemlos ändern.
Könntest du die Dateien entfernen die deiner Meinung nach nicht benötigt werden?
weil ich hab frühestens am Donnerstag Zeit dafür

Grüße
Matthias

[Aramis]

Ich kam auch erst jetzt dazu. Die verbleibenden Header sollten ausreichen. Wenn ich mir den Output aber genau anschaue verbleibt da noch viel zu tun.

[kimmi]

Der CMake-Install-Patch ist geliefert. Das lief auch soweit bei mir unter Windows. Nicht wundern: in den CMake-Files sind einige Files auskommentiert. Das sind die, die für den BSP-Loader drinn sind, aber noch nicht von mit committed wurden.

Gruß Kimmi

[Aramis]

Hab es nur schnell getestet. Build mit cmake (2.6-p4) lief sauber, install über das generierte makefile scheitert noch wie folgt:

Code: Alles auswählen

acg@acg-laptop:~/dev/assimp/trunk$ sudo make install
.. 
[100%] Built target assimp
Install the project...
-- Install configuration: ""
-- Installing: /usr/local/lib/libassimp.so.1.0.0
-- Installing: /usr/local/lib/libassimp.so.1
-- Installing: /usr/local/lib/libassimp.so
CMake Error at code/cmake_install.cmake:54 (FILE):
  file INSTALL cannot find file "/home/acg/dev/assimp/trunk/code/aiAnim.h" to
  install.
Call Stack (most recent call first):
  cmake_install.cmake:37 (INCLUDE)

make: *** [install] Error 1

.. es sucht scheinbar im falschen Verzeichnis.

[kimmi]

Jupp, da ist was krumm. Ich schau mal!

Gruß Kimmi

[klickverbot]

Ich wollte gerade einen Fix committen, da sehe ich, dass du das schon gemacht hast, kimmi. ;)

[kimmi]

Jupp, ich war schneller ;). Aber Danke für die Mühe ...

Gruß Kimmi

[klickverbot]

Gibt es einen Grund, wieso du im Library-Target die Header explizit aufgelistet hast, anstatt einfach PUBLIC_HEADERS und COMPILER_HEADERS mit aufzunehmen (wie ich in meinem Patch)? Das ganze ist ohnehin nur nötig, um den MSVC-Generator dazu zu bringen, die Header in das Projekt-File aufzunehmen, aber würden die Variablen nicht auch reichen?

EDIT: Welche Boost-Version braucht Assimp mindestens?

[Aramis]

Wunderbar, funktioniert jetzt. Danke!

Damit entstünde die Frage, was wir mit dem alten Makefile in ./code machen. Ich bin dafür es einstweilen zu lassen, es aber als deprecated zu markieren (z.B. als Ausgabe beim Build). Setze ich in der Form um -- wenn niemand Einspruch erhebt.

@BoostWorkaround nach Code - dito.
@BoostVersion: 1.35 (war zum Zeitpuntk der Projektgründung aktuell. foreach und tuple sind die einzigen Boost-Libs, die erst später verwendet wurden. Beide in 1.35 gemäß Versionsgeschichte bereits enthalten).

- Alex

[klickverbot]

@BoostWorkaround nach Code - dito.

Die Arbeit brauchst du dir nicht zu machen, ich habe einen entsprechenden Branch schon in meinem lokalen Git-Repository, der nur noch auf die Freigabe wartet.

Eine Frage zum Thema hätte ich aber noch: Aus welchem Grund sind die Pfade zu den Boost-Workaround-Headern per #ifdef hardgecodet¹? Ob man als Benutzer nun ein Include-Verzeichnis oder eine Präprozessor-Definition zu den Compiler-Optionen hinzufügt, sollte doch wirklich egal sein – erst recht, wenn einem die mitgelieferten IDE-Projektdateien bzw. CMake-Skripte sowieso ersparen, sich mit diesen Details auseinanderzusetzen…

Mein SWIG-D-Port macht übrigens auch Fortschritte. Ich habe mich jetzt einfach entschlossen, die Vorschlaghammer-Methode anzuwenden und alle Zeiger-und-Länge-Arrays als std::vector zu wrappen. Den aktuellen Stand gibt es auf GitHub zu sehen.

¹ Entschuldigt bitte das Deutsch – das kommt davon, wenn man den ganzen Tag lang in Englisch programmiert und schreibt… ;)

[Aramis]

Das stammt noch aus der Zeit als das Buildsystem etwas unausgereift und inhomogen war. Ein einzelnes Define war überall recht leicht umzusetzen (Faulheit ..). Dank deiner und Kimmis CMake-Anstrengungen besteht das Problem grundsätzlich nicht mehr :-) also kann man in der Tat auf einheitliche Includes ohne #ifdef wechseln.

EDIT: Die Boost-Includes sind sowieso etwas ... zu global für meinen aktuellen Geschmack, teilweise gar nicht mehr benötigt. Ich räume da mal etwas auf, in kleinen Etappen.

[Aramis]

Die Arbeit brauchst du dir nicht zu machen, ich habe einen entsprechenden Branch schon in meinem lokalen Git-Repository, der nur noch auf die Freigabe wartet.

Fein!
Das random-Unterverzeichnis im BoostWorkaround wird seit soeben nicht mehr benötigt, insofern kannst du es beim Einchecken gleich weglassen :-)

[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...