Welches ist die beste LOD-Methode für das Rendern von Planeten?

Ich arbeite gerade an meiner These, es ist eine Engine, um Terrains von planetarischer Größe zu rendern.

Ich bin noch am Ende meiner Recherche und habe eine Menge Dinge zu diesem Thema gefunden. Das Problem ist, dass ich mich nicht entscheiden kann, welche LOD-Methode (Level of Detail) ich verwenden soll.

Ich kenne mich mit Geomipmapping, Geometry Clipmaps (GPU) und Chunked LOD von Ulrich aus, die auf großen Terrains gut funktionieren und zum Rendern von 6 Flächen eines Würfels und anschließenden "Sphärifizieren" des Würfels mit dieser Methode verwendet werden können, und ich verstehe, wie alles implementiert wird Diese Methoden auf der GPU unter Verwendung von C ++ / OpenGL / GLSL (die Verwendung von Methoden wie ROAM oder einer anderen Methode, die keinen Würfel verwendet, ist nicht in meiner Reichweite, da die Texturierung schmerzhaft ist). Außerdem habe ich kürzlich ein Tutorial zum Rendern von Terrains mithilfe von Tessellation-Shadern gelesen

Ich habe also nicht die Zeit, ALLE Methoden zu implementieren und herauszufinden, welche die beste und am besten geeignete Methode für eine Planetenskala ist, und ich frage hier, ob jemand diese Art von Vergleich durchgeführt hat, und helfe mir bei der Entscheidung, welche Methode sollte ich implementieren und verwenden (mein Tutor ist irgendwie verrückt und möchte, dass ich etwas mit einem Ikosaeder mache, aber ich kann diese Methode nur verstehen, wenn ich ROAM verwende)

Wie auch immer, wenn Sie mir bei der Entscheidung helfen können oder einen anderen Vorschlag oder eine andere Methode haben, werde ich das wirklich zu schätzen wissen. Eine Bedingung ist, dass die Methode in der Lage sein sollte, GPU-seitig (zumindest größtenteils) zu implementieren, um einen CPU-Engpass zu vermeiden.

Eine andere Bitte ist, dass ich weiß, dass es numerische Probleme mit der Präzision von Schwimmern gibt, wenn ich viele Details im Gelände bekomme. Ich weiß nicht, wie ich das lösen soll. Ich lese eine Lösung in einem Forum, kann aber nicht verstehen, wie es geht implementieren, ich habe den Überblick über diesen Thread verloren und möchte wissen, wie dieses Präzisionsproblem zu lösen ist.

Ich lese gerade über einige Matrixtransformationen, um die Float-Präzision, Z-Fighting-Probleme, Kegelstumpf-Culling mit dynamischen Z-Werten und Datendarstellung für Chunks (unter Verwendung von Patch-Space mit Floats und seiner Position in den Weltkoordinaten als Double) zu lösen Ich denke, ich kann das Präzisionsproblem leicht lösen. Ich brauche noch einen Vergleich zwischen LOD-Methoden mit Ihren Meinungen und Vorschlägen, um zu entscheiden, welche für dieses Projekt besser sind. Berücksichtigen Sie die Schwierigkeit der Implementierung, die visuelle Qualität und die Leistung. Ich möchte das Beste.

Ich habe vergessen zu erwähnen, dass die Generation hybride ist. Ich meine, ich sollte in der Lage sein, den Planeten vollständig mit GPU (Höhenberechnung im Fluge) und / oder mit einem Basishöhenkartenbild zu rendern und Details mit GPU (Scheitelpunkt) hinzuzufügen Shader). Die Texturierung wird ein Nebeneffekt sein, den ich später bemühen werde. Im Moment verwende ich nur Farben, die von der Höhe abhängen, oder möglicherweise eine Art Rauschtextur, die auf dem Fragment-Shader erzeugt wird.

