Ähem,

ich habe hier ein "Simples" Collada model *hust*,
das ich mit der "Open Asset Importer" Library öffne.

Das model hat 976 Meshes, jedes Mesh enthält Vertices, Faces und mehr.
Ingesamt sind es 742461 Vertices (X,Y,Z) mit 247487 Faces (Jedes face ist ein Dreieck).

Diese Library ist mittels SWIG in C# also in .NET eingebunden.

Habe nun ein einfaches Proggie gebaut in C# welche das Model öffnet und "Versucht" dieses model in ein anderes Format zu speichern.

Genauer gesagt habe ich mir gestern abend ein Format ausgedacht, indem man eigentlich models schnell lesen kann.
Runtergecodet war es schnell, zu schnell vielleicht -.-

Weil das ding läuft schon seit 3-4 Stunden und hat noch nichtmal nen Viertel des Models auf die Platte geschrieben.

Der Speicherverbrauch ist extrem, es springt von 200mb - 800mb.
Ab und zu räumt der Garbage collector auf, das merkt man das dann der verbrauch auf 200 mb sinkt.

Aber ich weiss absolut net warum das so lange brauch zum speichern.

Möglicherweise ist mein Format das ich mir ausgedacht habe nicht für massen daten ausgelegt ?
Oder .NET ist einfach für die Datenmenge zu langsam ? Kein plan.

Was auch doof ist in .NET kann ich nicht direkt float oder int arrays speichern.
Ich muss jedes einzelne float oder int über den BinaryConverter jagen, was wohl super langsam ist ?

Ich erkläre dazu mal schnell noch das Format das ich mir ausgedacht habe:

- Header mit folgenden Infos:
- Magic char[9]
- Anzahl an Meshes (uint)
- Start position des ersten Meshes (uint)

Alle meshes folgenden nun nacheinander:

- Mesh header mit folgenden infos:
- Mesh flags (uint)
- Anzahl vertices (uint)
- Anzahl indices (uint)
- Anzahl faces (uint)
- Start position der vertices für dieses mesh (uint)
- Start position der indices für dieses mesh (uint)
- Start position der faces für dieses mesh (uint)

- Vertices für dieses Mesh (X,Y,Z, U, V, Normals XYZ, Tangents XYZ, BiNormals XYZ)

- Indices für dieses Mesh (Uint pro index)

- Alle faces für dieses mesh

- Anzahl indices für dieses face (uint)
- Start index im index array für dieses face (uint)

Fertig.





Hab den Source zum Schreiben der "aiScene" mal als .cs Datei angehängt.

Vielleicht hätte wer eine Idee wie man das "Besser" oder "Schneller" machen könnte.

Geplant ist es auf jedemfall das diese Daten dann in einen Octree geladen werden.

Hat das seine Richtigkeit? Den du schreibst da das gleiche wie bei mesh.HasTextureCoords(0).

Ich habe keine Ahnung was du da falsch machst, aber länger als eine, zwei Sekunden sollte das pro Mesh nicht dauern, selbst wenn du es ein paar mal unnötig herum kopierst. Ich könnte mir höchstens vorstellen das es sich bei deinen Zugriffen auf das Mesh nicht wirklich um Arrays handelt sondern innerhalb deiner Library der []-Operator überladen wurde und der da eigentlich intern eine Halbkantenstruktur speichert oder etwas in der Art. Aber selbst das dürfte nicht so lahm sein.

_________________
Yeah!

Ah das issen bug das mitem texcoord 1 ^^
Danke für den hinweiss.

Also was ich weiss das assimp alles in Vectoren speichert.
Das sind glaub ich die generischen array listen in c++.

Ich raff aber auch nicht wieso das so lahm ist.
Habs in meiner Win XP mit 2 GB ram VM laufen lassen (VMware Workstation 7.0).

Ich vermute das es am BinaryWriter liegt von .NET.
Dieser scheint schon extrem lahm zu sein.

In C oder delphi kann man ja direkt den buffer wegspeichern und es ist ihm fast wurst egal was da für daten drin sind, wichtig ist nur das die länge die grösse im speicher nicht überschreitet.

Wäre wohl besser gewesen das in C++ zu machen oder ?

Am Writer sollte es nicht liegen. Irgendwo wirst du einen Fehler haben. Das letzte Mal als ich den BinaryWriter/Reader verwendet hab, hat der sämtliche Dateien 1-10MB in kürzester Zeit geschrieben bzw. geladen.

Hast schon nachgeschaut ob du nicht vielleicht irgendwo eine Endlosschleife erzeugt hast?

_________________
(\__/)
(='.'=)
(")_(")

Das ding hat keine Rekursion, benutzt nur for schleifen.
Somit endlosschleife kann nicht vorkommen, vor allem habe ich schon etliche male das ding debuggt und mir parameter für parameter anzeigen lassen. Sieht alles gut aus.

Habe ja die infos gepostet und source den source dazu.

Hmm, Code schaut echt sauber aus. Hast du schon probiert wie schnell er durchläuft, wenn du das Model nicht schreiben tust? Das sollte dann ja wirklich schnell von statten gehen.

_________________
(\__/)
(='.'=)
(")_(")

1. Die lahme Geschwindigkeit liegt bestimmt nicht an .Net selbst
2. Ist der BinaryWriter gepuffert? Falls nicht: Puffern!
3. Schonmal mit nem Profiler oder simplen getTickCount()s probiert?
4. Wo liegt denn die CPU-Auslastung während des Schreibens?
5. Da das in ner VM läuft, würde ich mal prüfen, ob das Festplatten-Image auf dem Host noch wächst
6. Und schlussendlich: Hat das System während des Schreibens überhaupt I/O-Last?
7. Nachtrag: Mir wird grad die Sache mit dem hohen Speicherverbrauch bewusst... Verwendest du die Collection-Klassen, die primitive Typen unboxed beinhalten können? Wenn deine Bytes nämlich alle erst in Byte-Objekte geboxed werden, fällt pro Byte nicht nur 1 byte Speicherplatz an, sondern halt gleich mal 13 (12 für das Objekt + 1 für das Byte selbst). Zumindest kostet eine Objektreferenz in der JVM 12 Byte, bei .NET wird's nicht sooo grundlegend anders sein

Grüße,
~ Frase

Tante Edith hat Punkt 7 dazugeschrieben.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."