Assimp - Brainstorming zum Release

[Matthias Gubisch]

Was meinst du mit harten Pfaden zu dependencies

dass die Pfade zu 3rd-PartyLibs VisualStudio bekannt sein müssen ist ja wohl nicht das Problem der SLN...

Pfadangaben innerhalb der Soulution sollten sich imho immer auf das Projekt beziehen und nich irgendwelche ThirdParty Libs an bestimmten Stellen voraussetzen
und imho ist das bei ASSIMP auch der Fall.

Grüße
Matthias

[kimmi]

Ich denke, hier wird das Problem adressiert, daß man kein AutoConfig beim Visual Studio hat. Das macht CMake im übrigen auch implizit, wenn man die Makes entsprechend schreibt *rumpose*...

Gruß Kimmi

[Thoran]

Was meinst du mit harten Pfaden zu dependencies

Voll ausgeschriebene Pfade wie z.B. "c:\meinLibPfad\meine3rdPartyLib"

dass die Pfade zu 3rd-PartyLibs VisualStudio bekannt sein müssen ist ja wohl nicht das Problem der SLN...

DIe Pfade müssen in der *.sln bekannt sein, so daß die 3rd-Party Lib gefunden wird.

Pfadangaben innerhalb der Soulution sollten sich imho immer auf das Projekt beziehen und nich irgendwelche ThirdParty Libs an bestimmten Stellen voraussetzen
und imho ist das bei ASSIMP auch der Fall.

Grüße
Matthias

Als Entwickler weiß man aber nicht wo derjenige, der die Lib runter lädt seine 3rd-Party lib liegen hat. Also kann ich das Verzeichnis auch nicht in der *.sln fest angeben.
Es sei denn mann packt alle 3rd-Party libs in das Projektverzeichnis mit rein, so daß man sie mit einem relativen Pfad angeben kann, was ich persönlich nicht so toll finde.

Ich hoffe es wird deutlich was ich gemeint habe. Aber nochmals: Vielleicht ergibt sich das Problem bei Assimp gar nicht.

Thoran

[Thoran]

Ich denke, hier wird das Problem adressiert, daß man kein AutoConfig beim Visual Studio hat. Das macht CMake im übrigen auch implizit, wenn man die Makes entsprechend schreibt *rumpose*...

Gruß Kimmi

Und durch die mal besser, mal schlechter funktionierenden CMake Module.

Thoran

[Schrompf]

dass die Pfade zu 3rd-PartyLibs VisualStudio bekannt sein müssen ist ja wohl nicht das Problem der SLN...

DIe Pfade müssen in der *.sln bekannt sein, so daß die 3rd-Party Lib gefunden wird.

Nein, das ist der Knackpunkt. Bei Visual Studio erklärt man die Include- und Libpfade der IDE und nicht dem Projekt. Sprich: jeder Entwickler kann seine Libs rumliegen haben, wo er will, er muss nur VS die Pfade zu den jeweiligen Includes und Libs geben. Danach findet jedes Projekt die.

Mit Visual Studio 2010 hat sich das geändert, jetzt gibt es die nur noch als Projekteigenschaften. Was mich sehr betrübt, weil ich dort ja keine absoluten Pfade eingeben kann... die gelten ja nur für meinen Rechner. Allerdings kann ich da auch keine relativen Pfade eingeben, dann auch die stimmen nur auf meinem Rechner. Mit diesem Umbau wurde einfach ein gut funktionierendes System aufgegeben, ich hoffe aus triftigem Grund.

Assimp hat übrigens außer Boost keine Abhängigkeiten. Und selbst das ist dank der andauernden Bemühungen von Aramis optional. Entgegen meiner andauernden Bemühungen, neue interessante Boost-Libs zu finden, für die er dann eine einfache Emulation schreiben muss...

[Aramis]

In jedem Fall sind wir dankbar für jeden Kommentar. Das inhomogene Buildsystem ist imho unser Hauptschwachpunkt, neben alten Codeleichen. Übrigens hat auch das Sample momentan nur eine separate vc8 solution und ein GNU makefile. Cmake's werden noch nachgeliefert ...


