Assimp - Brainstorming zum Release

[Schrompf]

Da ist die Doku veraltet. Wir haben das ja mal umgebaut, so dass das Standard-Koordinatensystem mehr dem entspricht, das die meisten zu erwarten scheinen. Das heißt: +X nach rechts, +Y nach oben, +Z zeigt aus dem Schirm heraus.

[Aramis]

Gut, ich hab das dann mal in der Dokumentation korrigiert und werd' bei nächster Gelegenheit auch mal die Doku auf dem Server aktualisieren. Außerdem hab ich einen Herrn an der Angel der unseren Collada-Loader ausgiebig mit C4D plagt - ein Problem hat er schon gefunden, das dürfte jetzt aber gefixt sein.

[klickverbot]

Ich habe die D-Bindings wieder einmal auf den aktuellen Stand gebracht. Gibt es eigentlich schon Neuigkeiten von der »aiGetMaterialProperty«-Front?

[kimmi]

Ich bin gerade am Linuxbuild per CMake drann. Hoffe, bald etwas liefern zu können.

Gruß Kimmi

[Aramis]

Hoi,

hauptsächlich interessant für die C# und Java-Bindings (beide, soweit mir bekannt, unfertig).

SWIG- Simplified Wrapper und Interface Generator.

Zuerst hatte ich enorme Zweifel, ob es hält, was es verspricht. Nachdem ich heute damit erfolgreich funktionstüchtige Python-Wrapper für mein komplettes Engine-API generieren konnte, zweifle ich nicht mehr sondern glaube nur noch. Beeindruckendes Tool ... erstellt selbst für verhältnismäßig komplexe C++-Konstruktionen (Smart-Pointer, Templates) passende Bindings. Mit den Assimp-Headern wären vermutlich nicht die geringsten Probleme zu erwarten. Getestet habe ich bislang aber, wie bereits erwähnt, nur das Python-Backend.

@klickverbot
Sorry, das ist irgendwie untergegangen .. :-)
Danke für deinen stetigen Einsatz die Bindings aktuell zu halten!

Gibt es eigentlich schon Neuigkeiten von der »aiGetMaterialProperty«-Front?

Leider nein .. es ist und bleibt ein Rätsel.

[klickverbot]

Danke für deinen stetigen Einsatz die Bindings aktuell zu halten!

Leider nein .. es ist und bleibt ein Rätsel.

Naja, den »stetigen Einsatz« muss ich eigentlich nur leisten, weil ich bis jetzt zu faul war, einen Generator zu schreiben, der mir diese Aufgabe abnimmt. Ich werde mir einmal SWIG anschauen, vielleicht bekomme ich diesbezüglich etwas auf die Reihe. Dann würde es ja möglicherweise auch OOP-Bindings für D geben. ;)

Dass sich das aiGetMaterialProperty-Problem noch nicht aufgeklärt hat, verwundert mich mittlerweile ziemlich. Sollte es bis zum Release ungelöst bleiben, müsste ich noch entsprechende Hinweise in der Dokumentation hinzufügen. Aber noch besteht ja Hoffnung … :)

[kimmi]

Der Linuxbuild mit CMake geht übrigens. Ich habe noch einige kleinere Probleme mit dem Unittests und dem gcc, die kriege ich aber auch in den Griff.

Gruß Kimmi

[Aramis]

-SConstruct aktualisiert, ConvertUTF.c fehlte.
Außerdem hab ich zwei weitere SCons-Parameter eingebaut: 'shared' und 'noboost'. Kimmi, ich glaube du nutzt doch auch SCons ... könntest du das bitte auch mal bei dir testen?

[kimmi]

Ich benutze mittlerweile zwar mehr CMake, aber klar, ich teste das gern.

Gruß Kimmi

[Aramis]

Vielleicht sollten wir die Installerfrage lieber hier auf Deutsch ausdiskutieren. Nochmal meine Meinung dazu: ein MSI-Installer für's SDK und AssimpView-Binärpackage wäre meiner Meinung nach eine nützliche Sache ...

