[MonoGame]Minecraft-Klon

φConst · 30. März 2016, 00:26

Hallo,

ich präsentiere euch mein Minecraft-Klon.
Es ist in C# und unter der Framework Monogame entwickelt wurden.

Der Klon offeriert :
- (temporär) eine 20x20 Chunks große Map. (Ein Chunk ist 16x16x256 Einheiten groß).
- Geringe Ladezeiten (20x20 Chunks werden in unter 3 Sekunden generiert)
- Kollisionserkennung(stark Verbesserungswürdig)
- Picking( ohne einen Würfel zu entfernen oder zu platzieren )
- die Seite eines Würfels zu determinieren(Picking)

Die Motivation, dieses Projekt in dieser Periode zu publizieren ist die, dass ich konstruktive Kritik erhoffe, um eventualiter den Source dementsprechend zu optimieren.

Ein besonderer Dank gilt @jvbsl , der mich auf das Projekt seines guten Freundes verwies(wodurch ich den Levelgenerator implementieren konnte).

Den Source findet ihr auf Github:
~~github.com/NET-D3v3l0p3r/Minec…er/MinecraftCloneMonoGame~~ (obsolet!)

Besonders interessant ist die Namespace "CoreOptimized".

Es empfiehlt sich "CoreObsolete" mit "CoreOptimized" zu parallelisieren( um daraus die Kenntnis zu schöpfen, wie es nicht aussehen zu dürfen hat).

Liebe Grüße.

Hinweis
Die Repository github.com/NET-D3v3l0p3r/Minec…er/MinecraftCloneMonoGame ist inzwischen obsolet.
https://github.com/NET-D3v3l0p3r/MCMG ist die aktuelle Version!

φConst · 30. März 2016, 17:50

Kürzere Ladezeiten, größere Maps!

Ich habe die Struktur DefaultCubeStructure als Klasse markiert.
Dadurch werden nur jene Würfel in den Chunk-Array geladen, die auch wirklich gebraucht werden.

Demnach sind nicht 20x20 große Chunk Maps sondern 32x32 möglich!(Etwa wie bei Minecraft) (Grad getestet, auch 64x64 große Maps sind diskutabel [45~60 FPS im DEBUG])
Die Ladezeit beträgt um die 0.7 Sekunden[DEBUG] in [RELEASE] (circa) 0.387s !!!

Viel Vergnügen!

jvbsl · 30. März 2016, 23:08

Nur um das Klarzustellen: Der Map Generator aus dem Projekt von Tom Wendel ist sogar von PatteKi und mir.
Insgesamt ist es ein Community Projekt, das zwar Hauptsächlich von Tom programmiert wurde, aber viele Dinge aus der Community enthält.

Trotzdem danke fürs erwähnen

Edit:
Ich sehe aktuell noch nicht den Sinn, warum du die 3D Noise verwendest aber doch nur 2D Maps generierst. Mit der 2D Noise bekommst sicher nochmal etwas geschwindigkeit und ähnliche Ergebnisse

Durch die Verwendung einer Primitiven Datenstruktur(short z.B.) im Gegensatz zu einer komplizierten Klasse(DefaultCubeClass) bekommst du sicher auch noch Geschwindigkeit.
Den Chunk Renderer interessiert nur die Textur und evtl. Orientierung dieser, sowie die Position eines Blockes.
Durch eine Verwendung eines Arrays mit indiziertem Zugriff int index = ((z*width)+y)*depth + x; reicht ein Eindimensionales Array und die Position ist automatisch daraus bekannt(BlockPosition muss nicht mehr gespeichert werden)

Habs mir jetzt nicht im Detail angeguckt, aber ich denke dass das Instancing dir eher Probleme bereiten wird, das Instancing ergibt zwar Sinn, aber eher in einer Kombination mit einem bereits genannten System zur Chunk Generierung.

φConst · 31. März 2016, 00:38

Hallo,
danke für die Rückmeldung!

