ASSIMP auf das wichtigste beschränken

[Spiele Programmierer]

Ich habe mir auch gerade mal ASSIMP anschauen und möglicherweise darauf umsteigen soll. Meine Loader hatte ich bisher immer selbst geschrieben. Und zwar in C#. Aber jetzt komme ich nach langer Zeit in die Verlegenheit, in C++ gerne auch Modelle zu laden, da wäre ASSIMP für mich vielleicht eine Option.
Meine Frage ist allerdings: Gibt es eine Möglichkeit bestimmte "Module" zu deaktivieren? Von den ~40 Formaten würden mir ~5 absolut reichen. Der Rest bläht nur meine Binaries auf, erhöht Compilezeiten und schafft unnötige Abhänigkeiten. In diesem Cmake habe ich gerade mal bisher keine solchen Einstellungen gefunden. Außerdem motzt er bei mir wegen fehlenden DirectX-SDK. Was bei Visual Studio 10/12 ja gar nicht sein sollte. Ich verwende OpenGL, ich hoffe, dass ist nicht obligatorisch wenn ich ASSIMP für ein paar offene Formate verwenden will?

[Schrompf]

Es gibt ein ganzes Rudel Defines, um einzelne Formate zu deaktivieren. Ich weiß nicht, ob es irgendwo ne Liste davon gibt, ich orientiere mich immer an Importer.cpp, wo die alle an einem Ort verwendet werden. Ich weiß nur nicht, ob das so viel bringt.

Das fehlende DirectX-SDK motzt er nur für den Viewer an. Und den kannst Du komplett ignorieren.

[Spiele Programmierer]

Ok, dass das Dx-SDK nicht gebraucht wird, ist schonmal gut zu wissen.

Ich habe mal eben in die "Importer.cpp" geschaut. Ich kann da nichts finden "wo die alle an einem Ort verwendet werden".
Aber "ImporterRegistry.cpp" sieht gut aus. Mal schauen ob ich das hinbekommen. Werde auch mal versuchen mal Zlib mit dem angeblich kompatiblen Miniz ersetzen, weil ich das eh schon verwende.

[Krishty]

Von wegen Aufblähen war bei mir die Speicherallokation das größte Problem. (Der besagte Allokator verringert auch die DLL-Größe um 120 KiB.) Angesichts der horrenden Menge Maschinentext habe ich darauf vertraut, dass ein Commit der DLL-Speicherkacheln vermieden wird, wenn er nicht benutzt wird. Die Verlockung, 30 unbenutzte Formate rauszuschmeißen und dadurch 1 MiB zu sparen, ist groß – steht aber IMHO nicht im Verhältnis zu dem Trubel wenn ein einziges, das man braucht, fehlt und man die Projekteinstellungen ändern und alles neu kompilieren muss.

Ich muss auch irgendwann drübergucken um die derbsten Aufreger wegzumachen. Der PLY-Exporter schreibt z.B.

  mOutput << "property float tx" << endl;
  mOutput << "property float ty" << endl;
  mOutput << "property float tz" << endl;
  mOutput << "property float bx" << endl;
  mOutput << "property float by" << endl;
  mOutput << "property float bz" << endl;

statt

  mOutput << "property float tx\n"
             "property float ty\n"
             "property float tz\n"
             "property float bx\n"
             "property float by\n"
             "property float bz" << endl;

was das gleiche tut, nur um ein Vielfaches schneller und in einem Zehntel der Maschinenbefehle. Ist zwar keine innere Schleife, aber dummerweise findet der meiste Bloat an solchen Stellen statt.

[Ingrater]

Sowie ich das verstanden hatte, ist ASSIMP ja eigentlich nur für tooling gedacht und nicht dafür, dass man es in die laufende Engine einbaut. Ich für meinen Teil habe mir ein kleines command line tool geschrieben, was mithilfe von ASSIMP die Modelle läd, optimiert und dann in einem eigenen binärformat wieder rausschreibt. Das binärformat ist dann so ausgelegt, dass meine Engine das ganze File mehr oder weniger an einem Stück direkt in den gpu-buffer schieben kann, was bei Ladezeiten ungemein hilft. Wählt man den hier beschrieben Ansatz, kann einem dann auch egal sein wieviele Formate unnötig in ASSIMP sind, da es zur Laufzeit ja nicht mehr verwendet wird.

[Spiele Programmierer]

@Kristhy
Solche Änderungen solltest du dann aber auch nach Möglichkeiten aber nicht bloß im stillen Kämmerlein für dich machen sondern anschließend auch einchecken. ;) Das sind genau die Arten von Ineffizienz gegen die ich persönlich auch allergisch bin. "PLY" brauche ich aber zum Glück eh nicht, habe ich noch nie gehört.

