ZFX + Developia

Wunderbar, und vielen Dank für die verbesserte Solution-Konfiguration.

Aramis hat geschrieben:Es gibt einen NFF-Importer in Assimp und er liest sogar gleich 2 Formate, die diese Dateierweiterung verwenden. Deines ist ein anderes, oder? Da waere es sinnvoll, einfach einen neuen Importer anzufangen und dessen CanRead()-Methode nur genau dieses Subformat akzeptieren zu lassen.

Genau. Habe ich nun soweit einsatzbereit, allerdings aufbauend auf dem original "vanilla C" BART-Parser-Skelett und damit momentan in keiner Weise bibliotheksgerecht. exit() bei Fehler und Memory Leaks in der Animation, weil ich ich diese zur Zeit noch gar nicht verarbeite. Ich werde versuchen, das demnächst zu vervollständigen.

Ich habe einmal meinen Patch aktualisiert, da z. B. der aktuelle Entwicklungszweig von boost die Versionsnummer 1.51 trägt, während in der CMake-Datei "nur" 1.50 als letzte Version unterstützt wird.

Achja, um Installer für alle Systeme zu erstellen eignet sich ja vielleicht CPack (Teil von CMake).

Danke, das ist wirklich eine gruendliche Ueberarbeitung des CMake-Buildsystems, insbesondere was die Einbindung von ZLIB und DirectX angeht!

Ich habe natuerlich nicht alle Permutationen testen koennen, aber die wesentlichen Sachen funktionieren. Beim Erstellen der Tests kriege ich noch einen CMake-Syntaxfehler, aber die Unittests sind ohnehin Sorgenkind auch von anderer Seite (das betrifft auch nicht deinen Patch, das Problem bestand schon vorher).

Eingecheckt als r1293.

Gruss, Alex

PS: das ist natuerlich CREDITS-wert, hast du einen Namen ausser "Mr. S"? ;-)

Oha, das nenne ich eine umfangreiche Überarbeitung. Vielen Dank für die Hilfe an dieser Stelle!

Gruß Kimmi

Aramis hat geschrieben:Danke, das ist wirklich eine gruendliche Ueberarbeitung des CMake-Buildsystems, insbesondere was die Einbindung von ZLIB und DirectX angeht!

Ich habe natuerlich nicht alle Permutationen testen koennen, aber die wesentlichen Sachen funktionieren. Beim Erstellen der Tests kriege ich noch einen CMake-Syntaxfehler, aber die Unittests sind ohnehin Sorgenkind auch von anderer Seite (das betrifft auch nicht deinen Patch, das Problem bestand schon vorher).

Aramis hat geschrieben:PS: das ist natuerlich CREDITS-wert, hast du einen Namen ausser "Mr. S"? ;-)

Die Tests benutze ich nicht, damit stehe ich auf Kriegsfuß. ;-) Z. B. funktionieren die bei OpenRTI wunderbar, aber es ist schwer funktionierende Beispiele zu erstellen.

Im Forum von OGRE bin ich noch als "Transporter" unterwegs, daher kommt auch der Patch. Ich aktualisiere und erstelle mein OGRE-Packet mit allen Tools automatisch mit Batch-Dateien & CMake. Nur bei Assimp hat der Fehler bei DirectX immer Handarbeit erfordert. Daher der Patch. Assimp hat außerdem mit dem Konverter (http://www.ogre3d.org/forums/viewtopic.php?f=11&t=65993) nicht so prickelnd gepasst, also habe ich beide CMake-Dateien gepatched.

kimmi hat geschrieben:Oha, das nenne ich eine umfangreiche Überarbeitung. Vielen Dank für die Hilfe an dieser Stelle!

Kein Problem, immer wieder gerne!

Die Tests müsst ihr selber patchen, aber bei anderen Sachen melde ich mich wieder wenn es Neuigkeiten gibt. 8-)

Mir ist bei dem patch ein kleiner Fehler unterlaufen. Hier der Korrekturpatch:

Index: test/CMakeLists.txt
===================================================================
--- test/CMakeLists.txt (Revision 1294)
+++ test/CMakeLists.txt (Arbeitskopie)
@@ -220,7 +220,7 @@

IF( WIN32 )
FIND_PACKAGE(DirectX REQUIRED)
-+ENDIF( WIN32 )
+ENDIF( WIN32 )
SET_PROPERTY(TARGET assimp PROPERTY DEBUG_POSTFIX ${ASSIMP_DEBUG_POSTFIX})

# TODO: Port to non-Windows platforms.

Vor dem ENDIF( WIN32 ) ist ein + "übrig" geblieben.

Danke, ist gefixt.

Ich habe noch etwas für Assimp. Beim Ogre-Projekt hat jemand das FBX-Format implementiert: http://www.ogre3d.org/forums/viewtopic.php?f=8&t=71332

Leider habe ich im Augenblick keine Zeit einen Reader für Assimp zu schreiben.

Schöne Entdeckung! Bei Assimp ist Aramis im Begriff, FBX zu implementieren... weiß nicht, wie weit er damit ist, aber er ist sicher über eine weitere Quelle an Informationen dankbar.

Auch das Tool benutzt wenn ich das richtig sehe nur das FBX SDK. Assimp hat das neuerdings nicht mehr noetig, ich habe den Loader im Prinzip einsatzbereit :-)


Kimmi: mir kamen Berichte zu Ohren dass der M3-Importer angeblich des oefteren crashed? Wie stabil ist der? Wir haben ihn immerhin mit-released :-)

Mir bisher nicht, was aber nichts heißt. Wenn ja, wären Fehlerreports zum Stabilisieren recht hilfreich. Nicht ohne Grund war der als experimental markiert.

Gruß Kimmi

Hab Assimp.NET mal wieder aktualisiert.

Hab soeben meinen FBX-Branch vom letzten Google Summer of Code in Assimp gemerged. Damit haben wir nun so halbwegs funktionstuechtigen FBX Support. Unterstuetzt werden ASCII und Binaerfiles. Animationen werden teilweise unterstuetzt. Skinning ist so verbuggt dass es quasi nicht funktionsfaehig ist, aber vielleicht kriege ich das in der naechsten Zeit hin :-)

Der Vollstaendigkeit halber: ich werde von nun an nur noch den Github bedienen (Website und Bugtracker auf SF.net verbleiben natuerlich). Klickverbot, wie machen wir das mitdem SVN-Mirror auf SF.net am besten?

Sehr schön! Wie weit bist du eigentlich mit der Blender/Assimp-Integration gekommen?

Aramis hat geschrieben:Der Vollstaendigkeit halber: ich werde von nun an nur noch den Github bedienen (Website und Bugtracker auf SF.net verbleiben natuerlich). Klickverbot, wie machen wir das mitdem SVN-Mirror auf SF.net am besten?

Da habe ich der Vollständigkeit halber auch mal eine Frage zu: Ist jetzt SVN oder GIT die offizielle Codeverwaltung? Sowohl auf der Gitcode-Seite

In this repository, you can find an inofficial Git clone of the Assimp SVN repository hosted at Sourceforge. It is read-only, the latest commits are pulled in from SVN every 15 minutes.

als auch auf der Webseite

A automatically updated git clone can be found on Github.

steht das Git nur eine Kopie von SVN ist. Dabei sind die Commits auf Github wesentlich aktueller. Vielleicht sollten mal die Webseiten aktualisiert werden. ;)

Sehr schön! Wie weit bist du eigentlich mit der Blender/Assimp-Integration gekommen?

Im Prinzip ist der Code voll einsatzbereit, ich muss mich nur mal ums Zurueckmergen kuemmern :-)

Mr.S:

du hast natuerlich Recht, die Website ist nicht auf dem neuesten Stand. Wir muessen auch immer noch den git->svn mirror einrichten.

Es besteht kein Zweifel: wir werden immer populaerer. Mittlerweile bringt die durchschnittliche Woche 800 Downloads, Zugriffe ueber Package-Repositories sind ohnehin unzaehlbar.

