Best Way? Objekt-Mesh Design?

[snoob741]

Aktuell bin ich damit beschäftigt für meine Engine die Objekt-Mesh Strukturen aufzubauen. Aktuell habe ich pro Objekt 1...n Mesh Objekte, von denen jede Mesh über ein VBO + IBO für die Geometriedaten verfügt. Layout, Shader usw. werden pro Mesh per Material definiert. D.h. pro Frame render ich mehre Meshes und damit habe ich auch mehrere Buffer die ich aktivieren muss.

Nun meine Überlegung ist das so Sinnvoll? Oder würde es mehr Sinn machen, z.B. die Vertexdaten in einem VBO vorzuhalten, und bei komplexeren Objekten die übrigen Meshes auf SubMeshes/Parts aufzuteilen, die nur den IBO beinhalten aber alle das gleiche VBO referenzieren. In dem Fall müsste ich nur die Indexbuffer mehrfach aktivieren und hätte mehrere glDrawElement calls ...

Mich würde brennend interessieren wie Eure Erfahrungen in dem Bereich sind. Was hat sich bewährt, was weniger? Auch im Hinblick darauf, dass z.b. zur Laufzeit einzelne Meshes/Materials getauscht werden müssen um z.B. Deformationen und Schäden darzustellen. Gleiches gilt fürs Skinning. Macht es ggfs. auch Sinn gleich bei Objekten Subobjekte einzuplanen, d.h. einen Graphen aufzuspannen bsp. Tragfläche Raketen oder würdet Ihr erst zur Laufzeit, wenn die Trennung erforderlich ist, ggfs. Meshes und Ihre Submeshes zu eigenen Objekten machen?

[Schrompf]

Das geht erstmal so. Das Thema ist hintenraus sehr komplex, aber für den Anfang ist das ok.

Später wirst Du dann alle möglichen anderen Konstrukte brauchen. Z.N. Objekte, die ihre Meshes zur Laufzeit neu erzeugen. Oder auch Objekte ohne Mesh - davon gibt es bei uns ne Menge.

[RazorX]

Da das Thema Graphen schon gefallen ist, würde ich hier einfach mal Entity-Component-System einwerfen. Einen Szenengraph mit Objekthierarchien (im Sinne der Vererbung) ist altmodisch und zu statisch. ECS bietet hingegen Aggregationen zur Laufzeit, auch darüber kannst du Parent-Child Hierarchien abbilden. Leider hab ich bis jetzt noch keinen schönen Ansatz gefunden ECS mit dem Renderer zu verbinden. Klar man benötigt eine Komponente, z.B. RenderableComponent, aber wie stellt man darüber unterschiedliche Sachen dar. Terrain und statische Meshes benötigen halt unterschiedliche Behandlungen. Wäre toll wenn sich dazu auch mal jemand äußern könnte.

[Schrompf]

"altmodisch" ist ein übles Wort. Komponenten-Systeme haben einige sehr spannende Vorteile, aber ich kenne aktuell noch kein schönes System, womit man die alle stressfrei und laufzeitflexibel zusammenstecken kann, so dass sie ordentlich zusammenarbeiten. Aus persönlicher Erfahrung habe ich bisher nur Komponenten als Ergänzung benutzt, nicht zur vollständigen Abbildung der gewünschten Funktionalität. Dafür klappen die auch prima, nur werden es halt immer mehr Events, über die die Komponenten informiert werden müssen. Und manche komplexe Komponente hat Herden von "Such andere Komponenten, mach je nach deren Typ unterschiedliche Sachen"-Logik - das ist nicht schön und auch ziemlich wackelig.

Was das Rendern angeht: Mach halt verschiedene Komponenten für verschiedene Renderzwecke. Dann bist Du wieder bei Ableitungshierarchien, nur halt für Komponenten und nicht für Objekte. Ich finde in beiden nix Böses, solange man rechtzeitig mitbekommt, wenn einen der Ansatz allzu sehr einschränkt.

[snoob741]

Hey danke für Eure Anregungen ich werde mal schauen was ich davon umsetzten kann.