Speicherallokationen, das hatte ich schon gelesen. Warum ist das eigentlich ein so großer Faktor? Ich dachte, dass geht grundsätzlich nur wenn man DLLs erstellt? Ich möchte eigentlich grundsätzlich keine DLLs für nicht optionales Zeugs verwenden.

@Integrator Hm, Binärformat ist natürlich eh geplant. Wäre auch eine Möglichkeit ASSIMP dann ganz rauszulassen(also aus der eigentlichen Software). Andererseits klingt es für mich verlockend, wenn man später vielleicht Modelle auch direkt ohne extra Tool importieren kann. Muss ich mir nochmal überlegen.

[Krishty]

@Kristhy
Solche Änderungen solltest du dann aber auch nach Möglichkeiten aber nicht bloß im stillen Kämmerlein für dich machen sondern anschließend auch einchecken. ;)

Ja; das war auch durchaus angedacht ;) Demnächst, wenn ich mehr mit Assimp zu tun habe.

Speicherallokationen, das hatte ich schon gelesen. Warum ist das eigentlich ein so großer Faktor? Ich dachte, dass geht grundsätzlich nur wenn man DLLs erstellt? Ich möchte eigentlich grundsätzlich keine DLLs für nicht optionales Zeugs verwenden.

Ja; geht nur mit DLLs. Ich hatte mich aus zwei Gründen für die DLL entschieden:

• Das mit dem page-out nicht benutzten Maschinentextes oben, und
• dass mir nicht immer Assimps globale Variablen um die Ohren fliegen wenn ich meine Heap-Optimierung durchführe.

Ein so großer Faktor ist es schlicht und einfach wegen der (im wahrsten Wortsinn) Millionen Mikroallokationen. So wie ich das sehe allokiert Assimp für jedes Polygon die Indexliste (also Millionen Mal drei oder vier Einträge und ab und zu auch mehr) via new.

Sowie ich das verstanden hatte, ist ASSIMP ja eigentlich nur für tooling gedacht und nicht dafür, dass man es in die laufende Engine einbaut. Ich für meinen Teil habe mir ein kleines command line tool geschrieben, was mithilfe von ASSIMP die Modelle läd, optimiert und dann in einem eigenen binärformat wieder rausschreibt. Das binärformat ist dann so ausgelegt, dass meine Engine das ganze File mehr oder weniger an einem Stück direkt in den gpu-buffer schieben kann, was bei Ladezeiten ungemein hilft. Wählt man den hier beschrieben Ansatz, kann einem dann auch egal sein wieviele Formate unnötig in ASSIMP sind, da es zur Laufzeit ja nicht mehr verwendet wird.

Damit hast du eigentlich 100 % recht, und so ein Tool habe ich ebenfalls. Nun bastle ich aber gerade am Level-Editor, und da ist es unbezahlbar, sich schnell ein beliebiges Asset aus dem Netz ziehen und direkt importieren zu können. Solche Fälle gibt es halt immer wieder.

[kimmi]

Stimmt, die tausend-und-eins Allokationen via new sind uns ebenfalls ein Dorn in Auge. Allerdings wurde Asset-Importer-Lib auch eher für das Tooling entwickelt und uns ging zunächst einmal Funktionalität vor Pre-Mature Optimization. Allerdings wird das ganze Importieren bei großen Modellen langsam langsa und dementsprechend wird wohl für den nächsten Release mehr Wert auf relevante Performance-Optimierungen gelegt werden müssen.

Kimmi

[Schrompf]

Du warst zu lange im Corporate Environment, Kimmi :-)

Ja, man müsste mal optimieren. Ja, es geht vor allem für die Freigabe der vielen kleinen Allokationen eine Menge Rechenzeit drauf. Ich habe aber keine Ahnung, wie ich das beheben sollte. Außer halt einen eigenen Allokator dahinterzuklemmen, der dann halt mit Inkaufnahme von Verschwendung ganz fix die Kleinstallokationen ausführen kann. Wir hatten da wie gesagt schonmal Experimente im Gange, aber die sind ewig her und haben es wohl nie zum release-fähigen Zustand geschafft.

[kimmi]

Stimmt :) ...

Ich hab bisher meist mehr auf Windeln geschielt als auf den Profiler. Ich hoffe, dass ich mehr machen kann in den nächsten Wochen als nur BUgs verwalten und ggfs. mal eine kleine Änderung.

Gruß Kimmi

[Krishty]

Es würde bereits reichen wenn man einen eigenen std::allocator übergeben könnte. Dann könnten die Anwender selber optimieren.

Beim PLY-Importer war es auch, IIRC, nicht die Indexliste sondern irgendwelche temporäre String-Objekte im Parsing-Code selbst.