ZFX + Developia

Hi

Ich versuche nun seit ein paar Tagen, Geometry Clipmaps (GPU-based) zu implementieren. Bisher leider ohne Erfolg. Die Informationen zur gpu-based-Variante im Netz sind leider sehr spärlich und zu DirectX 10 hab ich überhaupt kein Beispiel / Tutorial gefunden. Kennt jemand von euch ein Sample dazu, das in DX10 implementiert wurde? (idealerweise mit source...)
Ansonsten werde ich hier mal ein bisschen über DX10 lästern und meine Probleme posten... ;)

1. Problem: DX10 mag irgendwie keine 16-bit 2D-Vertices (DXGI_FORMAT_R16G16_SINT, DXGI_FORMAT_R16G16_FLOAT oder ähnliche), d.h. ich krieg nur Null-Vectors im Vertex-Shader. Mit 32-bit 2D-Vertices klappts allerdings... (input-layout korrekt gesetzt, im Shader half2 als input gesetzt)

2. Problem: Hab irgendwo gelesen, dass Texture-Lookups (per TexObj.Load()) im Vertex-Shader genauso schnell sind wie im Pixel-Shader. Nun frag ich mich: würde es Sinn machen, direkt im Vertex-Shader beim Geomorphing die Normalenvektoren zu generieren, oder entsteht durch die Load-Funktion und Floating-Point-Ungenauigkeit zu viel Aliasing (Flimmern)?

3. Problem: Kann ich bei der Generierung der Clipmaps aus der Original-Heightmap (in voller Auflösung) samplen oder führt dies auch zu Flimmern? Im Beispiel von Hoppe (2004) wird ja das Terrain vom coarsest zum finest Level hochgesampelt und jeweils ein Residuum addiert. Ich möchte aber eine Heightmap haben (die dauerhaft im Videomemory ist) und daraus die Clipmaps berechnen...

4. Problem: Wie lese ich die Terrainhöhe an der Stelle (x,y) am besten aus? (die Geometrie existiert ja erst nach dem Vertex-Shader...)

5. Brauche ich PSSetShaderResources resp. VSSetShaderResources wenn ich die Texturen via ID3D10Effect::GetVariableByName(...)->...->SetResource(...) setze? Was ist schneller resp. sinnvoller?

keepcoding hat geschrieben:1. Problem: DX10 mag irgendwie keine 16-bit 2D-Vertices (DXGI_FORMAT_R16G16_SINT, DXGI_FORMAT_R16G16_FLOAT oder ähnliche), d.h. ich krieg nur Null-Vectors im Vertex-Shader. Mit 32-bit 2D-Vertices klappts allerdings... (input-layout korrekt gesetzt, im Shader half2 als input gesetzt)

half dürfte unter SM 4+ garkein gültiger Datentyp sein … float2 wird funktionieren.

keepcoding hat geschrieben:3. Problem: Kann ich bei der Generierung der Clipmaps aus der Original-Heightmap (in voller Auflösung) samplen oder führt dies auch zu Flimmern? Im Beispiel von Hoppe (2004) wird ja das Terrain vom coarsest zum finest Level hochgesampelt und jeweils ein Residuum addiert. Ich möchte aber eine Heightmap haben (die dauerhaft im Videomemory ist) und daraus die Clipmaps berechnen...

Wenn sich dein Grid über die Textur bewegt, wird es flimmern … aber du kannst ja auch explizit ein Mip-Level zum Laden aussuchen – da sich Mip-Maps auf der GPU generieren lassen, bleibt es GPU-based.

keepcoding hat geschrieben:4. Problem: Wie lese ich die Terrainhöhe an der Stelle (x,y) am besten aus? (die Geometrie existiert ja erst nach dem Vertex-Shader...)

Wie jetzt, im Programm selber oder in einem Shader?

Für den Rest habe ich keinen Senf :)

Gruß, Ky

Hab das GPU-basierte Geometry Clipmaps gerade vor einigen Tagen fertig implementiert mit D3D10/11 und hier und da ein wenig verbessert. Ist allerdings Teil einer Abschlussarbeit und daher kann ich das erst alles freigeben, wenn die Abgabe erfolgt ist und das ganze bewertet wurde.