Das hier ist auch einen Blick wert, ich hab den Link grade erst bekommen. Wohlgemerkt ist das nicht (j)Assimp .. sueastside hat mit asssimp_cmd XML Dumps (*.assxml) generiert und diese dann in dem Applet geladen. Ursprünglich waren sie ja nicht dafür gedacht, aber es spricht nichts gegen diesen Verwendungszweck ... :-)

Edith meint:

Entgegen meiner andauernden Bemühungen, neue interessante Boost-Libs zu finden, für die er dann eine einfache Emulation schreiben muss...

Bäh! :x

[Matthias Gubisch]

dass die Pfade zu 3rd-PartyLibs VisualStudio bekannt sein müssen ist ja wohl nicht das Problem der SLN...

DIe Pfade müssen in der *.sln bekannt sein, so daß die 3rd-Party Lib gefunden wird.

Nein, das ist der Knackpunkt. Bei Visual Studio erklärt man die Include- und Libpfade der IDE und nicht dem Projekt. Sprich: jeder Entwickler kann seine Libs rumliegen haben, wo er will, er muss nur VS die Pfade zu den jeweiligen Includes und Libs geben. Danach findet jedes Projekt die.

Mit Visual Studio 2010 hat sich das geändert, jetzt gibt es die nur noch als Projekteigenschaften. Was mich sehr betrübt, weil ich dort ja keine absoluten Pfade eingeben kann... die gelten ja nur für meinen Rechner. Allerdings kann ich da auch keine relativen Pfade eingeben, dann auch die stimmen nur auf meinem Rechner. Mit diesem Umbau wurde einfach ein gut funktionierendes System aufgegeben, ich hoffe aus triftigem Grund.

Ich bezog mich jezt auf die für ASSIMP vorhandenen .sln für vc8 und vc9
VS2010 hab ich noch nicht getestet von daher kann ich da noch keine Aussage dazu machen.

Wenn wir allerdings die C-Make skripte mitliefer dann ist es ja jedem freigestellt, die mitgelieferten makefiles oder .sln zu nutzen oder sich seine eigenen zu erstellen

[kimmi]

Also belassen wir es doch einfach dabei, daß wir für die gängigen IDEs / Makesysteme entsprechende Build-Enviroments mitliefern. Mich stört das nicht.
Und das Problem mit dem Buildsystem ist weit verbreitet. In der ZFXCE kenne ich das zu Genüge, OpenSceneGraph geht den CMake-Weg ( da habe ich die Idee überhaupt erst bekommen, das mal zu probieren ), Nebula2 auch. Ogre bietet mehrere Build-Enviroments an, die mal mehr, mal weniger zuverlässig aktualisiert werden. Will man Gimp unter Windows bauen, muß man sich sogar zuerst eine unixähnliche Buildumgebung mit Cygwin zusammenschustern. Auch nicht gerade der Weißheits letzter Schluß.

Gruß Kimmi

[klickverbot]

Ich habe meine Bindings jetzt einmal komplettiert (ich hoffe zumindest, dass nichts fehlt), und diesen Vladimir (wenn ich die kyrillische Mailadresse richtig gelesen habe) darum gebeten, sie zu testen (selbst benutze ich ja nur einen kleinen Teil des Funktionsumfangs).

