ZFX + Developia

Krishty hat geschrieben:Ich hatte gehofft, dieser Commit würde die OBJ-Probleme lösen, aber … er ist eine Katastrophe.

Krishty hat geschrieben:@OBJ: Stimmt; der Crash ist raus :) Die Geschwindigkeit ist aber nichtsdestotrotz eine Katastrophe – wenn ich in Notepad++ alle Backslash+Newline aus meiner Testdatei lösche (15 Sekunden Arbeit), lädt die OBJ in drei Sekunden. Wenn ich sie drinlasse … muss ich den Test nach zwei Stunden mit 100 % Kern-Auslastung abbrechen weil ich nicht weiß, ob es je fertig geworden wäre oder in einer Endlosschleife hängt. Da war der Crash fast besser.

Eine neue Episode aus OBJ, Backslashes, Katastrophen: Ihr habt nie getestet, was passiert, wenn ein Backslash genau am Ende eures I/O-Blocks liegt …

Vorschlag: CMAKE_DEBUG_POSTFIX standardmäßig auf 'd' setzen, damit Debug- und Release-Build unterschiedliche Namen haben. Der Wert 'd' wird scheinbar auch von FindAssimp.cmake erwartet.

(siehe unten, Problem fast gelöst).
Ich habe gerade den aktuellen Code (fce4d0cee75304ecfbdc025788d9ec17dae56d98) unter Windows 8 mit VS 2015 kompiliert. Das Ergebnis ist eine Datei 'assimp-vc140-mt.lib', und zwar unabhängig ob ich im Debug oder Release Modus kompiliere. Ich linke in meinem Projekt normalerweise auch die unterschiedlichen Bibliotheken in den unterschiedlichen Konfigurationen, aber mit dem aktuellen Namensschema scheint es mir nicht möglich zu sein, das Ergebnis des CMake-Install-Skriptes zu verwenden, ohne selbst noch einmal Hand anzulegen. Sprich, ich vermisse (schmerzlich) ein '-d' als Namensbestandteil im Debugbuild. Ich bin mir auch ziemlich sicher, dass das mal drin war (damals war die Kompilerversion aber noch kein Namensbestandteil).

Nachtrag:
Die beigelegte Findassimp.cmake sucht für den Debugbuild auch nach ${ASSIMP_MSVC_VERSION}-mtd.lib und CMAKE_DEBUG_POSTFIX ist vermutlich die Lösung meiner Probleme. Aber man könnte es vielleicht standardmäßig auf einen nicht-leeren Wert setzen (wovon die FindAssimp ja scheinbar schon ausgeht).

Hallo zusammen,

in der letzten Zeit hat sich bei Asset-Importer-Lib mal wieder etwas getan. Wir haben einen FBX-Exporter, das Laden von FBX-Assets ist stabiler geworden. 3MF kann nun importiert und exportiert werden. Es hat sogar einige Verbesserungen im Bereich IFC gegeben. Dazu habe ich viele viele kleinere Verbesserungen und Bugfixes gepushed.
Ich bin grad privat etwas unter Feuer ( kleine Kinder im Winter sind die Pest und meine Freundin ist leider auch nicht gesund zur Zeit ), so dass ich mich am liebsten gevierteilt hätte. Wider Erwarten hat das nicht geklappt.
Ich habe deswegen einen Poll auf Patreon gestartet, um etwas Feedback einzusammeln, was denn zur Zeit für Anwender wichtig ist.

Finden kann man die Umfrage unter dem folgenden Link: https://www.patreon.com/posts/april-feature-18293510

Ich würde mich freuen, etwas Feedback zu bekommen, was wirklich als wichtig angesehen wird. Postet eure Gedanken auch gerne hier.

Gruß Kim

simd.h: SSE2-Unterstützung durch CPUID abzufragen ist nicht unbedingt clever, weil das Betriebssystem das ebenso unterstützen muss. Statt nicht-portabler Assembler-Hölle könnt ihr unter Windows besser IsProcessorFeaturePresent(PF_XMMI64_INSTRUCTIONS_AVAILABLE) aufrufen. Zuverlässiger, kürzer, wartbar – und auf Linux nutzt eben weiter den Assembler-Code.

Gute Idee, werde ich umsetzen. Danke für den Tipp.

Ich wollte gerade ungenutzte Post Processing Steps aus meinem Kompilat schmeißen, und da asind folgende Abhängigkeiten aufgetaucht:

• MakeLeftHandedProcess: UnrealLoader XFileImporter B3DImporter LWOLoader LWSLoader MMDImporter
• FlipWindingOrderProcess: MMDImporter UnrealLoader XFileImporter B3DImporter COBLoader LWOLoader LWSLoader
• FlipUVsProcess: MMDImporter

Vielleicht wäre ein #ifndef #error in den Header nützlich, um nicht Linker-Warnungen auseinanderpopeln zu müssen …

Oh Freude, oh Freude. Mein Arbeitgeber SLM-Solutions fördert nun ganz offiziell meine OS-Arbeit an Asset-Importer-Lib. Viele Kudos an https://slm-solutions.com/ .

Gruß Kim

Wie cool! Als ich auf die Webseite gehen wollte, um zu sehen, ob ihr jetzt eine Art sponsoring-Abteilung auf der Webseite habt, ist mir übrigens aufgefallen, dass der Link zu Assimp in Deiner Signatur kaputt ist, da fehlt ein "w" beim "www".

Ups, das stimmt. Ich habe den Fehler beheben können. Call me an engineer :).

Vielen Dank für die Info!

Verspaetete Glueckwunsche zum Assimp-Sponsoring - sehr cool!

http://assimp.sourceforge.net/ sagt, es würde auf assimp.org weiterleiten – wenn man den Link klickt, landet man aber auf example.com ;)

Kim, der Link auf deine Webseite im Point-Cloud-Support-Artikel des Assimp-Blogs ist auch kaputt!

aiGetLegalString() meldet noch 2017 :)

Ein weiteres schönes Beispiel, warum Copyright-Meldungen so richtig dämlich sind.

Bekomme ich aus dem COLLADA-Loader die neue ZAE-Unterstützung raus? Ich habe hier eine auf DAE abgespeckte Version, und durch die neue Abhängigkeit vom ZipArchiveIOSystem muss ich nun bedeutend mehr Code warten …

Wenn dass wohl zunächst nur durch eigenes Handanlegen. ich bin gewissermassen zu mit Arbeit :).

Gruß Kim

Es gibt übrigens ein V5.0.0-Release: https://github.com/assimp/assimp/releases/tag/v5.0.0

Gruß Kim