Hier aber ein paar Tipps: Du brauchst überhaupt keine Vertices, es langt ein Index Buffer (Hoppe weißt ja schon im Artikel drauf hin, wie das funktioniert) und natürlich einen Instance Buffer für die Blöcke. Wenn du nur Indices verwendest sparst du dir auch hunderte Zeilen "For-Schleifen-Code" weil du nur die Indices erzeugen musst (was allerdings immer noch jede Menge solcher Zeilen Code bedeutet, allerdings viel weniger. Man beachte auch, dass es mittlerweile Cut Indices gibt (0xFFFFFFFF), d.h. du kannst mit einem DrawStriped-Aufruf jede Menge unabhängiger Strips zeichnen. Auf diese Weise brauch ich für das Terrain nur drei Draw-Aufrufe, die alle auf den selben Index Buffer und Instance Buffer zugreifen.

Das ganze ist übrigens mit nichten in ein paar Tagen implementiert. Rechne eher mit ein paar Wochen, denn so einfach wie sie es darstellen ist es bei weitem nicht und man stößt an allen Ecken und Kanten auf fehlende und/oder falsche Detailinformationen. Auch bestimmte vorgeschlagene Parameter passen so gar nicht. Das ist ganz schön viel arbeit, die du dir mit diesem Artikel aufhalst. Auf die Art und Weise wie Hoppe das implementiert, kann die Heightmap übrigens nur 8 Bit haben, was nicht mehr Zeitgemäß ist. Mit D3D10 und der Integerarithmetik lässt sich das aber leicht beheben.

Mir sind bei der Implementierung auch Fehler im Treiber von ATI aufgefallen. Vertextexturausmaße dürfen nur ein Vielfaches von 64 sein (bei FLOAT, es gehen bei den HD5000er-Karten auch andere Formate, aber die hab ich noch nicht ausprobiert, da ältere Karten das nicht können). Ansonsten versaut der Treiber dir die Texturen sobald du sie aktualisierst. Außerdem scheint man nicht mit den neuen RWTextures in die Vertextexturen schreiben zu können. Ich muss aber noch testen, ob das nicht ein Fehler von mir ist und auf einer nVidia-Karte auch nicht geht. Jedenfalls nervt das tierisch weil der Code für das Update der torodialen Vertex Texturen über Render-to-Texture richtig übel ist. Da wirst du einige Nächte dran sitzen.

Alles in allem würde ich dir zu einem anderen Ansatz für dein Terrain raten. Ich weiß nicht für was du das brauchst, aber wenn du ohnehin all deine Höhendaten auf die Grafikkarte schaufeln willst, sind Geometry Clipmaps allein schon konzeptionell der völlig falsche Ansatz. Dann bräuchtest du nämlich keine Clipmaps. Das ergäbe schlicht keinen Sinn. Anscheinend passen deine Daten auch ohne Probleme in den VRAM, wie wärs denn mit etwas wie das hier, was qualitativ ne ganze Ecke besser ist, als Geometry Clipmaps: http://wwwcg.in.tum.de/Research/Publications/Terrain

edit: Achja, auf Geometry Clipmaps sowie den angewandten Kompressionsalgorithmus hält Microsoft Patente. Eigentlich ein Unding dann so einen Artikel ohne auch nur eine Notitz dessen in einem Buch wie GPU Gems 2 zu veröffentichen.

Danke für eure Tipps!

@Krishty: float2 geht auch nicht.
Mip-Level auswählen beim Samplen klingt gut!
Ich mein im Programm selbst die Höhe auslesen, im Shader ist dies natürlich kein Problem. Aber wenn ich im Programm die Höhe wissen will, dann müsste ich doch die Heightmap-Daten noch extra abspeichern, damit die CPU darauf zugreifen kann...

@Unknown GER: Und ich dachte schon ich sei einfach zu dumm das Paper richtig zu lesen :) Aber allem Anschein nach ist es doch recht aufwändig. Gereizt an diesem Ansatz hat mich halt, dass dieses LOD-System praktisch nur Vorteile hat (u.a. sehr gut skalierbar, dynamisch und sehr schnell ist).
Dass Geometry Clipmaps für mich keinen Sinn macht versehe ich allerdings nicht ganz: Eine Heightmap passt prima in den VRAM, auch wenn diese 8k*8k gross ist! Was aber ist mit den Normalenvektoren und all dem anderen Zeugs? Ich mein ein Vertex an sich braucht ja schon 12 Byte. Ausserdem: mit irgendeinem LOD-System muss ich ja den Vertex-Shader entlasten!
Werde mir mal das Paper ansehen.

