Suchergebnisse

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 Primi…

Zitat von φConst: „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…

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

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).

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.

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 k…

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 …

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 Bl…

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

Ich hab leider keine Ahnung was du vorhast, wofür du überhaupt ein Array mit solch komischen Dimensionen brauchst?

Natürlich ist ein einzelner VertexBuffer effizienter, jedoch wirst du damit bestimmt auf Probleme stoßen, denn bei jedem mal wenn ein Chunk geändert wird wirst du wohl oder Übel Daten kopieren müssen und jenach Ansatz wird das entsprechend viel. Außerdem natürlich wesentlich komplizierter zu managen. Wär alles gar kein so großes Problem, wenn du sparse buffers(kp wie das in DX heißt, oder obs die überhaupt gibt) oder GPU side copying verwenden könntest, eins ist jedoch klar: MonoGame hat keins v…

bei einem Lichtquellenblock haben alle Vertices denselben Lichtwert, ansonsten ist deine Grundsätzliche Idee gar nicht schlecht, jedoch kann man das ganze weiter führen: 0fps.net/2013/07/03/ambient-oc…or-minecraft-like-worlds/

meine einzige Erfahrung mit Höhlensystem sind gesammelte Ideen, hab noch nichts davon implementiert. Meine aktuellste Idee war über nen Perlin Worms Algorithmus, das dürfte dann aber sehr schwer aufwendig werden, da man die Höhlen als Strukturen sehen müsste um diese Fortlaufend generieren zu können, am liebsten wäre mir natürlich ein Worms Algorithmus, welcher nur die Position haben möchte, das dürfte aber denke ich nicht so einfach sein, deshalb glaube ich, dass das beste tatsächlich das überl…

Was genau würdest du denn Cullen? Frustum Culling ist denke ich mal das erste, dann könnte man evtl. Occlusion Culling noch implementieren, ich frage mich, ob man das nicht evtl. sogar drastisch optimieren kann, dadurch dass man nur mit Würfeln arbeitet und man dann diese Projezieren könnte, anstelle das Objekt tatsächlich zu rendern, aber wenn das dann auf der CPU passiert ists vmtl. langsamer. Also könnte man einfach mal versuchen normal zu implementieren

Warte mal, die Hölen sind extra Meshes, warum denn das? Den Sinn dahinter seh ich nicht so ganz?

Zitat von φConst: „Die Höhlen; sind ja zusätzliche Meshes die gerendert werden...“ Das hat mich eben verwirrt. Das Ding ist du cullst nur komplette Chunks, alles andere dauert denke ich länger als das Rendern selbst, falls du teile der Chunks cullen wolltest?!

Wie gesagt schwer zu sagen ob das sinnvoll möglich ist. Ich würde das ganze erstmal lassen. Meine Engine mit Linux Mint. Hat noch nen paar Probleme, irwie ist die Maus invertiert Und Licht/Höhlen scheinen da noch nicht implementiert zu sein, oder? Edit: Es scheint ziemlich viel noch auf dem github repository zu fehlen, ich schein das falsche zu haben. Ich hab das hier: github.com/NET-D3v3l0p3r/MCMG

Nö, man macht verschiedene branches für verschiedene features, wenn die features dann soweit implementiert sind, kommen sie in den develop branch, wenn der develop branch zufriedenstellend funktioniert kommt es in den master. und alles im master ist release stand...

Wie gesagt ich halte diese Optimierung nicht für sinnvoll, abgesehen davon müsste die Überprüfung komplexer als nur ein einzelner ray sein. Occlussion culling kannst damit auch nicht ohne extra rendering schritt machen.