Aramis hat geschrieben:du hast natuerlich Recht, die Website ist nicht auf dem neuesten Stand. Wir muessen auch immer noch den git->svn mirror einrichten.

Stellt doch einfach komplett auf GIT um. SVN muss ja nicht (mehr) sein.

Ich nutze es auch um DAE Dateien in Ogre-Meshs zu konvertieren.

Website ist aktualisiert (und die Website ist jetzt auch auf Github).

Cool, Danke!

Im commit f7680f7f287bbdee63f113946d90db182afa1498 ist ein Fehler in der IFCOpenings.cpp:
Anbei ein Bugfix, der zugleich auch noch die möglichen boost-Versionen aktualisiert.

Ich habe ein interessantes Projekt gefunden mit welchem man IGES/STEP/STL einlesen kann: http://sourceforge.net/apps/mediawiki/n ... =Main_Page

Vielleicht kann man ja die Library (Nglib) in Assimp integrieren.

Edit: Es gibt auch bei http://www.gcad3d.org/ noch Implementierungen für IGES/STEP/STL.

Ich bin gerade über die Namen von Materialien und Meshes in Collada gestolpert. Bisher werden da wohl einfach die IDs als Namen eingesetzt, welche meist mit höchst unschönen Postfixes versehen sind. Fix anbei. Ich muss mich unbedingt mal um git kümmern. :/

Hm, die Dokumentation der Implementierungen von ColladaParser::GetAttribute und ColladaParser::TestAttribute ist genau verkehrtrum: Ersteres wirft, zweiteres gibt -1 zurück. Entsprechend muss es TestAttribute("name") heißen.

Ich habe gerade eben mal das git-Repo ausgecheckt, und direkt ein Problem gefunden:
Wenn man ASSIMP_NO_EXPORT einschaltet, sind in dermaterial.inl durch ein #ifndef eine ganze Menge Funktionen nicht definiert, die aber benutzt werden, so dass man massig Linkerfehler bekommt. Schaltet man den Export nicht aus, kompiliert es sauber durch.

Und noch ein Bug: Durch einen Fehler im Ogre-Importer, den ich noch nicht gefunden habe, wird ein nullptr als Material in die Szene gepackt. Beim Post-Processing knallt es dann, bei mir aktuell im "RemoveRedundantMaterials", wenn in ComputeMaterialHash aus der MaterialSystem.cpp darauf zugegriffen wird.
Dort aber eine Abfrage zu machen, wäre aber wohl der falsche Weg, davor gibt es doch einen Validation-Step der sowas melden könnte oder so. Der Hauptfehler liegt natürlich beim Importer, aber wenn man schon so ein Postprocessing hat, ist das IMO sehr schön, wenn das mit jeder Szene funktioniert, und nicht einfach abstürzt.

Ich hab gerade den Ogre.Loader gepatched. Ich hatte bei sourceforge einen Account, aber für github noch nicht. Daher verlinke ich mal den Patch, wäre nett, wenn den einer einpflegen könnte. (Wieso sind keine .patch Dateien beim Hochladen erlaubt?)

Hat die schon wer eingepflegt? Ich habe das gerade probiert und musste feststelllen: alles schon drinn :).

Kimmi

Aus der Assimp FAQ:

Is ASSIMP able to export models?
No. ASSIMP is an import library. It is intended to import assets, which have been exported from programs like 3ds max, into game engines or other realtime visualization systems. Normally you won't need to export the assets again. If you really need this feature, your're free to open a branch and start coding.

Ich denke, das sollte geändert werden :D

Danke, das wird auch geaendert! :-)

Eine Frage hierzu:

https://sourceforge.net/tracker/?func=d ... id=1067634

der Patch fuegt ein Key-Value Metadata-Feld zu aiNode hinzu. An sich ziemlich ordentlich und durchaus nuetzlich (nicht nur fuer IFC). Von mir aus koennten wir das aufnehmen.

Wie steht ihr dazu?