Klötzchenwelt

Während der Vorbereitungsarbeiten der nächsten Teile des Terrain 101 habe ich mich während ich den Streaming- und Generierungsalgorithmus für das Terrain entwickelt habe, noch ein wenig mehr um die Klötzchengrafik aus meinen beiden letzten Artikeln „Klötzchengrafik“ und „Marschierende Würfel“ gekümmert.

Mittlerweile hat sich das ein klein wenig verselbständigt und aus dem einfachen Paging-Mechanismus ist bereits etwas ganz schön feines geworden.

Ich habe einen Paging-Mechanismus erstellt, der vollautomatisch und konfigurierbar Terrain-Tiles oder im allgemeinen Geometry-Häppchen um die Kamera herum generieren kann. Diese Generierung erfolgt Multi-Threaded, so daß diese nicht den Render-Thread belastet. Man kann sich theoretisch unendlich in alle Richtungen bewegen. In der Nähe der Far-Plane und damit dem Ende der generierten Grafik wird diese durch einen dezenten Fog weich ausgeblendet.

Im nachfolgenden Screenshot wird – ganz Minecraft-like – jeweils eine Page bzw. ein Chunk mit 16*128*16 Blöcken generiert und in der Welt befinden sich insgesamt knapp 10 Millionen Blöcke. Diese werden mit Normalen, Texturkoordinaten, Vertex-Farben und Positionen generiert. Dem liegt ein Perlin-Noise-Algorithmus zugrunde, der allerdings noch die ein oder andere Macke hat. Die Geometrien verwenden dabei ein Custom-Vertex-Format, mit dem ich einiges an Speicher sparen kann. Die Daten werden geschickt kodiert, so daß möglichst wenig in den Grafikspeicher gepackt wird.

Um die Grafikkarte der XBox nicht zu sehr zu belasten (richtig gelesen, der Screenshot stammt von der XBox) wird selbstverständlich ein Frustum-Culling durchgeführt. Dadurch sinkt die Anzahl der Draw-Calls von 676 auf ca. 120-140. Damit sind problemlos 60 Frames/s möglich.

Wie man sieht gibt es eine rudimentäre Beleuchtung. Noch nichts weltbewegendes…

Nun aber der Screenshot…

Die Debugging-Ausgaben sind alle ein-/ausschaltbar und in mehreren GameComponents als Overlays realisiert und damit wiederverwendbar. Die Ausgaben im rechten Bereich scrollen durch, sobald neue Informationen kommen und fungieren als Trace-Listener mit .NET-Bordmitteln. Gesteuert wird alles per GamePad.

Sobald ich Perlin-Noise so um Griff habe, wie ich mir das vorstelle, werde ich mit dem nächsten Teil des Terrain 101 weitermachen. Dort wird es dann darum gehen, die erste Terrain-Page zu erzeugen. Natürlich nicht aus Klötzchen, sondern per GeoMipMapping und Heightmap. Der Paging-Mechanismus ist jedoch der Gleiche und wird sogar für eine planetarische Engine einsetzbar sein.

Advertisements

Veröffentlicht am 06.09.2011 in Random Noise und mit , , , getaggt. Setze ein Lesezeichen auf den Permalink. 4 Kommentare.

  1. Dann freue ich mich schon auf diesen Paging-Mechanismus, um mein Projekt weiter ran zu treiben. Noch so viel zu lernen ich habe 😉

  2. Ja, wird sicherlich hilfreich sein 😀

    Übrigens habe ich den Terrain-Artikel mittlerweile bereits veröffentlicht, allerdings ohne Perlin-Noise. Ich habe um es etwas einfacher zu machen einfach eine vorgefertigte Heightmap verwendet, die zwar auch mit Perlin-Noise generiert wurde, aber in einem externen Programm.

  3. Darf man vielleicht erfahren, wie dein Vertexformat ausieht, mitdem du den Speicherplatz sparst?

    • Das Format steht noch nicht komplett fest, aber ich kodiere schlicht und einfach mehrere Werte in die Vertex-Streams. Kommt extrem stark auf die speziellen Anforderungen an, aber bei einem 16x128x16 Chunk kann man z.B. wie folgt vorgehen:

      – Shader-Konstante für Block-Größe (Vector3)
      – Shader-Konstante für Welt-Offset des Chunks (Vector3)
      – 2x 4 Bit für x und z Koordinate innerhalb des Chunks
      – 8 Bit für die Höhe innerhalb des Chunks

      Die Werte werden im Shader entpackt und die tatsächlichen Positionen werden berechnet. So könnte man z.B. in 2 Byte pro Vertex plus zwei Konstanten die Positionen kodieren. So spart man schon mal 14 Byte pro Vertex.

      Wie gesagt: Man muss sich da genau Gedanken drüber machen, was man benötigt und wie man es kodiert. Das dekodieren ist schliesslich nicht kostenlos und das kodieren auch nicht. Je nachdem wie belastet der Shader bereits ist, kann es dadurch zu Performance-Problemen kommen…

      Ich schreibe vielleicht mal einen Artikel darüber, wenn ich das irgendwie generalisieren kann..

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: