Assimp - Brainstorming zum Release

[Matthias Gubisch]

Hallo

dann meld ich mich auch mal zu Wort

Also die SWIG Version des C#-Ports sollte im großen und ganzen Funktionieren.

@Seraph: Kannst du mir mal kurz mitteilen wo ihr genau die Probleme habt dann kann ich das eventuell noch anschauen.

Zum Thema Viewer: Der aktuelle .net-Viewer ist veraltet und könnte eigentlich genauso aus dem Repo verschwinden, zumindest ist er nicht releaswürdig...
Ich hab mal angefangen einen aktuellen Viewer mit SlimDX zu schreiben, leider beschäftigt mich mein RL zu Zeit zu viel um den bis zum Release fertig zu stellen.

Grüße
Matthias

[Seraph]

Die Probleme lagen mehr an Assimp selbst (irgendetwas was in letzter Zeit hinzugefuegt wurde (Extensions?)). Ich muesste nochmal nachsehen an was es genau lag.

[Aramis]

Die Vertex-Anim Datenstrukturen werden aktuell von niemandem benutzt, auch nicht validiert oder sonstwie. Ich schlage vor sie zum Release wieder zu entfernen, das schafft nur unnoetige Verwirrung und beschert uns auf Dauer stundenlange Mail&Foren Arbeit. SVN vergisst ja nix.

Nachdem ja grade weiterhin alles gut aussieht (und ich wg. den Assimp-Interessenten der letzten Zeit etwas Gas geben moechte), schlage ich vor weiterhin das WE 13/14. November als Releasetermin anzupeilen.

Bitte guckt dass ihr eure Baustellen ungefaehr eine Woche vorher abgeschlossen habt, damit wir dann noch Zeit fuer eine kleine QA-Runde haben!

Gruss, Alex

[Schrompf]

Ein guter Gedanke. Einfach auskommentieren oder ganz löschen und wieder aus dem Repos rausholen, wenn man mal mit der Implementation anfängt.

[Aramis]

Jau. Werden sicher irgendwann benutzt werden, aber grade braucht sie wohl niemand.
PS: Hab oben editiert, sorry fuer die Ueberlappung :-)

[kimmi]

Kamen die nicht für den werten Mike_irgendwas rein? Von mir aus auch auskommentieren.

Gruß Kimmi

[klickverbot]

Ich wäre auch froh, wenn eine Woche vor dem Release die Arbeiten am Interface abgeschlossen wären – dann kann ich nämlich in Ruhe noch die händisch erstellten D-Bindings auf den aktuellen Stand bringen und in Ruhe kontrollieren, ob meine kleinen Projekte auch mit der neuen Version funktionieren.

[klickverbot]

Werden die Vertex-Animation-Datenstrukturen also definitiv entfernt? Bei mir geht's auf der Uni zur Zeit relativ stressig zu, ich habe also u.U. wenig Zeit, um auf den entsprechenden Commit zu warten.

Besteht außerdem der Konsens, dass das Versionierungsschema nichts über Binärkompatibilität aussagt? Dann ändere ich den Code im D-Loader nämlich dahingehend um (es wird eine Warnung für potentiell inkompatible Versionen von Bindings und Shared Library auszugeben, um Debugging zu erleichtern) – zur Zeit verwende ich dort nach einem beliebten Schema (vor dem letzten Release stand, wenn ich mich richtig erinnere, noch nichts fest), dass bindingsMinor <= libMinor && bindingsMajor == libMajor sein muss, der erste Vergleich würde sich dann auch auf Gleichheit ändern.

[Aramis]

Werden die Vertex-Animation-Datenstrukturen also definitiv entfernt?

Ja.

Besteht außerdem der Konsens, dass das Versionierungsschema nichts über Binärkompatibilität aussagt?

Das hier wird ja Assimp 2, also passt es doch mit dem bisherigen Schema?

[klickverbot]

Das hier wird ja Assimp 2, also passt es doch mit dem bisherigen Schema?

Okay, das wusste ich nicht – mein letzter Stand war

(1.2 wenn ich es richtig im Kopf hab :-))

und mein unbeantwortet verhalltes Plädoyer für eine Version 2. ;)

Ich mach mich dann mal an die Arbeit…

[Aramis]

Oh Sorry. Ich sehe grade dass wir tatsaechlich noch nicht drueber diskutiert haben. Ich hatte auf deinen Hinweis hin die Versionsnummer 2.0 scheinbar etwas uebereifrig in meinem Kopf abgespeichert, ohne dir Feedback zu geben oder mit irgendwem darueber zu reden.

Ich denke aber nicht dass jemand was dagegen hat. Schlussendlich ist es ja nur eine Zahl.

[klickverbot]

Ach ja, das port/swig-Verzeichnis sollte ebenfalls nicht Teil des Releases werden – da schlummert lediglich der halbfertige (und mangels in SWIG Trunk aufgenommenen D-Moduls ohnehin für die breite Öffentlichkeit nicht benutzbare) SWIG-Port für D. Ich hatte das Verzeichnis ursprünglich auf Bitte von Matthias oder irgendjemand anderem an SWIG/C# Interessierten ins SVN committed, aber mittlerweile hat der C#-Port eine eigene SWIG-Interface-Datei.

Wenn mein D-Modul in SWIG aufgenommen wird (vermutlich mit dem nächsten SWIG-Release), und damit ein D-Port via SWIG spruchreif wird, scheint es natürlich sinnvoll, die beiden Interfaces wieder zu mergen, aber im Moment fehlt mir die Zeit dazu, also erstmal weg damit.

Nachtrag: Wenn wir die Vertex-Animation-Datenstrukturen und -Attribute entfernen, ist das neue Release nicht sogar binärkompatibel zu 1.1, oder habe ich auf die Schnelle etwas übersehen? Dann wäre meinen eigenen Argumenten zufolge wohl eher 1.2 angebracht… ;)

Edit 2: Vergesst es, für Binärinkompatibilität sorgen allein schon die const-Änderungen in Assimp::Importer, außerdem ist ohnehin aiMesh::mName dazugekommen. Stellt sich bloß die Frage, ob wir die Gelegenheit nicht gleich nutzen sollen, um die Vertex-Anim-Attribute zu aiMesh hinzuzufügen, dann müssen wir die Binärkompatibilität nicht gleich wieder brechen, sollten Vertex-Animationen in näherer Zukunft doch benutzt werden…

Edit 3: Wobei, wie groß ist die Chance, dass Vertex-Anims in der nächsten Zeit gebraucht werden, wirklich? Ich habe über die »Aktivitäten« von mick-p etwas den Überblick verloren…

Edit 4: Ach ja, Alexander, in einer Dokumentationsänderung in aiConfig.h, r772, redest du von »[files have] carry invalid normals« – ist das ein Fachbegriff, den ich nicht kenne, oder einfach ein have/carry zu viel?

[Aramis]

Ein 'have' zu viel ;-)

Wobei, wie groß ist die Chance, dass Vertex-Anims in der nächsten Zeit gebraucht werden, wirklich?

Von mir aus eher gering.

Dann wäre meinen eigenen Argumenten zufolge wohl eher 1.2 angebracht…

Jetzt machen wir einfach nicht laenger rum und sagen 2.0 ;-)

Gruss, Alex

[klickverbot]

Ja, ich habe mich ohnehin schon selbst korrigiert – selbst ohne die Vertex-Animation-Änderungen wäre das neue Release nicht BC, insofern.

Ich kann mich dunkel erinnern, dass der werte Herr P. mal irgendwo einen Importer vorgestellt hat. Da war doch noch irgendwas mit Quaternionen und Euler-Winkeln, oder?

[Aramis]

Der Importer hatte mir persoenlich zu viele gotos, zu viel Spaghetticode, zu viel Code-Wiederholung und ein mir zu unbekanntes Fileformat. Den mit reinzunehmen steht im aktuellen Zustand nicht zur Disposition (zumal es keine „freien“ Testmodelle gab und die einzige von ihm genannte Quelle fuer Testmodelle auf CHINESISCH war und es demzufolge schwer war ein Lizenzierungsmodell rauszulesen).

Der Importer hat allerdings mit besagten Modellen durchaus funktioniert ;-)

Da war doch noch irgendwas mit Quaternionen und Euler-Winkeln, oder?

Ja, er brachte eine templatisierte Version des Quaternion-Codes. Ist nicht im Repos drin, selbst wenn waere es eine rein interne Sache und betraefe nicht das oeffentliche Interface.

[klickverbot]

Kompilieren die OpenGL-Samples eigentlich mit MSVC und CMake? Mit MinGW hagelt es Fehlermeldungen…

Edit: Ich habe mal schnell die non-standard-Syntax aus dem Textured-Beispiel entfernt, und es kompiliert und läuft sogar unter MinGW. Allerdings versucht es, zum hardgecodeten Spider-Model eine Textur mit dem Dateinamen »« zu laden, was natürlich fehlschlägt (dwarf.x funktioniert aber texturiert). Ich habe gerade kein MSVC zur Hand, könnte bitte jemand ausprobieren, ob es dort funktioniert?

[Aramis]

Es geht davon aus dass sich das Binary in ./samples/bin befindet. Das ist zugegebenermassen scheusslich.

[klickverbot]

Huch, irgendwie scheinen CMake-Builds auf Windows (entgegen meiner sonst guten Erfahrungen mit CMake -.-) doch von bit rot betroffen zu sein – während BOOST_WORKAROUND-Builds auch mit MSVC funktionieren, bindet Boost 1.44.0 stdint.h ein, was zu Kollisionen mit unserer pstdint.h führt.

Tritt das Problem auch in den handgewarteten Solutions auf? Irgendwelche Lösungsideen?

[kimmi]

OpenGL-Beispiele sollten in CMake verfügbar gemacht worden sein. Wenn ich da was vergessen habe, ist das pure NAchlässigkein von mir :). Das Einbinden unserer pstdint.h könnte man doch durch einen #ifdef-Block abfangen, wenn NOBOOST=TRUE ist, oder?

Gruß Kimmi

[glassbear]

Ich werf mal noch eine Bitte in den Raum: Hab mir gerade das Source Release runtergeladen (assimp--1.1.700-sdk.zip) und entpackt. Es wäre toll, wenn der ganze Inhalt in einem Unterverzeichnis drin wäre, z.B. assimp-1.1/ ;)

[kimmi]

Das wäre in der Tat eine tolle Sache. Diesen Antrag würde ich gern unterstützen. By th way @Aramis: Du kann übrigens auch per CMake dir NullSoft-Installer-Skripte bauen.

Gruß Kimmi

[klickverbot]

Das Einbinden unserer pstdint.h könnte man doch durch einen #ifdef-Block abfangen, wenn NOBOOST=TRUE ist, oder?

Ja, aber ich bezweifle irgendwie, dass die VC9-Workspaces nicht mit Boost funktionieren sollen – deswegen die Frage, wie das Problem dort gelöst ist, bzw. woran es liegen könnte, dass es in CMake/MSVC/Boost-Builds hapert. Ich habe leider nur die Express Edition von MSVC 2010 installiert, wegen der x64-Targets kann ich die Solution nicht öffnen (und dort selbst nachsehen)…

[Aramis]

Evtl. wird es am WE bei mir zeitlich schwierig.
Ich hoffe es hat niemand was dagegen, das ganze um eine Woche zu verschieben? :?

[klickverbot]

Von mir aus können wir den Termin auch gerne auf nächstes Wochenende verschieben, ich bin im Moment ohnehin damit beschäftigt, den Merge meines D-Modules in den SWIG-Trunk vorzubereiten, insofern wäre das auch bei mir günstiger.

Somit hätten auch andere Leute noch genügend Zeit, ihre Einwände und/oder Patches einzubringen. Vielleicht sollten wir die Entscheidung bezüglich Vertex-Anim-Datenstrukturen auch auf der Mailing List bekanntgeben bzw. diskutieren?

Wir sollten uns ebenfalls irgendwo eine Tabelle zurechtlegen, wer welchen Build (CMake/MSVC/XCode/…) auf welchen Systemen getestet hat, damit wir sicher sein können, dass wenigstens die beliebtesten Konfigurationen auf jeden Fall funktionieren (CMake: MinGW/Windows, GCC/Linux, GCC/OS X, MSVC: 9, 10, XCode: 3.2.4, …).

Was auf jeden Fall noch einer Überlegung bedarf, ist der CMake-Install-Support unter Windows – »make install« installiert die Dateien zwar in einen Ordner unter %ProgramFiles%, aber weil die Library nicht im gleichen Verzeichnis wie die Binaries liegen, funktionieren die Samples nicht out-of-the-box (wenn ich mich richtig erinnere). Ich weiß nicht, ob das in irgendeiner Weise relevant ist (»make install« unter Windows, wer macht das schon?), aber vielleicht gibt es hier ja eine einfache, bessere Lösung.