Gibt es noch andere Meinungen zum Thema Geometry Clipmaps?? Ich überleg mir echt es sein zu lassen und wieder sowas wie Geo-Mipmapping zu verwenden...


[EDIT] Da ist mir noch was eingefallen zum Thema "es braucht keine Vertices": Mag sein, aber ich hab das so gelöst, dass ich einen grossen Index- und einen grossen Vertex-Buffer verwende (der mit sechs Zeilen Code initialisiert ist), den ich einmal pro Frame setze (also keinen allzu grossen Traffic verursacht, vorausgesetzt, die Clipmap ist nicht grösser als 1023x1023).

keepcoding hat geschrieben:@Krishty: float2 geht auch nicht.

Hmm, ich habe beide Formate schon verwendet und keine Probleme gehabt … das eine habe ich sogar ebenfalls für Terrain angewandt. Vielleicht ist das Input-Layout ja doch fehlerhaft, oder die sechs Zeilen, die den Vertex-Buffer erzeugen …

keepcoding hat geschrieben:Eine Heightmap passt prima in den VRAM, auch wenn diese 8k*8k gross ist!

Äh ja, aber der ist ja nicht ausschließlich für deine Heightmap da …

keepcoding hat geschrieben:Aber wenn ich im Programm die Höhe wissen will, dann müsste ich doch die Heightmap-Daten noch extra abspeichern, damit die CPU darauf zugreifen kann...

Dafür gibt es Staging-Texturen, damit kannst du dir die Daten von der GPU holen ohne sie beim Rendern zu stören … wenn deine Heightmap nicht allzu variabel ist, wäre eine Kopie im RAM aber wohl einfacher.

keepcoding hat geschrieben:Da ist mir noch was eingefallen zum Thema "es braucht keine Vertices": Mag sein, aber ich hab das so gelöst, dass ich einen grossen Index- und einen grossen Vertex-Buffer verwende (der mit sechs Zeilen Code initialisiert ist), den ich einmal pro Frame setze (also keinen allzu grossen Traffic verursacht, vorausgesetzt, die Clipmap ist nicht grösser als 1023x1023).

Wenn es in sechs Zeilen geht kannst du dir die plus alles, was mit Vertex- / Indexbuffern und Input-Layouts zu tun hat, auch noch sparen und SV_VertexId benutzen (jaja, ich bin Fan) – aber ob das auch noch bei Implementierungen wie denen im Paper effizient ist, musst du selber bestimmen … vielleicht kann das Unknown GER einschätzen?

Dass D3D10+ kein Ressource-Limit kennt heißt jedenfalls noch lange nicht, dass man nach Belieben den VRAM vollpumpen sollte.

Äh ja, aber der ist ja nicht ausschließlich für deine Heightmap da …

äh 8k x 8k ist ein ganz schön grosses Terrain und damit eher selten, und naja, 64 MB ist ja keine Datenmenge bei heutigen VRAMs.

Irgendwie klappt das nicht so richtig mit der Interpolation zwischen zwei LOD-Stufen (siehe T-Junctions).



Im Vertex-Shader interpoliere ich wie folgt zwischen zwei Mip-Stufen der Heightmap:
Sollte doch eigentlich gehen, wenn linear aus der kleineren Mip-Stufe gesampelt wird...
Ach ja, das alpha.x sollte korrekt sein, d.h. ist am äusseren Rand 1.

Wie es sind nur sechs Zeilen? Eine Clipmap besteht nicht einfach aus N*N Vertices, sondern aus einer ganzen Reihe verschiedener Strukturen. Da wären zum einen die einfach zu konstruierenden Blöcke bzw. ein Block, allerdings auch noch die degenerierten Dreiecke, ein Ring für den feinsten Level, vier verschiedene L-Stücke und die Ring-Füllsel. Um die alle geschickt zu erzeugen bedarf es einer ganzen Menge Code. Zumal möchte man die ja alle so konstruieren, dass man alles mit möglichst wenigen Draw-Aufrufen rendern kann und evtl. sogar mit der gleichen Topologie.

Video von 7 15x15-Clipmap-Levels ohne Blöcke

