Beste CLOD-Methode für das Rendern von Planeten

7

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

Ich beende immer noch meine Forschungen und ich habe eine Menge Zeug über dieses Thema gefunden, das Problem ist, dass ich mich nicht entscheiden kann, welche LOD-Methode ich verwenden soll.

Ich kenne Geomipmapping, Geometry Clipmaps (GPU) und Chunked LOD von Ulrich, die gut auf großen Terrains funktionieren und verwendet werden können, um 6 Flächen eines Würfels zu rendern und dann den Würfel mit diese Methode und ich verstehe, wie Sie alle diese Methoden auf GPU mit C ++ / OpenGL / GLSL implementieren (mit Methoden wie ROAM oder irgendeine andere Methode, die keinen Würfel benutzt, ist außerhalb meiner Reichweite, weil die Texturierung ein Schmerz ist).

Also, ich habe nicht die Zeit, ALLE Methoden zu implementieren und zu sehen, welche die beste und geeignetste für einen planetaren Maßstab ist, und ich frage hier, ob jemand diese Art von Vergleich gemacht hat und mir hilft Entscheide, welche Methode ich implementieren und verwenden soll (mein Tutor ist irgendwie verrückt und möchte, dass ich etwas mit einem Ikosaeder mache, aber ich kann diese Methode nicht verstehen, wenn ich nicht ROAM benutze)

Wie auch immer, wenn Sie mir helfen können, mich zu entscheiden oder einen anderen Vorschlag oder eine Methode zu haben, die ich wirklich zu schätzen weiß. Eine Bedingung ist, dass die Methode in der Lage sein sollte, GPU-Seite (zumindest das Meiste davon) zu implementieren, um CPU-Engpässe zu vermeiden.

Eine weitere Anfrage ist, dass ich weiß, dass es numerische Probleme mit der Präzision gibt, wenn man im Gelände eine Menge Details bekommt, ich weiß nicht, wie ich es lösen soll, ich lese eine Lösung in einem Forum, komme aber nicht dazu verstehe, wie man es implementiert, ich habe den Faden verloren und möchte wissen, wie man dieses Präzisionsproblem löst.

PD: Sorry für mein Englisch.

[EDIT] Ich lese gerade über einige Matrix-Transformationen, um die Gleitkomma-Genauigkeit, Z-Kampfprobleme, Keulenkeulen mit dynamischen Z-Werten und Datendarstellung für Chunks zu lösen (mit Patch-Space mit Floats und seiner Position in der Weltkoordinaten als Doppel) so denke ich, dass ich das Präzisionsproblem leicht lösen kann. Ich brauche immer noch einen Vergleich zwischen den LOD-Methoden mit Ihren Meinungen und Vorschlägen, um zu entscheiden, was für dieses Projekt besser ist. Zähle die Schwierigkeit der Implementierung gegenüber der visuellen Qualität gegenüber der Leistung, ich möchte das Beste.

Etwas, das ich vergessen habe zu erwähnen, ist, dass die Generation hybrid ist, ich meine, ich sollte den Planeten komplett mit GPU rendern können (Höhen, die im Flug berechnet werden) und / oder ein Basis-Heightmap-Bild verwenden und Details mit GPU hinzufügen ( Vertex-Shader). Die Texturierung wird ein Nebeneffekt sein, den ich in letzter Zeit stören werde. Im Moment bin ich froh, wenn ich nur Farben verwende, die von der Höhe abhängen, oder vielleicht eine Art von Rauschstruktur, die auf dem Fragment-Shader erzeugt wird.

    
nosmirck 11.05.2013, 07:06
quelle

1 Antwort

19

Nach vielen Recherchen kann ich schlussfolgern, dass es, wie bereits gesagt wurde, keine allgemein "beste" Methode gibt. Aber meine Forschung führte mich zu folgenden Dingen:

Abhängig vom Mesh werden Sie abschließend:

  • Spherified Cube: Jede LOD-Methode mit Quadtree-Implementierung funktioniert einwandfrei, Sie müssen nur auf spezielle Fälle wie Grenzen zwischen Gesichtern achten. In diesem Fall muss Ihr Quadtree einen Zeiger auf den Nachbarn in haben das angrenzende Gesicht in jedem Level.
  • Verschiedenes: Ich denke, dass ROAM (neuere Version 2.0 oder jede andere Erweiterung wie BDAM, CABTT oder RUSTIC) gut funktionieren wird, aber diese Algorithmen sind schwer zu handhaben, erfordern mehr Speicher und sind ein bisschen langsamer als andere aproaches mit Würfeln.

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

Jeder bietet eine einzigartige Möglichkeit, Terrains zu rendern, zB CDLOD hat eine sehr einfache Implementierung mit Shadern (GLSL oder HLSL), kann aber auch auf der CPU implementiert werden (für Legacy-Hardware), aber das Ziel beim Planet Rendering ist um die Besten auf modernen GPUs zu explodieren, also ist GPUGCM das Beste, wenn du deine GPU komprimieren willst. Beide funktionieren sehr gut mit datenbasierten, prozeduralen oder gemischten (Terrain basierend auf festen Daten oder Höhenabbildungen und Details, die mit prozeduraler Arbeit hinzugefügt wurden), die große Terrains wiedergeben.

Es existiert auch eine sphärische Erweiterung der grundlegenden geometrischen Clipmap-Methode, die jedoch einige Probleme hat, da die planaren Proben der Heightmap mit sphärischen Koordinaten parametrisiert werden müssen.

