Java Aufnahme von Dreiecken in ein/mehrere Objekte

Guten Tag!

Ich beschäftige mich gerade damit, Objekte im dreidimensionalen Raum nur aus Dreiecken zusammenzubauen. Wenn man es jetzt ähnlich wie z.B in der STL macht (diese Richtung wird es wahrscheinlich werden), dann benötigt man dafür erstmal drei "Eckpunkte" bzw. Vertices (jeweils mit x-y-z Koordinate) zur Festlegung eines Dreiecks und eine Flächennormale (mit x-y-z Koordinate) um die Ausrichtung im R³ festzulegen. Soweit so gut.

Wenn ich mir die STL-Beschreibung ansehe, dann werden ganze Körper in einer Datei zusammengefasst, d.h. in einer Datei befinden sich mehrere Dreiecke (mit je drei Vertices inkl. der jeweiligen Koordinaten) mit der dazugehörigen Flächennormale je Dreieck.

Meine Frage ist jetzt, wie man das Handling der Daten am sinnvollsten und vor allem objektorientiert (!) umsetzen kann. (Es geht auch erstmal nur um das Behandeln der reinen Daten; das Anzeigen der Körper usw. werde ich zu einem späteren Zeitpunkt umsetzen, nur habe ich mich noch nicht entschieden, wie das passieren wird.)

Wäre es sinnvoll, aus jedem Dreieck ein eigenständiges Objekt zu machen und dann alle Dreiecks-Objekte mit sowas wie einem Vector zu "wrappen"? Die drei Vertices (bzw. die Koordinaten derer) plus Flächennormale könnte ich mir als Array vorstellen, ggf. auch mehrdimensional für die Vertices. Oder könnte/sollte man noch tiefer gehen und jeden Vertex als eigenständiges Objekt erfassen?

Vielleicht kann mir jemand ein wenig Input dazu liefern.

MfG usw...

Nun, das Thema ist leider deutlich komplizierter als es vielleicht aussieht. Zuerst wäre es sinnvoll, deine konkreten Anforderungen an das Modell zu klären, denn man kann da ziemlich schnell auf die Nase fallen, wenn man etwas vergisst.

Paar Dinge:

• Die Flächennormale eines Dreiecks ist implizit durch die Punkte gegeben. Man muss sie also nicht zwangsläufig zu jedem Dreieck mitspeichern - die Orientierung der Fläche wird durch die Reihenfolge der Vertices vorgegeben. Normalen vielleicht besser on demand in einer separate Struktur dafür berechnen.
• Falls die Normalen vornehmlich für Beleuchtung verwendet werden sollen, gibt es da ohnehin ein kleines Problemchen - normalerweise hat man ja nicht nur eckige Objekte, sodass Per-Vertex-Normalen benötigt werden, die sich aus den Flächennormalen benachbarter Dreiecke zusammensetzen.
• Was uns zu dem Punkt bringt, dass ein Vertex auch zu mehreren Dreiecken gehören kann. Effektiv würde es darauf hinauslaufen, dass man ein Vertexarray hat und seine Dreiecke nur noch durch Indizes auf die jeweiligen Vertices definiert - so ähnlich werden Geometriedaten nebenbei auch in Grafik-APIs verwaltet.
  Das wäre nebenbei gerade dann von Vorteil, wenn Bone-basierte Animationen auf der CPU berechnet werden sollen - verringert den Berechungsaufwand um ~80%.
• Falls man jetzt Per-Vertex-Normalen für besagte Beleuchtung tatsächlich effizient berechnen will, kommt man genau darum eigentlich sowieso nicht herum - zusätzlich benötigt man dafür aber noch eine Struktur, die sich zu jedem Vertex merkt, von welchen Dreiecken er benutzt wird.

Die Punkte zielen jetzt auf eine Struktur ab, die geeignet ist, die Daten für möglichst viele Einsatzzwecke (Rendern, Animationen, ...) im RAM zu halten. Ich denke mal, so etwas war auch gemeint. Was du davon letztenendes tatsächlich brauchst, hängt natürlich allein von der Anwendung ab.

Das Problem ist, dass Objektorientierung im Java-Stil für so ein Datenmodell in vielerlei Hinsicht kaum sinnvoll bzw. unglaublich ineffizient ist. Besonders bei Punkt 4 würde man damit fürchterlich auf die Schnauze fallen - denn was würde man machen? Für jeden Vertex eine eigene Liste mit Pointern auf Dreiecke speichern? Dass das nichts werden kann, sollte klar sein.


BTW. Was meinst du eigentlich mit STL? Die C++-Standard Template Library kann es ja nicht sein

STL - Das meine ich damit.

Das Format ist schon unglaublich alt und wurde anscheinend für diverse Szenarien konzipiert, bei denen u.A. die Berechnung der Normalen nicht immer möglich und/oder sinnvoll ist. Es gibt halt einerseits die Vertices für jedes einzelne Dreieck sowie eine Normale pro Dreieck vor (man kann sich diverse Testdateien im Netz ergoogeln).
Es ist tatsächlich so, dass in einer Datei mehrere Dreiecke mit ihren Eckpunkten und Normalen abgelegt sind, woraus dann schließlich ein Körper generiert wird. D.h. dass es auf jeden Fall doppelte Vertices geben wird, sofern man keine Lücke in seinem Körper haben will. (Apropos rendern: Ich denke, wenn ich irgendwann mal soweit bin, werd ich ne GUI dazu bauen, die mir die Modelle anzeigen kann. Wahrscheinlich mir JavaFX, da ich eigentlich nichts mehr mit Swing/AWT machen möchte.)

Ich halte mich jetzt an dieses Schema, weil ich damit ein relativ simples Konstrukt habe, mit dem ich schonmal arbeiten kann. Mir ist schon klar, dass Java für derartige Anwendungen nicht gerade die die beste Wahl ist, aber irgendwas muss ich ja machen, um mich mit dem Thema OOP anzufreunden. Letztenendes wird es aber ein recht rudimentäres Programm bleiben.