Runshak schrieb:

ich würde keinen shooter daraus machen sondern im minecraft style halten...aber wenn du monster etc hinzufügst, dann könntest du diese so spawnen lassen, sodass diese außerhalb gebauter mauern spawnen und nicht ständig innerhalb eines hauses oder so, nur weils dort dunkel ist...so würde man sich das mühsame ausleuchten ersparen

Finde ich nicht notwendig. Wenn der Ersteller es jedoch dennoch so machen möchte, dann mach es mit speziellen Blöcken wo Monster nicht spawnen dürfen. Das erleichtert dir das Coden. Ansonsten müsstest du ja irgendwie nach dem Haus Abfragen aber.. dafür müsstest du dem Spiel erst sagen, ab wann ein Haus auch ein Haus ist und.. dafür müsstest du irgendwie das Haus scannen. Ach, egal. Lasst mich. xD Es ist jedenfalls viel einfacher, wenn die Monster nur auf Gras spawnen dürfen.

Ich würde eher Vertices anstatt Indices löschen, die Vertices beinhalten ja auch die Information über Texturen etc. macht doch mehr Sinn die zu entfernen.
Außerdem kann man die Indices für alle CHunks wiederverwenden.

Und wie texturierst du mit unterschiedlichen texturen? Oder machst du das alles über einen Shader?

Es werden die Vertices erstellt, die gebraucht werden, für jede Seite an der Oberfläche erstmal alle 4 Vertices, d.h. du wirst viele doppelte Vertices haben, selbst wenn es sich bei den nebeneinanderliegenden Flächen um diesselbe Textur handelt(diese Optimierung wird denke ich auch sehr Kompliziert, ich hab mir dazu auch noch nicht wirklich etwas überlegt, da es viele andere Optimierungen gibt, die vermutlich eifacher zu lösen sind und sogar einen größeren Effekt haben dürften).
Diese Vertices kommen alle einfach in deinen VertexBuffer pro Chunk.
Der IndexBuffer dürfte dabei für jede Seite immer folgendes Enthalten:
{i*4+0,
i*4+1,
i*4+3,

i*4+0,
i*4+3,
i*4+2
}
n ist dabei der Index der Seite(die ansich nicht relevant ist), für jeden Chunk geht i von 0 bis n(Anzahl der Quadrate).
Wie du aber dabei siehst, ist es vollkommen egal, was für Vertices später verwendet werden, die IndexBuffer werden für jeden Chunk(bis auf die Anzahl der indices) gleich sein. Deshalb reicht dir ein IndexBuffer, der einfach so groß ist, wie es der größte Chunk verlangt.

Das maximale an benötigten Indices dürfte dem hier entsprechen(kann auch falsch sein):
Jeder zweite Block gesetzt-> Chunk.Size.X / 2 * Chunk.Size.Y / 2 * Chunk.Size.Z / 2
Bei jedem Block sind alle Seiten Sichtbar -> Chunk.Size.X / 2 * Chunk.Size.Y / 2 * Chunk.Size.Z / 2 * 6
eine Seite braucht 6 Indices-> -> Chunk.Size.X / 2 * Chunk.Size.Y / 2 * Chunk.Size.Z / 2 * 6 * 6
so kann man auch den höchsten Index bereichnen: Chunk.Size.X / 2 * Chunk.Size.Y / 2 * Chunk.Size.Z / 2 * 6 * 4 - 1


bei 32*32*32 also
16*16*16*36=147456
der höchste Index:
16*16*16*24-1=98303-> es wird ein (U)Int32 zur Indizierung benötigt

bei 16*16*16:
8*8*8*36=18432
höchste Index:
8*8*8*24-1=12287-> es genügt ein (U)Int16

welches von beiden nun besser ist lässt sich streiten bei 32^3 brauchst du natürlich nur ein 8tel der DrawCalls, jedoch auch die doppelte größe für den IndexBuffer.
Ich würde dabei zu den größeren Chunks tendieren, da du nur einen IndexBuffer hast und dieser nur einmal übertragen werden muss, ob das tatsächlich die schnellere Variante ist hab ich nie getestet. Andere Möglichkeit wäre natürlich den IndexBuffer mit Shorts zu machen, bis die obere Grenze bei der Indizierung erreicht wird, ich glaube, dass nur wenige Chunks tatsächlich an die obere Grenze kommen zumindest nicht in einer natürlichen Welt.

Edit: es ist natürlich gut möglich, dass ich bei der Berechnung einen massiven Denkfehler drinne hab, also falls dir was auffällt auch am besten gleich sagen.

Entschuldige, natürlich alle 4 Vertices der jeweiligen Seite

Texturatlas + entsprechende Texturkoordinaten, was natürlich die übergänge erschwert, da gibt es Möglichkeiten, die ich aber nie erfolgreich umgesetzt habe, wie man verhindert, dass er an den Rändern zwischen den einzelnen Texturen interpoliert.
Sinnvoller wäre natürlich ein Texture-Array, welches von MonoGame nicht unterstützt wird, schließlich hatte XNA auch nichts in der Art und features hinzufügen wollen sie nicht.
Andere Möglichkeit ist ein Custom-Vertex-Format(ist sowieso sinnvoll, da man die anderen Daten noch ziemlich komprimieren kann), indem dann für die Vertices die jeweilige Textur über einen Index gespeichert und im Shader aus einem Array die entsprechende auszuwählen.

(Werbung: oder du versuchst irgendwann auf meine Engine umzustellen, die Texture2DArrays hat :D)

DrawIndexPrimitives dürfte schneller sein, da Static Instancing(welches genau so gemacht wird) über eben diese Funktion geschieht. Und immer wenn es um Instancing ging hab ich gelesen, dass man falls möglich immer das verwenden soll(heißt, wenn es eben statisch und nicht bewegt ist z.B.). Bewegte braucht man dann evtl. später für Dinge wie fallenden Sand, würde ich dann aber ähnlich MC als Entities machen.
-> Wenn der Block beginnt zu fallen wird ein Entity gespawnt das genau aussieht wie der Block und an derselben Stelle, der Block wird aus dem Chunk entfernt->Dann beginnt das Fallen mit Kollision->Nachdem eine Kollision erfolgt wird der Block wieder im Chunk gesetzt und das Entity gelöscht.

Werbung:
github.com/OctoAwesome/engenious
gibt sogar nen Nuget Paket dazu, jedoch muss ich dich warnen, ist alles in development das wenigste ist getestet und es funktioniert etwas anders als MonoGame, aber im Grunde ist der Aufbau ähnlich.
Ich möchte aber im Gegensatz zu MonoGame nicht das exakte Verhalten von XNA nachahmen, sondern hab nur Grundsätzlich den gleichen architektonischen Aufbau, sodass das Umsteigen erleichtert wird(Hab damit angefangen, weil eben MonoGame die Shader nicht funktioniert haben und ich neue features verwenden möchte).
Meine Engine läuft außerdem komplett auf OGL.
Die Badges für Linux/Mac lügen aktuell, lokal buildet das bei mir einwandfrei, nur auf den Build-Servern scheint es Probleme zu bereiten(und das nicht mal beim compilen - sondern schon vorher).

Ich denke du hasts verstanden

Wie gesagt, das sind zwei unterschiedliche herangehensweisen. MonoGame unterstützt keine richtigen TextureArrays, also musst du entweder merhere texturen an den shader einzeln übergeben, und diese dann im shader verwenden, oder in einem texturatlas, dann geht auch alles noch mit dem BasicShader