Was der Threadposter aber, wenn ich es richtig im Kopf hab, meinte war das 'install'-Target für Unixoide ... sollten wir auch für den MAKE-Build wohl mal einführen.
PS: http://wasaproject.net16.net/?p=175#more-175 - zufällig gefunden, nette Sache.

[kimmi]

Unter dem normalen Make bäuchten wir dann ein Install-Target, daß nach /usr/lib ( oder etwas ähnliches ) die Lib und unter usr/include/ die Include hinterlegt. Für Windows würde ich unter Programme etwas ähnliches als Default hinterlegen. Ich muss mal schauen, was cmake da alles kann. Wenn die auch Workspaces für MSI'a ausspucken: toll. Ansonsten fällt mir für Windows noch WXI ein.

Gruß Kimmi

[Aramis]

Kann es sein, dass die OBJ-Spinne seit den letzten Patches anders aussieht? Die Textur an den Beinen wirkt merkwürdig verzerrt und ist außerdem gelb.

[kimmi]

Hm, das kann muß ich mal checken.

Gruß Kimmi

[kimmi]

In der Tat ist da ein Problem eingeführt worden. ICh habe dementsprechend folgende Punkte gerade offen:

• 1. Installationstarget: Im GNU-Makefile und im CMake
  2. Obj-Loader: Ergebnisse zwischen Validate und real existierendem Modell unterschiedlich.
  3. Obj-Loader: Parsing-Problem auf Mac
  4. Obj-Loader: Scheinbar falsches Material

Ich denke, daß Punkt 2 und 3 am selben problem hängen.
Wenn der Schnee mich mal früher nach Hause kommen lässt, lege ich da los.

Gruß Kimmi

[Schrompf]

Von meiner Seite offen ist:

- Collada - MotionCaptureROM.dae sieht animiert seltsam aus. Das ging früher mal... was ist da passiert?

und eigentlich auch noch:

- Milkshape3D-Support
- FBX-Support

Die letzteren beiden wird's aber wohl nicht geben. Dazu hab ich einfach so schon zu viel um die Ohren. Nur leider wären das zwei recht wichtige Formate... FBX sogar sehr wichtig, wenn man die sonstige Tool-Unterstützung dafür betrachtet. Grmpf.

Bye, Thomas

[kimmi]

Einen hab ich auch noch:

• - Prototyp vom Q3-Loader aus ZFXCE nach AssImp.

Gruß Kimmi

[Aramis]

Die letzteren beiden wird's aber wohl nicht geben. Dazu hab ich einfach so schon zu viel um die Ohren. Nur leider wären das zwei recht wichtige Formate.

Ja, dann werde ich mir Milkshape, deine Zustimmung vorrausgesetzt, in naher Zukunft mal angehen. Die Spezifikation des Formats sieht ja eigentlich so aus, als sei es recht einfach in unsere Datenstrukturen konvertierbar. Einzig bei den Animationen gibt es Unterschiede, so ganz steige ich aktuell noch nicht durch.

Von mir noch:

• Testsuite - hab ich letztes WE erstmals wieder dran weitergemacht ... grade in Bezug auf diese ganzen unvermeidbaren Regressionen (siehe Obj) wird es wohl recht nützlich werden.
• Subdivision im AC-Loader
• Java/C#-Bindings: zusammen mit Jonathan herausfinden ob SWIG uns die Arbeit und die spätere Codepflege abnehmen kann.
• (für's erste auf 'nach unserem Release, in welchem Jahrzehnt dieses auch stattfinden mag' verlegt): .blend-Support.
• ... viele, viele Kleinigkeiten an einzelnen Loadern. Da hab ich in letzter Zeit mal so sporadisch was gefixt.

PS: *lechz* nach Q3-Maps.

[dowhilefor]

Ja, dann werde ich mir Milkshape, deine Zustimmung vorrausgesetzt, in naher Zukunft mal angehen. Die Spezifikation des Formats sieht ja eigentlich so aus, als sei es recht einfach in unsere Datenstrukturen konvertierbar. Einzig bei den Animationen gibt es Unterschiede, so ganz steige ich aktuell noch nicht durch.

Ich hätte noch sehr sehr seeeehr schlechten Milkshape Code zur Verfügung ... Meine auch mit Animation. Wobei der zum größtenteil auf dem Code aufbaut den im alten Forum jemand mal in seiner Terrain Demo benutzt hat (wer war das nochmal *grübel*). Den würde ich aber zur Verfügung stellen, damit du vielleicht einen Einstieg hast, falls dir das hilft.

[kimmi]

Wo kann man eigentlich mehr Zeit kaufen ;)...
Habe ich erwähnt, daß die ZFXCE nun die AssImp benutzt?