jvbsl schrieb:

Ich sehe aktuell noch nicht den Sinn, warum du die 3D Noise verwendest aber doch nur 2D Maps generierst. Mit der 2D Noise bekommst sicher nochmal etwas geschwindigkeit und ähnliche Ergebnisse

Einfach nur zum Testen.
Wollte Höhlengenerierung implementieren, kommt aber später..
nach "InfDev".

jvbsl schrieb:

Durch die Verwendung einer Primitiven Datenstruktur(short z.B.) im Gegensatz zu einer komplizierten Klasse(DefaultCubeClass) bekommst du sicher auch noch Geschwindigkeit.

Das ist wohl war,
doch es wird nicht klar, was gemeint ist.

Die DefaultCubeClass ist obligatorisch, weil nun mal einige Werte darin enthalten sind.
Meinst du etwa, dass ich die Datentypen der Eigenschaften dieser Klasse (exemplarisch Vektor) ersetzen solle durch drei Komponenten
short X, Y, Z?

jvbsl schrieb:

Den Chunk Renderer interessiert nur die Textur und evtl. Orientierung dieser, sowie die Position eines Blockes.

Tut er ja auch.
Bloß die Transformations-Matrix und die Texture-Id.

Quellcode

int index = ((z*width)+y)*depth + x

gab's mal Probleme damit im Namespace "ChunkObsolete", gebe dir aber vollkommen recht.

(BlockPosition muss nicht mehr gespeichert werden)

Die Idee hatte ich auch, kommt voraussichtlich im nächsten Update.

jvbsl schrieb:

aber ich denke dass das Instancing dir eher Probleme bereiten wird

Inwiefern denn

?

Liebe Grüße.

jvbsl · 31. März 2016, 03:54

φConst schrieb:

Die DefaultCubeClass ist obligatorisch, weil nun mal einige Werte darin enthalten sind.
Meinst du etwa, dass ich die Datentypen der Eigenschaften dieser Klasse (exemplarisch Vektor) ersetzen solle durch drei Komponenten
short X, Y, Z?

Ich meinte eher soetwas
0 Air
1 Gras
2 Dirt

mehr muss der Renderer auch erstmal gar nicht Wissen Zusatzinformationen wie MetaData können gerne noch mit einem ZweitArray/tatsächlichem Element in einem primitiven Typen realisiert werden.
Falls mit MetaDaten tatsächlich für das Rendern entscheidende Daten gemeint sind, ansonsten komplett getrennt von deinem einfachen Short Array halten.

φConst schrieb:

Bloß die Transformations-Matrix und die Texture-Id.

Eine Komplette Transformationsmatrix für einen einzelnen Block, der Relativ zu den restlichen Blöcken nie skaliert oder rotiert wird und auch in seiner Position(relativ) immer gleich bleibt?
4x4 float ist ein bisschen viel für eigt. nur eine Position 3 float oder gar per Indizierung 1 int

φConst schrieb:

Inwiefern denn ?

Irgendwann kommst du vmtl. an den Punkt, andem du so viele Würfel zeichnest, dass die Optimierung durch das Instancing nicht mehr ausreicht, da immer noch unnötige Flächen der Würfel gezeichnet werden, die wegoptimiert werden können, jenach HW trifft dies früher oder später ein.

φConst · 31. März 2016, 17:21

Ich werde dann im HardwareInstancedRenderer nur die Position übergeben(und die Matrix im Shader erzeugen).

Irgendwann kommst du vmtl. an den Punkt, andem du so viele Würfel zeichnest, dass die Optimierung durch das Instancing nicht mehr ausreicht, da immer noch unnötige Flächen der Würfel gezeichnet werden, die wegoptimiert werden können, jenach HW trifft dies früher oder später ein.

Werde ich nicht.
Wenn exemplarisch die Map 32x32 Chunks groß ist, dann bleibt sie immer genau so groß.
Was höchstens eine Komplikation generieren kann ist das Platzieren von Cubes.