Ich werde mir morgen übrigens MSVC 2010 über Dreamspark besorgen, dann kann ich das Boost-Problem hoffentlich selbst klären…

[kimmi]

Das mit dem Verschieben ist von meiner Seite aus kein Problem. Und die Diskussion bezüglich der animated-vertices kann ich gern in der ML starten.
Wegen Build: welche sollten wir testen? Ich kann VS2003 + VS2008 + Linux Builds testen.

Gruß Kimmi

[Aramis]

Und genau jetzt kommt einer der uns evtl. bei aiAnimMesh helfen will:
https://sourceforge.net/projects/assimp ... ge=8773065

Murphy‘s Lay, schon wieder ;-)


Beeinflusst aber dieses Release nicht - davon abgesehen dass ich um die Datenstrukturen jetzt wohl doch nur ein #if 0 herumsetzen werde.

[Chromanoid]

Wegen der von mir gemeldeten Unzulänglichkeit:

btw DAE Loader: im dae loader steht, dass keine leeren texture channel unterstützt werden. ich bin auf einige modelle gestoßen, die leere channel haben bzw. wo der erste textur channel 1 und nicht 0 war... Ich hab das per Hand in den DAEs geändert, aber wenn du dich irgendwann nochmal dran setzt, wäre das vielleicht auch etwas, was man ändern könnte .

Also hier eine test DAE von mir. Es handelt sich um eine Box.
Das Ding hat drei UV-Kanäle (1,3 und 4). 3 wird für die obere und untere Seite benutzt. 4 für die Seitenflächen. 1 ist unbenutzt.

In AssimpView wird immer nur der erste UV-Kanal im Kanal-Array angezeigt. Deshalb wird hier das Modell sowieso fehlerhaft dargestellt.

Assimp selbst lädt die Kanäle in den Kanal-Array ohne die Kanal-Nummer zu beachten. Entweder ich habe eine Zuordnungstabelle übersehen oder man soll die Indizes im Kanal-Array über die Sortierung und Reihenfolge der Kanal-Nummern herausfinden oder Assimp ist auf solche Modelle nicht ausgelegt. Denn wenn man direkt die Kanal-Nummer aus dem Material nimmt, hat man den falschen Index für den Kanal-Array.

Viele Grüße
Christian

PS: Im Anhang auch eine korrigierte Datei, die allerdings auch nur halb mit AssimpView funktioniert, da dort ja eh nur der erste Kanal im Array benutzt wird. Beim Anpassen per Hand habe ich einfach die set-Attribute des Materials/der Kanäle verändert.

[Schrompf]

Danke für das Testmodell. Collada ist echt ein Dauerbrenner :-( Ich hab mit diesem hier jetzt wieder drei Fehlerfälle und noch einen Tag Urlaub - mal schauen, was ich machen kann.

[Chromanoid]

Also nur dass du informiert bist :) ich hab da nicht unbedingt mehr bedarf dran. Das iphone Projekt hat endlich sein ende gefunden. Bei gelegenheit kann ich ja mal den code für ein assimp objective-c tutorial zur verfügung stellen (ist aber ohne animations- oder lichtimport oder so - einfach nur die modelle, mit texturen, vertexfarben und normalen + default belichtung)... :)

[Schrompf]

Moin Christian,

ich bin trotz Undringlichkeit mal Deinem Problem nachgegangen. Das Modell wird korrekt geladen! Im Ernst :-) Es sieht im Viewer aber nicht korrekt aus, weil das Modell drei Texturkoordinaten-Sätze mitbringt - benannt 0, 3 und 4. Und davon wird in der einen Subgroup nur die 3 und in der anderen nur die 4 benutzt. Der Collada-Loader macht daraus zwei Meshes, die jeweils alle drei Texkoord-Sätze mitbringen. Man müsste also einen Shader schreiben, der tatsächlich den in aiMaterial benannten Texkoord-Satz benutzt, wenn er aus der Textur liest. Aber AssimpView bringt einen solchen Shader natürlich nicht mit. Wenn Du einen eigenen Renderer schreibst und solche Stunts mit Texkoord-Sätzen brauchst, musst Du die aiMaterial-Settings pro Textur berücksichtigen.

Ich persönlich würde aber eher die Finger von Multi-Texkoord-Geschichten lassen :-)