Assimp - Brainstorming zum Release

[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.

[klickverbot]

Assimp wird auf Linux (CMake) derzeit nicht fehlerfrei gebaut.

Einerseits funktionieren die Unit-Tests nicht, weil erstens die cppunit-Kopie im contrib-Verzeichnis nicht in den Include Path aufgenommen wird und sich zweitens die Boost-Workarounds auf GCC 4.3.4 anscheinend nicht kompilieren lassen (eine lange Liste wüster Fehlermeldungen wie »assimp/test/unit/BoostWorkaround/../../../include/BoostWorkaround/boost/tuple/tuple.hpp:155: error: class ‘boost::tuple<T0, T1, T2, T3, T4>’ is implicitly friends with itself«).

Andererseits wird in den CMakeLists zu assimp_cmd fix zu »comctl32.lib« und »Winmm.lib« gelinkt, die auf Linux natürlich nicht existieren. Der folgende Patch behebt das Probelm, assimp_cmd scheint weiter zu funktionieren. Mangels README oder zumindest einem funktionierenden »./assimp_cmd help« kann ich das aber nicht wirklich überprüfen.

Code: Alles auswählen

diff --git a/tools/assimp_cmd/CMakeLists.txt b/tools/assimp_cmd/CMakeLists.txt
index 79175a9..c680df6 100644
--- a/tools/assimp_cmd/CMakeLists.txt
+++ b/tools/assimp_cmd/CMakeLists.txt
@@ -69,8 +69,9 @@ IF( WIN32 )
                        "C:/Programme/Microsoft Platform SDK for Windows Server 2003 R2/Lib"
                DOC "Path to psdk"
        )
-ENDIF( WIN32 )

-# Link the executable to the Hello library.
-target_link_libraries ( assimp_cmd assimp ${DX9_LIBRARIES} comctl32.lib Winmm.lib  )
+       target_link_libraries ( assimp_cmd assimp ${DX9_LIBRARIES} comctl32.lib Winmm.lib )
+ELSE( WIN32 )
+       target_link_libraries ( assimp_cmd assimp )
+ENDIF( WIN32 )

[klickverbot]

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

Da ich einen Link zu http://assimp.sf.net auf ein paar D-Seiten gepostet habe, wäre es wohl geschickt, das so bald wie möglich zu tun…

[Aramis]

Ich hab mal Links und Hinweis auf die HP gesetzt, ich hoffe du bist in der Form damit einverstanden. Morgen kann ich dann gerne noch Änderungen vornehmen ;)

[klickverbot]

Ich hab mal Links und Hinweis auf die HP gesetzt, ich hoffe du bist in der Form damit einverstanden. Morgen kann ich dann gerne noch Änderungen vornehmen ;)

Ich habe gerade gemerkt, dass mir der Broweser-Cache einen Streich gespielt haben dürfte – sorry, falls die D-Bindings eh schon seit längerem erwähnt worden sind. :)

Edit: Ich würde den Hinweis zu D auf der »Documentation«-Seite fast auf »There's a README in the port/dAssimp directory« abändern, damit gleich ersichtlich ist, dass dAssimp ganz normal im SVN liegt. Geschmackssache…

[kimmi]

Danke für den Linux-Patch. Ich habe das zugegebenermaßen aufgrund der Tatsache, daß ich auf meinem Developer-PC noch keine Linux-Installation habe, noch nicht unter Linux getestet. Ich bau erst mla deinen Patch ein und werde das dann noch mal etwas genauer testen.

Gruß Kimmi

[Aramis]

Hoi,

Ein vielleicht etwas überaschender, weil völlig ungeplanter, zugleich etwas umfangreicherer Patch:

• (Fast) alle textbasierten Loader kommen nun mit Unicode-Eingabedateien klar (UTF8, UTF16 LE/BE, UTF32 LE/BE). Alles wird nach UTF-8 konvertiert, zum Einsatz kommt die Referenzimplementierung des Unicode-Konsortiums (die ist nicht kompakt, funktioniert dafür aber äußerst zuverlässig).
• Auch IrrXML verwendet nun den Unicode-Konverter anstelle eines simplen Typcasts.
• aiString ist in der Dokumentation nun explizit als UTF-8 String markiert. aiString::length ist also nur noch die binäre Länge des Strings, wenn Multibyte-Sequenzen eingebettet sind ist die tatsächliche Länge des Strings entsprechend kürzer.

Alle diese Änderungen sind vollständig rückwärtskompatibel, wer bislang einen aiString als ASCII-Zeichenkette sah, kann dies auch in Zukunft machen, erhält für japanische Sonderzeichen dann aber naturgemäß nur Schrott :-)

Oben: korrektes Unicode-Handling, Unten: Alter Stand.

Ich hab soweit es ging mit einer großen Anzahl an Modellen getestet, und konnte keine Probleme feststellen. Dennoch ist die Änderung weitgreifend und betrifft nahezu die Hälfte aller Loader ... ich bitte euch also, ebenfalls vorsorglich nochmals zu testen und auftretende Probleme zu melden bzw. einen revert durchzuführen (ich bin die nächsten Tage eventuell nur eingeschränkt am Internet)

- Alex

[Gelöschter Benutzer]

Ich will jetzt hoffentlich nicht für Stress sorgen, aber mir ist da etwas aufgefallen :P.

Nach Doku erhält man die Materialeigenschaft mit:

Code: Alles auswählen

aiColor3D color (0.f,0.f,0.f);
mat->Get(AI_MATKEY_COLOR_DIFFUSE,color);

Ich hab das nun einfach mal 1 zu 1 angewendet:

Code: Alles auswählen

MeshMaterial(BSX::Main::DX10Device &Device, BSX::Main::DX10TextureList &TexList, const aiMaterial &Material)
{
	aiColor3D tmpColor(0.0f, 0.0f, 0.0f);

	// Get the material colors:
	Material.Get(AI_MATKEY_COLOR_AMBIENT, tmpColor);
	aiColorToFloat4(ColorAmbient, tmpColor);

// Und so weiter...

Warum kommt das?:

Code: Alles auswählen

error C2664: 'aiGetMaterialProperty' : cannot convert parameter 3 from 'unsigned int' to 'aiTextureType'
1>          Conversion to enumeration type requires an explicit cast (static_cast, C-style cast or function-style cast)
1>          g:\pumi\programmierung\bsgameengine\demo brute-force-terrain-indexed\bsmesh_material.h(110) : see reference to function template instantiation 'aiReturn aiMaterial::Get<aiColor3D>(const char *,unsigned int,unsigned int,Type &) const' being compiled
1>          with
1>          [
1>              Type=aiColor3D
1>          ]

IDE ist VC++ 2010. Es handelt sich um den aktuellsten trunk.

[Aramis]

Sollte nun gefixt sein. Eigentliche Ursache war eine fehlende Templatespezialisierung für aiColor3D.
Danke für den Bugreport :-)

[Gelöschter Benutzer]

Gern geschehen. Da ich mich gerade in die Bibliothek einarbeite werden mir bestimmt noch weitere Fehler auffallen, die ich dann einfach mal melden werde. Btw konnte ich mir mal das Materialsystem ansehen. Alles erstmal afaik ganz nett, außer diese Texturliste für verschiedene Dinge ;).

[Aramis]

Da ich mich gerade in die Bibliothek einarbeite werden mir bestimmt noch weitere Fehler auffallen

Unmöglich! Unsere Schilde sind undurchdringlich!

Btw konnte ich mir mal das Materialsystem ansehen. Alles erstmal afaik ganz nett, außer diese Texturliste für verschiedene Dinge