Kennst du denn eine Alternative zu Hardware-Instancing?

Dieses Video ist mir ein Mysterium :

In seinem Deskription gibt er an, dass er;

No occlusion culling, hardware instancing or other tricks.

verwende...

und

Ich meinte eher soetwas0 Air1 Gras2 Dirt

Stimmt, muss ich mir überlegen, wie ich die Klasse neu definiere.

Liebe Grüße.

jvbsl · 31. März 2016, 17:30

eine alternative ist die Flächen selbst einmalig zu erzeugen, wenn die Vertices einmal an der Graka sind ist das schneller als HW Instancing.

φConst · 31. März 2016, 17:33

Ist das, was in OpenGL VBO's sind?

EDIT: @jvbsl

Ich sehe um ehrlich zu sein keinen Unterschied zu dem wie ich es mache.(Ich habe es gewiß missverstanden).

Meine Hardware-Instanced-Renderer Klasse(etwas modifizierte Version von Microsoft) sieht folgendergestalt aus,
Die Render-Methode:

C#-Quellcode

public bool Render()
{
if (MatrixBufferArray.Length == 0)
return false;
if ((InstancedVertexBuffer == null) || (MatrixBufferArray.Length > InstancedVertexBuffer.VertexCount))
{
if (InstancedVertexBuffer != null)
{
InstancedVertexBuffer.Dispose();
InstancedTextureBuffer.Dispose();
}
InstancedVertexBuffer = new DynamicVertexBuffer(GlobalShares.GlobalDevice, InstancedVertexDeclaration, MatrixBufferArray.Length, BufferUsage.WriteOnly);
InstancedTextureBuffer = new DynamicVertexBuffer(GlobalShares.GlobalDevice, InstancedTextureIDs, TextureBufferArray.Length, BufferUsage.WriteOnly);
InstancedVertexBuffer.SetData<Matrix>(MatrixBufferArray, 0, MatrixBufferArray.Length, SetDataOptions.Discard);
InstancedTextureBuffer.SetData<Vector2>(TextureBufferArray, 0, TextureBufferArray.Length, SetDataOptions.Discard);
}
for (int i = 0; i < Texture2Ds.Length; i++)
{
if (Texture2Ds[i] != null)
InstancingShader.Parameters["Texture" + i].SetValue(Texture2Ds[i]);
}
foreach (var mesh in Model.Meshes)
{
foreach (var meshPart in mesh.MeshParts)
{
GlobalShares.GlobalDevice.SetVertexBuffers(
new VertexBufferBinding(meshPart.VertexBuffer, 0, 0),
new VertexBufferBinding(InstancedVertexBuffer, 0, 1),
new VertexBufferBinding(InstancedTextureBuffer, 0, 1));
GlobalShares.GlobalDevice.Indices = meshPart.IndexBuffer;
InstancingShader.CurrentTechnique = InstancingShader.Techniques["HardwareInstancing"];
InstancingShader.Parameters["World"].SetValue(WorldMatrix);
InstancingShader.Parameters["View"].SetValue(Camera3D.ViewMatrix);
InstancingShader.Parameters["Projection"].SetValue(Camera3D.ProjectionMatrix);
InstancingShader.Parameters["EyePosition"].SetValue(Camera3D.CameraPosition);
InstancingShader.Parameters["FogEnabled"].SetValue(1.0f);
InstancingShader.Parameters["FogColor"].SetValue(Color.CornflowerBlue.ToVector3());
InstancingShader.Parameters["FogStart"].SetValue(0.0f);
InstancingShader.Parameters["FogEnd"].SetValue((float)Camera3D.RenderDistance);
foreach (EffectPass pass in InstancingShader.CurrentTechnique.Passes)
{
pass.Apply();
GlobalShares.GlobalDevice.DrawInstancedPrimitives(PrimitiveType.TriangleList, 0, 0, 1, 0, 12, MatrixBufferArray.Length);
}
}
}
return true;
}

