Wie funktioniert die schnelle Darstellung in "Minecraft"



  • Hi,

    mir ist schon klar, dass Minecraft ein Voxelsystem ist, aber wie werden so viele Voxel so flüssig dargestellt?

    Mit der Höhenbeschränkung von 128 Voxeln fällt mir die Zweierpotez ein und schließe darauf, dass eine Octree Struktur verwendet wird.
    So wird die Welte wohl immer weiter in 8-ter Unterblöcke zerteilt und nur die Voxel, die im Frustum liegen gezeichnet.

    Ich nehme an, dass von allen Voxeln zunächst berechnet wird, welche "Wände" der Voxel keine anderen Voxel berühren, weil diese ja niemals zu sehen sein können.
    (So eine At Marching-Cubes-Verfahren)

    Eine weitere Möglichkeit wäre, nur die Oberflächen der Voxel zu zeichnen, die eine Orientierung in Richtung zum Spieler haben.
    (Oder ist es schneller auf den Test zu verzichten und alle Teile zu zeichnen)

    Aber ist das der ganze Trick?

    Wenn man z.B. in einer Höle steht, werden dann wirklich alle theoretisch sichtbaren Teile der Voxel gezeichnet die im Frustum liegen?
    Also auch Teile die "hinter der Hölenwand" liegen?
    z.B. eine zweite Höle die hinter der aktuellen liegt, aber eigentlich nicht sichtbar ist?

    Wenn nein, wie werden diese nicht sichtbaren Teile weiter aussortiert?


  • Mod

    MisterX schrieb:

    mir ist schon klar, dass Minecraft ein Voxelsystem ist, aber wie werden so viele Voxel so flüssig dargestellt?

    ich sah da nichts herausragend fluessig dafuer dass er nur boxen zeichnet.

    Mit der Höhenbeschränkung von 128 Voxeln fällt mir die Zweierpotez ein und schließe darauf, dass eine Octree Struktur verwendet wird.

    ziemlich am anfang im blog sagte notch mal er hat einen AABB tree, keine ahnung ob er das nun geaendert hat.

    So wird die Welte wohl immer weiter in 8-ter Unterblöcke zerteilt und nur die Voxel, die im Frustum liegen gezeichnet.

    jup, frustum culling macht er wohl.

    Ich nehme an, dass von allen Voxeln zunächst berechnet wird, welche "Wände" der Voxel keine anderen Voxel berühren, weil diese ja niemals zu sehen sein können.
    (So eine At Marching-Cubes-Verfahren)

    das muss man nicht "berechnen", einfach nur pro achse zwei nachbar bloecke vergleichen ob die solid sind, falls != generierst du ein quad.

    Eine weitere Möglichkeit wäre, nur die Oberflächen der Voxel zu zeichnen, die eine Orientierung in Richtung zum Spieler haben.
    (Oder ist es schneller auf den Test zu verzichten und alle Teile zu zeichnen)

    du meinst backface culling? das ist sicherlich an, ja.

    Aber ist das der ganze Trick?

    nein, gibt noch andere, steht alles in seinem blog.

    Wenn man z.B. in einer Höle steht, werden dann wirklich alle theoretisch sichtbaren Teile der Voxel gezeichnet die im Frustum liegen?
    Also auch Teile die "hinter der Hölenwand" liegen?
    z.B. eine zweite Höle die hinter der aktuellen liegt, aber eigentlich nicht sichtbar ist?

    laut seinem blog werden diese nicht sichtbaren dinge nicht gezeichnet.

    Wenn nein, wie werden diese nicht sichtbaren Teile weiter aussortiert?

    alle deine antworten stehen im blog.



  • Hi,

    ist dies der offizielle blog von Minecraft?
    http://notch.tumblr.com/

    Wenn ja, auf welcher Seite steht ungefähr was über die werwendete Technik zur Darstellung der Voxel? (80 Seiten dafür durchlesen ist nen bisl viel)

    Ich habe noch wenig Ahnung von Minecraft, weil ich dieses "Spiel" erst heute morgen entdeckt habe. (Auf einem Youtube Video)



  • Ich habe auch mal einen Berich gelesen, dass es sich lohnen kann, Oberflächen die aus Voxeln repräsentiert werden als Polygone darzustellen. Da Minecraft mit Chunks arbeitet klingt das noch plausibel...



  • EOutOfResources schrieb:

    Ich habe auch mal einen Berich gelesen, dass es sich lohnen kann, Oberflächen die aus Voxeln repräsentiert werden als Polygone darzustellen. Da Minecraft mit Chunks arbeitet klingt das noch plausibel...

    Natürlich sind das Polygone.

    In einem bestimmten Bereich um die Kamera herum werden für alle Blöcke die theoretisch sichtbaren Polygone generiert. Das heißt, dass in einer normalen Welt >99% aller Blöcke gar nicht gezeichnet werden müssen, weil sie unter der Erde liegen. Höhleninnenwände und so werden generiert. Das erkennt man, wenn durch einen Fehler von Minecraft Wände unsichtbar werden und man kilometerweit durch die Erde sehen kann. Durch das Zusammenlegen von benachbarten Oberflächen kann man bestimmt nochmal 50% der Polygone sparen. Die Menge, die am Ende übrig bleibt, lässt sich von einer halbwegs fähigen Grafikkarte bewältigen. Die Texturen haben eine geringe Auflösung und die Shader werden eher simpel sein.

    Die Darstellung ist also nicht so schwierig. Der aufwendigere Teil ist das Generieren der Dreiecke. Ein Chunk ist 128 Blöcke hoch und jeweils 16 breit und tief. Im sichtbaren Bereich befinden sich Größenordnung ~100 Chunks (weiß ich nicht genau). Macht 32768 Blöcke pro Chunk und ca. 3 Millionen Blöcke insgesamt. Das ist nicht wenig, da man für jeden Block seine unmittelbare Nachbarschaft prüfen muss. Deswegen baut sich die Welt in Minecraft teilweise nach und nach auf. Man muss dabei noch berücksichtigen, dass die Prüfung nicht nur innerhalb eines Chunks, sondern auch an den Chunk-Grenzen stattfinden sollte.



  • Flüssig?
    Sorry, aber MC ist alles andere als flüssig und meine Maschine is echt nicht schlecht. Da laufen besser aussehende Titel weit flüssiger.


  • Mod

    EOutOfResources schrieb:

    Ich habe auch mal einen Berich gelesen, dass es sich lohnen kann, Oberflächen die aus Voxeln repräsentiert werden als Polygone darzustellen. Da Minecraft mit Chunks arbeitet klingt das noch plausibel...

    die per ray casts zu rendern waere vermutlich um einiges schneller, zumindestens auf gpu seite. auf cpu seite waere das ein wenig eine herausforderung, aber an sich ist das bei 128 einheiten in die hoehe, als ob du 128 mal doom2 level renderst. wenn man dann pro ebene noch ein optimierungen einbaut fuer grosse leere flaechen, dann sollte das auch auf cpu schneller sein als polys zu zeichnen.


Log in to reply