Ja, vielleicht wäre eine wweitere Hierarchieebene in der Datenstruktur für Material-Texturen sinnvoll gewesen. Lässt sich nun aber nicht mehr ändern - aiMaterial::GetTexture() macht das ganze zudem völlig unsichtbar für den Anwender. Die langen Konstantenlisten existieren teils nur aus Kompatibilitätsgründen zur ersten Assimp-Beta - mit der ersten Major-Version nach diesem Release fliegen sie vermutlich raus :-)

Achja, mehrere Funktionsparameter von einem Mako übergeben zu lassen ist zugegebenermaßen auch nicht die feine Englische. Auch das war nötig um Rückwärtskompatibilität zu wahren, leider.

[Gelöschter Benutzer]

Ist auch akzeptiert, dann eben nicht. Aber zu den Fehlern... also Gesetzeslücken findet man ja wohl immer :lol: !

[Jonathan]

Mal ein Vorschlag, was man noch einbauen könnte:
Ein PostPro Flag, welches nicht genutze Bones bei Animationen entfernt.
Hauptsächlich fände ich das gut, um in de Lage zu sein, mehrere Animationen auf einem Objekt zu haben. Z.B. eine beliebige Lauf Animation für die Beine + eine Armanimation (damit man zum angreifen weder stehen bleiben muss, noch eine extra Laufangriff-Animation benötigt).
Ich meine, einige Exporter mögen das wohl direkt ordentlich liefern, aber eine ganze Menge bestimmt nicht. Daher fänd ich das als PostPro Schritt überaus sinnvoll.

[Aramis]

Du meinst ein Step, der Bones, die von keiner Animation referenziert werden, entfernt?

Hauptsächlich fände ich das gut, um in de Lage zu sein, mehrere Animationen auf einem Objekt zu haben

Aber das ist doch möglich!? Die aiScene nimmt beliebig viele Animationen auf. Wenn eine Animation bestimmte Bones nicht braucht, so ist für diese meist auch kein (Dummy-)Eintrag in der aiAnimation enthalten. Oder stört dich genau dieses 'meist'?

[Jonathan]

Ja, das "meist" ströt mich. Also wie schon erwähnt, ich habe meinetwegen eine Lauf- und eine Hauanimation. Jetzt will ich ein System programmieren, welches mehrere Animationen gleichzeitig abspielen kann und zwischen diesen interpoliert. Nur, wenn bei der Schlaganimation nur Arme bewegt werden, aber trotzdem die ganzen Keys für die Beine mit drin sind, würde ja Laufanimation ja nur mit halber Gewichtung abgespielt werden, die Beine würden sich also z.B. nur halb so weit wie eigentlich bewegen.
Oft hat man diese Anforderung ja nicht unbedingt, weil ein Modell z.B. nur eine Animation zur gleichen Zeit hat. Ich habe jetzt noch nicht so enorm viele Exporter getestet, aber bei Cal3D war es z.B. so, dass wenn man zum animieren IKs benutzt hat, der Exporter die Animation "baken" (mir fällt gerade echt kein passendes, deutsches Wort ein) musste, und man somit zu jedem Zeitpunkt für jeden Knochen einen Key hatte, wodurch das über- und zusammenmischen von Animationen sehr komische Ergebnisse lieferte.

Ich weiß nicht, wie viele Exporter das betrifft, aber ich meine, dass auch in Ogre Dateien für Knochen die eigentlich überhaupt nicht bewegt wurden zumindest eine handvoll Keys vorhanden waren.

[Aramis]

Grade entdeckt:

By default, all 3D data is provided in a right-handed coordinate system such as OpenGL uses. In this coordinate system, +X points to the right, +Y points away from the viewer into the screen and +Z points upwards. Several modeling packages such as 3D Studio Max use this coordinate system as well. By contrast, some other environments use left-handed coordinate systems, a prominent example being DirectX. If you need the imported data to be in a left-handed coordinate system, supply the aiProcess_MakeLeftHanded flag to the ReadFile() function call.

Ich dachte, es sei das 'andere RH' (X-Up, Y-Right, Z-Back)? Stimmt da die Doku nicht, oder hat sich das geändert?