Interessant ist diese Zeile,

C#-Quellcode

if ((InstancedVertexBuffer == null) || (MatrixBufferArray.Length > InstancedVertexBuffer.VertexCount))
{
if (InstancedVertexBuffer != null)
{
InstancedVertexBuffer.Dispose();
InstancedTextureBuffer.Dispose();
}
InstancedVertexBuffer = new DynamicVertexBuffer(GlobalShares.GlobalDevice, InstancedVertexDeclaration, MatrixBufferArray.Length, BufferUsage.WriteOnly);
InstancedTextureBuffer = new DynamicVertexBuffer(GlobalShares.GlobalDevice, InstancedTextureIDs, TextureBufferArray.Length, BufferUsage.WriteOnly);
InstancedVertexBuffer.SetData<Matrix>(MatrixBufferArray, 0, MatrixBufferArray.Length, SetDataOptions.Discard);
InstancedTextureBuffer.SetData<Vector2>(TextureBufferArray, 0, TextureBufferArray.Length, SetDataOptions.Discard);
}

Ich erzeuge nur dann ein neues VertexBufferObjekt wenn etwas geändert wurde.

Die Methodenaufrufe:

C#-Quellcode

GlobalShares.GlobalDevice.SetVertexBuffers(
new VertexBufferBinding(meshPart.VertexBuffer, 0, 0),
new VertexBufferBinding(InstancedVertexBuffer, 0, 1),
new VertexBufferBinding(InstancedTextureBuffer, 0, 1));
GlobalShares.GlobalDevice.Indices = meshPart.IndexBuffer;

sind obligatorisch, weil nun mal der BackBuffer geleert wird; (und wohl auch der Vertex -und Indexbuffer des GraphicDevices)

Und dann findet ein Render()-Call für einen Chunk statt..

Wie sähe es denn aus, wie du es beschreibst?

Ich danke dir herzlichst!

φConst · 31. März 2016, 19:18

Mir ist etwas eingefallen.

Ich glaube ich weiß was du meinst.
Ein Chunk soll ich betrachten wie ein Model.

Bei der Generierung eines Chunks, generiere ich einen VertexBuffer mit einer gewissen Anzahl an Vertices.
(Bei 16x16 müssten es also nur die sein, die die Oberfläche des Chunks repräsentieren).

Also generiere ich mehrere Würfel, und lade sie in EIN VertexBuffer.

EDIT:
Ist auf der TODO-Liste.

Das wäre genial; ist es das was du meinst?

φConst · 31. März 2016, 23:20

Ich habe es _ geschafft in die Z -Achse unendlich weites Terrain zu generieren(wird generiert wenn die hinteren Chunks nicht mehr in der Map-BoundingBox liegen).
Das Problem ist nun der GarbageCollector.

Er tut nicht, was sein Name verspricht.
Wie kann ich ein Array disposen?

Ich weiß, ich weiß, nicht null setzen , sondern seine Elemente diposen.
Mein ChunkOptimized erbt von IDisposable, :

C#-Quellcode

public void Dispose()
{
for (int i = 0; i < ChunkData.Length; i++)
{
if (ChunkData[i] != null)
ChunkData[i].Dispose();
}
HeightMap = null;
GC.SuppressFinalize(this);
}

bringt gar nichts.
Der Ram Speicher wird exponentiell stupriert.
Wie dispose ich eine benutzerdefinierte Klasse nach WindowsForms-Manier?

Lieben Dank.

nafets · 31. März 2016, 23:32

Du kannst ein Array oä in .NET nicht einfach in C-Manier "free'en", der GC macht das automatisch, sobald das Array ausm Scope fällt, allerdings arbeitet er nicht immer so schnell, wie man es gerne hätte.

φConst · 31. März 2016, 23:39

Stimmt, hast recht.
Er hat gedisposet

Gut, hat sich dann auch erledigt.

jvbsl · 31. März 2016, 23:55