Wie schon angekündigt, sind mit in den Dokumentationskommentaren einige kleine Schnitzer aufgefallen. Einen Teil davon habe ich gleich ausgebessert (Diff unter http://gist.github.com/151610), den anderen Teil habe ich leider zum Großteil wieder vergessen. Gemerkt habe ich mir:

• In der README werden sowohl Leerzeichen als auch Tabulatoren zur Einrückung verwendet.
• Die Copyright-Texte (im Lizenz-Vorspann und in AssimpPCH.cpp) sollten wohl einheitlich die gleichen Jahreszahlen angeben (und 2009 einschließen).
• Für AssimpCmd fehlt noch eine README.
• Der Name »Assimp« wird in drei verschiedenen Groß-/Kleinschreibungs-Varianten verwendet.

Zur Versionierung bzw. API-Stablilität: Ich kenne es von anderen Libraries so, dass innerhalb einer Major-Version garantiert ist, dass alle Releases abwärtskompatibel sind. Neue Schnittstellen können hinzugefügt werden; Funktionen, die aus der API entfernt werden sollen, werden als »deprecated« markiert und verschwinden dann mit dem nächsten Major-Release.

Die Bindings testen dann auf eine gleiche Major-Version und eine mindestens so große Minor-Version um sicherzugehen, dass einem nicht unerwarteterweise alles um die Ohren fliegt.

Edith sagt, dass »aiGetMaterialProperty« noch immer nicht richtig in die dynamischen Bibliotheken exportiert wird – ich binde die Funktionen dynamisch (nach dem Namen), und »aiGetMaterialProperty« wird nicht gefunden…

[Aramis]

Die Bindings testen dann auf eine gleiche Major-Version und eine mindestens so große Minor-Version um sicherzugehen, dass einem nicht unerwarteterweise alles um die Ohren fliegt.

Halte ich für eine gute Idee.

Ein weiterer Vorschlag an alle Bindingmacher außerhalb des Hauptrepos: was haltet ihr davon, wenn wir wenigstens Dummyverzeichnisse in <root>/port anlegen und darin einen Link auf die jeweiligen Projekte setzen? Es muss ja nicht unbedingt sein dass bestimmte Bindings gleich mehrfach entstehen, bloß weil die Betreffenden nichts voneinander wissen ...

[klickverbot]

Hielte ich für eine gute Idee. Wobei ich auch nichts dagegen hätte, wenn die D-Bindings in das SVN Repo wandern, sobald sie stabil sind – mir ist beides gleichermaßen recht.

[Aramis]

Edith sagt, dass »aiGetMaterialProperty« noch immer nicht richtig in die dynamischen Bibliotheken exportiert wird – ich binde die Funktionen dynamisch (nach dem Namen), und »aiGetMaterialProperty« wird nicht gefunden…

Ja, Matthias ist vor ein paar Tagen auch wieder drauf gestoßen ...

wenigstens kennen wir jetzt das eigentliche Problem (es tritt sowohl mit gcc/ld unter Linux als auch mit MSVC auf). aiGetMaterialProperty wird schon exportiert, aber so wie's aussieht mit C++-Bindung und entsprechend langem Namen.

Bloß, niemand weiß wieso . Gleich deklariert und definiert wie alle anderen aiGetMaterialXXX ... im globalen Namensraum .. dickes und fettes extern "C" ... Jegliche Hinweise sind willkommen. Ich kriege langsam aber sicher eine Paranoia davon, und hab Angst davor mich schrecklich ärgern zu müssen sobald wir dann wissen welche Kleinigkeit dran schuld ist.

Wobei ich auch nichts dagegen hätte, wenn die D-Bindings in das SVN Repo wandern, sobald sie stabil sind – mir ist beides gleichermaßen recht

Fände ich sogar noch besser ... bei entsprechender API-Stabilität werden die ja auch nicht sonderlich pflegebedürftig sein. Ist aber völlig deine Entscheidung - wenn du mir deinen SF.net-Accountnamen sagst, gebe ich dir gerne mal präventiv Schreibzugriff :-)

[klickverbot]

wenigstens kennen wir jetzt das eigentliche Problem (es tritt sowohl mit gcc/ld unter Linux als auch mit MSVC auf). aiGetMaterialProperty wird schon exportiert, aber so wie's aussieht mit C++-Bindung und entsprechend langem Namen.

Mhm, »_Z21aiGetMaterialPropertyPK10aiMaterialPKcjjPPK18aiMaterialProperty«… Ich habe leider auch keine Ahnung, woran das liegen könnte.

wenn du mir deinen SF.net-Accountnamen sagst, gebe ich dir gerne mal präventiv Schreibzugriff :-)

Dreimal darfst du raten… ;) Vorher muss ich die Bindings aber dringend noch testen, 4/5 der Funktionalität Assimps benutze ich in dem Software Rasterizer-Projekt nicht…

[Schrompf]

Gibt's von der Funktion vielleicht Overloads, weswegen die Compiler sich gezwungen fühlen, die als C++ exportieren? Die Parameter im Mangled Name klingen danach.

[kimmi]

