Asset-Importer-Lib Version 3.3 released

[kimmi]

Nach einem Jahr gibt es wieder ein neues Asset-Importer-Lib-Release. Insgesamt sind mehr als 500 neue Commits Teil dieses Releases. Unter https://github.com/assimp/assimp/releases/tag/v3.3 könnt Ihr die Highlights nachlesen.

Ich hatte mir ursprünglich als Ziel gesetzt, vor v3.3 auf unter 100 Issues zu kommen. Das hat fast geklappt. Aktuell sind etwa 188 Issues offen :). Aber ich gebe nicht auf.

Vielen Dank für all den Support der letzten Jahre!

Gruß Kimmi

[Krishty]

Super! Auf die Gefahr hin, dass die Antwort höchstwahrscheinlich „selber machen“ ist:

1. Werdet ihr irgendwann mal Fortschrittsanzeigen implementieren?
2. Werdet ihr dabei auch Abbruch unterstützen?

Sind die Issues, die Assimp recht UI-unfreundlich machen …

Nachtrag: Da hat ja jemand den Cinema4D-Code aktualisiert! Geschah das auf mein Nachhaken oder einfach so?

Nachtrag 2: Das dynamic_cast dort funktionierte bei mir nicht, aber ich hatte vielleicht auch eine andere SDK-Version. Ich werde am Wochenende aktualisieren und dann prüfen, ob’s jetzt in Ordnung ist.

Ach, und: Willst du keine News draus machen?

[Jonathan]

Super! Auf die Gefahr hin, dass die Antwort höchstwahrscheinlich „selber machen“ ist:

1. Werdet ihr irgendwann mal Fortschrittsanzeigen implementieren?
2. Werdet ihr dabei auch Abbruch unterstützen?

Sind die Issues, die Assimp recht UI-unfreundlich machen …

Hm, das hört sich so an, als müsse das jeder einzelne Importer unabhängig voneinander unterstützen, oder? Dürfte ein ziemliches Monsterunterfangen sein, das zu implementieren.

[Krishty]

Ja. Wenn sowas nicht von Anfang an eingeplant wird, läuft das auf Sisyphosarbeit hinaus.

Aber Assimp hat doch I/O gewrappt, oder? Wenn die Importer etwas lesen, kann man gucken, wie weit in der Datei das ist. Darüber kann man dann den Fortschrittsbalken annähern. Geht *natürlich* kaputt bei Formaten, die viel hin- und herspringen, würde aber viele einfache Formate mit minimalem Aufwand abdecken.

Das andere Monsterunterfangen ist Lokalisierung, die ist bei Assimp auch total verkackt. Ich dachte erst, dass die Codes vor den Assimp-Nachrichten Fehlercodes wären, aber es ist … die Thread-ID -.- Naja; wer die Fehlermeldungen eines Mesh-Imports braucht, kann wahrscheinlich auch Englisch.

[kimmi]

Hi Krishty:
- Abbruch des Importes ist als Packet für den nächsten Release vorgesehen: per Exception
- Fortschrittsanzeigen haben wir als Issue drinne, ich meine auch, wir haben bereits einen Progresshandler gebaut.

Ansonsten wollte ich mich mal an eine vernünftige nebenläufigkeit machen. Und Pointclouds sind auch noch vorgesehen. Und FBX stabiler machen. Und und und ...

Da hilft es, dass ich gerade nach einem neuen Job suche :).

Gruß Kimmi

[Krishty]

Hi Krishty:
- Abbruch des Importes ist als Packet für den nächsten Release vorgesehen: per Exception

Mein Notallplan war, Speicheranfragen mit Exceptions zu beenden, sobald abgebrochen werden soll. Da Assimp konstant irgendwo Speicher anfragt, hat man da eine ganz gute Reaktionszeit. Meine Erfahrung mit Drittbibliotheken ist aber, dass sie dann instabil werden; und ich befürchte, dass auch bei Assimp nicht alle Fehlerpfade getestet worden sind.

- Fortschrittsanzeigen haben wir als Issue drinne, ich meine auch, wir haben bereits einen Progresshandler gebaut.

Alles klar; werde ich am Wochenende ansehen.

Ansonsten wollte ich mich mal an eine vernünftige nebenläufigkeit machen.

Bringt IMHO nur für Post Processing was. Die einfachen Formate (STL usw) sind nicht ALU-bound, sondern hängen an der HDD-Übertragungsrate. Die komplexen Formate (DXF/DWG habt ihr nicht, aber damit hatte ich mal zu tun) sind derart verwurschtelt, dass man praktisch gezwungen ist, sie seriell abzuarbeiten. Außerdem wollen Kontrollfreaks wie ich steuern können, wie die Aufgaben verteilt werden (ich versuche z.B. verzweifelt, alle Drittbibliotheken auf einen gemeinsamen Thread Pool umzubiegen, damit ich nicht dauernd 60 Threads debuggen muss). Fortschrittsanzeigen und Abbruchbehandlung müsste ebenfalls unter den Threads abgestimmt werden.

