spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Sebastian Müller«

Jedoch frage ich mich, ob man das Terrain nicht im VertexShader erstellen kann.

Ja, kann man...

Zitat von »Sebastian Müller«

Mann liest einen Pixel mit Tex2D und transformiert den Vertex auf den jeweiligen wert.

Ja, genau so könnte man das machen...

Zitat von »Sebastian Müller«

Oder gibt es auch in D3D ein Funktion wie Tex2D?

Bin mir nicht sicher, was genau du damit meinst...

Zitat von »Sebastian Müller«

Wie klappt das mit der Kollisionen Erkennung mit der Landschaft? wenn der Spieler einen Berg hochläuft, soll er mit dem Terrain gehen.

Naja, es geht wohl um ein Terrain auf Basis einer Heighmap. In dem Fall kannst du ja die Höhe des Terrain an jedem Punkt bestimmen...

Der Ansatz scheint auch laut meinen recherchen so ziemlich mit das aktuellste zu sein (dot, bitte korrigiere mich wenn ich falsch liege!). Der Trend geht bei Terrains stark auf die GPU, was durch Vertex-Texture Fetches ziemlich gut abgebildet wird. Interessant fand ich den Geometric Clipmaps Ansatz. Dummerweise habe ich ihn nicht 100% technisch verstanden, sonst hätte ich damit schon längst mal ein Terrain gebaut.
Was ich besonders gut an den Vertex-Texture-basierenden Lösungen finde: Verformung geht ziemlich einfach, in dem man aus der Heightmap eine dynamische Textur macht und sie beliebig zur Laufzeit anpassen kann. Das einzige was ich nicht abschätzen kann, wie sich das bei sehr großen Terrains mit mehreren Heightmaps verhält.

Ich bin ehrlich gesagt nicht wirklich über den aktuellen State of the Art im Terrain-Rendering informiert. Vector Displacement Maps scheinen mir atm wohl relativ populär (mich persönlich überzeugt das Prinzip ehrlich gesagt allerdings nicht). Aber ja, wenn man die Terraingeometrie nur zum Rendern braucht und rein auf der GPU arbeiten will, dann ist die Vertex-Texture-Fetch-basierte Lösung wohl immer noch aktuell. Heightmaps haben ihre Vorteile, sind allerdings doch auch beschränkt in ihren Möglichkeiten...

Naja, Kollisionserkennung hat eigentlich sehr wenig mit Rendern zu tun. Die Frage ist halt, wie genau die Kollisionserkennung implementiert ist. Man kann sicherlich eine schreiben, die mit Heightmaps arbeitet, aber auch wenn sie Dreiecksbasiert ist, kann man ja aus der Heightmap ein Mesh für die Kollisionsabfrage erstellen. Dieses Mesh muss ja überhaupt nichts damit zu tun haben, wie du die Landschaft renderst.

Und: Einfach ein Raster zu nehmen und die Vertexhöhen auf die Höhe aus einer Textur zu setzen macht irgendwie auch nur dann Sinn, wenn du die Vorteile ausnutzt, die sich daraus ergeben können. Denn ansonsten könntest du die Vertexe auch gleich auf die richtige Höhe setzen und würdest den Speicher für die Heightmap und die Rechenzeit für das Transformieren sparen.
Vorteile die mir spontan einfallen:
- Du kannst das selbe Raster für verschiedene Landschaftsabschnitte benutzen (wenn sie die gleiche Auflösung haben). Du musst also nur die Textur wechseln, behältst das Modell aber bei. Insgesamt dürfte das etwas Speicher sparen, weil du nicht jeden Eckpunkt immer mit 3 Koordinaten speichern musst.
- Du kannst leicht die Auflösung wechseln: Je nachdem, welches Raster du mit einer Textur zusammen benutzt, kannst du deine Landschaft mit unterschiedlichen Auflösungen rendern.

Na, die Heightmapt ist eine ganz normale Textur die gefiltert werden kann. Wenn Dreiecke kleiner dargestellt werden, als ihre Textur hätte man ja ansonsten genau das selbe Problem. Du nimmst also ein Mesh, das niedriger Aufgelöst ist, als die Heightmap, aber trotzdem passende Texturkoordinaten hat. Die Folge ist, dass dann eben nicht alle Texel berücksichtigt werden, aber das ist ja im Grunde gerade die Detailreduktion.

