[Assimp] Große Modelle

[kimmi]

Hallo zusammen,
da ich gerade auf ein Problem mit einem recht großen Modell, welches mittels Assimp geladen werden sollte, gestoßen bin, eine Frage von meiner Seite: Wie groß ( Vertices, Faces als ganz grober Messwert ) sind typischerweise eure Modelle, die Ihr mit Assimp ladet? Wie verhält es sich mit der Skalierung, wenn die Modelle größer werden? Hat sich da schon jemand mal etwas mehr mit ausgetobt bzw. Erfahrungen gemacht?
Mir fliegt hier gerade ein Modell mit einer Out-Of-Memory-Exception um die Ohren. Es werden etwas mehr als 1.000.000 Vertices beim Postprocessing in einen Vector geschoben. Und da bin ich neugierig, wie groß typischerweise eure Modelle sind.

Gruß Kimmi

[Schrompf]

Meine Modelle sind wegen geforderter Echtzeit-Tauglichkeit bisher immer recht klein gewesen. Das Komplexeste war das Luftschift, welches etwa 200k Polygone verteilt auf 100 Meshes hat.

Worauf zielt die Frage ab?

[Aramis]

Ich hab Assimp testweise mit gewaltig grossen Files benutzt, deren aiScene mehr als 100 mio Dreiecke Vertices hatte (Groessenordnung 2 Gigabyte nur dafuer, Postprocessing hat mich dann an den Rande des verfuegbaren Arbeitsspeichers getrieben).

[kimmi]

Die Frage zielt in Richtung Laufzeit-Verhalten der PostProcessing-Steps und ich war einfach mal neugierig, ob andere an ähnliche Limits gestoßen sind wie ich. Und ich habe mir einfach mal die Frage gestellt, wie die einzelnden Postprocessing-Steps skalieren, wenn man sie auf sehr große Modelle loslässt.

Bei kleineren bis mittleren Modellen hatte ich auch nie Probleme. bei einem sehr großem STL-Modell eines Gerätes bin ich im JoinVerticesProcess auf die Nase geflogen. Ich schau gerade mal, wieso ( sofern ich hier mal dazu komme ).

Gruß Kimmi

[Aramis]

Speicherverbrauch O(n), Laufzeit O(nlogn) fuer alle relevanten PP-Steps.

Wirklich geruestet fuer grosse Modelle sind wir nicht. Erstens kennen wir kein piecewise loading (wie sollte man das auch sinnvoll machen?) und zweitens hat das Verbose-Design unserer internen Datenstrukturen einen signifikaten Overhead (wenn man den Ergebnissen des JIV-Steps in der Testsuite glauben darf, sind es 285%).

Nur so nebenbei: die Verbose-Repraesentation ist nicht zwingend notwendig und verschlechtert sogar die Laufzeiten - ohne sie waeren einige der Steps sogar in linearer Laufzeit im best-case denkbar (wenn auch unter hoeherem Speicherbedarf, der aber laengst nicht so stark ins Gewicht fallen wuerde wie der Overhead des Verbose-Formats).

Wie dem auch sei, dafuer ist es wohl zu spaet :-(

[Schrompf]

An welche Steps denkst Du genau? Ich bin da nämlich anderer Meinung. Klar wäre es nützlich, wenn man bestehende Index-Strukturen benutzen könnte, aber nach meiner Erfahrung kann man sich bei keinem Format darauf verlassen. Die Vertices sind manchmal schon vorab vom Exporter verdoppelt worden, aber sind nicht mehr hinreichend verdoppelt, sobald zusätzliche Per-Vertex-Daten dazukommen. Jeder Step müsste das Verdoppeln bei Bedarf implementieren und könnte sich trotzdem auf nichts verlassen bei den Eingangsdaten. Ich sehe also keine Alternative zum Verbose-Format.

[kimmi]

Für piecewise müsste man Our-Of-Core Datenstrukturen definieren und man müßte diese performant irgendwo zwischen-parken können. Ich habe mal mit so etwas gearbeitet, abber entwickeln will ich das nicht: viel zu viel Arbeit und am Ende nicht das, was wir wirklich adressieren wollen. Irgendwann stößt man halt auf Limitationen, wenn man alles im Speicher hält.

Abkehr vom Verbose: Sehr viel Arbeit und mit vielen vielen Problemen behaftet.

Ich versuche mal Zeit zu finden, wie ich mein lokal auftretendes Problem lösen kann.

Gruß Kimmi