spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Deine Stichworte lauten Octree und View Frustum Culling

Im Kontext von Minecraft-ähnlichen Welten, bzw. Welten, die aus Blöcken oder einer klar gerasterten Grundfläche bestehen, bietet sich auch das Thema Chunks an.
Ich setze es bei meinem Spiel auch ein, so stellt man sicher, dass alles außerhalb eines gewissen Radius entladen und damit auch weder gerendert wird, noch durch die Updatezyklen läuft.

Zitat von »2310«

Nun laggt mein Spiel übelst, weil ich 300 Tsd. Blöcke aufeinmal zeichne

Warum die anderen beiden nicht gefragt haben wie Du die genau zeichnest, weiß ich nicht, aber ich mach's einfach mal. Also, wie zeichnest Du diese 300k Blöcke denn genau?

Es ist wesentlich billiger, ein Objekt mit 100.000 Dreiecken zu rendern, als 1000 Objekte mit 100 Dreiecken zu rendern. Für eine halbwegs gute Framerate kannst du nicht jeden Block einzeln zeichnen, sondern musst die Blöcke zu größeren Objekten zusammenfassen und die dann rendern. Das dürfte im Moment viel viel mehr bringen als Octrees oder Viewfrustum Culling.

In Bezug auf Jonathan Klein's Post:
Also ich habe die Blöcke in meinem Spiel nach Material (d.h. nach Textur) gruppiert.
Das heißt, pro Chunk habe ich pro Material eine Vertexliste mit allen Blöcken darin, die ich immer als ganzes zeichne. Damit brauche ich nicht für jeden Block einzeln wieder die Textur im Grafikspeicher austauschen, sondern nur 1x pro Chunk und 1x pro Material... das zum einen. Und zum anderen zeichnest du halt mehrere Blöcke auf einmal und nicht einzeln.

Im Minecraft Wiki wird die Technik genau beschrieben, sogar eine genaue Beschreibung der Serialisierung und des Datenformats findest du da.
Das ist gar nicht mal so schwer, ich hab das aus spaß mal selber geschrieben, hab ich aber nicht hier grad.

Zitat von »2310«

Kann ich mein Spiel auch beschleunigen, wenn ich einfach eine weniger Hochauflösende Textur für jeden Block verwende ?

Kurze Antwort: Nein.
Weniger kurze Antwortie Zeit zum Rendern eines Frames setzt sich aus mehreren Komponenten zusammen. Der Befehl muss von der CPU zur GPU gehen, die muss ihre Daten vorbereiten, dann die Vertexe verarbeiten und alle Pixel zeichnen. Größere Texturen können vermutlich das Zeichnen der Pixel etwas langsamer machen, aber den Rest der Zeit beeinflussen sie halt nicht. Selbst wenn du überhaupt keine Textur benutzen würdest, würdest du nur einen einzigen dieser vielen Schritte beschleunigen, der aber prozentual nur sehr wenig ausmacht. Es wird dir also in diesem Fall nichts bringen, selbst wenn der Wechsel von riesigen auf winzige Texturen es theoretisch schon leicht schneller machen würde.

Hi,

eventuell kannst du von Instanzing profitieren. Das könntest du ganz gut mit anderen Techniken verbinden. Du könntest z.B. deine Daten in Chunks aufteilen (ggf in einen Octree sortieren o.Ä.). Dann können viele der Chunks schonmal verworfen werden, indem du gegen das Viewfrustum testest. Den Rest der Daten kannst du instanziiert rendern, d.h. du hast im Idealfall nur einen Drawcall für alle Blöcke in deinem Chunk.

Ohne zu wissen wo wirklich das Bottleneck bei dir liegt würde ich stark darauf tippen das du CPU bound bist. Vor allem wenn du die 300k Blöcke mit 300k Drawcalls renderst ist der CPU Overhead extrem. Die GPU wird sich vermutlich nicht besonders stark für die Datenmenge interessieren. Also solltest du dringend dort ansetzen (wie gesagt, ohne zu wissen wo das tatsächliche Bottleneck liegt). Am besten wäre es natürlich wenn du dein Programm erstmal profilest um gezielter zu optimieren.

Zitat von »Jonathan_Klein«

Der Befehl muss von der CPU zur GPU gehen, die muss ihre Daten vorbereiten, dann die Vertexe verarbeiten und alle Pixel zeichnen. Größere Texturen können vermutlich das Zeichnen der Pixel etwas langsamer machen, aber den Rest der Zeit beeinflussen sie halt nicht.

So in etwa funktioniert das! Auf jedenfall sollte @2310 Mipmaps verwenden um cache trashing zu vermeiden. Außerdem könnte man sich die Pixeldensity genauer betrachten und ggf die Auflösung von den Texturen tatsächlich vermindern.