Nur so können sich die Clipmaps jeweils um eine Einheit ineinander verschieben, was für das Streaming der neuen Höhendaten unabdingbar ist. Und genau das ist der Punkt. Die ganze Datenstruktur der Clipmaps ist darauf aufgebaut, neue Höhendaten auf diese Weise effizient in den VRAM zu streamen. Wenn du ohnehin schon alle Höhendaten im VRAM hältst, kannst du dir die ganze komplexe Clipmap-Level-Struktur sparen und auch die Interpolation am Rand ist einfacher. Dann brauchst du einfach nur ein statisches Mesh das scheinbar so aussieht, als bestünde es aus Clipmaps, sprich, je weiter die Vertices vom Zentrum entfernt sind, desto größer ist der Abstand zu einander. Die ganze Verschieberei um Eins in den einzelnen Levels bei Bewegung kannst du dir sparen weil du nichts mehr streamen musst. Das hat dann aber nichts mehr mit Clipmaps zu tun und dürfte schnell und einfach zu implementieren sein. ;)

edit: Fürs Interpolieren empfehle ich dir den Alpha-Wert zu visualisieren indem du z.B. deine Vertices mit ihm einfärbst. So erkennst du sehr schön ob da alles stimmt. Vor allem wenn du eine 1 und eine 0 ganz speziell einfärbst, dass sie hervorstechen. Schnell ists nämlich mal passiert, dass bei kleinen Clipmapgrößen am Rand des feinen Levels der Alpha-Wert zwar 1 ist, aber am inneren Rand des gröberen Levels > 0 obwohl er dort 0 sein muss. Außerdem solltest du einfach mal so tun, als seien die gröberen Vertices (sprich die Höhe) alle 0 oder ein sehr hoher Wert, so kannst du sehen ob er die Positionen wirklich interpoliert. Zusätzlich musst da abhängig von der Position eines Vertex (gerade-ungerade, ungerade-gerade, ungerade-ungerade und gerade-gerade) unterschiedlich interpolieren.

edit2: Und das Verfahren hat mitnichten nur Vorteile, auch wenn die Autoren das so rüberbringen. Schau dir mal das Video von dem anderen Paper an, das ich dir empfohlen habe. In der zweiten Hälfte siehst du die selbe Puget Sound 16kx16k Höhenkarte wie die aus dem Demoprogramm von den Geometry Clipmaps. Da siehst du dann sehr gut, was man eigentlich aus der alles rausholen kann und dass Geometry Clipmaps ziemliche Defizite bei der Detaildarstellung haben. Ich würde sie jedenfalls nicht mehr verwenden, es sei denn, es ginge um eine GIS-Anwendung bei der man immer einen gehörigen Abstand zum Boden hat und somit hochfrequente Details wie Ufergefälle irrelevant sind.

Thx für die Erklärungen.
Cooler Video, zeigt sehr schön wie die Blocks verschoben werden.
Werde nun doch nicht Clipmaps implementieren, macht in der Tat keinen Sinn, wenn alles im VRAM ist.

Wie es sind nur sechs Zeilen?

Ja eben, ich hab halt einen Vertex-Buffer der Grösse NxN erstellt und dann die Indices aller Blöcke (MxM, Mx2, L-Shape und Degenerated) in einen Index-Buffer. Dadurch brauchts nur einen VB und die ganze Arbeit reduziert sich auf das Erstellen der Indices. Braucht zwar etwas mehr Speicher so, deshalb muss aber während dem Rendern des Terrains kein einziger Index- oder Vertex-Buffer gewechselt werden.

Zusätzlich musst da abhängig von der Position eines Vertex (gerade-ungerade, ungerade-gerade, ungerade-ungerade und gerade-gerade) unterschiedlich interpolieren.

Das scheint das Problem zu sein, denn die alpha-Werte hab ich mal visualisiert, und die stimmen.

Ich kriegs nicht hin, sieht jemand den Fehler beim Upsampling der tieferen Mip-Stufe??
g_ClipmapPos.z enthält das Grid-Spacing (also in der höchsten Detailstufe 1, dann 2, 4, etc.).
g_TexelSize bleibt konstant (muss auch so sein, denn durch WorldPos * g_TexelSize werden die Texturkoordinaten in 0..1 gemappt).
Ein Point-Sampler müsste auch völlig ausreichen, wenn die Texturkoordinaten stimmen würden (da Vertexposition & Texelposition exakt übereinstimmen sollten).

Geht SampleLevel überhaupt im Vertex Shader? Auf die Schnelle würde ich behaupten es klappt nur Load, kann mich aber auch irren.

Unknown GER hat geschrieben:Geht SampleLevel überhaupt im Vertex Shader? Auf die Schnelle würde ich behaupten es klappt nur Load, kann mich aber auch irren.

Richtig – alles, was mit Sample anfängt, ist im VS nicht verfügbar.

