spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ja genau. Hätte ich ein Wochenende frei würde ich mal eine TechDemo schreiben um das zu testen. Aber probier es ruhig einmal aus, die Ergebnisse würden mich echt interessieren.

(Das ist auch übrigens ein gutes Beispiel für das Entkoppeln des Renderns und der Physikberechnung. Physik sollte ja nicht von der aktuellen Betrachterposition abhängen und das Mesh das zum Rendern benutzt wird, hat nicht so richtig viel mit einem Kollisionsmesh zu tun.)

Naja, eine Zeile um die Variable im Shader zu setzen, eine Zeile um die Variable im Shader zu deklarieren und eine Zeile im Shadercode um die Koordinaten zu verschieben. Das sollte nicht schwer sein.
Dann wird das Terrain allerdings "schwimmen", was man aber durch eine geschickte Modulo-Rechnung ausgleichen können sollte. Letztendlich werden das auch nur 1-2 Zeilen Shadercode sein, aber darum kann man sich ja später kümmern.

Das mit dem konstanten Raster, das die Höhen aus der Heightmap samplet, hatte ich vor ein paar Jahren mal implementiert.

Wenn ich mich recht erinnere muss man darauf achten, dass das Raster immer an Pixeln der Heightmap ausgerichtet ist (weil das Terrain in der Entfernung sonst unheimlich wabert wenn die Vertices über Anhöhen gleiten). Das ist, was Jonathan mit "schwimmen" meint. Dann bekommt man aber sofort ein Popping-Problem, wo Details in der Entfernung immer dann aufplöppen, wenn man eine Rasterlinie überquert.

Letztendlich muss man also die höhere Dreiecksdichte mit Mip-Levels der Heightmap kombinieren, damit die Heightmap niemals höhere Frequenz hat als das Dreiecksnetz das drübergelegt ist. Da habe ich dann nicht mehr weitergemacht.

Zitat von »Krishty«

Letztendlich muss man also die höhere Dreiecksdichte mit Mip-Levels der Heightmap kombinieren, damit die Heightmap niemals höhere Frequenz hat als das Dreiecksnetz das drübergelegt ist. Da habe ich dann nicht mehr weitergemacht.

Ah, das klingt cool

Wie zufrieden warst du denn ansonsten so damit? Kriegt man damit wirklich ein Terrain mit nur einem Drawcall gut gerendert? (Mit ein bisschen tricksen müsste man es auch hinkriegen, dass nur Dreiecke gerendert werden, die die Kamera wirklich sehen kann. Das Mesh würde sich dann also auch mitdrehen.)

Für meine Zwecke war es ausreichend. Perfektion erreicht man damit wahrscheinlich nicht; wenn einen das Aufplöppen der Details in der Ferne nicht stört (oder das Terrain schön regelmäßig ist), kriegt man damit solide Ergebnisse hin. Und das, wie du sagtest, in nur einem Draw Call.

Aber das mit dem Modulo muss UNBEDINGT rein; sonst macht einen das Wabern und Schwimmen wahnsinnig. Ohne sollte man es garnicht erst versuchen.

Dürfte interessanter werden, wenn das nächste Direct3D Paging erlaubt (und damit quasi-unbegrenzt große Heightmaps).

Du musst, weil Vertices schließlich nicht auf dem Bildschirm liegen, entweder auf die Filterung verzichten (tex2Dlod()) oder die Koeffizienten nach Blickrichtung selber berechnen (tex2Dgrad()).

tex2D() benutzt die Bildschirmkoordinaten der Pixel um zu berechnen, welches Mip-Level benutzt werden soll und wie z.B. die anisotropen Texturfilter gefüttert werden sollen. Im Vertex Shader hast du aber keine Bildschirmkoordinaten, darum kannst du die Funktion da nicht benutzen.

Du musst dem Sampler also selber mitteilen, welches Mip-Level er im Vertex Shader zu benutzen hat. Das machst du, indem du tex2Dlod() aufrufst.