Kimmi

[Aramis]

Nein, hast du bislang noch nicht erwähnt. Schöne Sache!

Ich hätte noch sehr sehr seeeehr schlechten Milkshape Code zur Verfügung ... Meine auch mit Animation. Wobei der zum größtenteil auf dem Code aufbaut den im alten Forum jemand mal in seiner Terrain Demo benutzt hat (wer war das nochmal *grübel*). Den würde ich aber zur Verfügung stellen, damit du vielleicht einen Einstieg hast, falls dir das hilft.

Das wäre super, insbesondere falls tatsächlich Animationen enthalten sind. Ich finde zwar brauchbare Spezifikationen/Header, aber ganz eindeutig sind die nicht. Etwas Referenzcode sollte als kräftig Trial&Error einsparen :-)

[kimmi]

So, ich habe mal einen ersten Versuch in Richtung make install committet und auch gleich die ersten Fehlermeldungen bekommen. Ich korrigiere die bzw. werde das Makefile, daß uns auf der Mailingliste angeboten wurde, versuchen zu adaptieren.
Dazu habe ich eine Lösung für die berichteten Probleme mit den Materialien geliefert. Ich werde den aber noch aufhüpschen. Dann dachte ich daran, den BSP-Loader mal klarzumachen und den CMake mit einem Install-Target zu versehen.
Und der Schnee hier oben im Norden geht mir langsam auf den Geist. Ich hab heute 35 Minuten ins Büro gebraucht ( sonst unter 15 Minuten mit dem Rad ). Ich will Frühling!

Gruß Kimmi

[Jonathan]

Weiß grad nicht ob es schonmal vorgeschlagen wurde. Aber was haltet ihr von einem Wechsel Svn->git?
Imo sollte es möglich sein, die komplette History zu übernhemen und so.

[Schrompf]

Wenn Sourceforge das unterstützt? Ich hab kein Problem mit SVN, ich hätte es also allein aus Mangel an echten Ärgernissen beibehalten.

[kimmi]

Git wird unterstützt. Wir haben das mal bei der ZFXCE probiert und sind dabeigeblieben. Allerdings bin ich mit dem TortoiseGit noch nicht ganz so zufrieden. Es ist auf jeden Fall schneller als svn und man kann lokal seine Modifikationen überarbeiten. Der Merge ist ebenfalls einfacher. UNd man hat das gesamte Repo lokal bei sich vorliegen, also auch ohne Sourceforge kann man diffen etc. . Es dauerte allerdings einige Zeit, bis ich da einigermaßen reingekommen bin.
Allerdings stellt sich auch bei mir die Frage: wollen wir dazu wechseln? So richtig viele Vorteile fallen mir da gerade nicht ein. Für unsere Bedürfnisse reicht doch svn erst einmal aus.

Gruß Kimmi

[Aramis]

Eine Stimme gegen einen Wechsel. Wir nutzen SourceForge doch als Server mit uns als Clients - genau der Zweck, für den SVN konzipiert ist. Dass Git und Mercurial gewisse Vorteile für verteilte Entwicklerteams sowieso Projekte mit vielen parallel laufenden Branches aufweisen steht außer Frage. Jetzt aber noch zu wechseln nachdem wir alle User schon dazu verdonnern sich für aktuelle Versionen den Quelltext aus dem Repos zu ziehen? Man sollte nicht vergessen dass Subversion immer noch deutlich verbreiteter ist.

Übrigens hab ich vor einiger Zeit mal einen Mercurial-Clone von Assimp auf Bitbucket erstellt (aktuell nutze ich Mercurial für alle privaten Projekte). Seit 3xx aber nicht mehr aktualisiert. Einen solchen Clone könnte man auch für Git-User auf Gitourious oder GitHub hosten - wenn sich ein Maintainer findet, der regelmäßig aktualisiert.