Ich finde es sowieso immer fantastisch wenn keine Fehlermeldungen oder Problembeschreibungen gepostet werden, sondern nur „Ich kriegs nicht hin, sieht jemand den Fehler??“ ;)

Bevor du sowas behauptest, solltest du vllt erst mal in die Doku von HLSL schauen. SampleLevel ist ab Shader Model 4.0 verfügbar, auch im Vertex-Shader.

Was soll ich denn sagen als Fehlermeldung?? Es gibt keine Fehlermeldung, ausser dass die Vertices nicht korrekt gemorpht werden, was an dem Texture-Lookup aus der niedrigeren Mip-Stufe liegt! Ein Bild hab ich ja schon gepostet.

zfx ist auch nicht mehr das, was es mal war...

Nana, ganz so schnell musst du ZFX jetzt auch nicht verurteilen :-) Worauf Krishty sich vermutlich bezog ist eine allgemeine Tendenz. Oftmals (und gerade in DX–verwandten Themen) sind die Fehlerbeschreibungen verdammt ungenau - keine (HLSL–) Compiler–Fehler, kein DXDebug–Output. Es sieht fuer mich aber eher weniger so aus als sei das hier der Fall, allerdings sagt mir das Thema auch herzlich wenig.

Sachte sachte, mit solchen Behauptungen wirst du nicht großartig weiterkommen, weil es jedem vergehen wird, dir noch etwas konstruktives zu antworten. Gerade Krishty gibt teils phänomenale Antworten - und das fix und ausführlich. Wegen solchen Leuten bin ich erst wieder aktiv hier, weil ich wirklich das Gefühl hab, etwas lernen zu können und das einige hier wirklich Ahnung von dem haben, was sie sagen. Mit den Clipmaps hab ich das erste mal wirklich was mit Shadern und Direct3D gemacht und es hat zwar etwas gedauert, aber ich denke ich hab in den letzten zwei Monaten verdammt viel dazu gelernt und bekam immer bei meinen Anfängerfragen geholfen.

Ich hab nicht umsonst davor gewarnt, Geometry Clipmaps auf die leichte Schulter zu nehmen. Da spielen auch jede Menge krypitische Parameter eine Rolle, die man nicht versteht, wenn man nicht gerade selbst mitten in der Implementierung ist. Es bringt also nichts, hier ein paar Zeilen HLSL-Code zu posten und zu fragen wo der Fehler ist. Ich glaube nicht, dass sonst hier das noch implementiert hat. Nicht umsonst findest du im Netz keinen Source Code dazu, bzw. den einen, den man findet, ist äußerst "suboptimal". Ich war auch einst an dem Stadium, wo meine Clipmaps so aussahen, dass sie nur jedes zweite Vertex mit dem nächsten Clipmap übereinstimmten. Alles im allem hab ich an einigen Stellen werkeln müssen, um das dann hinzubekommen. Ich würde dir dazu raten mal mit InkScape oder so dir den Übergang zwischen zwei Clipmaps aufzuzeichnen - also das Gitter von oben. Und dann zeichnest du in einer anderen Ebene die Texturpixel ebenfalls als Gitter drüber. Erst so konnte ich mir darüber im klaren werden ob und wo man Offsets von -1/+1 braucht, und welche Pixel einer Clipmap genau den Pixeln der nächstgrößeren/kleineren Clipmap entsprechen. Das hat in meinem Fall sogar zu einer Verbesserung des Verfahrens geführt, weil ich nun die gleiche Übergangsqualität mit bilinearer Filterung hinbekomme, anstatt den Kobbelt-1996 zu nehmen.

keepcoding hat geschrieben:Bevor du sowas behauptest, solltest du vllt erst mal in die Doku von HLSL schauen. SampleLevel ist ab Shader Model 4.0 verfügbar, auch im Vertex-Shader.

Ohja – ich vergaß, dass man ja keinen Gradienten mehr braucht wenn eh nur ein bestimmtes Mip-Level gesampled wird. Sorry.

keepcoding hat geschrieben:zfx ist auch nicht mehr das, was es mal war...

Jaja, in der Zerbie-Ära war alles besser. Sieh es so: Wenn ich aufhöre, mir in wahllosen Threads am Post-Counter rumzuspielen, ist ZFX ab morgen nochmal zehn Prozent weniger von dem was es ist, egal, was das auch sei … spätrömische Demenz, oder so …