Ich glaube du hast verstanden was ich meine du erstellst einen VertexBuffer+IndexBuffer IndexBuffer genügt einer für alle Chunks, da die indices immer gleich aufgebaut sind.
VertexBuffer ist einfach nur die Oberfläche deiner Welt/Würfel, somit braucht man die Hinterseiten einiger Würfel z.B. nicht mehr zu zeichnen(oder cullen).

φConst · 1. April 2016, 01:31

@jvbsl Jop, das ist gut.
Muss mir nur überlegen, wie ich den IndexBuffer erzeuge.(respektive diesen mit Indices fülle).

Wenn ich das hab, implementiere ich das.

@GarbageCollector ist ja mal richtig Müll.
Der GC hat gar nichts gesammelt.
Ich muss die Arrays neu initialisieren(mit der Anzahl 0), wenn ich das nicht mache, steigt der RAM Verbrauch auf 5 Gigabyte...

EDIT: Perfekt!
Der GC macht nun was er will.

Ein Beispielprojekt.. nur in -Z und +Z Richtung möglich.
Generiert äonenweites Terrain!

jvbsl · 1. April 2016, 13:39

Der GC räumt managed Dinge schon auf, aber VertexBuffer und ähnliches müssen disposed werden.
Außerdem ist dann später die Idee den GC gar nicht erst arbeiten zu lassen, sondern den allozierten Speicher wiederzuverwenden.
Für die ChunkDaten ist das z.B. ganz einfach wenn es einfach nur primitive values sind.

φConst · 1. April 2016, 22:29

Infinitve-Maps ist implementiert!

Die Repository wird in Kürze synchronisiert.

Nächstes TODO:
Interaktion und Menü.

EDIT: github.com/NET-D3v3l0p3r/Minec…zed/Chunk/ChunkManager.cs

φConst · 3. April 2016, 00:59

Ich wollte neben dem SimplexNoise einen weiteren Generator implementieren: DiamondSquare!

Dadurch waren Inseln -Inselngruppen ; und sogar approximiert Europa möglich!
(Letzteres scheint mir so).

Im Anhang einige Bilder.

Repository wird in Ferne aktualisiert.

Trade · 3. April 2016, 01:04

Hi,

das sieht sehr gut aus. Finde es auch sehr toll, dass Du aktiv am Ball bist und so schnell dazulernst. :thumbup:

Ich wollte mir gerade den Source kompilieren, allerdings konnte er Earlz.BareMetal, VertexBufferBinding und GraphicsDevice.SetVertexBuffers nicht auflösen, sodass das nicht klappt. Woher kriege ich das Zeugs? Über NuGet ist nichts verfügbar und Release gibt es auf GitHub keinen.

Grüße

φConst · 3. April 2016, 01:08

Danke Dir!

Earlz: bitbucket.org/earlz/datastruct…63e80cffda1e3d/BareMetal/

Ist eine Klasse um die Größen benutzerdefinierter Klassen auszulesen.

Im Übrigen brauchst du Monogame 3.5 ..

nochmals vielen Dank für das Kompliment.. motiviert arg!

Trade · 3. April 2016, 01:13

Ah okay, Bitbucket.^^
Hmm, ich habe glaube wirklich nur die 3.4.x, weil das Ganze beim Herunterladen und Installieren von 3.5 rumgemeckert hat. Kann ich das einfach so samt Templates in VS etc. updaten?

Grüße

[MonoGame]Minecraft-Klon

[MonoGame]Minecraft-Klon

Kleines Update

jvbsl schrieb:

jvbsl schrieb:

jvbsl schrieb:

Quellcode

jvbsl schrieb:

φConst schrieb:

φConst schrieb:

φConst schrieb:

C#-Quellcode

C#-Quellcode

C#-Quellcode

C#-Quellcode

Update, neuer Rausch-Algorithmus

Benutzer online 1

Tags

Ähnliche Themen

19 Benutzer haben hier geschrieben