Assimp - Brainstorming zum Release

[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