Hallo Gemeinde,

ich bin neu auf dem Gebiet der Programmierung mit OpenGL und bin an einen Punkt gelangt, wo ich nicht ohne Hilfe weiterkomme. Dabei geht es um folgendes:

Ich habe eine BMP, in deren Größe ich ein Polygon-Gitter mit Hilfe von TRIANGLE-STRIP erzeugt habe. Anschließend habe ich die Höhenwerte (das BMP ist eine Karte) anhand Rotwerte eines Schwarzweißbildes der BMP ermittelt und somit das Gitter verformt, damit es plastisch wird. Meine follgende Aufgabe ist es, dass ich die Normalen zu jedem Knotenpunkt Berechne und dabei wird folgende Funktion vorgegeben: set_normal(int x, int y);

Mit Hilfe dieser Funktion und einer zusätzlichen - get_heightmap_value(int x, int y); -, bin ich in der Lage den genauen Knotenpunkt (Vertex) zu ermitteln. Allerdings fehlt mir an der folgenden Stelle die Idee, wie ich aus dem einen gegebenen Punkt an die beiden Vektoren komme, mit deren Hilfe ich die Normale über das Kreuzprodukt berechnen kann.

Hier mal die Funktion, wie sie bisher aussieht und keine richtigen Ergebnisse liefert...



Ich würde mich über Hilfe sehr freuen. Tips wären auch schon ganz hilfreich

Danke schonmal

Schau dir mal diesen Shader an, der macht (unter anderem) genau das was du möchtest:
http://wiki.delphigl.com/index.php/shader_Terrain_GPU4



Die Variable coords ist dein (x,y). Das "texelFetch2DOffset(...).a" ist quasi dein get_heightmap_value, was an der Stelle coords + offset die Höhe zurück gibt. Der Offset ist das jeweils +1 oder -1....das was da mit ivec2 angegeben ist. Letztlich ist wird der Durchschnitt der Normalen der 6 umliegenden Dreiecke berechnet.

Tipp: Mal es dir auf einem Blatt Papier auf was da berechnet wird.

Du musst die Idee jetzt nur noch in deinem Code umsetzen


=> Das ganze gibt "weiche" Normalen....d.h. das Terrain sieht dann schön rund aus.

_________________
Yeah!

Erstmal vielen Dank! Habe das ganze jetzt so in meinem Programm liegen und das sieht schonmal wesentlich besser aus als mein Gefummel vorher! Hier mal mein Code:



Allerdings wirkt das nicht wirklich "smooth", man sieht immernoch sehr stark, dass die beleuchtete Fläche grob in Vierecke aufgeteilt ist. Gibt es an meinem Code noch etwas zu verbessern?

Die Sache mit dem aufmalen hatte ich mir auch schon vorgenommen und das versucht umzusetzen, damit wurde mir dann klarer, was das Codefragment wirklich macht/machen soll.

Deine vectors-Array enthält die umliegenden Vertices, nicht aber den Vektor vom zentralen Vertex zum jeweiligen Vertex. Du bildest ein Kreuzprodukt von Punkten....nicht von Vektoren! Der Vektor von Punkt A zu Punkt B ist "B - A".

Du musst von jedem Vertex in deinem vectors-Array nochmal den zentralen Vertex abziehen. Bei mir ist diese Subtraktion und auch die Skalierung mit dem Faktor terrainscale quasi integriert, da ich für die x und z Koordinate direkt -1 bzw. +1 einsetze. Nur für die y-Koordinate (bei dir ist das z) muss die Subtraktion und Skalierung noch durchgeführt werden. Der Code ist halt ein wenig optimiert.

So müsste es gehen:



Des weiteren ist es möglich das deine Wahl der Dreiecke (das Quad muss ja irgendwie geteilt werden) nicht mit meiner übereinstimmt:

_________________
Yeah!

Nochmals vielen Dank!

Habe deine Variante mal getestet (hatte vorher auch noch mit der Höhe als Element in der Erzeugung der Vektoren rumprobiert) und festgestellt, dass unsere beiden Ansätze identisch aussehen. Wird dann wohl mit der Reihenfolge der Knoten zu tun haben.

Ich kann dir ja mal meinen STRIP zeigen, den ich verwende:

Screenshot?


Nein, das sollte kaum merkbare Einflüsse haben. (Zumindest sofern du ähnlich viele Dreiecke hast wie hier)


Wo wird den da die Normale gesetzt? Ich würde sagen das muss so aussehen:



P.S. Wenn du dein Terrain so renderst....wundere dich nicht wenn das EXTREM langsam ist. Aber erstmal überhaupt zum laufen kriegen....dann optimieren.

_________________
Yeah!

Du hattest recht, es lag am Setzen der Normalen bei der Erstellung des Gitters. Vielen Dank

Nun würde mich aber auch interessieren, wie man das ganze so rendern kann, dass das wesentlich schneller geht Ich habe da mal was von DisplayListen gelesen, könnte das damit zusammenhängen?

Jein

Optimierungen sind sortiert nach Effektivität, nach unten wird es besser:

1. Du renderst immer nur zwei Dreiecke gleichzeitig! Benutze GL_TRIANGLES und rendere das gesamte Terrain in einem Rutsch. Jeder glBegin-Aufruf hat einen gewissen Overhead...also möglichst viel auf einmal rendern.
2. Natürlich sollte man es vermeiden Dinge zu rendern die nicht sichtbar sind. Teile daher dein Terrain in Blöcke von 32x32 oder 64x64 Quads. Für jeden dieser Blöcke berechnest du im voraus eine BoundingBox und prüfst diese vor dem Rendern auf Sichtbarkeit. Bei einem großen Terrain sollte man diese BoundingBoxen zusätzlich in einer Baumstruktur anordnen (oder einer anderen für diesen Fall geeigneten Suchstruktur, etwa einem Grid)
3. Packe jeden Block in eine Displayliste. Damit müssen deine Vertexdaten nicht in jedem Frame erneut auf die Grafikkarte hochgeladen werden. Das kostet verdammt viel Zeit!
4. Vergiss die Displaylisten und nimm gleich VertexbufferObjects (VBO). Du kannst auch alle Blöcke in einen einzigen VBO packen und jeweils nur den entsprechenden Bereich rendern.
5. Bei der Verwendung von VBOs kannst du nämlich einen Indexbuffer (auch Elementbuffer) benutzen. Das reduziert die Vertexmenge auf etwas mehr als 1/6. Allerdings wird zusätzlich der Indexbuffers mit 12 Byte pro Dreieck gebraucht. Lohnt sich vor allem wenn du noch Texturkoordinaten verwenden willst.
6. Benutze einen Vertexshader der dir die Vertexdaten zur Laufzeit aus der Heightmap (als Textur) berechnet. Damit reduzierst du den benötigten Grafikspeicher nochmals massiv. Angenommen dein Terrain hätte eine Größe von 4096x4096 und jeder Vertex benötigt Position, Normale und zwei Sets von Texturkoordinaten (40 Bytes pro Vertex), dann würde selbst bei Verwendung eines Indexbuffers 640 MB Grafikspeicher benötigt. Dumm nur das viele Grafikkarten nur 512 oder gar 256 Mb haben! Mit dem Shader könntest du den Speicherverbrauch auf etwas mehr als 32 MB drücken. Das ganze ist hier beschrieben: http://wiki.delphigl.com/index.php/shader_Terrain_GPU4

Ausgehend vom genannten 4096x4096 Terrain mit 40 Byte pro Vertex:
Bei Punkt 1 liegt die Datenmenge bei 3.75 GB und wird in jedem Frame erneut zur Grafikkarte übertragen. Selbst mit der aller neuesten Hardcore-Grafikkarte wirst du nie mehr als eine handvoll FPS bekommen, der PCI-Express-Port gibt einfach nicht mehr her. Bei Punkt 6. haben wir das auf ca. 33 MB reduziert....die zudem permanent im Grafikspeicher liegen. Nur die eigentlichen Renderbefehle werden noch übertragen.

_________________
Yeah!

Oh Wow!

Dann gibts in der Hinsicht ja noch jede Menge zu lernen Werde mir deine verlinkten Artikel mal duchlesen und mich schlau machen, was die ganze Sache angeht

Jetzt muss ich aber erstmal weiter an den mir gestellten Aufgaben basteln, damit ich das dann zeitnah abgeben kann.

Nochmals vielen Dank!

schau außerdem mal hier rein das könnte sehr hilfreich sein...

_________________
Meine Homepage

Ich behaupte jetzt nicht das komplett gelesen zu haben, aber ich sehe irgendwie keinen Zusammenhang mit einem 3D-Terrain? Wie da auch steht ist das eine Technik die man benutzt wenn man nur wenige Mhz Rechenleistung zur Verfügung hat....im Gegensatz zu den heute üblichen 2-3 GHz. Heute hat eine Kaffeemaschine ja schon bald mehr Rechenleistung. Relevanz?

_________________
Yeah!