AssetImporterLib release 3.2 ahead

[kimmi]

Hallo,

ich will den 3.2 release fertigmachen. Allles, was uns davon abhält, bitte hier posten: https://github.com/assimp/assimp/issues/679

Danke,
Kimmi

[Krishty]

Mein Assimp hier ist zwei Jahre alt und ich muss es mal aktualisieren. Habe nicht die Zeit, das öfter als ein- oder zweimal zu tun, und eine große Hilfe wird euch das sowieso nicht sein, aber … sag einfach bescheid, wann ich’s machen soll. Vielleicht kurz vor Release oder so. Wenn ich’s kompiliert kriege, schafft’s auch jeder andere.

[kimmi]

Danke für das Angebot. Versuch dein Glück einfach ab sofort :).

Kimmi

[Krishty]

Okay ... vorher hatte ich die Version vom 15.06.2014. Wurde ja Zeit, da mal was zu tun :)

Keine Showstopper, nur eine schlechte Angewohnheit: An vielen Stellen Default-Pfade statt relativer zu nutzen (#include <> statt #include ""):

• Alle Drittbibliotheken nutzen relative #includes, nur der OpenDDL-Parser nicht.
• Ebenso alle Exporter außer OpenGEXImporter.h (46).
• ObjExporter.h (37), ObjExporter.cpp (49), ObjFileParser.h (30), ObjFileData.h (36), ObjFileMtlImporter.cpp (51), ObjFileParser.cpp (47), uvm. Im Grunde Find <assimp*>, Replace "../include/assimp*"
• Geht der C4DImporter nur mit dem Cinema4D-SDK?

Sind nur Details, aber bisher hatte ich's immer genossen, Assimp kompilieren zu können ohne #include-Pfade eintragen zu müssen :)

So. Kompilieren mit Visual Studio läuft also. Wirklich den Import ausprobieren muss leider noch ein paar Tage warten.

An dieser Stelle nochmal danke an euch alle für die geile Bibliothek ... ich nehme mir in regelmäßigen Abständen vor, auch etwas beizusteuern; aber die entsprechenden Projekte haben sich dann doch immer ein Bisschen anders entwickelt. One day ...

[Schrompf]

Nuja, da mich dieser Include-Kram auch heftig nervt, könntest Du ja einfach Deine jetzt genannten Include-Änderungen als Patch einstellen :) Mir würdest Du damit einen Gefallen tun. Ich dachte bisher, die globalen <>-Includes wären nötig, damit der Kram auch in den Linux-Distros läuft, in denen die Dateien ja über das gesamte System verstreut wird. Wenn das <> vs. ""-Ding aber eh nur Zufall nach Wahl des jeweiligen Autors war, könnte man das ja geradeziehen und aus Assimp wieder eine sinnvoll baubare Lib konstruieren.

[kimmi]

Das halte ich für einen Nachteil. Unter Linux kann man die includes getrennt halten von den Libs, wenn man keine Includes benutzt. Außerdem haben <> includes den netten Vorteil, dass sie einen Spur schneller sind als "" ( es werden weniger Suchpfade durchlaufen aus einem Grund, der mir gerade nicht komplett geläufig ist, das haben wir in unserem Laden mal gemessen ).

Kimmi

[Krishty]

Das halte ich für einen Nachteil. Unter Linux kann man die includes getrennt halten von den Libs, wenn man keine Includes benutzt.

Wenn man die Abhängigkeiten nicht selber kompiliert, meinst du? Halte ich in diesem Fall für sinnlos, da Assimp ja alle Abhängigkeiten beiliegen. Scheint ja bisher auch kein Problem gewesen sein, sonst wären nicht > 90 % der Selbst-Includes relativ.

Außerdem haben <> includes den netten Vorteil, dass sie einen Spur schneller sind als "" ( es werden weniger Suchpfade durchlaufen aus einem Grund, der mir gerade nicht komplett geläufig ist, das haben wir in unserem Laden mal gemessen ).

Woah. Das Durchlaufen der im Schnitt vier Ordner pro rund 300 #include-Anweisungen projektweit ist der Flaschenhals beim Kompilieren? Mit messbarem Unterschied? So argumentiere bei so einem Thema eigentlich nicht einmal ich ;) (Das müsste ich wissen -- da ich im Augenblick nur ein Netbook habe, hat Assimp bei mir ungelogen 46 Minuten kompiliert.)

@Schrompf: Ja, mache ich demnächst mal irgendwie irgendwann. Ich bin aber froh, wenn ich heute überhaupt mal dazu komme, einen Import zu starten.

[kimmi]

Das war ein Unterschied von etwa 20%. So gering ist der Effekt nicht.

Die anderen 10% ziehen eine lokal installierte zlib vor :).

Kimmi

[Krishty]

1>assimp\contrib\openddlparser\code\openddlexport.cpp(261): warning C4477: 'sprintf' : format string '%d' requires an argument of type 'int', but variadic argument 1 has type 'size_t'
1> assimp\contrib\openddlparser\code\openddlexport.cpp(261): note: consider using '%zd' in the format string

[Krishty]

Was ist denn mit dem C4D-Import los? Überall Syntaxfehler …

[Krishty]

Also … Cinema4D-Support ist abgefuckt. Scheint so auf 2012 stehen geblieben zu sein.

Das aktuelle Melange-SDK (16) hat eine Menge Änderungen hinter sich – vom Umbenennen fundamentaler Datentypen und namespaces bis hin zur Art, wie auf Daten zugegriffen wird. Ich glaube, Assimp ist noch für Version 6 ausgelegt.

Man kann das recht einfach fixen; hat mich zehn Minuten gekostet. Ist aber noch nicht das Hauptproblem.

Irgendwie scheint die ABI des SDKs nicht zu meinem Assimp-Projekt kompatibel zu sein. Im Speziellen habe ich eine Stelle, an der dynamic_cast nicht funktioniert und auch der Debugger gibt mir einen falschen Objekttyp aus. Wenn ich aber trotzdem ganz brutal via static_cast zum Typ caste, der da sein sollte, funktioniert es plötzlich und spuckt auch die wirklichen Daten aus. Jetzt zittere ich nur, dass es demnächst kracht.

Das ist nichts, was ich als ahnungsloser User mal schnell ändern und pushen will – da sollte der ran, der das Ding im Original geschrieben hat. War das Aramis?

[kimmi]

Ja!

[Krishty]

… dann kann ich mir ungefähr vorstellen, was er mir sagen würde. Also irgendwann, wenn ich mal Zeit habe, debuggen. Danke!

[kimmi]

Das ist auch einer der Importer, von denen ich am wenigsten Ahnung habe. Das wiederum macht das testen aufregend :).

Kimmi

[Aramis]

Ojemine, hoere ich da meinen Namen! :-)