Schließlich kann ich nach langem Nachforschen zu dem Schluss kommen, dass es, wie bereits gesagt, keine allgemein "beste" Methode gibt. Meine Recherche führte mich jedoch zu folgenden Erkenntnissen:

Abhängig von der Masche werden Sie schließlich verwenden:

• Spherified Cube: Jede LOD-Methode mit Quadtree-Implementierung funktioniert einwandfrei. Sie müssen sich nur um Sonderfälle wie Grenzen zwischen Flächen kümmern. In diesem Fall muss Ihr Quadtree in jeder Ebene einen Zeiger auf den Nachbarn in der angrenzenden Fläche haben.
• Sonstiges: Ich denke, dass ROAM (neuere Version 2.0 oder eine andere Erweiterung wie BDAM, CABTT oder RUSTIC) gut funktioniert. Diese Algorithmen sind jedoch schwer zu verarbeiten, erfordern mehr Speicher und sind etwas langsamer als andere Vorgehensweisen mit Cubes.

Es gibt viele LOD-Methoden, die gut passen, aber meine persönlichen Top 5 sind:

1. Kontinuierliche entfernungsabhängige LOD (CDLOD)
2. GPU-basierte Geomety-Clipmaps (GPUGCM)
3. Chunked LOD
4. Rendern von Terrains mit OpenGL-GPU-Tessellation (Buch: OpenGL Insight, Kapitel 10)
5. Geometrisches MipMapping

Jedes bietet eine einzigartige Möglichkeit, Terrains zu rendern. CDLOD bietet beispielsweise eine sehr einfache Implementierung mithilfe von Shadern (GLSL oder HLSL), kann jedoch auch auf der CPU (für ältere Hardware) implementiert werden Das Beste für moderne GPUs. Daher ist GPUGCM das Beste, wenn Sie Ihre GPU komprimieren möchten. Beide funktionieren sehr gut mit datenbasiertem, prozeduralem oder gemischtem Rendering (Terrain basierend auf festen Daten oder Höhenkarten und Details, die mit prozeduralem Rendering hinzugefügt wurden) von großen Terrains.

Es gibt auch eine sphärische Erweiterung der grundlegenden geometrischen Clipmaps-Methode, die jedoch einige Probleme mit sich bringt, da die planaren Samples der Höhenkarte unter Verwendung von sphärischen Koordinaten parametrisiert werden müssen.

Chunked LOD hingegen ist perfekt für Legacy-Hardware, benötigt keine GPU-seitigen Berechnungen, ist perfekt für große Datenmengen, kann aber keine prozeduralen Daten in Echtzeit verarbeiten (möglicherweise mit einigen Änderungen).

Die Verwendung von Tessellation-Shadern ist eine andere, sehr neue Technik, da OpenGL 4.x herausgekommen ist. Meiner Meinung nach könnte dies die beste sein, aber wir sprechen über Planet Rendering. Wir stoßen auf ein Problem, das andere Methoden sehr einfach handhaben können und das es auch ist über Präzision.

Verwenden Sie Tessellation-Shader, es sei denn, Sie möchten nur eine Genauigkeit von 1 km zwischen Verticies. Das Problem bei wirklich großen Terrains mit dieser Methode ist, dass Jitter schwer zu lösen ist (oder zumindest für mich, da ich neu in Tessellation-Shadern bin).

Geomipmapping ist eine großartige Technik, nutzt den Quadtree und weist einen geringen projizierten Pixelfehler auf. Für das planetarische Rendern müssen Sie jedoch mindestens 16 Detailebenen festlegen, dh, Sie benötigen (zum Zusammenfügen von Posen) einige zusätzliche Patches Um verschiedene Level zu verbinden und sich um das Level deines Nachbarn zu kümmern, kann es mühsam sein, dies zu lösen, insbesondere wenn 6 Geländegesichter verwendet werden.