Chunked LOD hingegen ist perfekt für Legacy-Hardware, benötigt keine GPU-Seitenberechnungen, es ist perfekt für große Datasets, kann aber keine prozeduralen Daten in Echtzeit verarbeiten (vielleicht mit einigen Modifikationen) könnte)

Die Verwendung von Tessellations-Shadern ist eine andere Technik, sehr neu, seit OpenGL 4.x herausgekommen ist, meiner Meinung nach könnte es die beste sein, aber wir reden über Planet Rendering, wir stoßen auf ein Problem, das andere Methoden sehr einfach handhaben können und es geht um Präzision.

Wenn Sie nicht möchten, dass Ihre Genauigkeit 1Km zwischen den Vertices liegt, wählen Sie Tessellation-Shader. Das Problem mit wirklich großen Terrains bei dieser Methode ist, dass Jitter irgendwie schwer zu lösen ist (oder zumindest für mich, da ich neu in Tessellations-Shadern bin).

Geomipmapping ist eine großartige Technik, nutzt den Quadtree und hat einen niedrigen projizierten Pixelfehler, aber für das planetare Rendering müssen Sie mindestens 16+ Detailebenen einstellen, das heißt, Sie benötigen (zum Sticken pourposes) einige zusätzliche Patches, um verschiedene Levels zu verbinden und sich um das Level deines Nachbarn zu kümmern, das kann mühsam zu lösen sein, besonders mit 6 Terrain-Faces.

Es gibt eine andere Methode, die sehr spezifisch ist: "Projective Grid Mapping for Planetary Terrain" ausgezeichnet für Visualisierung, hat aber seine Nachteile, wenn Sie mehr wissen möchten, gehen Sie auf den Link.

Probleme:

  • Jitter : Die meisten heutigen Grafikprozessoren unterstützen nur 32-Bit-Gleitkommawerte, die bietet nicht genügend Präzision für die Manipulation großer Positionen in planetarischem Terrain. Der Jitter tritt auf, wenn der Betrachter hineinzoomt und rotiert oder sich bewegt. Dann beginnen die Polygone vor und zurück zu springen.

    Die beste Lösung dafür ist "Rendering Relative to Eye Using" die GPU "-Methode. Diese Methode wird in dem Buch" 3D Engine Design für Virtual Globes "(Ich bin mir sicher, dass Sie es im Internet finden können aswell) in dem du grundsätzlich alle deine Positionen einstellen musst verdoppelt sich auf der CPU (Patches, Clipmaps, Objekte, Kaugummi, Kamera, etc.) und dann MV ist um den Betrachter zentriert, indem Sie seine Übersetzung einstellen zu (0, 0, 0) T und die Doubles sind in einem Fixpunkt kodiert Darstellung unter Verwendung der Bruchteil (Mantissen) Bits von zwei Schwimmern, niedrig und hoch nach einer Methode (lesen Sie unter Verwendung von Ohlariks Implementierung und die DSFUN90 Fortran-Bibliothek).

    Obwohl der Vertex-Shader nur zwei zusätzliche benötigt Subtraktionen und eine Addition, GPU RTE verdoppelt die Menge an Vertex Pufferspeicher für Positionen erforderlich. Dies verdoppelt sich nicht unbedingt die Speicheranforderungen, sofern nicht nur Positionen gespeichert sind.

  • Tiefenpufferpräzision : Z-Kampf.Da wir sehr große Terrains rendern, in diesem Fall: Planeten, muss der Z-Puffer SEHR GROSS sein, aber es spielt keine Rolle, welche Werte Sie für znear und zfar setzen, es wird immer Probleme geben.

    Da der Z-Puffer von einem Gleitkomma-Intervall abhängt, ist es auch linear (obwohl perspektivische Projektion nichtlinear ist) Werte in der Nähe das Auge leidet unter Z-Kämpfen, weil der Mangel an Präzision 32-Bit Schwimmer haben.

    Der beste Weg, um dieses Problem zu lösen, ist eine "Logarithmische Tiefe" Puffer" Ссылка

    Ein logarithmischer Tiefenpuffer verbessert die Tiefenpufferpräzision für entfernte Objekte mit einer logarithmischen Verteilung für zscreen. Es Trades Präzision für nahe Objekte für Präzision für entfernte Objekte. Da wir mit einer LOD-Methode rendern, benötigen ferne Objekte weniger Präzision, weil sie weniger Dreiecke haben.

Wichtig zu erwähnen ist, dass alle aufgelisteten Methoden (mit Ausnahme des projektiven Gitters) sehr gut sind, wenn man Physik (Kollisionen meistens) wegen der Quadtree-Basis macht, das ist obligatorisch, wenn man ein Spiel machen will.

Abschließend, überprüfen Sie einfach alle verfügbaren Optionen und gehen Sie für die, die Sie sich wohler fühlen, CDLOD macht meiner Meinung nach eine großartige Arbeit. Vergessen Sie nicht, die Jitter- und Z-Buffer-Probleme zu lösen, und am wichtigsten: viel Spaß dabei!

Weitere Informationen zu LOD finden Sie unter diesem Link .

Eine vollständige Darstellung des Sphärisierens eines Würfels finden Sie in diesem Link .

Eine bessere Erklärung zum Lösen von Jitter- und Z-Puffer-Genauigkeiten finden Sie in diesem Buch .

Ich hoffe, Sie finden diese kleine Rezension nützlich.

    
nosmirck 20.06.2013, 05:04
quelle