Hi Leute,

ich sitz grade an eime eher strukturellem Problem, wie ich meine Daten händeln soll.
Bisher hab ich noch überhaupt keine Optimierung via Octree/Frustum u.ä.

Ich habe eine Klasse TSceneNode die mir die ganze Szene als Baumstruktur beschreibt, so dass ich an sich immer nur eine relative Position/Skalierung/Rotation zum Elternobjekt habe.
TSceneNode enthält an sich keine Daten was gerendert werden soll sondern nur die Grundstruktur, Ableitungen von dieser Klasse händelten bisher das Rendern.

TSceneNode hat zwei Prozeduren die für das Rendern zuständig sind. Render() und RenderSelf(), zweitere ist virtuell und abstrakt, sie bewirkt, dass das Mesh oder was auch immer gerendert wird. Render wiederum sieht so aus, dass sich die ModelView-Matrix gespeichert wird (glPushMatrix()), dann die Transformation, dann die Rotation und dann die Skalierung vorgenommen wird (glTranslate*, glRotate*, glScale*). Wenn dann die Eigenschaft Visibile auf "wahr" ist dann wird RenderSelf() aufgerufen und danach wird dann in einer for-Schleife die Render()-Prozedur jedes Kindknotens aufgerufen.

Wenn ich zb. nach dem Visible-Test einfach nur einen Sichtbarkeitstest der Boundingbox mit dem Frustum mache, ist zwar schon eine minimale Optimierung drinne, aber wenn ich mir dann vorstelle, dass da vielleicht mal ein MeshSceneNode kommt, das aus ~10.000 Dreiecken besteht und nur zur Hälfte sichtbar ist, werden immernoch ~5.000 Dreiecke ins Nichts gerendert.

Dann bin ich auf das Octree-Tutorial gestoßen. Ist ja im großen und ganzen von der Logik her sehr simpel, nur weiß ich nicht, wie ich das nun umsetzen soll, die Daten vom Mesh würden ja in einem VBO im Grafikspeicher liegen.

Da wollte ich mal Fragen, wie das die Wissenden regeln.

MfG
bubble

_________________
Wenn Worte nichts als Worte sind,
dann müssen's Steine sein!
Solange - bis sie pleite sind - schmeißt Fensterscheiben ein!
- Fidl Kunterbunt -

Führe keinen Test auf Ebene der Dreiecke durch. Lass dies die GPU machen, die kann das schneller. Teile dein Mesh in Submeshes von ca. 1000 Dreiecken auf. Jedes Submesh bekommt eine BoundingBox, wenn diese sichtbar ist wird das entsprechende Submesh gerendert. Alle Submeshes werden in einer von deinen TSceneNode zusammengefasst, die BoundingBox enthält die BoundingBoxen der enthaltenen Submeshes. Die Kinder (Submeshes) sollten nur gerendert und auf sichtbarkeit getestet werden, wenn die BoundingBox des Eltern-Knotens sichtbar ist.


Du erstellst einfach beim Laden des Meshes eine BoundingBox aus den Daten. Die eigentlichen Daten werden von der CPU nicht benötigt. Beachte das du natürlich die BoundingBox transformieren musst. Wenn die Box an den Koordinatenachsen ausgerichtet sein soll musst du dazu die 8 Eckpunkte der BoundingBox transformieren und davon wieder eine BoundingBox bilden. Du kannst auch rotierte BoundingBoxen gegen dein Frustum testen, dann ist der Test aber aufwendiger/komplizierter.

_________________
Yeah!

Leider bin ich zur Zeit nicht zu hause, also kann ich das noch nicht umsetzen.

Eine Frage stellt sich mir aber noch:



Beschreibst du da nich an sich ein Octree? (bzw. n-Tree, je nach dem wieviele Submesh erstellt werden müssen) Also ich hab mir jetzt extra noch mal das Tutorial durchgelesen, bis auf das mit der Anzahl der Kindknoten, und dass die BoundingBoxen keine exakten Würfel sind, erkenne ich ehrlich gesagt keinen Unterschied

MfG
bubble

_________________
Wenn Worte nichts als Worte sind,
dann müssen's Steine sein!
Solange - bis sie pleite sind - schmeißt Fensterscheiben ein!
- Fidl Kunterbunt -

Dann hast du offensichtlich das Prinzip verstanden

Vorteil bei meiner Methode:
Du musst nicht exakt teilen. Die BoundingBoxen können sich überlappen, etc.

_________________
Yeah!

Wenn sie überlappen, ist aber wieder das doppelt Zeichnens ein Problem. Naja das werd ich schon irgendwie lösen, bis dahin hab ich noch ein bischen Zeit und im Feedback-Forum bei Octree-Thread werden ja viele Lösungen vorgeschlagen :>
Und dann gehts ran, mir den Kopf zu zerschreddern, wie ich irgendwann einmal animierte Meshs implementiere ^^

MfG
bubble

_________________
Wenn Worte nichts als Worte sind,
dann müssen's Steine sein!
Solange - bis sie pleite sind - schmeißt Fensterscheiben ein!
- Fidl Kunterbunt -

Wenn die BoundingBoxen überlappen heißt das nicht das die Meshes überlappen. Stell dir z.B. zwei Zahnräder vor die ineinander greifen. Da wäre es blöde wenn du da einzelne Zähne abschneiden musst und Dreiecke zerschneiden nur weil die BoundingBoxen nicht überlappen dürfen.

_________________
Yeah!

Stimmt. Da hab ich mich mit dem Problem vom Octree-Tutorial vertan, wo es darum geht wenn man ein Polygon hat das in 2 Würfeln drinne ist und beide Sichtbar sind

_________________
Wenn Worte nichts als Worte sind,
dann müssen's Steine sein!
Solange - bis sie pleite sind - schmeißt Fensterscheiben ein!
- Fidl Kunterbunt -

Wenn du ein Octree nutzt, dann werden die Triangle, die zwischen 2 oder mehr Nodes liegen in das Parent-Node gelegt oder mit tiefentest doppelt in die pipeline gegeben. Ein recht effizienter weiterer Schritt, beim optimieren, ist occlussion culling. Bei der Hardware Lösung hat man viele Probleme, daher benutzen einige moderne Spiele für diesen Schritt ein primitiven Software renderer, der nur aus einem Tiefenpuffer besteht und auch nur triangle in diesen zeichnet. So bekommt man ein Tiefenpuffer und kann BB sehr einfach mit dem Tiefenpuffer abklopfen und aus der Pipe raus nehmen. Sollte man sich die Arbeit nicht machen wollen, kann man immer noch die Hardware Lösung verwenden.
Ein Nachteil beim zerlegen nach Trianglecount, gegenüber Volume, ist das Triangles nicht gleich verteilt sind du schnell ne menge unnötiger Tests an einem kleinen Bereich haben kannst und noch dazu skaliert der Triangle Durchsatz bei den Grafikkarten am meisten und daher skaliert das system nur schlecht und wird mit der Zeit ineffizient.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004