ZFX + Developia

Ich bau da gerade was mit der ZFXCE2, sofern ich zu so etwas mal kommen würde ...

Gruß Kimmi

Hab Assimp's boost-workaround mal separat hochgeladen falls jemand mal Interesse daran hat.

https://github.com/acgessler/micro.boost

Ich reg' mich auf, weil Visual Studio mir für make_shared nur 10 Parameter gibt, und ihr kommt mit 7 aus? :) (Und, ja, ich hatte in meinen Code deswegen schon Hacks eingebaut, dass ich via make_pair zwei Parameter zu einem zusammenfasse, um auf die 10-Parameter-Grenze zu kommen.) Oh wie schön wäre die Welt mit variadic templates. Aber eine nette Sammlung habt ihr da.

Hi Assimp-Team,

welche Bugs und Features wollen wir eigentlich bis zum 3.0 Release gefixed haben? Mir fällt spontan die folgende Liste ein:

• LLVM Compiler Bug
• Obj-Crash ( bin ich drann )
• Fehler im Triangulieren
• ...

Was müsste eurer Meinung nach noch gefixed werden? Lasst uns das mal dingfest machen.

Ich brauche zur Zeit klare Ansagen, was wichtig ist, daher diese Anfrage. Sonst komme ich aufgrund massiven Zeitmangels zu rein gar nichts mehr. Und mit solch einer Liste ist es leichter, irgendwann den Deckel dicht zu machen. Sonst dümpeln wir Weihnachten immer noch in der Pre-Release-Phase rum ;) ( das war nat. klar übertrieben, aber irgendwie hat man ja immer noch was, was in den nächsten Release soll ).

Gruß Kimmi

P.S.: Neuen Fehler aufgenommen.

Mit Obj meinst du die Probleme beim Post-Pro triangulieren? Kai fragt mich schon immer, wann das wieder geht :D

Von meiner Seite: Ich vermute, dass im OgreLoader noch irgendwas nicht so ganz sauber läuft, aber ich muss jetzt erstmal Animationen in meinem Spiel implementieren. Sobald der Loader dann quasi produktiv eingesetzt wird, wird sich sicherlich noch das ein oder andere ergeben.

Achja, über folgendes hab ich neulich nochmal nachgedacht: Wir wäre es mit einem schöneren C++ frontend? Zum Beispiel mit Vectoren statt Arrays, und namespaces statt prefixes? Die simple Lösung wäre es, alles ganz normal zu laden, und dann in eine 'moderne' C++ Datenstruktur zu kopieren. Ich meine, durch das ganze post-pro und einiges umherkonvertieren beim Laden der verschiedenen Formate liegt das Design von Assimp eh nicht auf schnellen Ladezeiten. Und alle Daten am Ende einmal zu kopieren sollte nicht wirklich ins Gewicht fallen. Auf der anderen Seite hätte man dann eine schönere Schnittstelle mit der man arbeiten kann.

800 Downloads in einer Woche und das ohne ein Release. Eventuell bringt Qt5 eine Menge Public Momentum.

Die Watch&Fork Zahlen auf Github sind derweil auch tendentiell nichtlinear steigend. Ich denke wir werden uns auf Dauer tatsaechlich ueberlegen muessen ob wir das Primaer-Repos nicht nach dort umziehen :-) (Wichtigster Punkt dabei: jedesmal wenn ich einen Patch im Git-Format einspielen muss und grade keine Linux-Box vor mir habe werde ich schier wahnsinnig - weshalb es zuletzt auch dankenswerterweise klickverbot erledigt hat, aber es ist keine Dauerloesung.)

PS: Ich mache eine Liste aller kritischen TODOs.

Von mir aus können wir gerne zu Github überwechseln. Das von Hand-Patchen ist echt Schxxxx!

Gruß Kimmi

Kann man git-svn eigentlich auch nicht auch umgekehrt benutzen? Also das SVN-Repos aus dem Git-Repos aktualisieren :-)