Und ja, du kannst als Mesh so ziemlich jedes 3d Modell nehmen. Der Vertex-Shader wird ja einfach nur die Z-Koordinate jedes Vertex auf die Höhe setzen, die er anhand der Texturkoordinate des selben Vertex aus der Heightmap gelesen hat. Das ist so zunächst einmal komplett unabhängig von der Geometrie des Modells, aber es machen natürlich nicht alle Modelle Sinn.
Ein gleichmäßiges Raster wäre halt das naheliegenste. Man könnte aber auch zum Rand hin entweder mehr oder weniger Vertexe haben, um besser einen sauberen Übergang zwischen verschiedenen Detailstufen zu erreichen.

Einen Quadtree brauchst du dabei nicht unbedingt, es liegt halt ein wenig daran, wie du es umsetzen möchtest.

Ich hatte gerade noch eine interessante Idee. Nicht das ich mich wirklich intensiv mit Terrain Rendering beschäftigen würde, aber es klingt trotzdem ganz nett.


Die Grundidee ist ja, dass man in der Nähe der Kamera viele Details haben möchte, und im Hintergrund wenige. Dafür kann man eine große Heightmap in verschiedene Teile aufteilen, die jeweils in verschiedenen Detailstufen vorliegen. Je nachdem wie weit ein Teil von der Kamera entfernt ist, wird es dann mit mehr oder weniger Details gerendert.


Nehmen wir jetzt an, wir würden den Ansatz mit der Heightmap in der Textur, die im Vertexshader ausgelesen und als Höhe für die Vertexe benutzt wird. Wenn unser komplettes Terrain in eine einzige Textur passt, müsste folgendes funktionieren:

Man erstellt ein spezielles Raster (als Mesh), dass in der Mitte eine sehr hohe Dreiecksdichte hat, zum Rand hin aber eine geringe. Dieses Mesh rendert man jetzt immer an der Kameraposition, so dass automatisch in der Nähe der Kamera viele Dreiecke sind, in der Entfernung aber nur wenige. Durch einen passenden Offset (basierend auf der Kameraposition) verschiebt man beim Rendern aber die Texturkoordinaten, so dass immer der passende Teil der Landschaft dargestellt wird. Durch entsprechende Filtereinstellungen würde alles außerhalb des Terrains die Höhe 0 bekommen, also eine flache Ebene.
Dadurch wird das komplette Terrain-Rendering ziemlich simpel: Man muss nur noch ein Modell mit einer Textur rendern, hat aber trotzdem ein LOD-System und immer eine konstante Dreieckszahl, unabhängig von der Größe oder Auflösung des Terrains (entscheidend ist halt das Mesh, das man passend wählen muss). Damit die Vertexe nicht über das Terrain "schwimmen" muss man eventuell noch einen zusätzlichen Offset einbauen.

Ein paar Nachteile hat das ganze natürlich auch: Das LOD System ist darauf ausgelegt, dass die Kamera "auf" der Landschaft steht, für Flugsimulationen will man vermutlich andere Aufteilungen haben. Außerdem möchte man normalerweise in flachen Bereichen wenige, in detailreicheren Bereichen dagegen mehr Dreiecke haben (damit die Form von weit entfernten Bergen trotzdem noch gut wiedergegeben wird). Das wäre mit dieser Technik unmöglich, da sie ja gerade unabhängig vom konkreten Terrain sein soll.

Falls man Probleme mit der Texturgröße bekommt, wäre auch ein mehrstufiges System denkbar: Ein Terrain für die Nähe und eines für die Entfernung, das analog funktioniert, aber mit einer niedriger Aufgelösten Textur (die aber die selbe Größe hat und damit eine größere Landschaft abdecken kann).

Den Hauptvorteil sehe ich darin, dass man die beschriebene Technik sehr schnell (ein Nachmittag oder so) implementieren kann. Wenn man nicht richtig viel Zeit ins Terrain-Rendering investieren will, sondern einfach nur ein Terrain, das funktioniert, aber nicht unbedingt immer optimal ist, haben möchte, könnte das durchaus etwas sein.