Hallo Leute,
anbei eine kurze Vorstellung des internen Objektformates mit der Bitte um Kommentare/Kritik. In den Beispielen sind nur die Eckpunkte berücksichtigt (vertex data), in der "richtigen" Version kommen dann noch Normalenvektoren, Texturkoordinaten, usw. unter Verwendung der gleichen Technik dazu! Außerdem werden 3D-Objekte priorisierbar sein, hohe Prioritäten kommen zuerst in den Speicher der Grafikkarte (buffer objects), niedrige Prioritäten erst später oder gar nicht (je nach Größe des Grafikspeichers). So optimiert man (hoffentlich) die Performance ein wenig!
Anteilige Eckpunkte (vertex sharing) für Projekt XY (Name noch nicht festgelegt, Ideen sehr willkommen)
Die Darstellung von Eckpunkten in der Open Graphics Library (hier kurz OGL) und in Grafikkarten-Shadern erfolgt durch float (IEEE 754) mit 32 Bit/4 Byte pro Koordinate, im 3D-Raum werden für einen Eckpunkt (vertex) somit 12 Bytes benötigt. Für ein Dreieck (einziges verwendetes OGL-Primitiv im Projekt) werden 3 Eckpunkte benötigt, das sind nach Adam Riese 36 Bytes.
Beispiel 1 (Eckpunkte sind durch o dargestellt):
o-o
\ /
o
3 x 12 Bytes = 36 Bytes
3D-Objekte bestehen üblicherweise aus zahlreichen Dreiecken, die (fast) IMMER viele Eckpunkte teilen. Sammelt man die Eckpunkte in einer schnellen Liste (std::list), so braucht man für ein Dreieck "nur" 3 Indizes speichern, das sind 3 x 4 = 12 Bytes. Im schlechtesten Fall (worst case, 1 einzelnes Dreieck) braucht man diese 12 Bytes ZUSÄTZLICH zu den 36 Bytes, das sind also 48 Bytes (+33%).
Beispiel 2 (GL_TRIANGLE_STRIP):
o--o--o--o
| / | / | / |
o--o--o--o
Normales Dreieck-Objekt: 6 Dreiecke zu 36 Bytes ergeben 216 Bytes
Mit anteiligen Eckpunkten: 8 Punkte zu 12 Bytes ergeben 96 Bytes plus 6 Dreiecke zu 12 Bytes (je 3 Indizes) ergeben 72 Bytes, gesamt 168 Bytes (-22%)
Das ist noch nicht wirklich viel.
Beispiel 3 (Ikosaeder, 20 Dreiecke/12 Eckpunkte):
Normales Dreieck-Objekt: 20 Dreiecke zu 36 Bytes ergeben 720 Bytes
Mit anteiligen Eckpunkten: 12 Punkte zu 12 Bytes ergeben 144 Bytes plus 20 Dreiecke zu 12 Bytes ergeben 240 Bytes, gesamt 384 Bytes (-46%)
Ikosaeder dienen oft als Ausgangs-Körper für Kugeln/kugelförmige Körper (vgl. subdivision). Deshalb das Beispiel, das immerhin eine Ersparnis von 46% ermöglicht. Ich schätze, dass professionelle Programme mit noch besseren Speicherspar-Techniken arbeiten. Viel Verlust an Performance ist nicht zu erwarten (werden wir noch prüfen) da der Indexzugriff bei einer Liste schnell ist (sein sollte). Vielleicht hat jemand auch noch eine bessere Idee!
Übrigens wir suchen noch Leute, die Lust und Laune haben, bei einem kleinen/feinen Projekt mitzumischen!
Freundlichen Gruß an alle Leser!