Der Idee mit Major / MInor-Release stimme ich zu. Verstehe ich das richtig, daß dann die Minor Releases ( also z.B. 1.1, 1.2 etc. ) Bugfix-Releases darstellen beziehungsweise nur marginal neue Funktionalitäten beisteuern?

Gruß Kimmi

[klickverbot]

Verstehe ich das richtig, daß dann die Minor Releases ( also z.B. 1.1, 1.2 etc. ) Bugfix-Releases darstellen beziehungsweise nur marginal neue Funktionalitäten beisteuern?

In der Praxis wird das so sein, weil man bei einschneidenden Neuerungen meist auch die API umbauen will (wobei im Assimp-Kontext ein neuer Loader wahrscheinlich keine »marginal neue Funktionalität ist«, aber trotzdem keine API-Änderungen erfordert).

Theoretisch könnte man auch bei einem Minor Release große Neuerungen einführen, solange man die existierenden API nicht anrührt. Das gilt zumindest für den Plain C-Teil, bei C++ muss man für ABI-Kompatibilität auch auf einige andere Dinge achten (Stichwort: vtables, …).

Edith stellt fest, dass das Codebeispiel in der Dokumentation zu »aiGetPredefinedLogStream()« so nicht funktionieren kann.

[kimmi]

In der Praixs kenne ich das auch, vor allem das Geschrei bei API-Änderungen. Das ist auch der Grund gewesen, Architektur-Änderungen zumindest einen Zwischenrelease lang mit einer Deprecated-API zu versehen. Aber da wir da noch keine 1000 Installationen draußen haben, hoffe ich darauf, daß das Geschrei bei Änderungen in der Assimp-API nicht so groß ist und wir auch ohne sowas auskommen ;-)...

Gruß Kimmi

[klickverbot]

Nachdem sich der Typ nicht mehr gemeldet hat (und ich in den nächsten Wochen keine Zeit haben werde, extra eine Test-Applikation zu schreiben), habe ich die D-Bindings einmal commited. Vielleicht finden sich so ein paar Tester (ich nutze ja wie schon erwähnt nur einen kleinen Teil der API).

Ebenfalls in den Trunk gewandert ist meine Sammlung kleiner Dokumentations-Fixes, die ich oben gepostet habe.

[Aramis]

Wunderbar, danke dir für deine Mühe :-)

Vielleicht finden sich so ein paar Tester

Ich setze morgen noch Infos über die Existenz eines offiziellen D-ports auf die Assimp-Seite, somit wäre ich da durchaus zuversichtlich.

[kimmi]

Ich habe die fehlenden CMake-Files committed. Wer will, kann die nun probieren. Zumindest bei mir zu Hause konnte ich damit alles bauen. Nun lassen sich auch Build-Enviroments für AssImp-Cmd und die Unittests erstellen.

Gruß Kimmi

[Gelöschter Benutzer]

Was mir einfällt und mir bei meinem Projekt mittlerweile sehr gut gefällt:

Könnt ihr Definitionen und Konstanten nicht in einem Constants Namespace packen und diesem speziellen Bereich eine Klasse mit statischen Attributen? Das macht die Arbeit einfacher, da man hier nicht 1000x mal in die Doku schaun muss, wie jetzt nun das Property hieß (zum Beispiel bei Materialien oder Post-Prozessen).

Man schreibt sich!

[Aramis]

Das PlainC-Interface und die Datenstrukturen sind C, so etwas wie ein namespace oder eine Klasse ist nur schwer zu realisieren :-)
Die Frage ist, was wären die Vorteile? Intellisense funktioniert auch für #define's ..

[kimmi]

Der Vorteil wären ein sauberer Zugang zu Assimp-Symbolen, ohne Konflikte mit anderen Constants anderer Libs im globalen Namespace zu riskieren. Und sowas ist mir schon passiert :).

Gruß Kimmi

[Gelöschter Benutzer]

Vorteile? Kimmi hat schon einen genannt.

Mir fällt da noch einiges ein:

• Seitens des Users kann er zu einem bestimmten Flag besser die Flags finden und ordnen (bessere Übersicht für den Nutzer).
• Man kann es noch weiter treiben und sogar eine Funktion schreiben, die mittels bool-Parameter selbst die Flags packt (noch freundlicher).
• Für den Programmierer ist mehr Struktur vorhanden und dies beinflusst die Programmierung im positiven Sinne (spart Ärger und Arbeit).
• IntelliSense zeigt nun nicht einzig den Wert, wenn man den Namen schon kennt, sondern leitet einen gleich hin.
• Die Werte können in der lib besser miteinander kombiniert werden (sprich: Ein Konstantenregister für n Klassen allgemeingültig, oder man kann die Konstanten vererben).

Was mir als Gegenargument einfällt ist der "Mehraufwand". Der rechtfertigt sich aus eigener Erfahrung aber schnell (auch dessen Dokumentation).

Btw: Mir war auch so, dass es irgendwie ein define gab, mit dem man prüfen kann ob man C oder C++ Programmiert? Wenn ja, dann kann man das einfach nur für C++ als Specialfeature zupacken. Allgemein frage ich mich auch, warum man unbedingt auf C basieren muss, da es nun doch schon zumindest für Multimediaanwendungen nicht mehr wirklich verbreitet ist in aktuellen Projekten. Oder hängt das jetzt mit der .NET, Java und D Anbindung zusammen? Wo ist eigentlich der angekündigte OpenGL-Viewer-Code, ich finde nur den mit DirectX 9 und der Code-Stil ist in meinen Augen so grausam wie die Hölle... :mrgreen:

Man schreibt sich!

[kimmi]

@OpenGL-Viewer:
Aramis baut da an was. Ich versuche mich daran ebenfalls ( ist was neben der ZFXCE ), allerdings komme ich in der letzten Zeit nicht mehr so viel wie in meiner Singelzeit ;).

Gruß Kimmi

[Schrompf]

Keine Namespaces in der API. Nicht solange so viele andere Programmiersprachen ihre Bindings an der C-API festmachen. Die API ist stilistisch sauber... viel besser geht es nicht mehr, solange man in AnsiC-Gefilden bleibt. Man könnte höchstens einige unnütze Sachen entfernen. Daher: die API bleibt, wie sie ist.

Ein Define, um das Zeug in Abhängigkeit von C oder C++ in einen Namespace zu packen, hatten wir ganz am Anfang auch mal. Ergab aber Konflikte bei der Kompilierung der C-API. Wenn Du Auto-Completion haben willst, tippst Du aiThema_ ein und bekommst alle Werte zu dem Thema. Und zumindest Visual Studio erlaubt auch den Scope-Operator auf enums. Also im Sinne von aiEinEnum::Irgendwas.

Apropo "API bleibt, wie sie ist": finale Entscheidung zum Thema "Material-Indizes pro Mesh-Instanz"? Wenn das noch vor dem Release werden soll, müssten wir demnächst mal damit anfangen. Meine Stimme geht an "Ja".

[kimmi]

Wegen Namespaces: Zustimmung, den Ärger muß man sich nicht geben. Intern kann man sich ( sofern noch nicht geschehen ) ja etwas überlegen, um Konstanten etc. besser zu kapseln. Nach außen hin wäre das ein recht großer Ballen Ärger kurz vor Schluß, der einen Haufen Arbeit mit sich brächte. Hätte ich vorher besser herausstellen sollen, sorry.

Und wegen der API-Änderung bezüglich Mesh-Instancing: ich bin ebenfalls dafür. Noch ist eine Änderung ohne Deprecated aufgrund der fehlenden älteren Releases ja möglich.

Gruß Kimmi

[Aramis]

Könnt ihr Definitionen und Konstanten nicht in einem Constants Namespace packen und diesem speziellen Bereich eine Klasse mit statischen Attributen? Das

Ich sehe keinen Ärger mit den Konstanten - wir benutzen unser AI_ prefix, via Intellisense sind unsere define's und enum's keinen Deut weniger zugänglich als Klassen oder Namespaces die nur Konstanten enthalten (ganz mal davon abgesehen dass Klassen, die nur dazu dienen ein paar Konstanten zu kapseln definitiv nichts mit OOP oder dem C++ way of life zu tun haben ...).