Es gibt eine andere Methode, die für sich ganz besonders ist: "Projective Grid Mapping for Planetary Terrain", die sich hervorragend zur Visualisierung eignet , aber ihre Nachteile hat, wenn Sie mehr wissen möchten, gehen Sie zum Link.

Probleme:

• Jitter : Die meisten heutigen GPUs unterstützen nur 32-Bit-Gleitkommawerte, was für die Manipulation großer Positionen in Terrains mit planetarischem Maßstab nicht genau genug ist. Jitter tritt auf, wenn der Betrachter zoomt und sich dreht oder bewegt, und die Polygone beginnen, vor und zurück zu springen.

  Die beste Lösung hierfür ist die Verwendung der Methode "Rendern relativ zum Auge mit der GPU". Diese Methode ist im Buch "3D-Engine-Design für virtuelle Globen" (ich bin sicher, Sie finden es auch im Internet) beschrieben, in dem Sie im Grunde alle Ihre Positionen mit Doppel-CPU festlegen müssen (Patches, Clipmaps, Objekte, Frustrum, Kamera usw.) und dann wird MV um den Betrachter herum zentriert, indem seine Übersetzung auf (0, 0, 0) T gesetzt wird, und die Doppelbilder werden in einer Festkommadarstellung unter Verwendung der Bruchbits (Mantisse) von zwei Floats, niedrig, codiert und hoch durch eine Methode (lesen Sie über die Implementierung von Using Ohlarik und die DSFUN90 Fortran-Bibliothek).

  Obwohl der Vertex-Shader nur zwei zusätzliche Subtraktionen und eine Addition erfordert, verdoppelt GPU RTE die Menge des für Positionen erforderlichen Vertex-Pufferspeichers. Dies verdoppelt nicht unbedingt den Speicherbedarf, es sei denn, es werden nur Positionen gespeichert.

• Tiefenpuffer-Präzision : Z-Fighting. Da wir in diesem Fall sehr großes Terrain rendern: Planeten, muss der Z-Puffer RIESIG sein, aber es spielt keine Rolle, welche Werte Sie für znear und zfar festlegen, es wird immer Probleme geben.

  Da der Z-Puffer von einem Gleitkommaintervall abhängt und es sich auch um lineare Werte handelt (obwohl die perspektivische Projektion nicht linear ist), leiden die Werte in Augennähe unter Z-Fighting, da es an präzisen 32-Bit-Gleitkommas mangelt.

  Die beste Lösung für dieses Problem ist die Verwendung eines "logarithmischen Tiefenpuffers" http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

  Ein logarithmischer Tiefenpuffer verbessert die Tiefenpuffergenauigkeit für entfernte Objekte, indem eine logarithmische Verteilung für zscreen verwendet wird. Es tauscht Präzision gegen nahe Objekte gegen Präzision gegen entfernte Objekte. Da wir mit einer LOD-Methode rendern, erfordern ferne Objekte eine geringere Genauigkeit, da sie weniger Dreiecke haben.

Zu erwähnen ist, dass alle aufgelisteten Methoden (mit Ausnahme des projektiven Gitters) aufgrund der Quadtree-Basis sehr gut in der Physik sind (Kollisionen meistens). Dies ist ein Muss, wenn Sie vorhaben, ein Spiel zu erstellen.

Überprüfen Sie abschließend einfach alle verfügbaren Optionen und wählen Sie die, die Ihnen am besten gefällt. Meiner Meinung nach leistet CDLOD eine großartige Arbeit. Vergessen Sie nicht, die Probleme mit dem Jitter und dem Z-Buffer zu lösen. Und das Wichtigste: Viel Spaß beim Erstellen!

Weitere Informationen zum LOD-Check diesem Link .

Für eine vollständige Demonstration über die Sphärisierung eines Würfels überprüfen diesen Link .

Weitere Informationen zum Lösen von Jittering und Z-Buffer-Genauigkeiten finden Sie unter diesem Buch .

Ich hoffe, Sie finden diese kleine Rezension hilfreich.