Aufbau von Klassen für 3D rendering

[roboter202]

Hallo,

Ich hab zwar schon etwas Erfahrung was die Verwendung von OpenGL angeht aber mich würde interessieren wie man am besten die Spiel eigene "Welt" zeichnen kann. Ich dachte Daran eine Vaterklasse für alle zeichnbaren Objekte anzulegen. Darunter gibt es dann die entsprechenden "Objekte" die alle die Methode zeichnen geerbt haben. Bei zeichnen der Welt müsste man dann alles geladenen Objekte der Szene durchlaufen und bei bedarf deren zeichnen-Routine aufrufen.

Delphi-Quellcode:

for i := 0 to Scene.ObjectsCount - 1 do
begin
  if Scene.Objects[i].mustBeDrawn then Scene.Obejcts[i].draw;
end;

Beim durchstöbern von Code anderer Programme z.B. Minecraft hab ich aber herausgefunden das nicht das Objekt selbst die OpenGL befehle ausführt sondern nur Daten an einen Tesselator sendet der dann die Vertexe an die Grafik sendet.

Ist meine Lösung akzeptabel?
Gibt es andere, bessere Lösungen?

[Medium]

Minecraft ist wegen seiner Voxel-Welt ein Spezialfall. Im Grunde würde da ja jeder Würfel für sich gezeichnet werden, was aber nicht nötig ist, da oftmals eine Menge von Würfeln einfach nur eine große Fläche ergeben. Daher ist dort noch eine Zwischenschicht, die von den Objekten gesagt bekommt: "So würde ich gerne aussehen", der Tesselator weiss aber im Gegensatz zum einzelnen Objekt, dass es in der Nachbarschaft noch andere gibt, durch die sich das vereinfachen lässt.

Es gibt ganz grob zwei mögliche (und praktizierte) Wege in "normalen" 3D-Szenen:
1) Jeder zeichnet sich selbst
2) Jeder übergibt seine Randdaten an einen Renderer, der dann abschließend alles in einem Rutsch zeichnet

Nummer 2 hat den großen Vorteil, dass man durch entsprechend intelligentes Gruppieren seine Resourcen effizienter nutzen kann, und vor allem weit weniger State-Changes auslöst (Wechsel von Shadern, Texturen, Buffertypen), aber eben erkauft durch den Overhead einer Verwaltungsschicht. Der Gewinn ist dann eher bei komplexeren Szenen zu erwarten. Bei Methode 1 muss man auch ein wenig drauf achten, dass jedes Objekt seinen Durchlauf immer sauber verlässt, also Matrixstack anfangs gepusht, nachher gepoppt, States zurück gesetzt, etc. pp., sonst kann es mal passieren, dass das bloße Zeichnen eines Teils alle nachfolgenden bzw. untergeordneten Teile ungewollt beeinflusst.
1 ist also eher Quick & Dirty für kleinere überschaubare Dinge, Nummer 2 ist aufwendiger in Implementierung und (zunächst) Laufzeit, lohnt sich aber in aller Regel schon.

[Uwe Raabe]

Schau dir doch mal GLScene an - und sei es nur um Anregungen zu bekommen.

[mkinzler]

Oder Asphyre Sphinx 2

[roboter202]

Vielen dank ich werde mir das mal anlesen.
Also macht Minecraft es so wie bei der 2. Methode um nachher zu optimieren.