CarstenF hat geschrieben:Ich möchte gerne versuchen, auch besser zu erklären, was mich motiviert und wie:
Tut mir leid, die Antwort ist irgendwie bei mir untergegangen. Ich möchte mir ihr trotzdem, nun da ich sie bemerkt habe, detailliert widmen:
Bitte korrigiere mich, wenn ich Deine Vorhaben falsch verstanden habe oder falsch darstelle.
a) Assimp in Deiner Engine einsetzen
Ein verständliches Ziel, einige hundert andere Programmierer tun das ja auch schon. Assimp hat da eine Art Marktlücke getroffen, wenn ich das Feedback in den Internetforen recht verstehe.
b) das Datenmodell auf MD5-Strukturen umstellen
Als Grund gibst Du an, dass Du das Format für ebenso mächtig und dabei verständlicher hälst. Nunja, das ist Deine Meinung. Ich persönlich denke, dass gar keine so großen Unterschiede zum aktuellen Format bestehen. Immerhin lassen sich ja beide Formate ineinander umwandeln - der MD5-Loader tut ja genau das. Ich finde daher, dass - selbst wenn Du mit Deiner Meinung die Mehrheit der Nutzer vertreten solltest - die bestehenden Assimp-Datenstrukturen NICHT geändert werden. Das Umschreiben von 30+ Loadern und soundsovielen PostProcessingSteps ist das Eine. Das andere ist der Kompatibilitätsbruch zu all den bestehenden Nutzern und ihrem Glue Code. Die Vorteile des neuen Formats müssten gewaltig sein, um einen solchen Schritt zu rechtfertigen. Und das sind sie nicht.
c) das Datenmodell weg von POD und hin zu C++-Containern verändern
Nunja... das Datenmodell ist ein gelöstes Problem. Auch wenn es bisweilen mühselig ist, manuell die Arrays konstruieren zu müssen, ist doch der bestehende Code darauf ausgelegt und gut damit klargekommen. Man könnte mit C++-Containern an vielen Orten die eine oder andere Zeile Code sparen, müsste aber wieder alle Loader und all PPSs anpassen. Und das für ein im Grunde gelöstes Problem? Ich denke nicht. Auch wenn diese Änderung wahrscheinlich machbar wäre, ohne die externe Schnittstelle zu ändern. Schließlich könnte man jedes Datenarray intern ja als Container implementieren und die bisherige Zeiger/Count-Strukturen einfach darauf zeigen lassen. Das wäre auch Bedingung, damit all die Bindings zu anderen Programmiersprachen weiterhin funktionieren - die basieren aufgrund der portablen Natur reiner AnsiC-Funktionen meist darauf. Nur damit sich diese Änderung überhaupt lohnt, müsste man wie gesagt alle Loader und PPSs anpassen. Das halte ich in Anbetracht des doch reichlich diffus definierten Gewinns für fehlgeleitetes Engagement.
d) Die CodeStyle-Vereinheitlichung
Dazu wurde ja (inzwischen auch wieder sachlich :-)) genug diskutiert. Ich verstehe Dein Bedürfnis nach einheitlichem Stil - es macht das Lesen ein bisschen einfacher. Für private Zwecke der Lesbarkeit reicht es allerdings auch, das lokal auszuführen, wie Kimmi schon schrieb. Das Einchecken dieser Änderungen - nunja, das Thema hatten wir schon durchgekaut.
Nebenbemerkung: e) das Schreiben eigener Loader.
Das steht Dir natürlich frei. Es steht Dir sogar frei, Dir dazu beliebige Code-Teile aus Assimp zu nehmen - wir haben uns ja bewusst gegen die GPL und all ihre Einschränkungen entschieden. Ich möchte allerdings zu bedenken geben, dass das kein so einfacher Job wird, wie Du vielleicht denken magst. Allein das OBJ-Format hat in den letzten Jahren den einen oder anderen Grenzfall gehabt, der Detailkorrekturen am Code erfordert hat. Und das OBJ-Format ist eins der schlichtesten Formate. Formate, die Bone Animations unterstützen, gibt es nach meinem Wissen nur MD5, XFiles, Collada, (FBX), (Blender), evtl. 3ds? Den MD5-Loader hat Aramis geschrieben, dazu kann ich nichts sagen. XFile- und Collada-Loader stammen dagegen größtenteils von mir. Und die sind komplexe Biester, die auch heute noch regelmäßig Korrekturen und Zusatzcode brauchen, wenn mal wieder ein neuer Grenzfall zu behandeln oder um einen Bug eines seltenen Exporters drumrum zu bauen ist. Auch wenn Du den Code von Assimp nicht magst - Dein gutes Recht, nebenbei bemerkt - enthält er doch bereits enorm viel solchen Maintenance Code, den nachzumachen einer einzelnen Person schwerfallen wird.
Bye, Thomas