[klickverbot]

Einen solchen Clone könnte man auch für Git-User auf Gitourious oder GitHub hosten - wenn sich ein Maintainer findet, der regelmäßig aktualisiert.

Mein persönlicher Git-Clone auf GitHub: http://github.com/klickverbot/assimp. Ich aktualisiere das Repository per Hand, deswegen ist es meist nicht am allerneuesten Stand, aber als Ausgangsbasis (um für eine vollständige History nicht alle alten Revisionen importieren zu müssen) sollte es durchaus taugen.

Ich würde übrigens vorerst auch nicht wechseln, SVN ist ja derzeit so etwas wie der kleinste gemeinsame Nenner in der Open-Source-Welt: Die Entwicklung findet (zumindest bis dato) vollständig in der Mainline statt, also legt einem SVN nicht übertrieben viele Steine in den Weg, und als »Frontend« verwenden wahrscheinlich ohnehin viele Entwickler ihr DVCS der Wahl (was in meinem Fall mit git-svn auch recht komfortabel von der Hand geht).

[Aramis]

So, ich hab mal etwas .. aufgeräumt. Assimp kompiliert jetzt mit GCC4.4 auf -wall mit nur noch einer Warnung. Die Änderungen waren überschaubar, betrafen aber fast alle Loader. Solltet ihr in nächster Zeit merkwürdige Regressionen entdecken, so prüft bitte ob es in r541 evtl. unbeabsichtigte Verhaltensänderungen am jwlg. Loader gab.

Hinzu kam gestern noch ein Patch um Assimp's Abschneiden bei VC2010's statischer Codeanalyse zu verbessern (dafür an dieser Stelle nochmals vielen Dank an Krishty!).

Loader für statische Milkshape-Files steht, Animationen stehen noch aus.
EDIT - Aktueller MS3D Prototyp auch gleich eingecheckt.

[Aramis]

klickverbot -

kann ich deinen Git-Clone von der Assimp-Seite aus verlinken?

[klickverbot]

kann ich deinen Git-Clone von der Assimp-Seite aus verlinken?

Verlinken kannst du den Clone natürlich gerne, auch wenn ich nicht versprechen kann, dass ich ihn in Zukunft stets aktuell halten werde.

Vor dem Release sollten wir unbedingt noch einen Anlauf unternehmen, das »aiGetMaterialProperty«-Problem zu lösen – da es für SOs ja keine Import-Libraries wie für DLLs unter Windows gibt, die das Problem gewissermaßen maskieren (korrigiert mich bitte, wenn ich die Lage nicht richtig erfasst haben sollte), ist es derzeit schwierig bis unmöglich, Assimp unter Linux als dynamische Bibliothek zu verwenden. Zumindest hat ein schneller Versuch vor ein paar Tagen nicht so funktioniert, wie er sollte – ich habe aber zugegebenermaßen nicht viel Zeit in eine mögliche Lösung des Problems investiert.

Aus meiner Sicht ebenfalls wünschenswert und für ein »richtiges« Release wohl bitter nötig ist »make install«-Unterstützung für CMake unter *nix, das ja jetzt unsere Standard-Build-Methode ist, das sollte aber nicht besonders schwer umzusetzen sein. Ich werde mich dessen in den nächsten Tagen annehmen.

Mit SWIG (siehe oben) habe ich mich mittlerweile schon etwas intensiver auseinandergesetzt und sogar ein mehr oder weniger komplettes D-Backend geschrieben, meine Versuche, es auf Assimp loszulassen waren aber leider wenig erfolgversprechend. Die Pointer-in-den-Speicher-samt-Längenangabe-API verträgt sich wohl nicht so gut mit der Herangehensweise von SWIG – ich lasse mich aber gerne eines Besseren belehren.

[kimmi]

Der Blocker der Shared-Object-Version hängt mit aiGetMaterialProperty zusammen, habe ich das richtig verstanden?

Gruß Kimmi