Falls du höhere Leistung willst: Ich hatte doch Region-Based Memory Management eingebaut, weil ich mit eurem Memory Management unzufrieden war. Das war vor zwei Jahren – ich weiß nicht, ob ihr die Bottlenecks mittlerweile beseitigt habt – und hat die Leistung verfünfzehnfacht; viel mehr, als Nebenläufigkeit bewirken würde. Mach doch lieber sowas.

Da hilft es, dass ich gerade nach einem neuen Job suche :)

Wenn ich Geld hätte, würde ich dich für die Assimp-Weiterentwicklung bezahlen. Mal gucken, wo wir in ein paar Jahren sind ;)

[kimmi]

Wenn geht es bei Nebenläufigkeit auch nur um Post-Processing + Regressions-Tests. Die fressen zur Zeit am meisten Zeit und auch nur dort sehe ich Potentiale.

Dazu haben wir allüberall verschiedenste Hacks, die ich hoffentlich nach und nach etwas mehr bereinigen kann. Man muss die Zeit zwischen 2 Jobs ja effektiv nutzen, gelle?

Kleinere Spenden würde uns auch das Leben etwas einfacher gestalten. Zur Zeit tragen wir die Kosten der Webseite über Donations. Mal schauen, was die Zukunft so bringt.

Gruß Kimmi

[Krishty]

Fun Fact: seit dem letzten Release kann ich nicht mehr auf meinem 32-Bit-System kompilieren; VC meldet immer out of memory :)

[kimmi]

Bei welchem File?

[Krishty]

Während der Link Time Code Generation, also beim Optimieren am Ende.

[kimmi]

Hm, das ist aber schade. Irgendeine Idee, wie man dem entgegenwirken könnte?

[Krishty]

Codeumfang reduzieren. Ist kein Ding; Firefox war schon vor zehn Jahren an diesem Punkt. Wer heute noch mit einer 32-bit-Gurke kompiliert (ich), ist selber schuld.

[Krishty]

Der dynamic_cast in C4DImporter.cpp funktioniert noch immer nicht. Ich weiß auch nicht, was ich da falsch mache. Aber sonst ist der Code jetzt endlich komplett kompatibel zum aktuellen SDK; tolle Sache. Ist auch deckungsgleich mit meinen eigenen Änderungen von vor einem halben Jahr.

Danke für’s schöne Release! :)

P.S.: Mache ich was falsch, dass ich 300 Warnungen wegen Konvertierung von size_t zu 32-Bit-Integer bekomme?

[Krishty]

- Fortschrittsanzeigen haben wir als Issue drinne, ich meine auch, wir haben bereits einen Progresshandler gebaut.

Der wird bisher ausschließlich vom OBJ-Loader genutzt, aber es ist ein Anfang :) Dann klinke ich mich in den ein. Ach neee, geht garnicht – der steht ausschließlich über Importer zur Verfügung. Zum einen setzt das eine C++-API voraus (ich brauche C), zum anderen wird der Importer erst zur Laufzeit entsprechend dem Dateiformat ausgewählt (oder?) … habe ich via aiImportFileExWithProperties() und Konsorten keine Möglichkeit, da irgendwie meinen eigenen Zeiger reinzukriegen?

[Krishty]

Ich nörgle einfach mal hier weiter weil ich das verdammte SourceForge-Passwort vergessen habe (erst einmal im Leben benutzt) und keine Wiederherstellungsinfos bekomme:

• STLImporter::LoadBinaryFile(): Da ist dieser Code-Block, der den String COLOR= sucht:
  • Der liest über das Dateiende hinaus, falls die Datei genau 84 B groß ist und das 79. Byte “C” lautet.
  • Der erkennt CCOLOR (doppeltes C!) nicht, weil das sz++ auch dann ausgeführt wird, wenn der Buchstabe unterschiedlich ist.
• Ihr verarbeitet Dateigrößen überall als 32-Bit-Zahlen; ich habe hier mit bis zu 8 GiB großen Dateien zu tun und dann brechen die Checks zusammen (insbesondere ist expectedBinaryFileSize = faceCount * 50 + 84; anfällig für Integerüberläufe und entsprechende Attacken!)
   
• Ein riesen Problem mit STL ist die fehlende Maßeinheit:
  • Viele alte CAD-Programme exportieren in Metern, da importiert Assimp korrekt.
  • Viele neue Programme (so ziemlich alle, die irgendwie mit 3D-Druck in Berührung gekommen sind, denke ich) exportieren in Milimetern; da spuckt Assimp dann kilometergroße Meshes aus.
  • Man kann viele Fälle (natürlich nicht alle – aber genug, um gut der Hälfte der Nutzer einen Mehrwert zu bieten) durch die Signaturen der Programme erkennen (vor allem bei binär-STL). Dann kriegt man öfter korrekt skalierte Objekte raus.
• Ihr könnt keine Dateien laden, die mit einem Zeilenumbruch beginnen (ihr filtert nur Leerzeichen und Tabs). Ich glaube, eine entsprechende Datei liegt sogar in eurem Testverzeichnis.

Ich soll hier gerade unsere Importfehler auswerten. Falls da noch mehr auftaucht, werde ich einen eigenen STL-Importer schreiben und zusehen, dass ich den irgendwie mit Assimp verschmolzen kriege. Falls nicht: fixt das!