Konflikte sind beim üblichen Einsatzzweck von Assimp sowieso unwahrscheinlich - die Lib wird ja nicht projektweit gebraucht, sondern idealerweise nur in einer Konverterunit lokal inkludiert. Insofern halte ich jegliche Änderung für Zeitverschwendung (seien wir mal realistisch, API-Änderungen in diesem Umfang sind auch nicht mehr möglich)

Btw: Mir war auch so, dass es irgendwie ein define gab, mit dem man prüfen kann ob man C oder C++ Programmiert?

__cplusplus

Wo ist eigentlich der angekündigte OpenGL-Viewer-Code

Es hat ein OpenGL-Codebeispiel, in <root>/Samples - mehr ist gerade nicht zu haben.

•Die Werte können in der lib besser miteinander kombiniert werden (sprich: Ein Konstantenregister für n Klassen allgemeingültig

Verstehe ich nicht, tut mir leid.

Apropo "API bleibt, wie sie ist": finale Entscheidung zum Thema "Material-Indizes pro Mesh-Instanz"? Wenn das noch vor dem Release werden soll, müssten wir demnächst mal damit anfangen. Meine Stimme geht an "Ja".

Wenn aiNode nur ein weiteres Array mit Mesh-Indizies erhält anstelle einer vollen neuen Datenstruktur ('aiMeshRef'), so sind nur noch ein paar Steps direkt betroffen:

RemoveRedundantMaterials
FindInstancedMeshes
OptimizeMeshes
OptimizeGraph
ValidateDataStructure

Und Loader mit entsprechendem Optimierungspotential:

Collada
NFF

Und sonstiges:

Die Assimp_cmd'schen Dateiformate hab ich bei mir sowieso komplett umgeschmissen, eine weitere Änderung wäre ertragbar.
Unittests -> keine Ahnung, wird wohl eher keine Probleme geben, auch wenn man evtl. die Testfälle für die obigen PP-Steps aktualisieren müsste. Regressionstests -> ah, ich will sie endlich einchecken können, aber ich traue ihnen noch nicht so ganz -> beeinflusst würden sie duch die API-Änderung aber nicht

- Alex

EDIT: es handelt sich auch um ein 'Ja'

[kimmi]

Ich sehe keinen Ärger mit den Konstanten - wir benutzen unser AI_ prefix, via Intellisense sind unsere define's und enum's keinen Deut weniger zugänglich als Klassen oder Namespaces die nur Konstanten enthalten (ganz mal davon abgesehen dass Klassen, die nur dazu dienen ein paar Konstanten zu kapseln definitiv nichts mit OOP oder dem C++ way of life zu tun haben ...).

Da die Konstanten nach außen per C bekannt gemacht werden, ist der Prefix dort sowieso bereits ein "C-Namespace". Innerhalb ( also nicht nach außen hin sichtbar ) kann es durchaus Sinn machen, Konstanten in der zugehörigen Klasse bzw. dem Loader per "Konstante in Klasse deklarieren" zuzuordnen. Aber das gibt nach außen hin keinen Benefit, da diese Definitionen nicht exportiert werden sollten. Das ist eher was für besser lesbaren Code, wenn man sowas bevorzugt:

Code: Alles auswählen

class foo {
  ...
  static const int Baa = 0;
};
int pos = foo::Baa;

Ist halt Frage des Stils ( und der Zeit / Lust, das zu ändern, wenn man will ). Und eigentlich gehört das auch nicht in die Release-Diskussion, ich schweife ab :).

Wegen Umstellung:
Wenn die Unittests Fehler auswerfen, sieht man schon mal, in wie weit die Änderung sich auswirken wird. Ist doch schon mal was.

Gruß Kimmi

[Aramis]

Wir sollten die Änderungen in einem separaten Branch vornehmen - aus dem Haupttrunk gibt es zu viele Check-outs pro Tag als dass wir da gefahrfrei so weitreichende Änderungen vornehmen könnten.

Die Anpassung der PP-Steps kann ich übernehmen, ebenso die Anpassung von assimp_cmd und die Aktualisierung der Unittests.

Eventuell sollte es auch eine Konfigurationsoption geben, um die Verwendung des neuen Features zu deaktivieren - dann käme einfach der bisherige Codepfad zun Einsatz, immerhin besteht er ja schon.