Ich schäme mich dafür, dass ich total halbarschig bei der Sache war und werde jetzt the fuck upshutten. Als Zeichen meiner Reue trage für den Rest des Tages den Socially Awkward Penguin. Und jetzt hör zumindest auf den anderen Typen, der dir helfen will, und mach es richtig oder garnicht, aber nicht mit in sechs Zeilen erzeugten Indices …

Das ist wie Kaffeesatz lesen...
Ich kann addieren und subtrahieren zu den Texturkoordinaten was ich will, aber das passt nie. Hab die Heightmap in höchster Auflösung drübergelegt und mit dem Ergebnis verglichen: Immer liegt das Ergebnis um ein paar Pixel daneben (links wie es ist, rechts, wie es sein sollte):

Nagut, gib mir noch eine Chance:

Wie rechnest du Weltkoordinaten in Texturkoordinaten um?

Warum benutzt du SampleLevel() statt Load()? (Du interpolierst ja zwischen zwei Randtexeln von Hand, also dürfte garkeine Filterung mehr nötig sein)

Warum ist dein Raster auf dem oberen Screenshot eine Reihe zu klein? (63 statt 64 Vertices)

Wenn die Ränder nämlich nicht passen, würde ich sagen, dass die Texturkoordinaten falsch berechnet werden (63 Vertices greifen auf 64 Höhenwerte zu und sind deshalb alle interpoliert, Interpolation ist zwischen Mip-Levels nicht konsistent).

Danke für deine Hinweise. Hoffe, du hast mich nicht falsch verstanden. Ich finds super, wenn du auf viele Threads antwortest. Lieber mal eine falsche Antwort als gar keine!

Warum benutzt du SampleLevel() statt Load()?

Stimmt, hab ich jetzt geändert.

Warum ist dein Raster auf dem oberen Screenshot eine Reihe zu klein? (63 statt 64 Vertices)

Geo Clipmaps sind von der Grösse (2^n - 1), also z.B. 63 ;) Hab jetzt aber die Geometrie angepasst, ich brauch gar nicht so eine komplizierte Struktur...




nachdem x Stunden probieren nichts gebracht hatten, hab ich mir das Problem nochmals aufgezeichnet und ein bisschen überlegt. Ich musste bloss eine Zeile im Vertex-Shader anpassen, und nun klappts! :D
Anstelle der WorldPos muss man die relative Position des Vertex im Gitter nehmen und davon den Modulo.

Werde nun nicht Clipmaps nach dem Paper von Hoppe implementieren, sondern ein etwas abgewandeltes Verfahren... mal sehen ob das was wird.


[EDIT] hab mich wohl doch etwas zu früh gefreut: Da ich die Höhenkoordinate ohne Filterung lade (ausser bei der höchsten Detailstufe), flimmert das Terrain nun ganz schrecklich, also die Vertices springen hin und her wenn sich die Kamera bewegt^^
Wird wohl doch nix mit einem Camera-Centered-Grid...

Ohne irgendwas vom eigentlichen Topic gelesen zu haben: bei solchen Dingen würde es sich doch anbieten, das Grid nur in fest definierten Schritten (vielfache von Pixeln in Weltkoordinaten) zu bewegen, dann müsste das auch Camera-centered ohne Sprünge klappen.

Dito … ich dachte, das sei bei sowas eh Standard.

Warum lädst du das höchste Detaillevel mit Filterung? Ist die Heightmap geringer aufgelöst als das Grid?

Warum lädst du das höchste Detaillevel mit Filterung? Ist die Heightmap geringer aufgelöst als das Grid?

Hab mich wohl verschrieben. Ich wollte sagen, dass nur im höchsten Detaillevel die Höhenkoordinate korrekt berechnet wird, denn eigentlich müsste man bei allen anderen Levels 3 zusätzliche Lookups machen...

Habs jetzt so gelöst, wie ihr vorgeschlagen habt. Klappt soweit nicht schlecht: Einzig die Normal-Map wird jetzt nicht mehr smooth von einem zum nächsten Level gemorpht.

Kann aber auch daran liegen, dass noch irgendwas falsch ist mit den Normals. Der Unterschied von der höchsten Detailstufe zum 2. Level ist doch etwas markant:





Hab aktuell 1 + 4 Texture Lookups für die Höhenwerte und 4 + 16 für die beiden Normalenvektoren, macht total 25 Texture-Lookups im Vertex-Shader... irgendwie nicht sehr performant. Geht das irgendwie schneller?