spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Naja, da in Minecraft ja alles an einem regulären Gitter ausgerichtet ist wird es sich anbieten die ganze Welt in einem solchen abzulegen (also einfaches Array). Damit sollte Frustrum Culling sehr einfach und genau realisierbar sein, ein Octree wäre da nur unnötiger Overhead und würde vermutlich sogar bremsen.

Nun, jeden Würfel einzeln zu cullen (und ich hoffe nicht, dass du Würfel/Flächen zeichnest, die im Inneren liegen und somit eh nicht sichtbar sind) dürfte fast mehr Performance fressen als sie einfach zu zeichnen. Daher ist zumindest eine Gruppierung definitiv sinnvoll, auch wenn es nicht unbedingt ein Octree sein muss.

Culling macht nur auf Objektebene Sinn, wenn es nur Würfel sind vermutlich sogar nur (wie BlueCobold schon gesagt hat) auf Ebene von ganzen Brocken von Würfeln. Einzelne Dreiecke zu Cullen macht ganz sicher keinen Sinn da die CPU sehr viel länger brauchen würde um festzustellen ob ein einzelnes Dreieck gezeichnet werden muss oder nicht als die Grafikkarte braucht um 20 ganze Würfel zu malen

Zitat von »Kippstrahl«

Da habe ich mir überlegt, dass beim Generieren des "Terrains" überprüft wird, ob ein Würfel von 6 anderen umschlossen wird, und wenn ja, dass dieser dann gar nicht gezeichnet wird. Hierbei handelt es sich ja nicht um eine Überprüfung in der Echtzeit.

Man kann sogar einzelne Seiten der Würfel weglassen, welche an einen anderen angrenzen. Kann ja durchaus sein, dass von einem Würfel nur eine Seite sichtbar ist, ähnlich wie bei Kopfsteinpflaster auf einer Straße. Allerdings sollte die Geometrie dabei wirklich irgendwie gepuffert werden ohne diese Berechnung in jedem Frame zu machen, sonst verlierst Du mehr als Du gewinnst. Mit "statischen" VBOs ist das aber eine duchaus eine Überlegung wert.

Zitat von »Kippstrahl«

Eine zweite Frage: Das Culling der Innenseiten (also das, was man dank Clipping eh nicht sieht) muss ich nicht übernehmen oder? Denn ich habe mal gehört, dass man auch die Würfel einfach Face per Face zeichnet und von Anfang an nicht sichtbare Faces ausschließen kann.

Backface-Culling meinst Du. Nein, lass das die GPU machen. Wenn du das selber machen willst, dann müsstest Du das nach jeder Kamera-Änderung prüfen und das bringt nur Einbußen.

Die Meshklasse wird intern VertexBuffer benutzen. Ich benutze DX zwar eine ganze Weile schon nicht mehr, aber alles andere würde keinen Sinn machen.

Du solltest zusehen, dass du die Optimierungen nicht in jedem Frame neu berechnest. Zusätzlich solltest du dir Gedanken darüber machen, dass die Kommunikation mit der Grafikkarte teuer ist, also immer möglichst viel in einem Rutsch rendern. Es ist weitaus billiger 100 Würfel auf einmal so rendern, als 10 Würfel für Würfel (die Dimensionen müssen nicht genau stimmen und hängen auch von sehr vielen Faktoren ab, aber so ungefähr verhält es sich).
Ich würde dir empfehlen, Große teile des Levels zu einem Vertexbuffer zusammen zu legen. Dabei kannst du dann gleich im inneren liegende Würfel weglassen und auch nur die Seite dabeipacken, die man wirklich sieht. Die Vertexbuffer musst du natürlich aktualisieren, sobald sich was im Level ändert, aber das passiert ja nur ab und zu (im Bezug auf die Framezahl), also ist das ganz egal. Ist natürlich mehr Aufwand, sollte die Sache aber erheblich schneller machen.

Letztendlich musst du wissen, was du willst. Man kann vermutlich mittelgroße Levels auch ohne Optimierungen flüssig rendern, aber wenn du was lernen willst, macht es ja durchaus Sinn, das ganze mal zu optimieren.

Jup. Einmal 100 Würfel zu rendern ist deutlich schneller als hundert mal einen einzelnen.
Da wirst Du vermutlich ähnlich viel Performance rausholen wie Du mit Deinem Frustum-Culling erreichen willst. Eine Umstellung Deiner gesamten Geometrie wäre also von Vorteil.
Wie Jonathan sagte wäre es vermutlich klug, große Teile des Levels (die Du dann separat cullen kannst) in einem VBO abzulegen statt jeden Würfel einzeln.