So etwas gibt es auf jeden Fall. Keine Ahnung, wie das Tool dann wirklich heißt.

Es wäre hlfreich, wenn du die Showstopper-Bugs aus deiner Sicht heraus mal aufzählst. Dann können wir die vor Release3.0 als zu fixen markieren.

Gruß Kimmi

Na ich benutze auch git-svn. Damit kann ich mir Änderungen vom SVN holen und auch zurückschicken. Und es als ganz normales Git-Repository benutzen, also von/zu anderen pullen/pushen. Man braucht dafür kein extra Tool oder so, war alles schon in Tortoise-Git mit drin.

Achja: Heute geht es ja richtig rund:
http://sourceforge.net/projects/assimp/ ... Repository

Hab im Tracker alle kritischen Fehler auf hoechste Prio gesetzt, siehe auch ML Posting.

@Jonathan: einige Leute haben via git-svn gepulled, dabei werden jedes Mal alle (neuen) Revisionen gezogen was pro Revision einen Stat-Eintrag generiert :-)

Wahrscheinlich also 2 neue Gitclones an einem Tag.

Achso, das macht Sinn. Wobei ich sagen muss, ich hatte kein Bock so lange zu warten und hab dann neulich nur die letzten 20 Versionen oder so gepulled. Absolut alle Revisionen zu laden muss doch ewig dauern :D

Kleine Ankuendigung in eigener Sache: ich wurde in den diesjaehrigen Google Summer of Code akzeptiert und zwar mit einem doch recht Assimp-nahen Projekt.

http://www.google-melange.com/gsoc/org/ ... 12/blender

Kurzfassung: FBX-Importer fuer Assimp und Assimp in Blender implementieren :-) Damit wird es umso wichtiger, dass wir moeglichst bis Mitte Mai das Release fertig kriegen.

Gratulation! Ok, weiß ich Bescheid.

Gruß Kimmi

Oehm weshalb committest du in den 2.0 Branch hinein? Sollte das nicht eher in den trunk gehen?

Japp, sollte er. Allerdings habe ich auch nur im trunk gearbeitet. Irgend etwas ist da bei meinem Repo scheinbar kaputt. Kannst du das reverten, bitte? Bin gerade im Büro und komme nicht so schnell dazu, das wieder zu korrigieren.

Danke und Gruß,
Kimmi

Ich schau mir noch mal genauer an, was da schief geht. Einer der Fehler auf unserer Liste ist nun erledigt.

Gruß Kimmi

Ich hab hier ein Modell mit mehreren Texturkoordinaten, dass der Collada-Importer nicht fressen will.

Collada: house01.dae - Expected attribute "texcoord" at element "texture".

(Wieso sind keine .dae Dateien erlaubt? Bzw. wieso wird das überhaupt eingegrenzt?)

Vielleicht ist einfach nur der Blender-Exporter falsch, das könnte natürlich auch sein. Aber vielleicht ist es ja auch ein Problem, wo es sinnvoll ist, den Importer zu ändern.

Ich sehe keinen Weg, da einen Workaround zu bauen. Die Texturkanal-Zuordnungen in der Material-Zuordnung der Mesh-Instanziierung geben eine ungültige Kanal-ID an. Alle anderen Files, die ich hier habe, geben in der Effekt-Definition für jede Textur auch eine Kanal-Id an - dieses File nicht.

Also, ich habe da auch noch ein paar Änderungsvorschläge, die CMake betreffen:

• Um die assimp-Einträge von den CMake etc. besser unterscheiden zu können (Gruppierung) sollten sie mit ASSIMP_ beginnen.
• Die DirectX-Erkennung fürassimp_view funktioniert nicht richtig. Eine nützliche Lösung wäre FindDirectX von OGRE zu verwenden.
• Da die mitgelieferten externen Bibliotheken wie z. B. ZLib veraltet sind verwende ich hauptsächlich eine externe Version. Hierfür verwende ich FindZLIB von OGRE, weil die OGRE-Version auch zwischen Debug und Release unterscheiden kann, d. h. Debug-Zlib zu Debug-Assimp und Release-Zlib zu Release-Assimp.
• Die aktuelle Boost-Version (dev) ist mittlerweile bei 1.50 angekommen, daher sollte Boost_ADDITIONAL_VERSIONS angepasst werden.
• Wofür ASSIMP_BUILD_ARCHITECTURE und ASSIMP_BUILD_COMPILER gut sein sollen habe ich noch nicht ganz begriffen, aber warum wird da nicht einfach CMAKE_CL_64 bzw. CMAKE_GENERATOR verwendet?
• Ich vermisse die Möglichkeit die Debug-Dateien (PDB) von Visual Studio mit zu installieren.
• comctl32.lib muss eigentlich nicht extra gesucht werden. Es reicht die Bibliothek bei den Standardabhängigkeiten aufzulisten da sie zum Platform-SDK gehört.
• Ich kann bei MSVC10 assimp auch ohne VC10_STDINT_FIX erfolgreich verwenden. Vielleicht sollte man die Option entfernen, oder wenigstens bei Nicht-MSVC10 ausblenden.

In dem angehängten Patch habe ich die Änderungen als Vorschlag eingebaut.

Noch ein paar "CMake-Änderungswünsche" ohne Patch:

• Die CMake-Dateien im Verzeichnis SDK\lib\cmake\assimp-2.0 liegen ein bisschen ungünstig, finde ich. Besser wäre eine FindASSIMP.cmake in SDK\cmake. So passt es dann zu dem meisten anderen Programmen, die CMake so verwenden.
• Warum wird alles in das Hauptverzeichnis installiert? Es gibt keine Unterverzeichnisse für Debug, MinSizeRel, Release und RelWithDebInfo.
• Eine aktuelle GLUT-Version gibt es im Cg-Toolkit von nVidia, welches auch 32- und 64-Bit-Versionen bereit stellt. Die Version im Verzeichnis samples\glut ist schon "etwas" älter und nur für 32 Bit.

Danke dafür. Ich werde mal zusehen, dass wir diese Woche den 3.0 Release auf die Reihe kriegen und dann mal schauen, wieviel von deinen Änderungen mit dabei sein werden. Auf jeden Fall danach :), sofern sie für uns Sinn machen ...

Danke und Gruß,
Kimmi

Jo, kein Problem. ;)

Ich werde weiterhin Verbesserungsvorschläge machen und gerne auch mit Patches mithefen.

Noch eine Kleinigkeit ;)

In dem Template assimp-config-version.cmake.in wird wieder PACKAGE_VERSION an Stelle von ASSIMP_PACKAGE_VERSION verwendet. Das ist ungünstig, wenn man assimp per cmake in ein eigenes Projekt einbindet, da man bei vielen Bibliotheken den Überblick verliert zu welchem Projektteil PACKAGE_VERSION gehört. Achja, vielleicht wäre es auch nicht verkehrt neben der Versionsnummer auch zu speichern ob die Bibliothek statisch oder dynamisch erstellt wurde. Das spart ggf. die Suche nach der DLL.

Guter Hinweis, werde ich nachziehen. Danke für die Mühe!

Gruß Kimmi

Wie ist denn jetzt eigentlich der aktuelle Stand - sorry, ich bin mal wieder leicht abgehaengt.

Source-Release ist draußen, ich hab allerdings die Änderungen noch nicht zurück gemergt auf den Trunk. SDK muß noch gebaut werden, da fehlte mir die Zeit in der letzten Woche. Release-Notes fehlen ebenfalls.

Gruß Kimmi

Soll ich SDK und Binaries erstellen und hochladen?

In Anbetracht, dass ich grad zu gar nichts komme: Das wäre so was von super, dass ich das gar nicht in Worte fassen kann :) !

Gruß Kimmi

Ok - vielen Dank dir fuer den Einsatz in den letzten Wochen!

Ich gucke dass ich die Faeden zusammenfuehre und das Release abschliesse.