Drahtgitteroptimierung evtl. mit Baumstruktur. Wie?

[dizzy]

Södale, ich hab mal ordentlich rumprobiert. Aber leider ist es keine O(n)=n Story

Das Problem sind die VIELEN Plattenzugriffe, und immens viele String-Operationen, und String-Vergleiche. Das zieht ganz gehörig an der Bremse.

Ich habs jetzt logendermaßen gemacht:

- Ich schreibe meinen ersten Punkt in die Datei
- überprüfn bis EOF, ob der nächste String schon vorhanden ist
- wenn ja, break, und aktuelle Zeilennummer gehört zum aktuellen Face
- dieses in nem dicken array merken
- wenn nein (bis EOF durchgerannt) -> append neuen Vertex
- in dickem array merken

Und das ganze in einer Schleife für eine tierisch wachsende Datei. Bei einer Qualitätsstufe des Meshes, die man getrost als "unbrauchbar" bis "indiskutabel" bezeichnen kann, bin ich trotz Optimierung bei Files von locker > 2 MB, und schon ab ca. 500k (ca. 3000 Vertices - und es werden bei guter Quali > 1mio !!!) wirds ungemütlich lahm .
Das liegt mit unter auch daran, dass allein die Berechnung des Meshes SEHR zeitintensiv ist (es geht um Quaternion-Fraktale = "echte" 3D-Fraktale). Das ist aber noch verschmerzbar, und teuflisch optimiert. Aber das ganze Platten- und Stringgerödel jetzt, das haut mir die ganze Codeoptimierung ad absurdum .

Aber funktionieren tut das SUPER! Nur ganz deutlich zu langsam.
Deshalb hoffte ich auch auf ein Verfahren, die ganze Optimierung schon bevor IRGENDWAS auf die Platte kommt erledigen zu können.
Ein Fakt hilft evtl.: Ich berechne das Objekt würfelweise. D.h. ich müsste lediglich die Vertices auf Dopplung prüfen, die zu Faces gehören, die zu Nachbarwürfeln gehören. Das Problem dabei ist allerdings, dass die vollkommen verstreut in der Datei liegen, und es gibt kein Sortierkriterium DAS in den Griff zu bekommen (zumal das ein 3-Dimensionales Problem ist).

Daher kam ich ursprünglich auf den Trichter eine Art verkettete Liste oder einen Zeigerbaum zu verwenden. Nur fehlt mir da leider jeglicher Ansatz zur Realisierung
Zumal man ja auch einen Baum für jeden neuen Vertex einmal komplett durchsuchen müsste, ob der nicht schon existiert! Aber das wäre halt im RAM und net auf der Pladde. Ich fürchte aber, dass ich da arg Speicherprobleme bekäme bei > 1mio Nodes (whatever) (Und der Stack bedankt sich bei einer solchen, wohlmöglich rekursiven Suche...)
Also muss wohl eine partielle Lösung her, weil alles im RAM -> zu viele Daten und alles auf der Platte -> deutlich zu langsam.
Isch krisch die Kriese

Habt schon mal kräftig Dank für etwas mehr Klarheit bei mir!
Falls euch dazu noch was nettes einfällt... ich sitz da jetzt sporadisch immer mal wieder, seit über 1 Monat dran. Hülfeee!